Allow SCA cards to be setup and charged offline for subscriptions

[andrewpbrett]

What? Why?

Closes #4182
Closes #4723

This change allows customers to perform the extra SCA auth step when they authorize shops to charge their card offline.
It also no longer creates a clone of the card on the shop's Stripe account each time we need to authorize or charge a card stored on the platform (instance) Stripe account.

What should we test?

Adding a card that requires SCA (see http://stripe.com/docs/testing ) to the /account page, setting it to be the default card, and then ticking the box to authorize a shop to charge it offline should prompt the extra SCA auth step.

Release notes

We now support SCA when charging cards offline for subscriptions.

Changelog Category: User facing changes

Dependencies

Documentation updates

[andrewpbrett]

That rubocop failure is not showing up for me locally...

[mkllnk]

There are still a few detours in the commit history but it all looks reasonable. I would need to invest a lot more time to properly understand how it all works. Instead I'll trust you. 😜

And I'm glad we have thorough testers.

[sauloperez]

This is really good! Congrats on this great effort @andrewpbrett 👏 !

[filipefurtad0]

Hey @andrewpbrett ,

Awesome work, very interesting changes and quite a lot going on... Let's have a look at some test cases, starting with the acceptance criteria & tests from the issues this PR is closing:

1. adding a new card under /account#cards

• adding a new card works, and removes existing charge authorizations (as introduced in Update default card/authorized shops UI (v2.0) #6456)
• adding a new card will never trigger authentication. This was checked for 3D-Secure and non 3D-Secure cards

2. enabling authorizations for an enterprise to charge:

• a newly added, valid 3D-card - 4000 0027 6000 3184:
  All good. The authentication window kicks-in, and one can cancel, proceed or decline authentication, as usual (pic below):

• a newly added, invalid 3D-card - 4000008260003178:

Same as above. Authentication works here as well 👍

• a previously existing, valid 3D-card - 4000 0027 6000 3184
• a previously existing, invalid 3D-card - 4000008260003178

All good!

3. deleting cards

all good: 3D- or non-3D cards can be deleted.

I found a issue with some "really old" cards, from Spree Upgrade still. these can't be deleted, for some reason: generates error 500

for example, https://staging.openfoodnetwork.org.uk/credit_cards/2995

https://app.bugsnag.com/yaycode/openfoodnetwork-uk/errors/5fd355b56e76b60018be4983?event_id=5fd355b500661b9c4d590000&i=sk&m=nw

I don't think this PR introduced this.

4. Regression test: I made a quick test on subscriptions, using the newly introduced testing-method on PR Add tasks to help manually test subscriptions #6291 (it works!)
   I found subs not to be working for 3D-Secure cards yet, but are working with the usual settings.

All good! Awesome work 🎉

[filipefurtad0]

I've extended the regression test mentioned in the testing notes (point 4) to Stripe Connect - before, this was only tested for StripeSCA for 3D-Secure (not working) and non-3D-Secure cards (working).

This PR appears to break subscriptions for Stripe Connect and triggers the error:

https://app.bugsnag.com/yaycode/openfoodnetwork-uk/errors/5fd7a8e03ba8d20017bb3ae0?event_id=5fd7a8e000658c991a880000&i=sk&m=nw