#eddts-element

1 messages · Page 1 of 1 (latest)

hazy hornet
#

Hi! What is your question exactly?

short wraith
#

Hi Soma, So previously we had a checkbox which we controlled to let the user indicate they wished to save their card details. That in turn sent the setup_future_usage flag along with the confirmCardPayment call to stripe. With the new Payment element there is no option to send this flag as you just pass the entire StripeElements instance to the confirmPayment call. Looking at the docs it seems that the server must now pass the setup_future_usage flag when creating the PaymentIntent with Stripe, but I don't quite follow how that allows a user to choose whether or not to save their payment details as by the time you've mounted the Payment element you have already created the PaymentIntent in order to get the client_secret it requires. Does that make sense?

#

My initial assumption was that passing this flag was essentially enabling the option when creating the PaymentIntent - i.e it would then mean that the Payment element would render a checkbox to allow the user to choose to save their details, but when we tested it, by including this flag when creating the intent, it renders an additional message telling the user that their payment details WILL be saved, rather than letting them choose

hazy hornet
#

Makes sense! So you have two options:

  1. Ask the user if they want to save their card details before showing the Payment Element form. This way, when creating the payment intent, you already know the value of setup_future_usage
  2. Ask the user if they want to save their card details above the Payment Element form with a checkbox. If they change the default option, then you need to send a request to your server to update the existing Payment Intent.
short wraith
#

Right ok - I did think it may be the case based on the docs but it seemed a bit counterintuitive to have to say "do you want to save your card details" before you've collected any. In most situations I think a user would expect that option to be presented along with the card form, especially as this was previously the case.

#

So it sounds like to preserve the same user experience we will have to add a call to update the intent (option 2. as described above) - once that's done will the Payment element then render the payment options for the user to select? i.e Can they save multiple card details and then choose which to use for a given payment? This is what we currently have (again the old card element allowed you to just pass the payment method id)

hazy hornet
#

once that's done will the Payment element then render the payment options for the user to select?
I don't know. Give me a few minutes to test that.

short wraith
#

👍

hazy hornet
#

So no, the Payment Element UI is not updated when updating the Payment Intent.

#

You could create the Payment Intent with setup_future_usage:null, to show users the default Payment Element form. And if they check the box "save card" you update the Payment Intent, and if needed also display a new sentence on the page to explain what it means.

short wraith
#

Ok, not sure how that differs from what you said above - I think I get that now, but my question was what happens if a customer comes along and pays with card A, indicates they want to save that card for future usage, then makes their next payment with card B and also indicates they want to save that card. They then return at a later date and want to choose whether to use card A or B, how would they do that?

#

Previously we had our own UI to let them choose which saved card to use and then we passed the card id, but you can't do that any longer so I would expect the Payment element to offer them a choice? Otherwise how do they know which card is going to be used?

hazy hornet
#

Oh sorry, I miss-understood you question earlier.

Previously we had our own UI to let them choose which saved card to use and then we passed the card id, but you can't do that any longer so I would expect the Payment element to offer them a choice?
That's exactly what you would do: build your own UI to list all Payment Method attached to the customer, let them choose the one they want, then create a Payment Intent with the corresponding payment_method. Finally on the front end you confirm the Payment Intent.

short wraith
#

Ah right ok, I guess it's just because we previously created the intent quite early as all of this info was sent with the confirmation call to stripe rather than with the intent, so it sounds like we need to rework some stuff to gather more information before we create the intent.

#

I think this is quite a common scenario, especially for people migrating from the card element to the payment element, so may be worth a mention in the migration docs - one thing which made me uncertain was that the thumbnails on the docs sort of suggest that the payment element is going to do some of this work for you

#

As you can see in this screenshot the first two images are basically the scenarios I am discussing, but neither are then mentioned on those pages

#

Anyway, thanks a lot for your help