Multiple UPE - Explore single payment intent with multiple instances of UPE

[harriswong]

Description

This came up in one of the team chats. Currently, we have a PR (#3968) to split UPE into multiple UPE. Each split payment method is its own UPE instance.

A question came up: "Have we tried to reuse same payment intent with multiple instances of UPE?"

We would like to investigate/confirm the feasibility of this. Here are the proposed steps to confirm:

1. Create a single payment intent with all payment types allowed on it ( payment_method_types arg).
2. Create an instance of UPE with that intent, but pick only a single PM to display on the instance (hope it's possible via config options).
3. Create another instance of UPE with the same intent, but other config options (for another PM)

Acceptance criteria

Answer the question - "Have we tried to reuse the same payment intent with multiple instances of UPE?"

Additional context

Check p1661964644907429/1660685029.312559-slack-CGGCLBN58 for more context.
Most likely not possible paJDYF-5dK-p2#comment-13799

[FangedParakeet]

Create an instance of UPE with that intent, but pick only a single PM to display on the instance (hope it's possible via config options).

So it turns out that this is indeed possible, though not exactly in the way that I'd imagined!

By first tweaking the #3968 branch, so that all payment elements would share the single intent--all using the same payment method--I confirmed that it is possible to have multiple payment elements on the page all using the same payment/setup intent. I tried to update the payment intent after mounting, but this had no effect on the mounted payment elements...which proved that the payment element only presents the payment methods included in the payment_method_types field and is unaffected by any changes to the intent after the initial mount.

This means if we update the value of this field to contain a different, single payment method before we mount each new payment element, this will permit us to present us multiple payment elements present on the same checkout, all using the same payment or setup intent, but all displaying different payment methods at the same time! The actual payment_method_types value will always refer to the most recently mounted/updated payment method and not necessarily the actual payment method currently selected or used in the final transaction; however, this is not a problem at all, because in every UPE checkout we always update this value to the correct, chosen payment method immediately prior to confirming the payment, so this will always be corrected at the last available opportunity and it appears Stripe's API has no outward offense with us doing this.

In this implementation, we will only need a single payment/setup intent per UPE checkout and only a single transient to store this intent ID as long as the checkout session persists. The main drawback is that we need to keep updating the payment intent when we mount a new payment element with a new payment method, which creates a lot of noise on the event history on the payment intent.

Oops, did I do that?

To address this situation, I've created two parallel branches that implement this feature in slightly different ways.

Option 1: Mount all payment elements on page load

See #4838.

In this implementation, just as in the current branch, we mount all payment elements immediately on page load. This means that the elements all mount and load while the customer is completing their checkout. This option probably has the lowest wait time for a customer, however, there will be a new update request to the shared payment intent for each enabled payment method.

This creates a lot of unexpected noise on the payment intent request history and perhaps sends unnecessary requests to update the intent for payment methods that are never used or even selected at checkout.

Option 2: Only mount payment elements when they are selected

See #4837.

In this implementation, we only update the payment intent to a new payment method when that payment method is selected at checkout. This creates the minimum amount of requests to Stripe's API and leaves the fewest traces on the intent itself; however, whenever the customer selects a new payment method for the first time at checkout, they will have to wait while we update the payment intent and mount the element. This isn't a particularly long wait, but they still have to stare at a preloading spinner for some amount of time.

Personally, I prefer the second implementation, because the history on the intent seems cleaner and it feels nice not to bother Stripe with so many unnecessary requests: though, this could be the developer in me, since the former approach has a more optimal wait time and functions more similarly to the current branch.

Just FYI, Stripe is nearing the rollout of a new feature that will supposedly allow us to mount a payment element without requiring a payment intent up front, which would make this entire approach ultimately redundant, if it works as described. However, while we figure out what exactly that new feature allows us and how we can implement it, we can sleep easy knowing that this approach is still possible as a fallback.

[FangedParakeet]

I am closing this issue for now, since this has now been explored and thoroughly excavated up here. With Stripe's new UPE integration on the horizon, it isn't yet clear or obvious that we would be eager to implement any of the solutions described above just yet; but they shall not be forgotten and will remain in our back pocket, should their hour of need arise in the future.