Perry

[thick gyro]

Hello 👋
Sounds like you're confirming SetupIntents server-side?

[daring orbit]

yes on server side

[thick gyro]

Assuming you're using createPaymentMethod function for creating the payment method
I don't believe that function is supported on the ExpressCheckoutElement.

You could simply just use SetupIntents with ExpressCheckoutElement and confirm SetupIntents client-side

[daring orbit]

Right I can do that, but i need to pass payment method ID for future payments,
if you are saying future payments can be handled by different ID, may i know which one? and can that be created with Setup Intent?

[thick gyro]

Right I can do that, but i need to pass payment method ID for future payments,
Confirming the SetupIntent client-side attaches the PaymentMethod to the Customer object which you can retrieve server-side when you create future payments.

This guide shows how you can do it with PaymentElement but the flow for Express Checkout element would be the same
https://stripe.com/docs/payments/save-and-reuse?platform=web&ui=elements#charge-saved-payment-method

[daring orbit]

let me check this documentation, i will be back here in this inbox

Okay, so i see i always have to "confirm payment" for ExpressCheckoutElement, is that mandatory, since without it Apple payment UI throws error as payment is not confirmed

[thick gyro]

With SetupIntents, you'd use confirmSetup

[daring orbit]

okay, let me check quickly

okay that is helpful
main problem is my form is built and split into to 2 page form

1st page is used for just filling out the details and 2nd page is to review so that if user wants to edit their details, they can and on 2nd page we have submit button.

Card elements and apple pay is placed on 1st page
For card elements it is easier to do as i created payment method on 1st page as soon as user enters card details and then i would create setup intent and confirm it on 2nd page during form submission

but in case of express checkout, we have to call all these API's at once which breaks the actual flow
how can we deal wth this?

[thick gyro]

I see. Hmm thinking..

[daring orbit]

okay :),

[thick gyro]

Ah actually, Express Checkout Element does support creating a PaymentMethod separately
https://stripe.com/docs/elements/express-checkout-element/accept-a-payment#create-pm

So you can build the flow similar to CardElement and use createPaymentMethod

This would allow you to similar flow to the one mentioned in the guide here (but with Express Checkout Element instead)
https://stripe.com/docs/payments/accept-a-payment-deferred?platform=web&type=setup

Apologies for the confusion 🙂

[daring orbit]

No worries 🙂

so via this documentation i see we have to confirm setup (instead of confirmpayment) but this has be done then and there when user clicks on the apple pay button right? this cannot be split in 2 pages logic?

Like if confirmSetup can be done on 2nd page where we actually submit the form and not on apple pay button? payment method i can create on Apple pay button but confirming setup has to be done on form submission

[thick gyro]

but this has be done then and there when user clicks on the apple pay button right? this cannot be split in 2 pages logic?

Like if confirmSetup can be done on 2nd page where we actually submit the form and not on apple pay button? payment method i can create on Apple pay button but confirming setup has to be done on form submission
I am not 100% sure, have you tested it already? If not, I'd recommend running a quick test.
This flow is new so I am unsure what the expected behaviour is here

[daring orbit]

I am testing is right now, let me forward you the documentation of stripe i followed for card elements for 2 page flow

https://stripe.com/docs/payments/build-a-two-step-confirmation

this one

[thick gyro]

That is similar flow to the one I shared here no?
https://stripe.com/docs/payments/accept-a-payment-deferred?platform=web&type=setup

[daring orbit]

Yes you are right, it's just this one is built in 2 step confirmation where you create payment method ID on one page and then on 2nd page (checkout page) you so the setup intent creation and confirmation

for express checkout button, i have to do all these API calls in "onConfirm" method of ExpressCheckoutElement button

I just tested, and Apple pay/ExpressCheckoutElement is success with confirm setup API, but again that is happening on same page only 😦

So this is how i have done API calls for ExpressCheckoutElement

[thick gyro]

Ah I see what you mean

[daring orbit]

🙂 yup

[left lotus]

👋 hanzo had to step away

Perry is there anything outstanding here that I can help with?

[daring orbit]

Hello

Yes, can you please check the above conversation? for Apple pay i need to split API logic on 2 pages but on ExpressCheckoutElement we have onConfirm method on which if you don't confirms Setup it doesn't succeed and clear Apple pay UI

[left lotus]

