3DS Authentication 2.0
What is 3DS Authentication?
3D Secure (3DS) is an authentication protocol designed to enhance the security of online transactions by verifying the identity of cardholders before a payment is processed. It reduces fraud and provides liability protection for merchants and issuers.
By implementing 3DS authentication, you can add an extra layer of security to your transactions and reduce the risk of fraud when processing payments.
Understanding 3DS 2.x Protocol
The 3DS 2.x protocol uses risk-based authentication to determine the appropriate verification method. The authentication flow is dynamically determined by many factors, including:
- Card brand and issuing bank
- Issuer's authentication infrastructure and capabilities
- Risk assessment performed by the card issuer
- Transaction characteristics (amount, location, device)
- Customer's authentication history
You must implement your integration to handle any of the possible scenarios that may be returned by the API based on these external factors.
Regional Availability
For detailed information about 3DS authentication 2.0 availability by country and supported card brands, see Core Cards - 3DS Authentication 2.0.
Important: For all transactions within the European Economic Area (EEA), 3DS authentication is mandatory in compliance with the Revised Payment Services Directive (PSD2) and Strong Customer Authentication (SCA) requirements. All card payments processed in Europe must be authenticated using 3DS, unless a valid SCA exemption is applied and accepted by the card issuer. For more information about SCA exemptions and how to apply them, see the Taxes and Regulations reference documentation.
How 3DS Works
The 3DS authentication process begins by initiating an enrollment flow to check if the card is enrolled in a 3DS program. The API response will indicate which scenario applies to that specific transaction based on the external factors mentioned above.
Possible Authentication Scenarios
status field returned from the enrollments-initial endpoint:Scenario 1: Direct Authentication (Attempt or Authenticated)
The authentication is completed immediately by the card issuer without requiring additional steps.
- Status returns as
AuthenticatedorAttempt. - Authentication data is immediately available.
ATTEMPT, you are responsible for determining whether the authentication is complete or if a challenge is needed.Scenario 2: Challenge After Initial Enrollment
The card issuer requires immediate customer authentication without additional processing.
- Status returns as
Pending Challenge. - The merchant has two options for redirection:
redirect_html_template: Render a provided HTML template directly in the application.acs_redirect_form: Perform a manual POST request using theaction_url,creq, andthreeDSSessionDataprovided in the response. This method is recommended for merchants who want to avoid external JavaScript and use custom transition screens.- After authentication, the validations endpoint must be called.
- The continue endpoint is not used in this flow.
Scenario 3: Pending Enrollment Continue
Additional processing is required before determining if authentication is complete or if a challenge is needed.
- Status returns as
Pending Enrollment Continue. - The enrollments-continue endpoint must be called.
- The continue response will then indicate either:
- Frictionless completion: Status becomes
AuthenticatedorAttempt. - Challenge required: Status becomes
Pending Challenge. In this case, the merchant can again choose to redirect the customer using either the provided HTML template or the ACS Direct Form object.
Key Takeaway
status field in API responses to determine which path the current transaction is following.External 3DS Authentication
In some cases, you may use an external third-party 3DS solution to handle authentication outside of the GetNet API. When using this approach, the authentication is performed by the third-party provider, and you must provide the resulting authentication data when creating the payment through GetNet.
When using external 3DS authentication, the process works as follows:
- The customer completes authentication through your third-party 3DS provider.
- You receive authentication response data from the third-party provider.
- You include this authentication data when creating the payment through GetNet's payment API.
Required Authentication Fields
When using external 3DS authentication, you must capture and provide the following fields from your third-party provider:
| Field | Description |
|---|---|
| tdsver | The 3DS protocol version used in the authentication (e.g., "1.0.2" or "2.2.0") |
| xid | A unique transaction identifier generated in the 3DS flow, linking the authentication to the payment |
| ucaf | Universal Cardholder Authentication Field - a cryptographic value proving authentication was completed (used in older 3DS versions) |
| eci | Electronic Commerce Indicator - a code indicating the authentication outcome and level |
| tdsdsxid | A transaction identifier generated by 3DS 2.x protocol (equivalent to ds_trans_id) |
Important Considerations
- Ensure data integrity and authenticity of authentication data received from the third-party provider before sending it to GetNet.
- Transactions may be rejected by the issuer if authentication fields are missing or invalid.
- The external provider must support the card brands and countries you operate in.
Next Steps
Now that you understand how 3DS authentication works and the different scenarios your integration must handle, you can:
- Implement 3DS authentication: Follow the Create a 3DS Authenticated Payment guide for step-by-step instructions, code examples, and best practices.
- Review API references: Consult the detailed API documentation for request parameters, response fields, and endpoint specifications:
On this page