3DS 2.0 in Checkout
Introduction
This page aims to describe the flow of 3DS 2.0 to merchants who are using the PXP Financial Hosted Payment Pages (Checkout).
Merchants using 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 for card on file transactions or merchant initiated transactions as recurring, also the other section of the 3DS 2.0 Information Hub.
In general, the PXP Financial Checkout handles the 3DS 2.0 process without any additional interference with the merchant and the merchant needs not do any implementation changes.
But, to take advantage of 3DS 2.0, 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 3DS 2.0 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
- Depending on the card enrollment the 3DS 2.0 or 1.0 process is applied and Checkout asks the customer for the authentication data (in case of 2DS2 and a frictionless flow, then the challenge is not done and the payment is authenticated immediately)
- Authentication is done and if successful payment will be authorised
- 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 3DS 2.0. Existing merchants should consider to extend 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.
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 optional 3DS 2.0 fields that can be sent in getRedirectData. All 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 that 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!
To test the fingerprinting time-out situation 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. |
Updated about 2 years ago