3D Secure 2: What a merchant needs to know about 3DS2
3D Secure (3DS) provides an additional layer of security for online transactions when consumers pay by credit card, adding an identity confirmation partner to the standard communication between acquiring and issuing banks.
3DS delivers real benefits to consumers (whose credit cards become harder to use fraudulently) and merchants whose exposure to chargeback fraud can drop like a rock. However, it also creates friction in the payment process, a potentially confusing user experience, and the risk of unanticipated fraud through identity theft in the initial 3DS registration (particularly the activation-while-shopping or AWS step.)
The “3D” stands for “3 domains” because this extra step involves adding a third participant in the payment process. In simple terms, when a transaction is sent to 3DS, the consumer must take an extra step to confirm their identity—usually a unique password entered into an interstitial page—even though they may have correctly entered all their information into the initial purchase form.
What is the purpose of 3-D Secure?
3DS has become an industry standard and is mandated in the EU and UK for all transactions; it is effectively mandatory in other geographies like Australia and India, where regulations require very strong identity confirmation.
3DS is not mandatory for merchants who strictly do business from and within the United States. 3DS has faced hard sledding in the United States, where businesses opt to avoid adding friction to the user experience. Recent data suggests U.S. issuers treat 3DS as a fraud signal, leading to lower authorization rates without challenging riskier transactions.
3DS enhances anti-fraud efforts. It was intended to prevent criminals from using stolen credit card numbers that the real owner did not know had been compromised, or from cards that the owner hadn’t realized had been stolen. By injecting another step into the transaction process, which, in principle, only the real cardholder would know how to fill out, the idea is to create a barrier to criminals successfully transacting deals.
While a criminal can complete an order form, potentially with literally every piece of data correct (perhaps by stealing a new card as it arrives in the mail), the secret that must be shared in the 3DS process would never be stored with the card, whether it be a login password or even access to a phone number to receive a one-time confirmation code.
This is great for consumers who don’t need to deal with tracking down fraudulent charges on their cards. In principle, it is also good for merchants because charges successfully completed on stolen credit cards are one of the largest sources of chargebacks: because the charge was not made by the account owner, pretty much by definition, the reversal process starts with the card network rather than the merchant.
Bearing in mind that having a significant chargeback rate can cost a merchant dearly in terms of fines and higher fees, reducing them is a win.
What is 3RI?
Merchant-initiated authentication, also known as requester-initiated authentication, is part of 3DS 2.2. 3RI is the process of an authorized merchant charging a customer’s credit card without direct involvement of the customer. Merchants can then process the transaction when the customer is not present, referencing prior authorization.
More information on Merchant Initiated Authentication 3RI.
Challenges for Merchants
While the benefits of 3DS are quickly identified, notably in the EU, where it’s mandated for all transactions, sadly, so are the challenges—specifically with the user experience.
For consumers, there is the frustration of being brought to an extra step. Adding the requirement to create a unique password, say, or to validate a personal phone number to receive text messages, can make the buying process overly long—and when 3DS only pops up from time to time, consumers often find they’ve forgotten the password and either have to go through the Lost Password process, or return to the order form to provide an alternative form of payment.
Generally speaking, 3DS is not a standard step in the checkout process but is triggered by a suspicion of fraud by one of the many payment services involved in the transaction process.
Each provider's automation—from acquiring bank, to PSP, to card network, to issuing bank—can spot a trend that raises suspicions even if none of its partners sees the same thing.
For instance:
- A particular transaction may seem unusually large to the issuing bank.
- The PSP flags the same person making more purchases than normal over a day.
- Another PSP might feel that mistyping the CVV once and then re-entering it is a good reason to worry about fraud.
Because 3DS involves adding a third party to the transaction, it received a fair amount of criticism for being both confusing and—ironically—an inspiration for other fraud. In some cases, a 3DS form will appear in an iFrame on a page that the consumer cannot confirm is properly SSL-encrypted or authentic.
Worse, there have been documented cases of hackers successfully injecting fake 3DS iFrames into legitimate order forms, allowing them to steal not only the cardholder information but also the 3DS credentials!
And given that 3DS will normally offer consumers arriving for the first time the opportunity to sign up on the spot (so-called activation-during-shopping, or ADS), it is possible for someone who has stolen an unenrolled credit card to take control of the 3DS requirements in place of the rightful card owner.
3DS2
The first version of 3D Secure was released more than 20 years ago. 3D Secure 2.0, or 3DS2 was released in 2016. All major banks switched from 3DS1 to 3DS2 in October of 2022.
3D Secure 2 (3SD2) is the main card authentication method used to meet Strong Customer Acquisition (SCA) requirements in Europe. 3D Secure 2 was released to address many of the shortcomings listed above with less disruptive authentication, leading to a better user experience.
3DS2 allows a business and its payment provider to send more data on each transaction to the cardholder’s bank, including payment-specific details like shipping address, customer device ID, or transaction history. This information can be used to assess the transaction's risk level.
- If the bank trusts the additional data, the transaction can go through a frictionless flow.
- If the bank needs further proof, the transaction can be asked for more information to authenticate the payment.
Enforcement of SCA makes 3DS2 all the more important if business is being done in Europe or even simply outside the United States. The improved user experience can help combat any negative impact on conversions.
Implementing 3DS
When a company wants to integrate 3D Secure into its system, it needs to account for two types of transaction flows.
Customer Initiated Transaction
Consider this when a customer actively participates in a checkout process. Once the customer enters the credit card information, the company authenticates the card and determines if a challenge is required. When a challenge is required, the customer is provided with a window to verify a password, username, etc.
Merchant Initiated Transaction
When a credit card is authenticated for a subscription service and charged after each period, 3DS is required to challenge the initial collection of the credit card, and each subsequent transaction can be facilitated using that approval.
Here’s more about why merchants choose Basis Theory and developer documentation to get started with APIs or SDKs.