SCAStrong Customer Authentication (SCA) is a regulatory requirement in effect as of September 14, 2019, that impacts many European online payments. It requires customers to use two-factor authentication like 3D Secure to verify their purchase. requires customers to complete 3D Secure3D Secure provides an additional layer of authentication for credit card transactions that protects merchants from liability for fraudulent card payments. for some payments. When this step is required by the bank, the customer must be online to complete authentication. This introduces complexity for businesses that save cards and charge them later when the customer is no longer on the website or application and can’t complete authentication. This is also known as off-session paymentsA payment is described as off-session if it occurs without the direct involvement of the customer, using previously-collected payment information.. Examples of this include fixed-amount subscriptions, metered-billing subscriptions, crowdfunding campaigns, and car rentals.
Stripe products and APIs now allow merchants to meet SCA requirements for off-session payments:
Mandate collection. A mandate represents the agreement you have with the customer on how you plan to use their card in the future. In your checkout flow, add some consent text. State that by completing checkout, the customer consents to your initiation of payment on their behalf. State the anticipated frequency of payments. Explain how the amount of the payments will be determined.
Strong authentication of the first transaction. Merchants are required to authenticate the customer when the mandate is set up. This can either be done by the first payment with the card or when saving the card to a customer without making an initial payment.
Flagging subsequent transactions. Any payment made with a saved card when a user is off-session must be marked accordingly, with reference to the first authenticated transaction. Stripe handles this for you.
By updating your payments integration to use these new APIs and flows, Stripe can request exemptions such as fixed-amount subscriptions and merchant-initiated transactions to process later payments made with a saved card. However, banks can decide to reject a request for exemption. Build a way to notify customers that they need to return to your application and complete authentication if required.
Stripe Billing with the new version of Checkout
Checkout is a prebuilt checkout page that lets you collect payments and manage simple subscriptions with a single integration.
Build your own off-session payments logic and handle getting users back on-session to complete re-authentication as needed. While this approach takes more work than using Stripe Billing, it provides more flexibility.
There are three parts to building an off-session payment flow:
Use a saved card to make a payment. Once you have cards saved to a
customer, you can make both on-session or off-session
payments.
Build a recovery flow. While Stripe requests exemptions to reduce the
need for customer reauthentication, there is always a risk that the cardholder’s
bank will reject the exemption request. You should always build a recovery
flow to bring a customer back
on-session in case they need to authenticate again.
For payments with separate authorize and capture, you can complete the full integration today.
The new version of Stripe Checkout
Get prebuilt, conversion-optimized checkout flows with minimal code. Choose this option if you prefer a low-maintenance integration. For this payment flow, you can complete the full integration today, and no additional work will be needed to handle exemptions.
SCAStrong Customer Authentication (SCA) is a regulatory requirement in effect as of September 14, 2019, that impacts many European online payments. It requires customers to use two-factor authentication like 3D Secure to verify their purchase. requires customers to complete 3D Secure3D Secure provides an additional layer of authentication for credit card transactions that protects merchants from liability for fraudulent card payments. for some payments. When this step is required by the bank, the customer must be online to complete authentication. This introduces complexity for businesses that save cards and charge them later when the customer is no longer on the website or application and can’t complete authentication. This is also known as off-session paymentsA payment is described as off-session if it occurs without the direct involvement of the customer, using previously-collected payment information.. Examples of this include fixed-amount subscriptions, metered-billing subscriptions, crowdfunding campaigns, and car rentals.
Stripe products and APIs now allow merchants to meet SCA requirements for off-session payments:
Mandate collection. A mandate represents the agreement you have with the customer on how you plan to use their card in the future. In your checkout flow, add some consent text. State that by completing checkout, the customer consents to your initiation of payment on their behalf. State the anticipated frequency of payments. Explain how the amount of the payments will be determined.
Strong authentication of the first transaction. Merchants are required to authenticate the customer when the mandate is set up. This can either be done by the first payment with the card or when saving the card to a customer without making an initial payment.
Flagging subsequent transactions. Any payment made with a saved card when a user is off-session must be marked accordingly, with reference to the first authenticated transaction. Stripe handles this for you.
By updating your payments integration to use these new APIs and flows, Stripe can request exemptions such as fixed-amount subscriptions and merchant-initiated transactions to process later payments made with a saved card. However, banks can decide to reject a request for exemption. Build a way to notify customers that they need to return to your application and complete authentication if required.
Off-Session Payments with the Payment Intents API
Build your own off-session payments logic and handle getting users back on-session to complete re-authentication as needed. While this approach takes more work than using Stripe Billing, it provides more flexibility.
There are three parts to building an off-session payment flow:
Use a saved card to make a payment. Once you have cards saved to a
customer, you can make both on-session or off-session
payments.
Build a recovery flow. While Stripe requests exemptions to reduce the
need for customer reauthentication, there is always a risk that the cardholder’s
bank will reject the exemption request. You should always build a recovery
flow to bring a customer back
on-session in case they need to authenticate again.
SCAStrong Customer Authentication (SCA) is a regulatory requirement in effect as of September 14, 2019, that impacts many European online payments. It requires customers to use two-factor authentication like 3D Secure to verify their purchase. requires customers to complete 3D Secure3D Secure provides an additional layer of authentication for credit card transactions that protects merchants from liability for fraudulent card payments. for some payments. When this step is required by the bank, the customer must be online to complete authentication. This introduces complexity for businesses that save cards and charge them later when the customer is no longer on the website or application and can’t complete authentication. This is also known as off-session paymentsA payment is described as off-session if it occurs without the direct involvement of the customer, using previously-collected payment information.. Examples of this include fixed-amount subscriptions, metered-billing subscriptions, crowdfunding campaigns, and car rentals.
Stripe products and APIs now allow merchants to meet SCA requirements for off-session payments:
Mandate collection. A mandate represents the agreement you have with the customer on how you plan to use their card in the future. In your checkout flow, add some consent text. State that by completing checkout, the customer consents to your initiation of payment on their behalf. State the anticipated frequency of payments. Explain how the amount of the payments will be determined.
Strong authentication of the first transaction. Merchants are required to authenticate the customer when the mandate is set up. This can either be done by the first payment with the card or when saving the card to a customer without making an initial payment.
Flagging subsequent transactions. Any payment made with a saved card when a user is off-session must be marked accordingly, with reference to the first authenticated transaction. Stripe handles this for you.
By updating your payments integration to use these new APIs and flows, Stripe can request exemptions such as fixed-amount subscriptions and merchant-initiated transactions to process later payments made with a saved card. However, banks can decide to reject a request for exemption. Build a way to notify customers that they need to return to your application and complete authentication if required.
Off-Session Payments with the Payment Intents API
Build your own off-session payments logic and handle getting users back on-session to complete re-authentication as needed. While this approach takes more work than using Stripe Billing, it provides more flexibility.
There are three parts to building an off-session payment flow:
Use a saved card to make a payment. Once you have cards saved to a
customer, you can make both on-session or off-session
payments.
Build a recovery flow. While Stripe requests exemptions to reduce the
need for customer reauthentication, there is always a risk that the cardholder’s
bank will reject the exemption request. You should always build a recovery
flow to bring a customer back
on-session in case they need to authenticate again.
Step 3: Implement the new integration path
You will need to make server-side and client-side changes.
Server-side
Creating a charge directly through the Charges API is not SCA-ready. Instead, use the Payment Intents API to create a payment. A PaymentIntent tracks the lifecycle of a customer checkout flow and triggers additional authentication steps when required by SCA.
Follow the migration guide to learn how to migrate from the Charges API to the Payment Intents API.
Client-side
In order to dynamically display 3D Secure authentication for card payments, client-side changes are also required alongside server-side changes for the Payment Intents API.
Follow the guides to integrate Checkout for
one-time and
recurring payments.
Step 4: Test dynamic authentication
To verify that your updated integration handles 3D Secure correctly, be sure to test both successful and unsuccessful authentication flows, using the regulatory test cards.
By default, 3D Secure authentication is only shown when the customer’s bank requires it, so your checkout conversion is not negatively affected. As of September 14, 2019, your updated integration displays the 3D secure authentication flow automatically whenever required by SCA.