Scenarios

You can use the 3D Secure REST APIs to verify whether a credit card is enrolled for the 3D Secure service, and then, if it is, to authenticate that credit card when it is being used for an online purchase request. This enables you to process transactions through the Card Payments API that are fully 3D Secure.

See the scenarios below describing the steps in some typical 3D Secure API processes.

Scenario 1: Customer not enrolled in 3D Secure

This scenario illustrates the scenario where the customer is not enrolled in 3D Secure.

API to use:3D Secure API + Card API

3D Secure Scenario - not enrolled

3D Secure Scenario: Customer not Enrolled in 3D Secure

In the above scenario, the merchant uses the 3D Secure API to check if the cardholder is enrolled in 3D Secure. The response from the Access Control Server (ACS) returns "N" since the customer is not enrolled. In this case the merchant can proceed directly to an authorization request using the Card API.

Even though the customer has not been authenticated, you may still be protected by liability shift if you proceed with the transaction, however note that this is not always the case. For more information see 3D Secure Results and Liability Shift.

Scenario 2: Customer enrolled in 3D Secure and authentication is successful

This scenario illustrates a typical process where the cardholder is successfully authenticated by the card issuer.

API to use: 3D Secure API + Card API

3D Secure Scenario

3D Secure Scenario: Successful Authentication

In the above scenario, the merchant uses the 3D Secure API to check whether the cardholder is enrolled in 3D Secure. The response returns a threeDEnrollement value of "Y" and includes the termUrl to access the ACS Server and the PAReq (payment authorization request) parameter.

The merchant then redirects the customer's browser to the Access Control Server (ACS) — the authentication request includes the PAReq value. The server response contains the PARes (payment response) parameter and threeDResult (PARes status) of "Y" returned by the card issuer following a successful cardholder authentication. The PARes parameter is encrypted and must now be submitted to the Paysafe authentication endpoint for validation. Paysafe validates the authentication, extracting the Authentication object, which the merchant then includes when making an authorization request using the Card API.

Merchants will typically benefit from liability shift with a successful cardholder authentication, however note that this is not always the case. For more information see 3D Secure Results and Liability Shift.

Scenario 3: Customer enrolled in 3D Secure and authentication is unsuccessful

This scenario illustrates possible steps that can be implemented if the cardholder was not successfully authenticated. This could be because the authentication service was unavailable or the cardholder failed authentication.

Merchants should consider carefully what steps to take after an unsuccessful authentication. They will not benefit from the liability shift that typical comes with a successful cardholder authentication, and may be liable if the transaction is later deemed to be fraudulent by the card issuer. For more information see 3D Secure Results and Liability Shift.

API to use: 3D Secure API

3D Secure Scenario

3D Secure Scenario: Unsuccessful Authentication

In the above scenario, the merchant uses the 3D Secure API to check if the cardholder is enrolled in 3D Secure. The response returns a threeDEnrollement value of "Y" and includes the termUrl to access the ACS Server and the PAReq (payment authorization request) parameter. The merchant then redirects the customer's browser to the Access Control Server (ACS) — the authorization request includes the PAReq value. Since in this case the cardholder was not successfully authenticated, the PARes value in the response from the card issuer returns "N". It is recommended that the merchant does not proceed with the transaction.

Did you find this page useful?