Strong Customer Authentication (SCA) compliance

Software improvement 5-Done
1

I’m creating this post to share some light on what has been discussed so far in Slack and Github, so that everyone can follow what’s going on.
I would like to add that once again I’m doing a summary, but that this summary is based on the work made by @lin_d_hop @kristinalim and @Matt-Yorkley

I’m making this post a wiki, please correct / add info as much as needed.

What is it about ?

Strong Customer Authentication (SCA) regulation is an EU regulation which requires a two-factor authentication on many payments in Europe. Payments without SCA may be declined.

Who does it impact ?

All EU instances, and more particularly all EU instances using Stripe (UK, FR, BE and Katuma).

We will need to made significant updates to Stripe in order to avoid an increase in declined charges and be compliant with this new regulation. Luckily Stripe has everything very well documented :ok_hand:

First steps made by the software team

The regulation was supposed to come into force on September the 14th. So we started a spike on what needed to be done. The issue covering the spike is here : [Spike] Stripe, Subs and changes to EU money laundering legislation · Issue #3927 · openfoodfoundation/openfoodnetwork · GitHub

And the result of the spike can be seen in this epic: Support for Strong Customer Authentication (SCA) in Stripe integration - Part 2 · Issue #4170 · openfoodfoundation/openfoodnetwork · GitHub

Main outcomes:

  • Priority number :one: is ensuring that once-off payments in the shopfront will trigger the 3DSecure authentication when necessary.
  • Priority number :two: is ensuring that in BOTH places a user can save a card (shopfront & Account->Cards), we always create a PaymentIntents for off-session payments (customer authentication) and save this
  • Priority number :three: is ensuring that Subs workflow can handle when SCA is requested despite us having PaymentIntents for this off-session payment
  • Priority number :four: is having a suitable workflow for hub managers to be able to handle taking card payments on the admin side

Plot twist

Instead of the previous deadline of September 14th, some EU countries said they would give banks a delay to apply the regulation.
We know today that it is the case for UK (until March 2021) and France (until September 2022).
We don’t know about Belgium and Spain and we don’t know when payments will be declined because of this.

On one hand, the risk is there but it may be low. On the other, we know we will have to do this work for sure. Moreover the spike is still fresh on our minds and @kristinalim is ready to tackle priority number :one: (ensure checkout is working) in the coming month (after bugs and performance work).

The size of priority number :one: is estimated at M.

So the proposal is currently to move forward and prioritize this first step. But this means we have less time to do something else.

We would love to have your feedback on this, especially for instances that are not faced with this issue ping @tschumilas @lauriewayne1 @Kirsten

2

I’m totally in favour of this work and defer on process to those of you closer to it. Eventhough I live in a land where the government is asleep when it comes to data privacy and user rights, I agree with it strongly. The work puts OFN-CAN in a stronger ethical position, even if our government doesn’t require this.

3

:warning: Stripe SCA Roll Out - Important Update for all EU Instance Managers using Stripe as a Payment Method :warning:

As of December 31st Secure Card Authentication comes into legislative force in Europe. This means that banks will start declining cards that are not securely authorised. Some banks have started declining cards already. You might have already noticed an increase in declined cards on the platform.

The delivery team has been working on ensuring that our Stripe integration is SCA compliant for many months. We are getting very close to the point in which our integration is fully SCA compliant, but it is likely that we won’t have finished everything we would like to before the deadline. We will, however, have finished enough to ensure that transactions continue with minimal disruptions to shops.

TO DO: For all enterprises using Stripe as a payment method, update their payment method to StripeSCA BEFORE their first order cycle opens for 2021.

