m5rian

[ocean tundra]

Hello! We'll be with you shortly. Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.

• m5rian, 2 days ago, 8 messages

[neat surge]

hi! I think it should just work, the docs just aren't very clear

once you get to this point where the subscription + Invoice + PaymentIntent are created, instead of confirming on the backend as it says there, you can do it on the frontend

https://stripe.com/docs/js/payment_intents/confirm_card_payment#stripe_confirm_card_payment-existing like you can pass information back to the frontend and call this

but I guess to be clear now that I re-read, no you can't avoid passing the initial payment info to stripe.elements really, if you want to create the PaymentMethod first , when using the PaymentElement.

the only way to use the PaymentElement is either to have a client_secret already(which means creating the Subscription when the page loads) or to defer the creation of the PaymentIntent(which allows you to create a two-step process) with the other approach where you pass the amounts etc into the elements constructor

there feels like other solutions to your problem though, like just checking if the email <input> is complete when the 'pay' button is pressed, or leaving the button disabled until it is; or splitting the flow so you have one page that is for the email, and then after you submit the email you redirect to a payment page

[winter marlin]

which means creating the Subscription when the page loads
So thats what I'm doing right now and this is completely fine. So there is no way to also finalize the payment on the server with this technique? So normally I would call here something like that on the client

  const {error} = await stripe.confirmPayment({
    //`Elements` instance that was used to create the Payment Element
    elements,
    confirmParams: {
      return_url: "https://example.com/order/123/complete",
    }
  });

Do you know if its possible to instead use stripe on the backend for the final "yes"?

[winter marlin]

the 2 flow idea would work but i decided against it. its a bit complicated since people already log in my website and I think its bad ux for them to log in twice.

[neat surge]

Do you know if its possible to instead use stripe on the backend for the final "yes"?
only if you use the "deferred" flow which is the one that involves passing the amount/currency etc into the Elements contructor, which you mentioned not wanting to do

[winter marlin]

ok I see. I mean I can later validate that on the server again but its just double the work x)

[neat surge]

to be clear those details are only used for showing the customer what they'll pay inside some of the UIs inside the PaymentElement, they don't control the actual charge(that is determined by the PaymentIntent you confirm)

also if it helps you could for example pass back the amount/currency other details from the PaymentIntent(along with the client_secret) on page load and use them directly, so you only have one place in the code(in the backend) that produces the details

[winter marlin]

yeah I wanted to suggest that rn too

[neat surge]

you can also call https://stripe.com/docs/js/payment_intents/retrieve_payment_intent on page load to get details (but seems easier to just provide them via the backend call you're already making or the server-side-rendering you're alread doing rather than an extra call)

[winter marlin]

Alright sounds like a plan! Thank you so much :) Appreciate the help here!