Support for Strong Customer Authentication (SCA) in Stripe integration - Part 2

[kristinalim]

Description

Banks will start declining payments that have not been SCA-authenticated in countries that will require this. We need to start supporting SCA, and thankfully Stripe makes this easy/manageable.

See migration guidelines here.

See discussion here #3927 and the articles here.

Issues:

1. Completion of Part 1 Support for Strong Customer Authentication (SCA) in Stripe integration - Part 1 #4211
2. Customer should see updated terms of off-session charging through Stripe Customer should see updated terms of off-session charging through Stripe #4175
3. Explanation if SCA authentication required when adding Stripe payment for an order in the admin section Explanation if SCA authentication required when adding Stripe payment for an order in the admin section #4178
4. Explanation in email if payment for subscription failed because of SCA authentication Explanation in email if payment for subscription failed because of SCA authentication #4179
5. Allow a customer to perform further action for a Stripe payment if needed Allow a customer to perform further action for a Stripe payment if needed #4181
6. Allow a customer to perform further action for a Stripe card if needed Allow a customer to perform further action for a Stripe card if needed #4182
7. Inform customers n days before their subscription orders are due payment if likely to need SCA authentication [Stripe SCA] Inform customers n days before their subscription orders are due payment if likely to need SCA authentication #4183

Acceptance Criteria

The problem will be solved when there is:

1. User flow for customers to save and use new authenticated card info
2. User flow for admin to set unauthenticated card info for orders, with proper notification when the card cannot be saved because authentication is required
3. User flow for customers to perform SCA authentication on an existing stored card if needed
4. User flow for customers to perform SCA authentication for an existing Stripe payment attempt if needed
5. Custom text in failed payment email for customers whose subscription payment failed because of lack of SCA authentication (Check: Is this needed for some non-subscription orders?)
6. Email notification for customers likely to need SCA authentication n days before their subscription orders are due payment. - I think this should be less than 7 days. Stripe releases charge authorization if not captured within 7 days.
7. Enterprises are informed when subscription payments fail for shoppers

[kristinalim]

Regarding current item 2: "User flow for admin to set unauthenticated card info for orders, with proper notification when the card cannot be saved because authentication is required"

It is still possible that SCA authentication will not be needed for the customer or the payment. But If it is required at this point, you are not able to proceed to save the card on Stripe because the customer cannot authenticate. (Unless we want shop owners to be able to enter authentication info for customers, e.g. when they are communicating directly. I suspect this would be violating the regulation though.)

[lin-d-hop]

Notes from running tests on our payment flows using test cards specified by Stripe to trigger error flows:

1. Once-off payment for an order with a new card requiring 3D secure authentication:
   Work Flow: Shop checkout with new card
   Bank: 3D Secure auth required
   Expected Behaviour: Customers will be asked to verify their identity with a push notification, a text message, or another method chosen by their bank.
   Actual Behaviour: Cart fails to proceed. No error given.

2. Payment from a shop with a saved card requiring 3D secure auth
   Work Flow: Shop checkout with new card
   Bank: 3D Secure auth required
   Expected Behaviour: SCA regulation requires that you authenticate your customer up front if you intend to collect payments from them again in the future.
   Actual Behaviour: Checkout succeeds (though at no stage was I asked to verify. Not on saving the card or checkout) This seems as though it should have failed either here or at the saving stage.

3. Adding a saved card to OFN
   Work Flow: Adding a saved card in Account -> Cards
   Bank: 3d Secure auth
   Expected Behaviour: SCA regulation requires that you authenticate your customer up front if you intend to collect payments from them again in the future.
   Actual Behaviour: Card saves without issue.

4. Adding saved card at checkout
   Work Flow: Adding a saved card at checkout.
   Bank: 3d Secure auth
   Expected Behaviour: SCA regulation requires that you authenticate your customer up front if you intend to collect payments from them again in the future.
   Actual Behaviour: Card currently saves despite not being checked.

[lin-d-hop]

@kristinalim has done a great job of understanding the subscriptions workflow.

For the most part subscriptions will work fine once the above has been completed such that we create PaymentIntent objects everytime we save a card.

There is also the option to ensure that all existing subs can simply continue using this:
https://stripe.com/docs/strong-customer-authentication/grandfathered-agreements

Sometimes a bank can re-request 3DSecure Auth for an existing saved card that has previously submitted 3D secure Auth (and has a PaymentIntent created). In this case we need to have a flow that notifies the customer in advance and ensures that they can re-enter the authorisation with minimal disruption to their order. This is a tricky flow to manage and I think it doesn't need to be completed with any urgency because UK are the only EU folks to be using Stripe for Subs and UK has an 18month extension.

[luisramos0]

I have now closed epic #4180 as the integration with PaymentIntents is complete.
I am adding a note here related to it because there are some details in there that will be relevant to this phase 2 where we integrate with SetupIntents. See tests in the description of #4180 and also the the last few comments in #4180 for more details.

[andrewpbrett]

I do believe this is now done :)

#6683 came up in the course of testing and should be fixed soon as well.