3D Secure Version 2.2
3D Secure 2 (3DSv2, also known as EMV 3DS) is the new industry standard for cardholder authentication and is a recognised solution for meeting PSD2’s Strong Customer Authentication (SCA) requirements.
Designed with the mobile checkout in mind, it introduces new flows that better suit cardholders paying on mobile devices with new authentication methods such as biometrics. It also introduces a Frictionless Flow where the cardholder is not challenged, when certain exemptions are meet.
SCA (Strong Customer Authentication) is a regulatory requirement introduced to reduce fraud and improve security of ecommerce transactions. It is essentially a two-factor authentication, where the cardholder is ‘challenged’ for authentication using two out of three of the below factors:
Something they know (e.g. passcode)
Something physical they have (e.g. a mobile phone or RSA token device)
Something biometric (e.g. a fingerprint or facial scan)
The following sections detail the changes to the initial payment requests, what the different authentications flows are and how to process a card issuer's challenge for cardholder authentication.
Browser Info & Billing Address
For the card issuer to make a more informed decision about if they wish to challenge the cardholder for authentication, the card issuer now requires additional details to be sent in the payment request. The additional content required is the cardholders billing address with Address line 1, City, Postcode as mandatory fields and the browser information shown below. The browser information is required so the card issuer can display their challenge page in the correct format, creating a better user experience.
"BillingAddress": {
"Address1": "1 The Boulevard,",
"Address2": "",
"Address3": "",
"City": " Welwyn Garden City",
"PostCode": " AL7 1EL",
"CountryCode": "GBR"
},
"browserInfo": {
"deviceCategory": "DESKTOP",
"acceptHeader": "*/*",
"userAgentHeader": "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1180.79 Safari/537.1",
"color_depth": "24",
"ip": "123.123.123.123",
"java_enabled": true,
"javascript_enabled": true,
"language": "en-US",
"screen_height": "1080",
"screen_width": "1920",
"challenge_window_size": "FULL_SCREEN",
"timezone": "0"
},
"NotificationUrl": "https://threedsreturnurl.free.beeceptor.com/",Note: You will also need to include a notification URL in your payment request which we append with 3D Secure transaction details and will be the url used to return the authentication results back to your platform.
Frictionless Payments
In a frictionless flow the Issuer can determine that no challenge is required to authenticate the transaction based on a valid exemption applied or they deem the transaction low risk.
When the cardholder is not challenged by the card issuer, you will receive an API response which does not contain any of the challenge details like the ACS URL or CRes. To proceed with these transactions however, you will still need to send a resume request as detailed below.
Exemptions
3D Secure v2 provides a framework for clients to benefit from Strong Customer Authentication (SCA) exemptions under certain conditions, such as payments below a certain risk threshold. An exemption from authentication for these "low-risk" transactions means the customer follows the Frictionless authentication flow and are not challenged for authentication.
Transactions that are also exemption from Strong Customer Authentication (SCA) are:
Merchant Initiated Transactions – Where you have an agreement (recurring/instalment) to take funds from a customer’s payment card.
Mail Order & Telephone Order (MOTO) – Where the channel is set to IVR/SMS/MOTO and the customer is not presented with a payment page.
Low Value Transactions – Where the value of the transaction is below £25 and the customer has not made 5 consecutive transactions up to the value of £100.
Challenge Authentication
Depending on what is returned in the payment request callback response will determine if the cardholder is challenged for Strong Customer Authentication:
If the response does not contains the AcsUrl then the payment is frictionless and you can resume immediately.
If the response contains either a CReq and PspId equals 2 or 3, or a ThreeDSServerTransId with PspId equal 1 then you are required to redirect the cardholder to the card issuer so they can challenge for authentication.
"TransactionId": 1000002556,
"PaReq": null,
"CReq": "eJxVUttuwjAMfd9XVHxAk/RCAZmgQtHGAxuiPGy...RBz77wNUXKtcXvnrcofdDAjUpSxyhTdQ1rsNiaokj0VWnpR10CKvhKxRcCp3dqBtHFTJ4U5WM+ZV0iA4CY16SfMem/A1pP3+QPIfS8/w==",
"PspId": 2,
"ThreeDSServerTransId": "3dad2cec-1d6e-40b8-8f12-510ac4c15321",
"AcsUrl": "https://3ds.issuingbank.com/",
"NotificationUrl": "https://threedsreturnurl.free.beeceptor.com?PayPointTransactionId=1000296765&PspId=1&ThreeDSServerTransId=3dad2cec-1d6e-40b8-8f12-510ac4c15321",
To allow the card issuer to challenge the cardholder for authentication you will need to create a page that redirects cardholder to the card issuer by doing a POST to the URL stated as ‘AcsUrl’ in both the guest payment and store card payment api callback. The data to be included in this redirect is now different depending on which PSP is processing the payment request.
When PspId equals 1 then the following details need to be POSTed to the card issuers ACS:
<form action="${AcsUrl}" method="POST">
<input name="transactionId" value="${ThreeDSServerTransId}">
<input name="notificationUrl" value="${NotificationUrl}">
<input name="MD" value="${TransactionId}">
</form>When PspId equals 2 or 3 then only the 'Creq' needs to be POSTed to the card issuers ACS:
<form action="${AcsUrl}" method="POST">
<input name="creq" value="${CReq}">
</form>The cardholder will then be presented with a Challenge Screen within the page that did the POST request. The new Challenge Screen will be compatible to the browser info sent in the payment request, and will ask for Strong Customer Authentication using two out of three of the below factors:
Something they know (e.g. passcode)
Something physical they have (e.g. a mobile phone or RSA token device)
Something biometric (e.g. a fingerprint or facial scan)
Upon the completion of the authentication of the cardholder the result will be posted back to the notificationUrl that was included in the payment request response.
The body of response of authentication will contain either an overallStatus or transStatus value depending on which PSP is processing the authentication process. We recommend that if the receive an overallStatus of '01'/'02'/'04'/'99' or transStatus of 'N'/'U'/"R" that you do not resume the transaction and inform the cardholder of the failed payment request.
Resume Request
When the cardholder completes a successful challenge for authentication with their card issuer your service will be POSTed back the authentication response to the notification URL that was stated in the initial payment request response.
The next step is to resume the suspended challenged transaction or the frictionless transaction, sending it for authorisation, this is made via the Resume API Request.
The 3DS Version 2 Resume Request contains only the PayPoint transaction id that you wish to resume in the request URL.
The transaction is then resumed and sent for authorisation with the result of the authorisation sent to the Callback URL in the body of the resume request. As the client you also have the option to include additional Callback URL(s) to inform your Third-Party service of the result of the transaction.
When a cardholder has been authenticated or an attempt has been successful then you are entitled to chargeback liability shift. Where a cardholder fails 3D authentication then we will automatically decline the transaction and not send the transaction for authorisation with their card issuer.
Test Cards
Below is a list of test cards which can be used when testing 3D Secure v2 functionality in the sandbox environment. The following test cards simulate various responses:
9908000000000004 – Force Challenge -Successful Authorisation, Card Type: VISA_DEBIT
For PSPid=1 – Returns the ThreeDSServerTransId and NotificationUrl needed to be Posted to the ACS URL (MPI Stub) to display the challenge authentication page. Upon a resume request you will receive a successful authorisations response.
For PSPid=2/3 - Returns the CRes needed to be Posted to the ACS URL (MPI Stub) to display the challenge authentication page. Upon a resume request you will receive a successful authorisations response.
9908000000000012 – Force Challenge -Unsuccessful Authorisation, Card Type: VISA_DEBIT
For PSPid=1 - Returns the ACS URL, ThreeDSServerTransId and NotificationUrl needed to be Posted to the PSP’s MPI Stub to display the challenge authentication page. Upon a resume request you will receive an unsuccessful authorisations response.
For PSPid=2/3 - Returns an error response in the callback.
9908000000000020 – Frictionless - Successful Authorisation, Card Type: VISA_DEBIT
For PSPid=1 - Returns the ACS URL, ThreeDSServerTransId and NotificationUrl needed to be Posted to the ACS URL (MPI Stub) which will automatically return the result to the notificationUrl without challenging the cardholder. Upon a resume request you will receive a successful authorisations response.
For PSPid=2/3 - Returns the ThreeDSServerTransId only and therefore can be resumed without displaying the challenge screen. Upon a resume request you will receive a successful authorisations response.
9908000000000038 – Frictionless - Unsuccessful Authorisation, Card Type: VISA_DEBIT
For PSPid=1 - Returns the ACS URL, ThreeDSServerTransId and NotificationUrl needed to be Posted to the ACS URL (MPI Stub) which will automatically return the result to the notificationUrl without challenging the cardholder. Upon a resume request you will receive an. unsuccessful authorisations response.
For PSPid=2/3 - Returns the ThreeDSServerTransId only and therefore can be resumed without displaying the challenge screen. Upon a resume request you will receive an unsuccessful authorisations response.
9908000000000079 – 3DS v2 Error/processing unavailable, Card Type: VISA_DEBIT
For PSPid=1 - Returns the ACS URL, ThreeDSServerTransId and NotificationUrl needed to be Posted to the PSP’s MPI Stub. This then displays the authentication failure message in the MPI Stub and returns the failure message back to the NotificationUrl.
For PSPid=2/3 - Returns an error response in the callback.
Cardholder Name – Alpha up to 150 characters
CVV – Numeric 3 characters
Expiry Date – MM/YY up to 8 years in the future.
Please Note: To test the 3DS process the account type must not be BillPay and that using 20.00 to 20.99 GBP as the transaction amount will create a Vend Failure response.