3D Secure Version 2.2

Required Data: Browser Info & Billing Address

To allow the card issuer to determine whether a challenge is needed, additional authentication context must be sent in the payment request. This includes:

• Cardholder billing address (Address1, City, PostCode are mandatory)

• Browser information required to correctly render the challenge window

• A NotificationUrl, used to return authentication results from the ACS/PSP

"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: The NotificationUrl is automatically appended with 3DS transaction details and is used to deliver authentication results back to your platform.

BACK TO TOP   ⇧

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 (null/empty/missing) 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.

When risk is low or a valid exemption applies, the issuer may approve authentication without challenging the cardholder.

BACK TO TOP   ⇧

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 contain 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.

BACK TO TOP   ⇧

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.

BACK TO TOP   ⇧

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=3 testing:
  CVV: 289
  ExpiryDate: 1229
  Amount: Between 1-24.99

  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=3 testing:
  CVV: 672
  ExpiryDate: 0129
  Amount: Between 1-24.99

  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 – MMYY 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.

BACK TO TOP   ⇧