In October of 2022, all major card brands will stop supporting 3D Secure 1. Use of this API is no longer recommended. If you want to continue using 3D Secure, adopt the Payment Intents API. This new integration:
Stripe users in the United States, Canada, Europe, Hong Kong, Singapore, Japan, Australia, and New Zealand can process card payments that require authentication with 3D Secure(3DS) using Sources—a single integration path for creating payments using any supported method. Users in other countries that Stripe supports can request an invite.
The process for 3DS card payments begins in the same way as regular card payments with your integration first creating a Source object that represents the card information. Instead of using this source to make a charge request, it’s used to create a 3D Secure
Source object. Your customer is then potentially redirected to their card issuer’s website to verify their identity using 3DS.
After the 3DS process completes, your integration uses the 3DS source to make a charge request and complete the payment. You then have the option of saving the card information to use for future payments.
Within the scope of Sources, 3DS card payments are a pull-based, single-use and synchronous method of payment. This means that your integration takes action to debit the amount from the customer’s card and there is immediate confirmation about the success or failure of a payment.
Handling card information
Card information is sensitive by nature. Card sources must be created client-side using Stripe.js and Elements. This ensures that no sensitive card data passes through your server so your integration can operate in a PCI compliant way.
When your customer submits their card information using your payment form, it’s sent directly to Stripe, and a representative
Source object is returned for you to use. The process is similar to the creation of tokens. If you’re already using Elements to tokenize card information, switching to sources is only a small change.
Disputed payments and liability shift
Payments that have been successfully authenticated using 3DS are covered by a liability shift. If a 3DS payment is disputed as fraudulent by the cardholder, the liability shifts from you to the card issuer. These types of disputes are handled internally, don’t appear in the Dashboard, and don’t result in funds being withdrawn from your Stripe account.
If a customer disputes a payment for any other reason (for example, product not received), then the standard dispute process applies. As such, you should make the appropriate decisions regarding your business and how you manage disputes, if they occur, and how to avoid them completely.
When a customer successfully completes 3DS authentication, the value of
redirect.status is set to
three_d_secure.authenticated is set to
true. If the cardholder disputes the payment as fraudulent, liability has shifted to the card issuer.
Liability shift can also occur when 3DS 1 is required by the card network, but 3DS isn’t available for the card or issuer. This can happen if the issuer’s 3DS server is down or if the issuer doesn’t support 3DS, despite the card network requiring 3DS support. During the payment process, the cardholder isn’t prompted to complete 3DS authentication, since the card isn’t enrolled. Instead, the value of
redirect.status automatically transitions to
not_required, though the value of
false. Although the cardholder did not complete 3DS authentication, liability still shifts to the issuer.
Liability shift can’t occur if the card does not support 3DS (in that case, the value of
not_supported), or if you charge the card source instead of the 3DS source of a card that supports it.
There are certain circumstances where payments that are successfully authenticated using 3DS don’t 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.
chargeable 3DSecure source must be charged within six hours of becoming
chargeable. If it’s not, its status is automatically transitioned to
canceled and your integration receives a
source.canceled webhook event. Make sure the order is canceled on your end and that you notify the customer when you receive the
pending sources are canceled after one hour if they’re not used to authenticate a payment, ensuring that all sources eventually transition out of their
pending state to the
canceled state if they’re not used.
Saving 3D Secure card information for later
After the 3DS source has been used to make a successful payment, you can save the original card source to a new Customer object.
The ID of the card source can be retrieved from the 3DS source as the value of the
Since the 3DS process has already taken place, you can create additional payments using the customer as normal.
As the 3DS process isn’t performed when using saved card information to make a charge request, future payments aren’t protected by the 3DS liability shift.
3D Secure cards and subscriptions
Testing 3D Secure payments
Not all cards support 3DS or require the customer be redirected to their card issuer’s authentication page. You can use the following card information to fully test 3DS payments. Each of these card sources returns a different value for the
Testing the redirect process
When creating a
Source object using your test API keys, you can follow the URL returned in the
redirect[url] field. This leads to a Stripe page that displays information about the API request, and where you can either authorize or cancel the payment. Authorizing the payment redirects you to the URL specified in
Clicking on the Failure button results in the 3DS source status transitioning to