The Apata 3DS Server implements the EMVCo 3DS protocol, allowing merchants and payment platforms to authenticate cardholders during online payments.
How it Works
A typical authentication flow runs through calls to the following three endpoints:
-
Version (
POST /api/v1/version)Determine which 3DS protocol versions the cardholder's issuer and card support. The returned values are used to set the
messageVersionin the AReq (authentication request). -
Authenticate (
POST /api/v1/authenticate)Provide transaction and cardholder data and initiate authentication flow. You will receive an ARes (authentication response) containing either:
- a frictionless result — authentication completed. Includes an authentication value to be used during authorisation.
- a challenge result — the issuer has elected to verify the cardholder directly.
-
Result (
POST /api/v1/result)To be used for challenge flows only. The ARes contains everything required for authorisation in frictionless flows. After the cardholder completes the challenge, call to retrieve the final authentication outcome.
Start Integrating
Start in Test Mode. The test endpoints (/test/v1/...) behave exactly like their live counterparts but return predictable responses driven by a set of test cards, so you can build and validate your entire integration, including frictionless approval, the full challenge flow, and error handling without processing a real payment.
Only once every scenario behaves as you expect, going live is just a simple configuration change! Swap your test mTLS certificate for a production one created with Apata, and update the base paths from test to live. No changes needed for your request or response handling!
Supported 3DS Versions
The Apata API supports 3DS versions 2.2.0 and 2.3.1. The version should be set on the AReq using the messageVersion field. Response structure is determined by the chosen version, with some fields being 2.3.1 specific and populated only for 2.3.1.
🔒 Authentication
All Apata 3DS Server API endpoints are protected by mutual TLS (mTLS). There are no API keys or bearer tokens, your identity is established by the client certificate presented during the TLS handshake.
POST /api/v1/authenticate, /api/v1/version, /api/v1/result, reject any request that does not present a valid, registered client certificate. Your mTLS cert will be issued during onboarding.