This guide summarises 3DS Version 2.3.1 relative to 2.2.0, and what that means in practice for your integration.
It is an incremental upgrade with the same overall browser flow and app flow as previously.
New fields or new values to existing fields are documented in the 3DS 2.3.1 API Changes.
There are many changes but the following are the most notable.
There have been additions to the API to allow you to send more information on your Authenticate Requests to the Schemes and Issuers. Ideally this should improve the chances of frictionless authentications.
Examples of new or enhanced functionality:
Likewise there have been additions on the API to return more information to you on Authenticate and Result responses.
Examples of new or enhanced functionality:
Device binding supports linking the Consumer Device used for a transaction to the Cardholder Account and/or Cardholder. Previously only one-time passwords (OTPs) were used. However now there is support for stronger cryptographic methods to be used such as biometrics or hardware tokens.
For the browser flow the ACS will generate a unique deviceId during the Method Request.
For the app flow the 3DS SDK will generate a unique deviceId during installation and persist it securely on device.
Subsequent authentications can then use device binding to facilitate a frictionless authentication from a trusted device.
Secure Payment Confirmation (SPC) is detailed in this dedicated guide.
Automated Out-of-Band (OOB) App Transitions: The SDK now natively supports seamless, automated app-to-app handoffs.
Device Binding Support: The SDK introduces the UI screens and underlying data elements required to ask cardholders if they want their current device to be “remembered.”
Trust List UI Updates: The SDK now includes updated configuration and UI rendering parameters for Trust List enrollment (asking the user if they want to trust the merchant for future purchases).
Decoupled Authentication Fallback: The 3DS ecosystem now supports mechanisms to trigger Decoupled Authentication as a fallback. If the standard challenge path fails or cannot render, the merchant app and ACS can gracefully pivot to an out-of-band method, allowing the app to bypass the SDK challenge UI and save the transaction.
Expanded Device Data Collection: The device parameters collected by the SDK have been updated to align with the latest privacy policies and APIs from Apple and Google, ensuring the SDK continues to capture a rich set of telemetry for the issuer’s Transaction Risk Analysis (TRA) without violating OS constraints.
The 2.3.1 specification proposes improvements on operational messaging, allowing the Schemes to communicate with the 3DS Servers and the Issuers’ Access Control Servers on any operational updates. These include messages of varying levels of criticality.
This provides us with greater visibility of the state of the 3DS2 ecosystem for proactive monitoring and remediation of any potential issues. Ultimately resulting in a more resilient 3DS2 experience for all parties.
Version 2.3.1 is not uniformly available by all Schemes and Issuers; as they begin to support it, this information appears in our Version Response.
Although version 2.3.1 may be listed in the availableVersions, we will not return 2.3.1 as a recommended version until you are ready.
If you are already using Ravelin 3DS for 2.1.0 & 2.2.0 authentication you will be required to make some very minor changes to your integration. We have developed the APIs in a backwards compatible way, to minimise the effort involved.
If you are looking to support 2.3.1, please reach out to your account manager.
There are only 2 new mandatory fields for 2.3.1 on the Authenticate request.
For all Authentications a value will be required for the acquirerCountryCode which you should be able to source from the acquirer.
For Authentications using the browser flow a value will be required for the acceptLanguage which shows the languages supported by the browser.
For Authentications using the app flow a value will be required for the sdkType which shows the type of 3DS SDK being used.
You will be able to test 2.3.1 authentications in our sandbox prior to enabling 2.3.1 support on your live account.
Please ensure the Integration team you are working with are aware you wish to support 2.3.1, and they will be able to enable the 2.3.1 functionality on your sandbox account.
Steps involved:
Was this page helpful?