3D Secure Guide
3D Secure reduces the risk of the unauthorized use of a cardholder account, and makes online shopping better and safer for both buyers and sellers on the web.
The service enables card issuers to verify a cardholder's identity and provide results to the merchant in real-time during the checkout process. This reduces the merchant's exposure to fraud and disputes, and protects the cardholder from fraudulent use of their credit card.
COPYandPAY
For users of COPYandPAY, minimal additional effort is required compared to the current integration. The widget will handle the entire additional communication and will be responsible for collecting required browser based information automatically.
Server to Server
For users who are integrating via server to server will need to follow EMVCo's guidelines on the frontend integration. When you are using the Server-to-server solution, you need to make sure to handle the 3D Secure response correctly, as it might be different to how the response is handled in case of a payment transaction without 3D Secure. Please refer to "Step 2" on our Server-to-Server 3D Secure tutorial.
Browser-based vs app-based 3D Secure
We have to make a distinction between 3D Secure authentication performed in a web browser and in a mobile app.
If the 3D Secure is performed in a web browser, then the standard integration applies, where the processing is being done via our 3D Secure Server.
However, if the transaction is performed in an Android or iOS app, then the 3D Secure SDK should be used which is built to handle the app-based flow. This applies even if the mobile app is using a WebView component instead of native components. Performing a browser-based 3D Secure transaction inside a WebView could work in some instances, but it is not supported officially by EMVCo. This type of integration is not guaranteed to work, and will lead to increased 3D Secure failures.
Features
Depending on your business, you can take advantage of a number of features 3D Secure authentication offers.
Exemptions can be used to reduce friction during cardholder authentication. The Open Payment Platform offers a simple way to handle these use-cases.
- As a passthrough each merchant can determine which exemption to use.
- As an addition to transaction processing the Open Payment Platform determines if an exemption is applicable and applies it to the payment transaction.
- As a standalone service the Open Payment Platform determines if an exemption is applicable and returns the suggested exemption flag.
Non-payment authentication (NPA in short) offers the option to authenticate the shopper even when there is no payment transaction happening and in cases when the transaction amount is not known.
- During card tokenization if there is no payment amount present, NPA will apply.
- During a payment transaction NPA can be used if the amount is not known of it is zero
Mastercard has defined a custom authentication message category called Identity Check Insights, formerly called Data Only. It provides the merchant with the flexibility to share cardholder data through the EMV® 3DS rails to influence an issuer’s decision to approve a transaction without requesting authentication and thus with no risk of cardholder challenge and added latency.
3RI authentication stands for 3DS Requestor Initiated Authentication. This is an authentication method where the cardholder is not present and the transaction is initiated by the merchant. This type of authentication is mainly used to get the status of an already authenticated transaction in case of delayed shipments, recurring transactions, or merchant initiated transactions.
Decoupled Authentication is an authentication method whereby authentication can occur independent from the cardholder’s experience with the 3DS Requestor (merchant). During decoupled authentication the shopper will not do the authentication during the challenge flow in the iframe on the merchant's website, but separately via a mobile application for example.
To request a decoupled authentication from the issuer, send the threeDSecure.decoupled=true field with the request. Please be aware that not all issuers support decoupled authentication. In case it's not supported, the transaction will be authenticated with the normal workflow.