Some things to note:

  • Hubs will not be able to refund their shoppers that paid for their order using StripeConnect payment method. They will need to log into Stripe to complete any refunds. This is a significant point to note as it will cause significant disruption to the way Hubs operate. Unfortunately there is no realistic way around this. As instance manager or support you have two options: a) offer to do refunds for enterprises by logging into your instance stripe account or b) Letting enterprises know how to do this themselves. Below are some notes to help minimise this disruption.
  • It is possible to switch enterprises to SCA without informing them, however you may end up with a large number of support requests for refunds as the above point explains. For this reason we strongly advise that you notify any users, and ideally coordinate with them (see below) if they trade a significant volume via OFN.
  • Currently subscriptions payments will work with SCA payment method, but if authentication is required by the bank then the card will be declined. By December 31st we plan to ensure that if a payment fails due to SCA this will be clear so we can ask the shopper to authorise their card (using the same process that they currently use to authorise subscriptions).
  • This issue makes refunds harder with SCA, but should be merged in the next release or two.

How to organise switching enterprises to SCA
The actual switch is very easy - you just update the payment method from Stripe to StripeSCA.
The planning around the switch is a little harder. This roll out plan has been used by the UK and, though a bit dated now, might have some ideas useful to others.How you do your SCA roll out will depend on a number of factors:

  1. How is your support team working over the Christmas period? If your team is taking a break then make sure you factor in this roll out.
  2. How are your enterprises trading over the break? Many enterprises don’t trade from the 25th until January, so it is worth checking in with them.

For any enterprises taking a break over Christmas and New Years it is worth checking in with them as to when they will finalise their pre-Christmas orders eg process their refunds. I would advise coordinating with these enterprises to switch to SCA:

  • AFTER they have finalised their Christmas orders, refunds etc
  • BEFORE they open their first order cycle for 2021.

This will certainly create the least support overhead.

For enterprises that are not taking any break then it is worth understanding if they expect reduced sales volume at any point. If so, best to roll out at this time so long as it is before Dec 31st. If they do not expect this, then roll out as soon as possible.

For enterprises that trade with subscriptions. You will need to take additional action - BUT not just yet. We recommend that you coordinate with your subscriptions users notify ALL shoppers that they will need to reauthorise their cards within OFN to ensure their payments are not interrupted. Card reauthorisation will follow the same process as is used now from the shoppers perspective. I’ll post on this channel when these changes are merged so that you know you can begin the process.

4

Step 3 of the ‘things to note’:
A sub payment fails and the customer re-authorises their card.
At the moment, if a sub payment fails (due to card out of date or other) and the customer updates their details, then payment can not be collected by the platform even though the details are now correct. The payment status remains as ‘checkout’ and is not editable (ie you can’t void the payment attempt).

Is the instruction still going to be that hubs will need to collect payment by other means for subs orders which required verification?

I’m just trying to think this through (from a support point of view) before it goes live.

In an ideal world, it would be fab if :

  • bank requires verification.
  • initial subs payment fails
  • hub and customer notified
  • customer re-authenticates their card
  • either hub can click ‘resume payment’ or payment is automatically attempted as soon as authorsation has gone through.
5

New issue related to SCA:

6

@lbwright22
Currently the roll out for Dec 31st will not reattempt the payment. However before the delivery team close the epic we will handle the case in which a payment requires SCA. In this case the Payment Intent will be held and payment will be collected after shopper authorisation.
If you are interested in all the work that has been prioritised within this phase of SCA roll out you can find it here: https://github.com/openfoodfoundation/openfoodnetwork/issues/4170

7

Just a note-
for current subs which fail due to card issues the customer is sent an email to say why the payment failed (ie it was their card), the hub is not (they just get an email to say it failed).

By the 31st would it be possible for the email chain to be tweaked so it looked more like this:

  1. Payment fails due to expired card/card details wrong (ie due to card problem but not SCA)- email sent to customer and hub states this. Email includes a link to the customer section of the UG (exact section) where it describes how to update card details in their OFN account.
  2. Payment fails due to Strong card authorisation check requested by bank at time of payment- email sent to customer and hub states this. Email includes a link to the UG where it shows how to re-autherise your card (I need to create this GIF when the release has been rolled out)

NOTE- two different emails so customers and hubs can pin down what action to take and in both cases the hub gets the customer copy of the email (at the moment the hub is left in the dark a little which results in support issues)

1 Like
8

Thanks for pointing this out @lbwright22. I think we can consider this part of https://github.com/openfoodfoundation/openfoodnetwork/issues/4179 and I can push another commit to address this.