What you need to know about the new European regulation, PSD2
Published on June 11, 2019 by Fatima Haidar
On September 14, 2019 a new European regularity is required to process online payments. In this post, we’ll run through what this means for you and your online business and break down what needs to happen.
As a Stripe verified partner, we have worked together with Stripe to understand the implications of SCA for our customers and to help them become PSD2 ready.
So tell me, what exactly is SCA?
SCA is meant to reduce fraud and make online payments more secure. To establish that, payments will rely on 3D Secure. 3D Secure is an authentication method that uses 2 or more layers when completing an online payment. The layers added can be any of these three elements: something a user knows, has, or is. The payment processes will therefore include an extra step. So instead of the process being composed of authorising and capturing a payment, it will evolve into authenticating, authoring, and capturing the payment.
SCA will be applied to customer initiated online payments having the two ends, the merchant and user, falling within Europe.
In preparation for this new coming era in online payments, Stripe has launched new products and APIs to support SCA and ultimately provide its users a facilitated transition:
What does the flow look like?
1. Initiate Payment Your customer fills in their card details and completes the checkout form to initiate the payment.
2. Trigger dynamic authentication Stripe’s platform detects whether authentication is needed. If required, Stripe uses 3D Secure 2 to authenticate the customer using a one-time passcode or biometric ID, depending on what their bank supports.
3. Complete Payment Once a customer’s identity has been confirmed through 3D Secure, the card can be charged.
Please, not verified by VISA again!
Before jumping into each product and explaining them in depth, it is worth mentioning that Stripe now supports 3D Secure 2. 3D Secure 2 provides a better UX than 3D Secure along with “frictionless authentication”.
Frictionless Authentication allows businesses and their payment provider to send more data elements on each transaction to the cardholder’s bank. This will enable the user to go through a frictionless flow if the data provided seems enough for the bank to authenticate the user. This will ultimately decrease the number of transactions that need further action from the users.
What if I do nothing?
As a part of the second Payment Services Directive (PSD2), online payments that do not support the new regulatory, which is known as Strong Customer Authentication (SCA), will be declined.
What does this mean from a technical point of view?
PaymentIntents API will eventually replace Charges API. This API is particularly very handy because of the different features and flexibility it provides.
PaymentIntents API flips the normal modal for creating charging that we know over its head. Instead of creating a source on the client side then creating a charge in the server, PaymentIntents require to do an API call first on the server to create a PaymentIntent and then create a source on the client side that allows Stripe to complete the charging process in the UI.
PaymentIntents will determine if a payment requires SCA and ultimately collect the required 3D Secure 2 data needed. PaymentIntents also check if there is an exemption and apply it.
There are two ways in which you can integrate with the PaymentIntents API. Either using Manual Confirmation or Automatic Confirmation
Manual Conformations are synchronous, webhook-free-flows. If you already have an application up and running and using Charges API, Manual Conformations are the easiest way for you to migrate into PaymentIntents.
In Manual Confirmation, authentication happens by checking the PaymentIntent status and calling handleCardAction if needed. In case extra authentication is needed, additional calls to the server will be needed. Finally, finalising the payment would be on the server side thus any extra logic that needs to be handled will be taken care of in the same server call immediately.
Automatic Conformations are asynchronous, webhook-flows. Stripe recommends using this method if you are starting fresh and are comfortable using webhooks.
In Automatic Confirmation, authentication is automatically handled by Stripe with handleCardPayment which will also take care of any extra steps required if additional authentication is needed. Finally, finalising the payment is done in Stripe and the application uses webhooks to handle the subsequent logic.
Stripe new Checkout is built on top of PaymentIntents API and can dynamically apply 3D Secure when required.
Stripe already has Checkout product. The later will be renamed to legacy Checkout and will be eventually deprecated. The new Checkout was designed and implemented because payments became more complex and need to support dynamic authentication.
Stripe Checkout would be ideal for businesses who are looking to implement one-time payments. Checkout is customisable and very easy to use. By adding just a few lines of code, your application will host a seamless experience for the users to process payments.
With that said, there are two ways to integrate with Stripe Checkout: client-only integration and the API integration.
To use this approach, you need to add products and plans in the Dashboard and then integrate with a client-side snippet. The down side for this approach is that you can not associate payments with existing users, nor use separate authorisation and capture for card payments. This approach would be ideal for startups that want something up and running fast to prove their concept.
To use this approach, you need to pass data about the one-time payment or the subscription to your server. This approach allows you to associate payments with existing users, and use separate authorisation and capture for card payments. Moreover, this approach works with Stripe Connect. You just need to include the connected stripe account when creating the charge.
Stripe Billing is also built on top of PaymentIntents API and can dynamically apply 3D Secure when required too. It is ideal for business with recurring payments.
Before we dig deeper into the Billing product, we need to explain two terms: off-session and on-session charges. Off-session charges refers to charges that happen when the user is not presented. These are typically N-th charges where (N is greater to equal to 2) and do not need the user to authenticate. On-session chargers, on the other hand, are charges that take place while the user is present. These are typically the first charges that need authentication.
The bulk of the Billing product is the payment flow and how it handles it with recurring payment.
To start off, there are two scenarios for the first payment: the user is either on-session or off-session. If the user is on-session, the subscription will require SCA. This will be handled by Billing. If the user is off-session, you need to reach out to the user to get them on-session to authenticate the payment. Payments that are yet to be authenticated will be marked as incomplete.
Once a payment is authenticated, authorized and captured, a recurring payment will happen after a specific time which will not need authentication. In the event that authentication needs to take place, the user needs to be notified to go on-session to complete SCA. This can be done by either using Automated emails feature provided by Stripe which will include a link to a Stripe-hosted page, or by implementing webhooks in your application that will listen to the event and trigger your desired action.
Finally, we mentioned earlier that there are some exemptions. These exemptions are low-risk payments that may not need to implement SCA. Stripe will be able to request these exemptions from the cardholder’s bank upon processing a payment. It is then up to the bank to either approve the exemption or ask for authentication. The following are cases which payment requests might be exempt:
Payments below €30: Payments below €30 will be exempt unless 5 exemptions have already taken place since the last successful authentication or if the total of the previous exempted payments exceeds €100.
Fixed-amount subscriptions: This will apply to business who charge users a fixed amount on recurring payments.
Merchant-initiated transactions: Payments that are initiated by merchants might be exempt from SCA. However, the application needs to still authenticate the card on either the first payment or when it is being saved. An agreement from the customer should be obtained in order to charge their card on a later stage.
Trusted Beneficiaries: These are businesses that the user has whitelisted.
Phone Sales: These are payments that are collected over the phone.
Corporate Payments: These are payments done by corporates to manage employee expenses.
Even though the application you are building might fall under one of the above categories, the application should be ready to handle SCA at any given time.
Help! Can MiniCorp help to get us ready for SCA & PSD2?
Of course! We're here to help, just send us a message and we'll get right back to you.