SCA migration guide for Connect platforms

    Learn how to update your Connect platform for Strong Customer Authentication (SCA).

    Strong Customer Authentication applies to businesses based in the European Economic Area (EEA) that accept online payments from customers located in the EEA. Many card payments require additional authentication through 3D Secure. As of September 14, 2019, transactions that don’t follow the new authentication guidelines may be declined by a customer’s bank.

    Updating your Connect platform for the Strong Customer Authentication regulation in Europe consists of the following steps:

    1. Choose an SCA-ready integration
    2. Examine Connect-specific changes
    3. Determine whether connected accounts need to make changes
    4. Implement and test the new integration path
    5. Educate your connected accounts

    You need to update your platform if you create any of the following charges:

    • Direct charges on a connected account based in the EEA
    • Destination charges if the on_behalf_of parameter is set and specifies a connected account based in the EEA
    • Separate charges and transfers if your platform is based in the EEA or if the on_behalf_of parameter is set and specifies a connected account based in the EEA

    Step 1: Choose an SCA-ready integration

    You need to update your Stripe integration to meet SCA requirements. For example, SCA requires off-session payments to be authenticated when customers enter payment details, and subsequent off-session payments may require notifying the customer to return to the application to re-authenticate. Refer to the SCA migration guide to review the integration paths for the new version of Stripe Checkout, Stripe Billing, and the Payment Intents API.

    Choose the new version of Checkout if it supports the features your integration requires. Checkout is a hosted payment page that can be branded by businesses, supports recurring subscriptions, and is the easiest way to provide SCA support to your connected accounts. It supports creating direct charges and destination charges for Connect.

    If you want to build a custom payments experience, use the Payment Intents API as the Charges API is not SCA-ready. The Payment Intents API supports the same set of Connect features as the Charges API.

    Step 2: Examine Connect-specific changes

    Update account creation requests

    Starting with the 2019-02-19 API version, capabilities must be requested when creating U.S. connected accounts. If you currently create U.S. connected accounts without requesting capabilities, we recommend requesting the legacy_payments capability to preserve your existing account onboarding requirements.

    Destination charge changes

    If you’re using the destination, destination[account], or destination[amount] parameters with the Charges API, note that these parameters have been replaced with transfer_data[destination] and transfer_data[amount] in both the Charges and the Payment Intents APIs.

    See the following table for more information.

    Use case Charges API Payment Intents API
    Your platform is the merchant of record, but you wish to create a transfer to a connected account after the payment completes Not possible Set transfer_data[destination] to the connected account’s ID
    You want your connected account to be the settlement merchant without creating a separate transfer after the payment completes Set on_behalf_of to the connected account’s ID No change
    You want your connected account to be the settlement merchant and you wish to create a transfer to that account after the payment completes Set destination or destination[account] to the connected account’s ID Set transfer_data[destination] and on_behalf_of to the connected account’s ID
    You wish to collect an application fee Set application_fee to the amount desired Set application_fee_amount to the amount desired
    You wish to transfer a partial amount to your connected account after the payment completes Set destination[amount] to the amount to transfer Set transfer_data[amount] to the amount to transfer

    3D Secure and Radar rules

    The new version of Checkout and the Payment Intents API triggers Dynamic 3D Secure authentication based on Radar rules. With Connect, the rules you create only apply to payments created on the platform account. Payments created directly on the connected account are subject to the connected account’s rules. Configure your default rules and test your integration with 3D Secure test cards.

    SCA impact on saving payment methods

    Under SCA, authentication is required when saving a card in order to collect customer permission and qualify for off-session exemptions for subsequent off-session payments. To reduce the rate of customers having to authenticate their payment method, update your integration to use the off-session API.

    If you use the Cloning Saved Payment Methods feature to save a payment method for reuse across multiple connected accounts, note that sharing a payment method with a connected account will automatically share customer permission as well. This allows the platform to make off-session payments on any of their connected accounts without requiring the customer to authenticate their payment method again.

    Step 3: Determine whether connected accounts need to make changes

    In most cases, once you update your payments integration for SCA, your connected accounts don’t have to do any additional work.

    If you provide your own payments API to your connected accounts in addition to or on top of Stripe’s API, your connected accounts may need to make changes to continue accepting payments on your platform. For example, if you run a subscriptions platform on Stripe in which your connected accounts pass payment information to you via your own API, and then you pass those payment details to Stripe’s API, you’ll need to ensure both APIs are SCA-ready. If this is the case for your platform, provide guidance to your connected accounts on any changes they need to make.

    Step 4: Implement and test the new integration path

    After you have identified your integration path and determined if your connected accounts need to make changes, follow the relevant migration guides for the new version of Checkout, Stripe Billing, or Payment Intents API.

    Once implementation is complete, configure your Dynamic 3D Secure rules to test your integration using 3D Secure test cards. Make sure to test both cases when the authentication is successful and unsuccessful.

    Step 5: Educate your connected accounts

    Finally, inform your connected accounts about how SCA can affect them and when your platform will be SCA-ready, regardless of whether they need to make any changes.

    In particular, provide them with the following information, tailored for your business:

    Overview of SCA

    Strong Customer Authentication (SCA) is a new European regulatory requirement to reduce fraud and make online payments more secure. Since SCA took effect September 14, 2019, online payments require additional customer authentication. Transactions that don’t adhere to the new guidelines may be declined by your customers’ banks. This regulation applies to transactions where both the business and the cardholder’s bank are located in the European Economic Area (EEA).

    If you’d like, you can also send along the SCA video and guide.

    How your platform should support SCA

    If you’re not migrating to an SCA-ready solution, reach out to any of your connected accounts with significant business from European customers so they can move to a new solution before experiencing declines due to SCA.

    Any actions your connected accounts need to take

    If no action is required on their end, let your connected accounts know. Similarly, if action is required, provide them with instructions on the necessary changes.

    How SCA can affect their business

    SCA changes the checkout flow for card payments. Payments that require authentication ask for 3D Secure (often known by its brand names, “Verified by Visa” or “Mastercard SecureCode”), which typically adds an extra step in which the cardholder must provide additional information, such as a one-time passcode or biometric ID.

    Was this page helpful?

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

    On this page