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 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

    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 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.

    Number 3D Secure usage Description
    4000000000003220 Required 3D Secure 2 authentication must be completed for the payment to be successful. Use this card to test that your integration is ready to support Strong Customer Authentication requirements in Europe. By default, your Radar rules will request 3D Secure 2 authentication for this card.
    4000000000003063 Required 3D Secure authentication must be completed for the payment to be successful. By default, your Radar rules will request 3D Secure authentication for this card.
    4000008400001629 Required 3D Secure authentication is required, but payments will be declined with a card_declined failure code after authentication. By default, your Radar rules will request 3D Secure authentication for this card.
    4000000000003055 Supported 3D Secure authentication may still be performed, but is not required. By default, your Radar rules will not request 3D Secure authentication for this card.
    4242424242424242 Supported 3D Secure is supported for this card, but this card is not enrolled in 3D Secure. This means that if 3D Secure is requested by your Radar rules, the customer will not go through additional authentication. By default, your Radar rules will not request 3D Secure authentication for this card.
    378282246310005 Not supported 3D Secure is not supported on this card and cannot be invoked. The PaymentIntent will proceed without performing authentication.
    Token 3D Secure usage Description
    tok_threeDSecure2Required Required 3D Secure 2 authentication must be completed for the payment to be successful. Use this card to test that your integration is ready to support Strong Customer Authentication requirements in Europe. By default, your Radar rules will request 3D Secure 2 authentication for this card.
    tok_threeDSecureRequired Required 3D Secure authentication must be completed for the payment to be successful. By default, your Radar rules will request 3D Secure authentication for this card.
    tok_threeDSecureRequiredChargeDeclined Required 3D Secure authentication is required, but payments will be declined with a card_declined failure code after authentication. By default, your Radar rules will request 3D Secure authentication for this card.
    tok_threeDSecureOptional Supported 3D Secure authentication may still be performed, but is not required. By default, your Radar rules will not request 3D Secure authentication for this card.
    tok_visa Supported 3D Secure is supported for this card, but this card is not enrolled in 3D Secure. This means that if 3D Secure is requested by your Radar rules, the customer will not go through additional authentication. By default, your Radar rules will not request 3D Secure authentication for this card.
    tok_amex_threeDSecureNotSupported Not supported 3D Secure is not supported on this card and cannot be invoked. The PaymentIntent will proceed without performing authentication.
    Payment Method 3D Secure usage Description
    pm_card_threeDSecure2Required Required 3D Secure 2 authentication must be completed for the payment to be successful. Use this card to test that your integration is ready to support Strong Customer Authentication requirements in Europe. By default, your Radar rules will request 3D Secure 2 authentication for this card.
    pm_card_threeDSecureRequired Required 3D Secure authentication must be completed for the payment to be successful. By default, your Radar rules will request 3D Secure authentication for this card.
    pm_card_threeDSecureRequiredChargeDeclined Required 3D Secure authentication is required, but payments will be declined with a card_declined failure code after authentication. By default, your Radar rules will request 3D Secure authentication for this card.
    pm_card_threeDSecureOptional Supported 3D Secure authentication may still be performed, but is not required. By default, your Radar rules will not request 3D Secure authentication for this card.
    pm_card_visa Supported 3D Secure is supported for this card, but this card is not enrolled in 3D Secure. This means that if 3D Secure is requested by your Radar rules, the customer will not go through additional authentication. By default, your Radar rules will not request 3D Secure authentication for this card.
    pm_card_amex_threeDSecureNotSupported Not supported 3D Secure is not supported on this card and cannot be invoked. The PaymentIntent will proceed without performing authentication.

    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:

    Questions?

    We're always happy to help with code or other questions you might have. Search our documentation, contact support, or connect with our sales team. You can also chat live with other developers in #stripe on freenode.

    Was this page helpful? Yes No

    Send

    Thank you for helping improve Stripe's documentation. If you need help or have any questions, please consider contacting support.

    On this page