3DS
Card payments with verification.
Three-Domain Secure or “3DS” is a messaging protocol merchants use to authenticate their customers’ card information when processing card-not-present (CNP) e-commerce or mobile purchases and payments. By enhancing authentication, 3DS helps prevent fraud and provides an additional layer of security for CNP credit card and debit card transactions. This service is provided by all four major card networks.
The latest version of 3DS is formally known as EMV 3DS (inclusive of versions 2.0, 2.1, 2.2, etc.), and EMV 3DS provides a much more streamlined, less intrusive customer experience than the prior 3DS 1.0 solution.
3DS Version Support
If you have not have fully migrated from 3DS 1.0 to newer versions, we can continue to process 3DS 1.0 transactions.
PSD2 Mandate
PSD2 requires all e-Commerce transactions to be authenticated unless SCA Exemptions apply.
3DS Payment Flow
1. Consumer intends to perform an e-commerce transaction using a payment card or token.
2. Invoke TabaPay 3DS SDK / API.
3. Cardholder's issuer authenticates consumer.
4. Risk-based authentication leads to a friction-free experience. With no additional consumer interference, issuer proceeds to authentication results.
5. When sufficient informaiton is not available to issuer for decisioning, issuer challenges consumer to authenticate (OTP, out-of-wallet question, etc.)
6. TabaPay relays result of 3DS authentication to the Client.
Benefits
EMV 3D Secure adds an additional layer of payment protection to online transactions. When 3DS is enabled during transaction, the cardholder is authenticated by the issuer. Typically, the cardholder is directed to an authentication flow on the issuer's website, and are asked to verify using means established by the issuer and cardholder.
While the major benefit of 3D Secure is to lower fraud, liability shifts from merchant to issuer for authenticated transactions.
Fraud Prevention
With an extra layer of security, CNP merchants will feel more confident knowing their data is rigorously authenticated. End users will likely not be aware during a frictionless transaction, unless they see a logo on the order page, which may provide the impression of added security.
Chargeback liability shifts
For an EMV 3DS authenticated transaction, liability most often falls with the approving issuing bank. Even if a cardholder claims a payment is not authorized, most of the time the card provider will be liable for managing refunds.
If an Issuer does not support EMV 3DS, Visa offers a stand-in processing service. MasterCard does not support this functionality.
Restricted MCCs for Liability Shift
Please note that the liability shift currently does not apply to Merchants using MCCs 4829 and 6051.
Lower Chargebacks
Based on current trends, merchants are benefiting significantly from fewer chargebacks which means more money in your pocket. Enabling EMV 3DS helps to mitigate the resources associated with disputes management, chargeback penalties and fees.
High authorization rates and lesser declines
Data shows that issuers approve more transactions when using EMV 3DS and it reduces false declines for both merchants and issuing banks.
Better user experience
The EMV 3DS solution supports exemptions under SCA (Strong Customer Authentication) requirements, so the customers experience the least possible amount of friction on applicable transactions reducing costs and cart abandonment.
How does 3DS compare with AVS or CVV2
CAVV returned by the Issuer is a cardholder device and merchant verification tool designed for e-Commerce. It provides a higher level of verification than either AVS or CVV2.
How 3DS Works
3DS uses XML messaging and SSL communication to secure and authenticate transactions.
| Transactions in EMV 3DS | Details |
|---|---|
| Frictionless Flow | If the data is satisfactory for the issuer to confirm that the actual cardholder is
making the purchase, the transaction will run through the “frictionless flow” which means authentication is
completed without the need for additional inputs from the cardholder. With EMV 3DS, there is a promise of friction-free payments 95% of the time when sufficient data is available to the issuer. |
| Challenge Flow | If the issuing bank requests further validation of the transaction, the cardholder’s transaction is routed through the “Challenge flow” which will ultimately prompt the cardholder to enter additional validation data (most often a One-Time Passcode) to authenticate the payment. |
TabaPay 3DS Solution
Browser-Based – In a browser-based EMV 3DS implementation, the transaction could go through either a frictionless or a challenge flow before the payment is authorized based on the issuer bank
Mobile Experience – For 3DS mobile experiences, TabaPay provides native app functionality via a 3DS SDK in tandem with our APIs. This functionality includes configuration for clients to match look and feel, perform 3DS cardholder authentication, collection of device data, and complete authentication. Available SDKs will assist merchants with implementation of the authentication protocol for their apps on Android and iOS platforms. For more information please look at our 3DS SDK guide.
For more information - Visit our how to use the 3DS APIs guide.
3DS Setup
The following is a breakdown of all potential EMV 3DS scenarios that TabaPay supports.
| Integration Scenario # | Client Integration | Supported Environments | Pre-Requisite |
|---|---|---|---|
| Scenario #1 | Integration with TabaPay SDK for Best-in-Class Mobile Experience | Mobile | • Sign up for TabaPay’s new EMV 3DS SDK and obtain the required credentials
(TabaPay facilitates this process). • Account ID will be required for 3DS APIs with TabaPay |
| Scenario #2 | Integration with TabaPay APIs only | Web | • Sign up for TabaPay’s new EMV 3DS API and obtain the required credentials (TabaPay
facilitates this process). • Account ID will be required for 3DS APIs with TabaPay |
Scenario 1: 3DS Mobile Experience using 3DS SDK
A 3DS mobile experience using our 3DS SDK offering allows you to incorporate the 3DS challenge flow into your application. Once the customer has submitted a payment request you can initiate a lookup, and if a challenge is necessary the SDK will manage it for you.
Scenario 2: 3DS Web Authentication with TabaPay
A 3DS web authentication flow begins with an initial payment request. A payment request contains the 3DS objects demonstrating that a 3DS authenticated payment is required.
Responses will be provided under three scenarios: payment is authorized without a challenge, challenge is required, or there’s been an error (if something goes wrong or the transaction is refused).
Merchants then handle the transactions based on the result codes.
Updated about 1 month ago