paysafe developer

Introduction to 3D Secure

To download a French version of this guide in PDF, click here.

3D Secure version 1.0.2. is no longer actively supported by Paysafe. Although it is still functional, we recommend that all new and existing customers integrate into the new 3D Secure 2 API. This is mandatory for all European merchants, who must integrate to 3D Secure 2 by September 2019, and optional, but recommended, for those in other regions.

3D Secure adds an additional security layer for online purchases by requiring cardholders who are enrolled in either the Verified by Visa or the Mastercard SecureCode program to authenticate themselves, typically by providing a password. With 3D Secure, merchants can mitigate fraud while cardholders can enjoy additional security using their cards online. Paysafe is compliant to 3DS version 1.0.2.

A transaction using Verified by Visa or Mastercard SecureCode will initiate a redirection to the website of the card issuing bank to authorize the transaction. Each issuing bank could use any kind of authentication method (the protocol does not cover this) but typically, a password-based method is used. So, to effectively buy on the Internet means using a password linked to the card. The Verified by Visa protocol recommends the bank's verification page load in an iframe. In this way, the bank's systems can be held responsible for most security breaches.

For a full description of the 3D Secure API, including the requests supported and parameters required, see the 3D Secure API

Steps in 3D Secure Cardholder Authentication

Once you have set up a Paysafe merchant account, you can connect to the Paysafe Payments Platform with our simple-to-use API. See our Scenarios section for a quick overview of integration options when using the API. Here is a summary of the process:

3D Secure Process Flow

Step A: Check If Customer Is Enrolled in 3D Secure
  1. The merchant submits an Enrollment Lookup request on the cardholder PAN (card number) to the enrollmentchecks endpoint.

  2. Paysafe submits an enrollment lookup to the appropriate Visa or Mastercard directory server to identify whether the card is registered for 3D Secure.

    If the call to the directory server does not return within 10 seconds, a call is made to the secondary directory server.

  3. The response from the directory server is returned to Paysafe.

  4. Paysafe returns the enrollmentchecks response to the merchant. The response contains the threeDEnrollment flag. If threeDEnrollment = N, then the cardholder is not enrolled in the card issuer's 3D Secure scheme, so a normal payment authorization can be made using the Card Payments API. If threeDEnrollment = Y, then the acsURL and paReq fields are populated in the response and the customer must now be authenticated.

Step B: Authenticate Customer
  1. The merchant redirects the customer's browser to the acsURL returned in step 4 above, using an HTTP form POST. The content of this POST request needs to contain the payment authentication request value (PaReq—note capitalization), the merchant response URL (TermUrl—note capitalization), and an optional merchant data (MD) field that the 3D ACS server will return at the end of the cardholder authentication process.
  2. The 3D ACS server will post the merchant data (MD) and payment response (PaRes) parameter back to the TermUrl provided. At this stage, the customer has now been authenticated by the card issuer.
Step C: Validate Authentication Result with Paysafe
  1. The merchant posts an Authentication message containing the paRes parameter (note capitalization) returned from the ACS server and their merchantRefNum to the Paysafe authentication endpoint. The endpoint includes the enrollment_id that was returned in the original enrollment lookup request.
  2. Paysafe links the authentication to the customer's card and returns a response to the merchant, which contains the threeDResult, signatureStatus, eci, cavv, and xid parameters.
Step D: Make a Payment Authorization Request
  1. The merchant uses the Card Payments API to submit a payment Authorization request, containing the above values along with the original card details.
  2. Assuming these details are passed to the Card Payments API correctly and the card is 3D Secure authorized, fraud liability is typically shifted from the merchant to the bank.
  • Cardholder Authentication (3D Secure) is a recommended step which merchants should implement in regions where the 3D Secure scheme is prevalent, to reduce the risks of fraud and chargebacks.
  • If a customer is not enrolled in the 3D Secure scheme (enrollment lookup returns "N") merchants can immediately request a purchase authorization using the Card Payments API.
  • If a customer is enrolled in 3D Secure (enrollment lookup returns "Y") merchants should redirect the customer to the card issuer's 3D Access Control Server (ACS), where the customer will be authenticated. In many cases (e.g. low transaction amounts or customers identified by the bank as low-risk ) the card issuer will return a successful authentication response without requiring the customer to enter a user name and password, meaning a seamless process for the customer. Merchants will still benefit from liability shift and can then request a purchase authorization as described in steps 7–9 above.
  • If the response to a 3D Secure authentication is unsuccessful, merchants should consider asking the customer to resubmit their payment or pay using a different payment method. For more information see 3D Secure Results and Liability Shift.

Example of a 3D Secure Page

The figure below shows an example of the 3D Secure page as shown to customers. This page can be embedded in an iframe on your website.

Verified by Visa

3D Secure Page Example

Source: https://www.visaeurope.com/making-payments/verified-by-visa/

PREV NEXT
Did you find this page useful?