"Register after Checkout" Pane causes payment method reuse to fail

I've submitted an MR with a solution to this issue, which makes sure customer ID's are associated with payment methods that we are saving, then retains them and assigns them to the User that gets created by Commerce.

I'm attaching a patch of the current MR for convenience.

The last submitted patch, 11: 3266382-anonymous-checkout-customer-11.patch, failed testing. View results →
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

Discovered an issue with the latest solution, which is that a payment intent can't use a payment with a different customer ID. You can see this issue emerge if you select saved payment method associated with a different customer ID (one using the field added in this patch), then go back to change payment to a different or new payment method.

This is feeling like a generally bad approach to solving this problem. Instead, we should probably be smart about associating the new user with the customer record in Stripe.

However, here's a workaround which refreshes the payment intent.

Updated patch & PR to prevent overwriting of a user's existing customer ID. This commit seems relevant beyond this issue's specific problems, as it's certainly possible for a user to have a customer ID, then make an anonymous purchase using their email address, which will then break their existing saved cards without a fix like this.

Alex Bukach → changed the visibility of the branch 3266382-register-after-checkout to hidden.

Alex Bukach → changed the visibility of the branch 3266382-register-after-checkout to active.

Re-rolled patch #7 against the head of 8.x.1-x and created MR!101.

An enhancement has been added to assign the payment method when the customer has orders assigned to them. (Note: this also handles other scenarios, besides the "Register after Checkout" pane, such as checkout flow with create account for guest user or checkout flow with sign to existing user options enabled.)

This allows the payment method to properly be reusable.

Some notes:

1. This works for the Stripe Payment Element. If needed for Card Element, please create a separate issue to port similar logic, as it would require some refactoring in the Stripe.php class.

2. If backfill is needed, the database update in this thread might work on smaller sites, but not for larger sites with 100k/millions of records. A more targeted and performant query would be needed, along with the ability to defer/skip this revision, to be performed offline. A drush command might be a better option. That should also be a separate issue.

Automatically closed - issue fixed for 2 weeks with no activity.