High-level implementation
We have done our best to limit the impact of 3D Secure version 2 on your operations. This means that we've retained the existing 3D Secure flow and statuses as before. The impact has been reduced to API changes introducing new properties that you can provide to increase the likelihood of your transactions being authenticated using the frictionless flow.
Flow
Below flow shows the high-level flow of both version 1 and version 2 of 3D Secure. Please note that we show the browser flow specifically for 3D Secure version 2, as version 1 doesn't support anything apart from the browser flow. The functional flow between the two versions is the same from your point of view.
After the initial payment creation two flows are possible:
- Flow requiring the redirection of the consumer
- Flow not requiring the redirection of the consumer
The flow with the redirection for 3D Secure version 2 could potentially only involve a page that allows the issuer to collect data from the consumer's device without any user interaction. We've chosen to handle this flow on our hosted payment pages, in order to reduce the implementation impact.
Simply put, redirection won't always result in a so called Challenge towards the consumer, and could still be considered frictionless in the 3D Secure version 2 terminology. This is referred to as the MethodURL page in the 3D Secure version 2 documentation. This flow is handled on our hosted payment pages, to reduce the implementation impact on your operations.
The statuses for each of the flows are identical, with REDIRECTED for the flow that involves redirection, and all the other possible statuses, like REJECTED, PENDING_APPROVAL, CAPTURE_REQUESTED, etc. for the non-redirect flow.
See below image illustrating the 3D Secure specific status flow for the most common implementation (not using the 2-step 3D setup that requires explicit approval from your side to continue with the authorization).
Additional data elements
The key aspect of 3D Secure version 2 is the ability of the issuing bank to better assess the risk involved of the transaction. The specification of 3D Secure version 2 contains a lot of data elements, some of them were already commonly used in fraud screening. However, some are new and specific to 3D Secure.
Generally, the data elements can be categorized in the following categories:
- Card details
- Recurring information
- Unscheduled card on file information
- Link to a previous transaction with Strong Customer Authentication
- 3D Secure specific information
- Previous 3D Secure results
- Specific 'settings' for this transaction
- Transaction information
- Billing address data
- Shipping details
- Transaction channel
- Meta information on what the transaction is for
- Consumer
- Device/browser data
- Account of the consumer with you
- Authentication used
- Account on file
- Payment history
Our existing APIs already capture many of the data elements. However, we're adding many new data elements as well. We do this as we believe everybody in the payments ecosystem benefits from increased security, with the least amount of negative impact to the consumer.
Payments are based on trust and by providing more data it becomes easier for parties to trust one another, without requiring additional challenges to authenticate the consumer. Nearly all of the newly added data elements are optional, but we advise you to supply as much of them as possible.
This increases the likelihood of your transactions following the frictionless flow, while you benefit from liability shift. Should you use the MyCheckout hosted payment pages, we'll automatically capture the device/browser-related data.