3D Secure Card Payments
Learn about 3D Secure, an additional layer of authentication that protects you from liability for fraudulent card payments.
3D Secure provides a layer of protection against fraudulent payments that is supported by most card issuers. The 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
Step 1: The customer enters their card details.
Step 2: The customer's bank assesses the transaction and can complete 3D Secure at this step.
Step 3: If required by their bank, the customer completes an additional authentication step.
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, handleCardAction or handleCardSetup, 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 add a native, customizable 3D Secure integration in your app. See our iOS and Android guides on supporting 3D Secure in your app.
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.
Manually triggering 3D Secure with custom logic
The default method to trigger 3D Secure is using Radar to dynamically request 3D Secure based on risk level and other requirements. Triggering 3D Secure manually is for advanced users integrating Stripe with their own fraud engine.
To trigger 3D Secure manually, set payment_method_options[card][request_three_d_secure] to any when creating or confirming a PaymentIntent or SetupIntent. This process is the same for one-time payments or future off-session payments. When this parameter is provided, Stripe attempts to perform 3D Secure and overrides any dynamic 3D Secure Radar rules on the PaymentIntent or SetupIntent.
When to provide this parameter depends on when your fraud engine detects risk. For example, if your fraud engine only inspects card details, you know whether to request 3D Secure before you create the PaymentIntent or SetupIntent. If your fraud engine inspects both card and transaction details, provide the parameter during confirmation—once you have more information. Then pass the resulting PaymentIntent or SetupIntent to your client to complete the process.
Explore the request_three_d_secure parameter’s usage for each case in the API reference:
Whenever 3D Secure authentication is available for a card, Stripe requires your customer to perform authentication to complete the payment successfully. If 3D Secure is not available for the given card, the payment proceeds normally.
Stripe’s SCA rules run automatically, regardless of whether you manually request 3D Secure. Any 3D Secure prompts from you are additional and not required for SCA.
Testing 3D Secure payments
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. Learn more about testing your Radar rules.
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: