#jonas reif - creatings subscriptions
loud mica
Hmm in this case you're going to need to make multiple round trips to accomplish this -- you'd first send the email/user info to your server to see about the customer/user existience
then you'd create the subscription for the new/existing customer
i'd suggest using payment_behavior=default_incomplete
then you'd send the client secret of the payment intent on the first invoice back to the client to confirm the payment with elements
Should work, but also note you want to protect your endpoint from abuse if its unauthenticated:
https://stripe.com/docs/card-testing#mitigations
floral fractal
But that means that I have to request our backend before "clicking" the purchase button. Because before I'm able to show Stripe Elements I need the client_secret.
Is there also another better way?
bleak peak
hello, I'm catching up here, one sec
correct, in order to render a PaymentElement from Stripe Elements, you need a client_secret
floral fractal
Yes, but my described use case does not have a client_secret.
Should I explain my user case again?
bleak peak
why would it not?
it would if you follow what synthrider advised you to do here
#921079304220213269 message
you're just creating a Subscription right
floral fractal
Yes but can I show the payment form before validating/creating the user?
Thats how our checkout page might look like
bleak peak
Yes but can I show the payment form before validating/creating the user?
on a technical level, yes you can
floral fractal
Ok thanks for the info.
To summarize your suggestion:
When user hits the purchase button, we:
- frontend sends the
emailto server - server creates a default_incomplete subscription there with either an existing or new user
- server returns the client_secret to frontend
- frontend uses this client_secret and submits the payment form
bleak peak
yes that sounds right