#streetfeels

1 messages · Page 1 of 1 (latest)

mild echoBOT
upper falcon
#

Hi 👋 I believe you're right about not being able to update the Customer that is associated with a Payment Intent, did you encounter an error confirming that when trying to do so?

mild echoBOT
empty parcel
#

We have not yet tried it implement it for this particular case, but believe this to be the case from previously trying to integrate.

#

However, we will certainly try it. Just trying to get ahead and plan for what might be alternate solutions in the event that that approach fails.

#

Actually this is the error we got:

#

"message": "You cannot modify customer on a PaymentIntent once it already has been set. To fulfill a payment with a different Customer, cancel this PaymentIntent and create a new one.",

upper falcon
#

Gotcha, alright, that is what I expected. Could you move the email association part of your flow so it occurs sooner in your process, so you can create the Payment Intent against the correct Customer from the start?

empty parcel
#

Yes that is the challenge, we implemented the Wallet option for ease of use by not having the user enter name and email when not necessary, i.e, user only has to enter name and email only once via Apple / Google Pay. Prior to that, the idea is to not collect this info, so currently, we don't have a way of knowing if a user already has an associated customer object.

#

One possible solution that we came up is to associate multiple customer objects with a payment intent, although this would not be ideal. Any other ways to resolve?

upper falcon
#

You can't associate multiple customers with a Payment Intent, a Payment Intent can only be associated with a single Customer.

The approach that comes to mind is this one:
https://stripe.com/docs/payments/build-a-two-step-confirmation
Where you first create a Payment Method and then process the payment for it, so you could then check the provided details before creating the Payment Intent.

Add an optional review page or run validations after a user enters their payment details.

#

To clarify though, are you using the Payment Element for your flow? I noticed you said you don't collect email outside of the wallet modals, so I'm not sure if you're using the Payment Element that wouldn't collect an email address if used directly, or if you're using a different approach so only Google/Apple Pay are available options.

empty parcel
#

We're using a combination, Payment Element for the credit card, and Payment Request Button Element for the Wallet.

We added custom inputs for name and email if the user chooses the credit card flow. And the name and email are updated in the customer object as they are entered.

#

If the user chooses Google or Apple Pay, then, it kicks of the respective flows via the Payment Button Request Element:

upper falcon
#

Hm, I'm not sure if there is a good way to change the Customer at the last second with the Payment Request Button flow. I'd consider moving the name and email collection out of the Card specific area and make it a more general field, then suppress the collection of name and email from the wallet flows.

empty parcel
#

ok got it, and to confirm, is there no way for Stripe to automatically get the name and email from the wallet card and associate it with a non-guest customer object?

upper falcon
#

No, we will not automatically try to associate the Payment Intent with an existing Customer in that fashion, partly because multiple Customer objects can have the same email address.