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.

3DS Protocol Versions

There are two main versions of the 3DS protocol, each with different characteristics and user experiences:

3DS 1.0.2 (Legacy)

The original version of the protocol, which redirects customers to their card issuer's website for authentication. After initiating enrollment, you must redirect the customer to their card issuer's authentication page using the URL provided in the response. Once the customer has authenticated with their card issuer, you call the validations endpoint to verify whether the customer has been successfully authenticated.

• Redirect-based authentication only

3DS 2.x (Modern)

The enhanced version of the protocol, which offers a frictionless experience by using risk-based authentication and only requiring additional steps when necessary. This is the most common flow.

• Frictionless Flow: The customer is authenticated behind the scenes without any additional action required. If the card issuer does not need to authenticate the customer, the authentication status is returned directly in the response with no further action needed.
• Challenge Flow: The customer is redirected to their bank to complete an extra verification step. If the card issuer needs to authenticate the customer, you must redirect them to their card issuer's authentication page for verification.

Regional availability

Below are the available payment methods that support 3DS authentication 2.0 in each country:

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 response from the initial enrollment call indicates the 3DS protocol version in use, which determines the subsequent steps.

This structured approach ensures that you handle both 3DS 1.0.2 and 3DS 2.x flows appropriately, guiding the customer through the necessary steps while validating their authentication status.

Frictionless flow steps

The frictionless flow allows authentication to occur behind the scenes without customer interaction when the card issuer determines that additional verification is not necessary.

1. First, you request an access token to authenticate your application with the GetNet API, which provides authorization for all subsequent API calls in the authentication process.
2. Next, you tokenize the customer's payment method data to securely convert sensitive card information into a token, ensuring the authentication process can proceed without exposing raw card data.
3. You then initiate enrollment by sending the enrollment initial request to check if the card is enrolled in a 3DS program and to determine which protocol version (3DS 1.0.2 or 3DS 2.x) is supported by the card issuer. This step returns important fields including transaction_id, xid, protocol, and status that will be used in subsequent calls.
4. After receiving the enrollment response, you confirm that the 3DS 2.x protocol is being used by checking the protocol field, which should indicate version 3DS 2.x (e.g., "3DS2.2.0"). This ensures the card supports the modern protocol that enables frictionless authentication.
5. With the protocol confirmed, you send an enrollments-continue request to complete the enrollment process and obtain the authentication result. For the frictionless flow, the response contains an EnrolmentContinueFrictionlessResponse object with the authentication data needed to proceed.
6. You then verify the authentication status by checking if the return status in the response is Authenticated, which confirms that the customer has been successfully authenticated without any interaction required.
7. Finally, you create the payment by sending a request that includes the authentication data (xid, eci, cavv, ds_trans_id) obtained from the authentication flow, allowing the transaction to be processed securely with verified cardholder identity.

Challenge flow steps

The challenge flow is used when the card issuer requires additional verification from the customer. The customer is redirected to their bank to complete an extra verification step.

1. First, you request an access token to authenticate your application with the GetNet API, which provides authorization for all subsequent API calls in the authentication process.
2. Next, you tokenize the customer's payment method data to securely convert sensitive card information into a token, ensuring the authentication process can proceed without exposing raw card data.
3. You then initiate enrollment by sending the enrolment initial request to check if the card is enrolled in a 3DS program and to determine which protocol version (3DS 1.0.2 or 3DS 2.x) is supported by the card issuer. This step returns important fields including transaction_id, xid, protocol, and status that will be used in subsequent calls.
4. After receiving the enrollment response, you confirm that the 3DS 2.x protocol is being used by checking the protocol field, which should indicate version 3DS 2.x (e.g., "3DS2.2.0"). This ensures the card supports the modern protocol.
5. With the protocol confirmed, you send an enrollments-continue request to complete the enrollment process and obtain the challenge payload. For the challenge flow, the response contains an EnrolmentContinueChallengeResponse object with redirect information needed to send the customer to their bank.
6. You then check if the return status indicates Pending Challenge, which confirms that customer authentication is required and that the card issuer needs to authenticate the customer directly rather than completing authentication behind the scenes.
7. Using the redirect_html_template provided in the response, you redirect the customer to the issuer's page for authentication, presenting the card issuer's authentication interface to the customer for identity verification.
8. After the customer completes authentication with their bank, they are redirected back to your site, allowing you to capture the payer authentication response from the card issuer.
9. You then send a validations request to verify the authentication outcome, which validates the payer authentication response received from the card issuer and confirms whether the customer has been successfully authenticated by checking if the return status is Authenticated.
10. Finally, you create the payment by sending a request that includes the authentication data (xid, eci, cavv, ds_trans_id) obtained from the authentication flow, allowing the transaction to be processed securely with verified cardholder identity.

Check the guide on how to create a 3DS authenticated payment to learn more about how to implement payments in both Challenge and Frictionless flows.

External 3DS flow steps

When using an external third-party 3DS solution, the authentication is handled outside of the GetNet API. You must then provide the authentication data when creating the payment.

1. The customer is redirected to the third-party solution and completes authentication, allowing them to authenticate using a third-party 3DS provider. This authentication occurs completely outside the GetNet system.
2. After authentication, you receive and extract the authentication response data from the third-party provider, which will be used for validation in the payment request. The response contains important authentication fields that must be captured:

   Field	Description
   tdsver	Indicates the 3DS protocol version used in the authentication (e.g., "1.0.2" or "2.2.0").
   xid	A unique identifier associated with a specific transaction generated in the 3DS flow, used to link the authentication to the payment transaction.
   ucaf	From the acronym Universal Cardholder Authentication Field, is a cryptographic value generated by 3DS 1.0.2 that proves the authentication was completed.
   eci	From the acronym Electronic Commerce Indicator, is a response code that indicates the outcome of the authentication attempted in a 3DS flow. Different values indicate different authentication levels.
   tdsdsxid	A transaction identifier generated by the 3DS 2.x protocol (equivalent to ds_trans_id), used to track the authentication in the newer protocol version.

3. When authorizing the payment with the GetNet API, you send the authentication properties to validate the external authentication data and process the payment transaction securely. The received information should be validated to ensure data integrity and authenticity before processing the payment. If the authentication fields are not provided, the transaction may be rejected depending on the issuer's configuration.