Update Stripe card info form and/or the cards authorization checkboxes in the Account section to use Payment Method and Setup Intents APIs

[luisramos0]

Description

Setting new credit card info for Stripe payment method should use the Payment Method and Setup Intents API and support SCA. The off-session mode is probably applicable.

Do this for the Customer saved cards page.

There are probably two parts to this process:

• when card is added: use the Payment Method API to create the card on stripe
• when user approves an enterprise to charge the card: create a SetupIntent

Acceptance Criteria & Tests

A customer can add a card to be used later in the Account section. This will never trigger extra authentication.
A customer authorizes a shop to charge their card. Further SCA authentication should be handled correctly.

[luisramos0]

ok, I think I have enough info to discuss the challenge of letting customers authorize cards for subscriptions.

Currently customers check a box that lets a specific enterprise charge their card in a subscription. The card used is the default card of that customer. If when the sub is running the default card is
changed, that new default card will start to be charged.

With SCA we need to show some extra auth page when the customer authorizes a given shop to use a specific card. This will authorize a specific card in a specific enterprise.
The problem is: if after this the customer changes the default card, this auth will not work anymore... so, if customer changes default card we need to void the enterprise authorizations.

The solution I see is:

• when customer ticks the "allow charges" checkbox we show the extra auth step
• if customer changes the default card and there is an entry on the right side allowing charges on it, we show a warning and let the user choose A. "keep default card and authorization(s)" B. "change default card and void authorization(s)". In case B, user will have to re-tick the checkbox(s) for the new default card (and go through extra auth if applicable) otherwise subs that are setup will fail when charging the new default card.

I need feedback before I continue with this.

[lin-d-hop]

This solution sounds perfect. It feels intuitive... and possibly the only feasible solution. In your thinking did you see another solution @luisramos0?

Am I right in thinking that in the (rare) case of a shopper having two subscriptions for two different shops we will need a UX change? One card authorisation is valid for one shop so the authorisation needs to clearly note which card is authorised? Or we stick to the default card for all shops?

I see this case being a bit trickier. Would it be useful to map out the workflow to this or any mock ups to help think it through a little more?

[luisramos0]

case A - shopper has two subs for 2 shops but pays them with same default card - this is covered by my solution above, when default card is changed the two "allow charges" checkboxes on the right will be voided and the user needs to authorize again both shops by clicking the checkboxes.

case B - shopper has two subs for 2 shops and pays with different cards - this is not possible right now as the subs code picks the default card for all subs - it would be a new requirement not related to SCA. If in the future we implement this, the user will have to select a card when allowing charges for a given enterprise and in that case, the default card would not be used and we would only have to void the authorization in case the selected card was deleted.

[luisramos0]

I just found something important regarding the implementation:
We use active merchant v1.78 and we have extra code in ofn copied from v1.98 to work with Stripe Payment Intents.
I just found out that meanwhile (this June!) active merchant v1.109 is now capable of creating setup_intents in stripe:
https://github.com/activemerchant/active_merchant/releases/tag/v1.109.0

Ideally we will be upgrading to active merchand v1.109, otherwise we do what we did for payment intents and we will just manually update the code we have copied from v1.98 to the version in v1.109...

[andrewpbrett]

I tried out upgrading active_merchant to v1.109; it requires ruby v2.5 or greater, however. I also tried bumping it to v1.98; the current version of the Spree gem locks us to v1.78. This may be resolved once byebye Spree is deployed.

I tried to copy in code from v1.109 to get the setup_intents code; however, it looks like it also is coupled with a lot of the code in gateway.rb; bringing that code in as well meant bringing additional files in. I paused that approach for now and am working on the frontend piece that @luisramos0 describes above. It looks like it may be possible to get what we need without even bringing in the v1.109 code but I'm still investigating.

[luisramos0]

Hey Andy, we could bring just the setup intents method for StripePaymentIntentsGateway from v.1.109
Bring just this to our lib/active_merchant/billing/gateways/stripe_payment_intents.rb file:
https://github.com/activemerchant/active_merchant/pull/3662/files#diff-19492101b546175aa3ca6a16ec7d0a610d0adae03cbaf130eff54092dec8e0fb
That's just an idea.

[andrewpbrett]

Good catch; I'd brought the whole file previously, I'll give that a try next.