#salt
amber adder
lofty timber
Is there a reason you're creating a separate PaymentIntent before creating the Subscription?
uneven kindle
yes i need the clientSecret. 🙂 I had already tried it in such a way that I created the subscription early and then used the client secret. However, I then have a subscription+invoice even if the purchase is canceled
lofty timber
What I'd recommend is following this guide -https://stripe.com/docs/payments/accept-a-payment-deferred?platform=web&type=subscription
(That's assuming that you're using Payment Element - if you're using something else let me know)
Basically, that flow allows you to collect/create the PaymentMethod first, and THEN you'll create the Subscription and attempt to confirm it
While it is possible fory ou to be left with some extra subscriptoins that need to be cancelled if payment never actually ends up being successful
It should minimze the number of unwanted subscriptions since you won't have to create them so early'
uneven kindle
i use nodejs, react native and Platform Pay
lofty timber
What is Platform Pay? Is that a third-party?
uneven kindle
is the wording from the stripe sdk - meaning googlePay and applePay
lofty timber
Ahh right, forgot that's what we called it in our react native sdk
uneven kindle
I'll take a look at the link, in case I have further questions should I start a new thread or write back here?
uneven kindle
ah i see does that mean that the customer doesn't buy immediately, but only gives me their payment details and permission to debit?
lofty timber
Your customer would still buy immediately, it's just changing the order that things are collected/created
So instead of creating the Subscription first, you'd collect the PaymentMethod first and then immediately use it
uneven kindle
thank you you untangled my brain