3D Secure provides a layer of protection against fraudulent payments that is supported by most card issuers. The upcoming Strong Customer Authentication regulation in Europe requires the use of 3D Secure for card payments. Unlike regular card payments, 3D Secure requires cardholders to complete an additional verification step with the issuer. Typically, this involves showing the customer an authentication page on their bank’s website, where they are prompted to enter a password associated with the card or a verification code sent to their phone. This process is familiar to customers through the card networks’ brand names, such as Visa Secure and Mastercard Identity Check.

Example of a 3D Secure 2 flow

When to use 3D Secure

When a customer uses 3D Secure to authenticate a payment, the card issuer assumes full responsibility. As such, Stripe users are covered by a liability shift against fraudulent payments that have been authenticated with 3D Secure.

Although 3D Secure protects you from fraud, it requires your customers to complete additional steps during the payment process that could impact their checkout experience. For example, if a customer does not know their 3D Secure information, they might not be able to complete the payment.

When considering the use of 3D Secure, you might find the right balance is to use it only in situations where there is an increased risk of fraud, or if the customer’s card would be declined without it. In these cases, Stripe has default rules you can use to trigger 3D Secure.

Disputed payments and liability shift

Payments that have been successfully authenticated using 3D Secure are covered by a liability shift. Should a 3D Secure payment be disputed as fraudulent by the cardholder, the liability shifts from you to the card issuer. These types of disputes are handled internally, do not appear in the Dashboard, and do not result in funds being withdrawn from your Stripe account.

Liability shift can also occur if the card or issuer isn’t enrolled in 3D Secure but the type of card could support 3D Secure (e.g., most Visa and Mastercard consumer cards). During the payment process, the cardholder isn’t prompted to complete 3D Secure authentication, since the card is not enrolled. Although the cardholder did not complete 3D Secure authentication, liability still shifts to the issuer.

There are certain circumstances where payments that are successfully authenticated using 3D Secure do not experience a liability shift. This is rare and can happen, for example, if you have an excessive level of fraud on your account and are enrolled in a fraud monitoring program.

Although payments that have been successfully authenticated using 3D Secure cannot be disputed as fraudulent with an upfront financial chargeback, issuers may initiate a retrieval request. This type of dispute is non-financial, and is basically a request for information.

It’s important to note that responding to retrieval requests is important for any charge, but is vital when a 3D Secure-authenticated charge is involved. Although the cardholder’s bank is not allowed to file an upfront financial chargeback for fraud, they are allowed to initiate a financial chargeback if the merchant does not respond to the retrieval request, known as a no-reply chargeback. To prevent no-reply chargebacks on 3D Secure charges, be sure to submit sufficient information about the charge. You should include information about what was ordered, how it was delivered and to whom it was delivered (whether merchandise or services, etc.).

Incorporating 3D Secure authentication into your integration

Stripe’s new Checkout and the Payment Intents API natively support 3D Secure and trigger it automatically if required by a regulatory mandate such as Strong Customer Authentication. You can also use Radar rules to control when customers are prompted to complete 3D Secure authentication, making a determination for each user based on the desired parameters.

On the web, you have a few options for displaying 3D Secure:

• Checkout: Checkout automatically triggers 3D Secure in a modal when required without any additional work from you.
• Pre-built modal: The Payment Intents API integrates tightly with Stripe.js and Elements to simplify the authentication process. If your Stripe integration uses handleCardPayment or handleCardAction, Stripe.js automatically handles the authentication process—displaying a modal dialog where the customer can provide the requisite information.
• Full-page redirect: You can send the customer to complete authentication via a full-page redirect by manually handling 3D Secure authentication instead of using the pre-built modal.
• Customized UI: You can customize how and where the 3D Secure UI is shown with our guide.

With the iOS and Android Payment Intents API integrations, you can open the redirect URL in a native browser or in-app web view so the customer can complete authentication. In the coming months, we’ll also offer a native, customizable 3D Secure integration with our mobile SDKs.

To track whether 3D Secure was attempted on a card payment, you can read the three_d_secure property on the card information in the charge’s payment_method_details. The property is populated when 3D Secure is attempted on a charge, and three_d_secure.succeeded indicates whether 3DS authentication was successful.

Triggering dynamic 3D Secure authentication with Radar rules

3D Secure is automatically triggered if required by a regulatory mandate such as Strong Customer Authentication.

In addition, Stripe provides three default rules to dynamically request 3D Secure when using the new version of Checkout or the Payment Intents API. You can configure these 3D Secure Radar rules in your Stripe Dashboard. The following screenshot depicts these Radar rules, which request additional authentication from customers when the issuer of their card requires 3D Secure:

The first two rules are enabled by default. You can disable the default rules if you do not wish to apply them.

If you have Radar for Fraud Teams, you can add custom 3D Secure rules using the syntax described in our Rules reference. Radar requests 3D Secure authentication for payments that match these rules. In the example below, the enabled rule requests 3D Secure authentication for payment attempts where the amount of the payment exceeds $500 USD and the risk level is not considered normal.

Testing 3D Secure payments

Not all cards support 3D Secure or require the customer be redirected to their card issuer’s authentication page. Use the following card information to fully test 3D Secure payments.

All other Visa and Mastercard test cards do not require authentication from the customer’s card issuer.

Testing the authentication process

When you build an integration with your test API keys, the authentication process displays a modal with information about the API request. In that dialog, you can either authorize or cancel the payment. Authorizing the payment simulates successful authentication and redirects you to the specified return URL. Clicking on the Failure button simulates an unsuccessful attempt at authentication.

You can write custom Radar rules in test mode to trigger authentication on test cards. You can learn more about testing your Radar rules in our Radar documentation.

Next steps

Congratulations, you have learned about 3D Secure and performing dynamic 3D Secure authentication with Radar. For more information, refer to the following documentation:

• Checkout Overview
• Payment Intents Overview
• Payment Intents Quickstart
• Strong Customer Authentication