How We Have Prepared for PSD2 SCA Payment Requirements

If you’re active in online business, you may have heard of the EU PSD2 directive which sets new rules for online payments in Europe. In September 2019, a new requirement for Strong Customer Authentication (SCA) will take effect. It basically requires online payments to be authenticated with an additional factor, such as a confirmation SMS message.

At Clouden we are using Stripe for payments. Luckily, Stripe will take care of the SCA requirements behind the scenes. The only requirement for us is to allow the Stripe client library to perform the additional authentication steps in the web browser when necessary.

The flowchart below illustrates the payment steps involved in our case. Note that we are not using the simplest possible Stripe integration because we’re supporting different types of products and we need some flexibility in how payments are handled.

Let’s go through the sequence step-by-step.

1. First the user must have a valid payment method. Payment methods are managed by Stripe, but we need to retrieve them through our own AWS Lambda based service. If the user doesn’t have a valid payment method yet, the client will ask them create one in the web browser. This is where the user enters their credit card information, which is sent directly to Stripe. After that we perform one more step to attach the new payment method to the user in our Lambda backend.
2. Next we proceed to create a payment intent for the product the user is buying. Stripe will check that the payment method exists and create an unconfirmed, uncaptured payment intent. The payment intent has an identifier which we use throughout the following steps to refer to the payment.
3. Now the client will perform a “loop” in the web browser where it attempts to confirm the payment intent. If Stripe tells us that the payment intent requires an additional verification step, the client handles it in the browser. This continues until the payment is successfully confirmed.
4. The client will now wait for the purchased product to become available. This is sometimes done by listening to a websocket connection and sometimes by polling a REST API. When the processing has completed, the end-user finally gets to enjoy their new product.
5. Meanwhile the server, seeing that the payment was confirmed successfully, proceeds to provision the purchased product. This might be instantenous or take a few minutes depending on the product. After the provisioning is completed successfully, the payment is finally captured and money is actually transferred. Here we can also cancel the payment if something goes wrong in the provisioning.

The sequence described above applies to purchases that are made interactively by an online user. We also support offline purchases for automatically renewing subscriptions and domain registrations and paying for other non-interactive services.

Offline purchases work essentially in the same way as online purchases, but the user must have already signed up and created a default payment method. It’s possible that offline confirmation of a payment doesn’t work for some reason. In this case we send out an email notification and ask the user to come back online to complete the payment manually.