| [ Web Proxy ] |
| Viewing: https://docs.stripe.com/strong-customer-authentication | [Back] [Original] |
Strong Customer Authentication (SCA), a rule in effect as of September 14, 2019, as part of PSD2 regulation in Europe, requires changes to how your European customers authenticate online payments. Card payments require you to use 3D Secure to meet SCA requirements. Your customers banks might decline transactions that dont follow the new authentication guidelines.
To support SCA:
If you use a third-party plugin, platform, or extension partner, contact your Stripe partner to see if changes are required to support SCA. Contact support if you have any questions.
Update your Stripe integration to support SCA, if all of the following apply:
While some low-risk transactions (based on the volume of fraud rates associated with the payment provider or bank) dont require authentication, banks can still request that the customer complete authentication. Even if youre primarily processing low-risk transactions, update your integration so your customers can complete authentication when requested by the bank. Learn about SCA exemptions.
Whether you collect one-time payments or save cards for later reuse, Stripe provides prebuilt and customizable products to help you meet SCA requirements.
Integrations that arent SCA-ready, like those using the legacy Charges API, might see high rates of declines from banks that enforce SCA.
Accept card payments with the Payment Intents API and Checkout, a prebuilt, Stripe-hosted checkout flow that automatically handles SCA requirements for you. Checkout is customizable and lets you accept payments for one-time purchases and subscriptions on your website.
Save a card for later reuse with the Payment Intents API and the Setup Intents API. You can also use Checkout to automatically handle SCA requirements, or use Billing to handle SCA for subscriptions.
You might need to update your integration to support SCA. For details about the changes to make, including for specific product recommendations based on use case, see the following guides:
You might need to update your Stripe plugin or developer library to support SCA. If youre looking for an SCA-ready plugin, visit Stripe Partners.
Include identifying information in your plugins and third-party libraries so we can contact you about future changes or critical updates to the API. Use the setAppInfo function to provide those details in your Stripe integration.
We encourage you to join the Stripe Partner Program, which includes free registration and more resources for developers building plugins. Learn more about suggested best practices.
Consider the following:
If none of these options work for your integration, let us know.
After you implement your integration path, configure your Dynamic 3D Secure Radar rules to test your integration using 3D Secure test cards. Make sure to test both successful and unsuccessful authentication cases.
As soon as you finish updating, provide an SCA-ready update to your customers. You can share the Strong Customer Authentication guide with your customers to help them understand these regulatory changes. When you release an SCA-ready update, notify Stripe as well. We direct users to SCA-ready solutions on the Stripe Partners page.
If you collect payments when your customer isnt actively using your application, SCA might require your customer to re-authenticate, even if they authenticated in the past. For these off-session payments, you can use the Stripe APIs to authenticate your customer once while on-session, and then reuse the card repeatedly while off-session.
Alternatively, you can use previous authorization agreements (sometimes referred to as grandfathering) for off-session payments that meet the following eligibility period, regardless of payment amount and frequency:
Stripe automatically looks for transactions made with cards prior to the dates listed above. If found, Stripe uses the previous authorization agreement for the current transaction. If the bank accepts the previous authorization agreement, the transaction is categorized as out-of-scope for SCA and can proceed without additional authentication.
If the bank declines the previous authorization agreement, the PaymentIntent status changes to requires_payment_method, and you must notify your customer to complete the payment.
After SCA takes effect, you can use the Payment Intents API to save and reuse cards, and the Setup Intents API to qualify for off-session exemptions. You can also save cards using Stripe Checkout.
For Stripe to reuse previous authorization agreements, you must use the Payment Intents API and tell Stripe the payment is off-session.
| Before the eligibility period | After the eligibility period |
|---|---|
You saved the card by passing a token, source, or payment method to the Customer object. | Create a PaymentIntent with an off-session flag. |
| You saved the card by creating a SetupIntent or using setup_future_usage in a PaymentIntent. | Create a PaymentIntent with an off-session flag. |
Prepare your payment flows for SCA-readiness as soon as possible, if SCA regulations impact you. This can help prevent an increase in declines from European cards, and prepare you in case of early enforcement by banks. Learn how enforcement varies by country.
Your integration is SCA-ready when you process all of your payments using SCA-ready products, such as Checkout, Billing, the Payment Intents API, or an SCA-ready partner solution.
Additionally, do the following:
Payments might not succeed for reasons including incomplete, declined, or failed payments. For payments stuck in an incomplete (Dashboard) or requires_action (API) status, do the following:
true when creating an off-session payment.Banks can decline payments that require 3DS authentication but dont have 3DS enabled.
If an off-session payment fails, but you think its exempt from SCA requirements, do the following:
setup_future_usage to off_session.usage to off_session.Exemptions arent guaranteed, and off-session payments might still require authentication by the bank.
In the Dashboard, go to Transactions > Payments.
From the Filter by: status dropdown, do one of the following:
Click Apply.
Hover over the status badge for the reason.
When monitoring disputes, be aware that payments successfully authenticated through 3DS fall under the liability shift rule. If a cardholder disputes a 3DS payment as fraudulent, the liability typically shifts from you to the card issuer. If the card issuer applies exemptions, the payment isnt authenticated through 3D Secure, and liability shift doesnt apply.
When you set up your payment flow to save a card using the Payment Intents API or Setup Intents API, Stripe marks subsequent off-session payments as a merchant-initiated transaction (MIT). These transactions require an agreement (also known as a mandate) between you and your customer.
On your website or application, minimally cover the following:
In your checkout flow, reference the terms of the payment:
I authorize to send instructions to the financial institution that issued my card to take payments from my card account in accordance with the terms of my agreement with you.
| Web Proxy Viewer | New URL | Original Page |