3DS 2.0 in Checkout
Introduction
This page aims to describe the flow of 3DS2 to merchants who are using the PXP Financial Hosted Payment Pages (Checkout).
Merchants using both Checkout and Backend2Backend
The information on this page is relevant for merchants using the PXP Financial Checkout (getRedirectData). In case that the merchant also uses Backend2Backend (initiatePayment), for example, to process card on file transactions or merchant initiated transactions (MITs), please refer also to the other sections referenced in the 3DS 2.0 Information Hub.
In general, the PXP Financial Checkout handles the 3DS2 process without additional intervention by the merchant.
However, to take advantage of 3DS, redirect merchants should consider sending additional information for risk assessment by issuers. The more information is sent, the higher the chance for frictionless authentication, without further user interaction, to complete authentication.
Process Overview
- Merchant sends getRedirectData (and if applicable includes new optional 3DS2 relevant parameters)
- Merchant redirects the customer to the PXP Checkout page
- Customer enters his card details and confirms the payment
- PXP Checkout collects Browser information and performs Device Fingerprinting
- PXP Checkout communicates with PXP backend to initiate SCA through 3DS2
- During authentication, Checkout asks the customer for the authentication data
- Authentication is done and if successful payment will be authorised either through the frictionless or challenge flow
- The customer is redirected as usual to the merchant success or error page
Pre-requisites
- You must have a test account set up for use with PXP Financial
- If you are an existing merchant you should already have a fully integrated redirect integration in place (using the PXP Financial Checkout)
- If you are a new merchant please refer to the Initiate New Payment (Redirect) section
Additional Information in getRedirectData
The getRedirectData request has been extended with new fields applicable to 3DS2. Existing merchants should consider extending their existing integration and send these fields in addition to those that they usually send. The more information is sent and provided to the Issuer, the higher the chance for frictionless authentication.
Visa Secure Data Requirements
As of 12 August 2024, Visa will require the following fields:
- One of the following - Cardholder Email/Cardholder Work Phone/Cardholder Home Phone/Cardholder Mobile Phone
In addition to this, providing all Cardholder Billing Address information in the userData.address element is highly recommended
Browser information
Issuers require also different Browser information to be transmitted. This information is collected by the Checkout and cannot/need not be sent by the merchant in the getRedirectData request.
The table below lists the 3DS2 fields that can be sent in getRedirectData. These fields should be provided in getRedirectDataRequest.additionalData.
| Field | Description |
|---|---|
| CardholderEmail | Email address of the cardholder |
| CardholderHomePhone | Home phone number provided by the cardholder. Expected format: <country_code>-<telephone_number>. <country_code> must be up to 3 digits. <telephone_number> is up to 15 digits. Example: 359-453921233 |
| CardholderMobilePhone | Mobile phone number provided by the cardholder |
| CardholderWorkPhone | Work phone number provided by the cardholder |
Example getRedirectDataRequest using the new parameters correctly:
<getRedirectDataRequest xmlns="http://www.cqrpayments.com/PaymentProcessing"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<merchantID>KalixaAcceptDEMO</merchantID>
<redirectParameters xsi:type="paymentMethodDetailsRedirectParameters">
<shopID>KalixaAcceptDEMO</shopID>
<httpMethod>GET</httpMethod>
<returnUrl>http://www.merchantwebsite.com/Return?orderID=10203040</returnUrl>
<languageCode>EN</languageCode>
<currencyCode>GBP</currencyCode>
<countryCode>GB</countryCode>
<additionalDetails>
<detail xsi:type="keyStringValuePair">
<key>SkinID</key>
<value>06c46a30-f882-4ba9-b9d2-628ea5aa617d</value>
</detail>
<detail xsi:type="keyStringValuePair">
<key>Description</key>
<value>Order Description</value>
</detail>
<detail xsi:type="keyStringValuePair">
<key>CardholderHomePhone</key>
<value>044-3069990672</value>
</detail>
<detail xsi:type="keyStringValuePair">
<key>CardholderMobilePhone</key>
<value>044-3069990836</value>
</detail>
<detail xsi:type="keyStringValuePair">
<key>CardholderWorkPhone</key>
<value>044-3069990707</value>
</detail>
<detail xsi:type="keyStringValuePair">
<key>CardholderEmail</key>
<value>[email protected]</value>
</detail>
</additionalDetails>
<user>
<id>KalixaTestUser_3</id>
<username>johndoe</username>
<firstname>John</firstname>
<lastname >Doe</lastname>
<currencyCode>EUR</currencyCode>
<languageCode>EN</languageCode>
<email>[email protected]</email>
<address>
<street>Lombardia</street>
<houseNumber>88</houseNumber>
<postalCode>9999</postalCode>
<countryCode2>AT</countryCode2>
<telephoneNumber>00437778889999</telephoneNumber>
</address>
<dateOfBirth>1995-10-10T00:00:00</dateOfBirth>
<gender>Female</gender>
</user>
<merchantTransactionID>20141211_2</merchantTransactionID>
<grossAmount>33.00</grossAmount>
<expirationTimeSpanInSeconds>900</expirationTimeSpanInSeconds>
<successUrl>http://www.merchantwebsite.com/success?orderID=10203040</successUrl>
<pendingUrl>http://www.merchantwebsite.com/pending?orderID=10203040</pendingUrl>
<errorUrl>http://www.merchantwebsite.com/error?orderID=10203040</errorUrl>
<cancelUrl>http://www.merchantwebsite.com/cancel?orderID=10203040</cancelUrl>
<refusedUrl>http://www.merchantwebsite.com/refused?orderID=10203040</refusedUrl>
<paymentMethodID>2</paymentMethodID>
<isPaymentMethodChangeAllowed>false</isPaymentMethodChangeAllowed>
</redirectParameters>
</getRedirectDataRequest>
Device Fingerprinting handled by Checkout
As part of the 3DS2 flow, device fingerprinting information has to be provided to the Issuers. This is done automatically by the PXP Financial Checkout.
The Issuer’s ACS should usually respond to the Checkout Fingerprinting request within 10 seconds.
If the response is not received within that time frame, Checkout considers the fingerprinting as not successful and will continue with the 3DS process without the fingerprint information.
Do not use Sandbox attribute in iFrame
If the merchant is displaying the PXP Financial Checkout in an iFrame, then the merchant iFrame must not use the Sandbox attribute!
Fingerprint testing
To test the fingerprinting time-out scenarios in Checkout, the following card numbers can be used:
| Scenario | Card Number | Details |
|---|---|---|
| 10 seconds delay | 4268845149926716 | A simulated ACS response will be received in Checkout after 10 seconds, this will lead to a time-out situation and the 3DS check would be done in Checkout without fingerprinting information. |
| 9 seconds delay | 4268845149926708 | A simulated ACS response will be received in Checkout after 9 seconds. This should not cause a time-out situation and 3DS would be done with fingerprinting information. |
| 11 seconds delay | 4268845149926690 | A simulated ACS response will be received in Checkout after 11 seconds, this will lead to a time-out situation and the 3DS check would be done in Checkout without fingerprinting information. |
Version History
| Date | Description |
|---|---|
| 01.09.2019 | Original version |
| 17.01.2024 | Removed references to 3DS1, added new Visa Secure requirements, minor formatting |
Updated over 1 year ago