generated: '2026-08-26'
method: searched
source: https://paymate.in/security.html; https://api.paymate.my/GlobalPartnerAPI; openapi/paymate-global-partner-api-openapi.yml
docs:
- https://paymate.in/security.html
- https://api.paymate.my/GlobalPartnerAPI
sector: payments
regulatory_regime: payments
standards:
- id: pci-dss
  name: PCI DSS
  conforms: true
  version: 3.2.1
  evidence: >-
    "PayMate operates on a validated PCI DSS 3.2.1 certified platform" — https://paymate.in/security.html.
    The page carries a ControlCase compliance seal (seal.controlcase.com, popup id 3637549589) naming
    ControlCase as the assessor. The claim is also made INSIDE the contract: the AddCard operation
    (POST /v1/AddCard) is described as "Businesses can tokenize their credit cards for secure transactions
    through Paymate Tokenize Card API. Only PCI certified customer can use this api" — i.e. the API gates
    raw-PAN submission on the caller's own PCI status.
  location: openapi/paymate-global-partner-api-openapi.yml#/paths/~1v1~1AddCard/post/description
- id: 3-d-secure
  name: 3-D Secure (EMV 3DS)
  conforms: true
  evidence: >-
    The AddCard response documented in PayMate's own endpoint dataset returns a FormData field containing a
    3-D Secure challenge form ("<title>3D Secure</title>", posting pspReference / PaReq / TermUrl to an
    Adyen threeDS2 endpoint) alongside StatusCode "Token creation in process". Card enrolment therefore
    carries an issuer authentication step the partner must render. The example in the docs points at Adyen's
    TEST checkoutshopper host, which also identifies Adyen as the acquiring processor behind card tokenization.
  location: openapi/_source/paymate-global-partner-api-my.json ("Add Card" -> response_code)
- id: iso-20022
  name: ISO 20022
  conforms: false
  evidence: >-
    No ISO 20022 message type (pain.001, pacs.008, camt.05x) appears anywhere in either API. Payments are
    described by domestic rail name (NEFT, RTGS, IMPS, EFT, ACH) with a proprietary JSON envelope.
- id: iso-9362-bic
  name: ISO 9362 BIC / ISO 13616 IBAN
  conforms: true
  evidence: >-
    BIC/SWIFT and IBAN fields are first-class parameters on the bank-account objects used by
    SetCollectionAccount, ContactBoarding, ModifyContact, ManageContacts, MakePayments, GetPaymentStatus,
    PaymentReport, CollectionStatus and CollectionReport, and Australia's dataset additionally carries BSB.
    Beneficiary identification follows the international identifier scheme rather than a PayMate-private one.
  location: openapi/_source/paymate-global-partner-api-my.json (BankAccountDetails)
- id: psd2-sca
  name: PSD2 / SCA
  conforms: false
  evidence: PayMate does not operate in the EEA/UK; no PSD2, SCA or open-banking claim is published.
- id: confirmation-of-payee
  name: Confirmation of Payee
  conforms: false
  evidence: >-
    No payee-name-check operation. PayMate does describe soft KYB/KYC and AML checks on suppliers and
    customers before payout (Introduction, Partner API docs) and exposes processbuyersupplierkyc, but that is
    an onboarding check, not a per-payment CoP.
- id: open-payments
  name: Open Payments
  conforms: false
  evidence: No Open Payments / Interledger surface.
- id: oauth2
  name: OAuth 2.0
  conforms: false
  evidence: Both APIs authenticate with issued header credentials; no OAuth 2.0 or OpenID Connect surface.
- id: oidc
  name: OpenID Connect
  conforms: false
  evidence: No /.well-known/openid-configuration on any PayMate host (all probed paths 404 — see well-known/).
- id: rfc9457
  name: RFC 9457 Problem Details
  conforms: false
  evidence: >-
    Proprietary envelope (RequestID / StatusCode / Description / DetailedSummary) with HTTP 200 on business
    failure. See errors/paymate-error-codes.yml.
- id: pagination
  name: Standard pagination
  conforms: false
  evidence: Report operations filter by date range only; no page/offset/cursor, no total count, no next link.
- id: idempotency
  name: Idempotency
  conforms: partial
  evidence: >-
    Mandatory partner-supplied RequestID on every operation and a client OrderID on payment/collection
    creation, with StatusCode 413 "OrderId already processed" rejecting duplicates. No Idempotency-Key
    header, no replay semantics, no retention window. See conventions/paymate-conventions.yml.
regulatory:
- regime: Reserve Bank of India — Payment and Settlement Systems Act
  claimed: true
  evidence: >-
    "PayMate is compliant as per Reserve Bank of India guidelines related to Payments and Settlements Act"
    — https://paymate.in/security.html.
- regime: India GST
  claimed: true
  evidence: >-
    GSTIN is a contact field on the India API and GST payment is a first-class product feature; 18% GST is
    applied to all published fees.
certifications:
- name: PCI DSS
  version: 3.2.1
  status: validated
  assessor: ControlCase
  source: https://paymate.in/security.html
  seal: http://seal.controlcase.com/ (popup id 3637549589)
  note: >-
    PCI DSS 3.2.1 was retired by the PCI SSC in March 2024 in favour of v4.0. PayMate's public page still
    names 3.2.1 and carries no visible assessment date, so the currency of the validation cannot be
    established from public material.
absent:
- No SOC 2 report, ISO 27001 certificate, HIPAA or FedRAMP claim is published.
- No trust centre, no compliance document portal, no published audit or pen-test summary.
- No security.txt, no vulnerability disclosure policy and no bug bounty programme (probed 2026-08-26).