Preparing your Connect platform for the upcoming Strong Customer Authentication regulation in Europe consists of the following steps:
- Determine if your platform is impacted by SCA
- Choose an SCA-ready integration
- Examine Connect-specific changes
- Determine whether connected accounts need to make changes
- Implement and test the new integration path
- Educate your connected accounts
Step 1: Determine if your platform is impacted by SCA
Strong Customer Authentication applies to businesses based in the European Economic AreaThe European Economic Area is a regional single market with free movement of labor, goods, and capital. It encompasses the European Union member states and three additional states that are part of the European Free Trade Association. (EEA) who accept online payments from customers located in the EEA. Many card payments will require additional authentication through 3D Secure3D Secure provides an additional layer of authentication for credit card transactions that protects merchants from liability for fraudulent card payments. During a transaction that incorporates the 3D Secure authorization process, the customer is prompted to supply a separate password or code to validate their purchase.. Transactions that don’t follow the new authentication guidelines may be declined by a customer’s bank, starting on September 14, 2019.
When creating a charge on behalf of a connected account, the settlement country of the charge determines whether the charge is impacted by SCA. If your platform creates one of the following type of charges, you are in scope for SCA:
- direct charges on a connected account based in the EEA
- direct charges, destination charges, or separate charges and transfers where the settlement merchant is based in the EEA (this is typically set with the
destinationparameters when creating the charge)
- separate charges and transfers from a platform based in the EEA
Step 2: Choose an SCA-ready integration
You will need to update your payment flows and your Stripe integration to prepare for SCA. For example, SCA requires off-session paymentsA payment is described as off-session if it occurs without the direct involvement of the customer, using previously-collected payment information. 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 3: Examine Connect-specific changes
Once you have picked an SCA-ready solution, be aware of Connect-specific changes that may impact your integration.
Destination charge changes with the Payment Intents API
If you’re using the
destination[account] parameter with the Charges API to create a destination charge, note the parameter has been replaced with
transfer_data[destination] in the Payment Intents API.
The following table describes the differences:
|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
|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
||Set transfer_data[destination] and on_behalf_of to the connected account’s ID|
|You wish to collect an application fee||Set
||Set application_fee_amount to the amount desired|
|You wish to transfer a partial amount to your connected account after the payment completes||Set
||Contact us if you need this|
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 qualify for off-session exemptions for subsequent off-session payments. An API to perform authentication when saving a payment method will be available by July 1, 2019. You should update your integration today and make incremental changes after July 1st to reduce the rate at which customers need to authenticate their payment method.
Step 4: Determine whether connected accounts need to make changes
In most cases, once you update your payments integration to become SCA ready, your connected accounts won’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 required of them and leave enough time for both your platform and your connected accounts to migrate ahead of the September 14, 2019 SCA deadline.
Step 5: 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 6: Educate your connected accounts
Finally, inform your connected accounts about how SCA impacts 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, although you should tailor it 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. Once SCA goes into effect on September 14, 2019, online payments will 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).
How your platform will prepare for SCA
If you won’t be migrating to an SCA-ready solution, please reach out to any of your connected accounts with significant business from European customers so they have a chance to move to a new solution before they start to experience payments declines when the SCA regulation takes effect.
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 may impact their business
SCA will change the checkout flow for card payments. Payments requiring authentication will trigger 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.