Hmm I'm confused. createPaymentMethod is supported with Express Checkout Element: https://stripe.com/docs/elements/express-checkout-element/accept-a-payment?client=html#create-pm

So you don't have to confirm a SetupIntent until later if you don't want to

[daring orbit]

my query was related to, how can i create and confirm setup intent but on 2nd payment using ECE button
i followed https://stripe.com/docs/payments/build-a-two-step-confirmation documentation for Card elements, and would liketo do the same for ECE button

[daring orbit]

But if i don't confirm setup on ECE button, then UI which shows up for Apple pay denies the payment

once you have provided the touch ID

[left lotus]

No that should not be the case

[daring orbit]

https://stripe.com/docs/elements/express-checkout-element/accept-a-payment#create-pm here

[daring orbit]

Okay, so what should be the logic of onConfirm method on ECE button? so that Apple pay UI shows "done" as status

[left lotus]

Hmm okay let me double check. I was under the impression we don't error.

But I haven't tested this in a bit

So maybe I'm misremembering.

[daring orbit]

hmm okay, 🙂 , no worries

[left lotus]

Give me a sec

[daring orbit]

yes please 🙂

[left lotus]

Right okay so we only close the modal from a successful confirmation request. I thought we did put in another method to close the modal but yeah appears I am indeed misremembering. I'll follow up internally with some feedback but overall right now you'll want to confirm a SetupIntent as you noted in order to close the modal. Can you clarify how this breaks your flow exactly?

Why do you need to confirm the SetupIntent on the second page necessarily?

[daring orbit]

Okay, i understand, no problem
yes please, let me know when you have update on this 🙂

[daring orbit]

So basically on 1st page we have form where user fills in data like personal data and card details and then on 2nd page user can review their changes and can finally submit form, but if form needs and update then user can go back to 1st page and make amendments

for normal Card elements according to https://stripe.com/docs/payments/build-a-two-step-confirmation what i did is: Create payment method on 1st page and then when user is on 2nd page where finally they submit the form, at that exact moment i create setup intent and confirm the same so that form submission has all the details

[left lotus]

Yeah I mean that all makes sense but what is the issue with having to confirm the SetupIntent on page 1 instead of 2 when a wallet is used?

Like it will mean two separate paths here

Which is unfortunate

[daring orbit]

now i would like to achieve same behaviour for Express checout button as well, but in that case as you said it opens modal and closes it only when we confirm setup or payment

[left lotus]

Right I understand. Unfortunately until we support a method to close the payment modal based on createPaymentMethod you won't be able to do that

But you can always just confirm the SetupIntent earlier in the flow -- it doesn't really make a difference on the Stripe side of things.

[daring orbit]

so in this case suppose user has filled in apple pay details (All the API calls are done now on confirm) and user is on 2nd page and again if user wants to edit something and chooses to go with different card on apple pay, won't that create ambiguous PM_ID and Cus_ID for no reason and everytime when user edits their details?

[left lotus]

Well yeah you would have to handle detaching the originally added PM in that case

Or just ensuring you select the correct PM (the most recently attached one) when charging the customer

[daring orbit]

Okay, i understand, then i can confirm on one single page and just submit it as soon as modal closes, i think that's better

[left lotus]

Yep that is going to be the way to go here

I certainly see your use-case and I'll file feedback!

[daring orbit]

Yes exactly, so as soon as new PM is created, that is then passed to backend, no matter how many times user edits the page

[left lotus]

I do think we should support closing the modal based on receiving the PM here

One more question here

[daring orbit]

Yes, if you get any update on this, pleas edo let me know, but as of now i think flow is clear to me 🙂

[left lotus]

Why use a combo of Card Element + Express Checkout Element instead of just using Payment Element here?

[daring orbit]

i will have to check once, client's requirement changes everytime 😅 , apple pay was bought later hence

also now changing to payment element mean changing validation logic and designs, and we have near dead lines..... but i will consider this option for sure, if i get extended time

[left lotus]

Yeah I mean right now this is much more complicated than just doing everything here with Payment Element which would show both wallets and card and would make it easy to add other LPMs in the future if desired

Makes sense

Well, good luck!

[daring orbit]

Yes, you are right 🙂 i will keep myself updated on this

Thank you so much for your support and helping me every single time 🙂

[left lotus]

Happy to do it