#morunas
formal quest
hi there!
robust kite
Hi soma 🙂
formal quest
Using SetupIntent with Immediate Subscription Creation: Concerned about potential double 3D Secure authentication,
yes we don't recommend this to avoid the double 3DS.
Using PaymentIntent with Immediate Subscription Creation: We're considering this approach
But why not simply create a Subscription, and use the PaymentIntent generated by the Subscription? That's the recommended flow
this is explained here in details: https://stripe.com/docs/billing/subscriptions/build-subscriptions?ui=elements
robust kite
I was trying to avoid the allow_incomplete, as a Subscription would be created, and then if e.g. 3DS fails, it requires some cleanup
with PaymentIntent I'd guarantee that the first subscription is only created if payment succeeds "on session" and that it is successfully setup for future charges
formal quest
yes you could technically create the PaymentIntent yourself, and then add a free trial to the Subscription to avoid the user paying twice. but that seems a lot more complicated that using the default Subscription flow.
robust kite
Alright I'll go with the recommended. My fear was regarding the management of default_incomplete behavior and failing 3DS auth leaving an "incomplete" Subscription, and when does it get provisioned, but I guess if I provision only when the subscription is active, then it'd be ok
formal quest
but I guess if I provision only when the subscription is active, then it'd be ok
yep that's what we recommend
robust kite
I'll give it a try 🙂
Thanks!
Ok so I have it working with the default subscription flow. The only bit that haunts me now is that provision is done via the hooks, so async to the client session. For the flow to be complete and seamless, I'll need to keep pinging the server for a status + potential timeout. That's also what I wanted to see if I could avoid with PaymentIntent 😛
formal quest
can you clarify how your payment flow workes exactly? why do you need to "keep pinging the server for a status"?
robust kite
- client picks a plan
- client fills in a single form that includes billing information, Card element and invoice preview (which updates based on country selection, e.g. 25% VAT for DK)
- client submits
- I call the server to create subscription
- server returns the payment_intent_client_secret which I use to confirmCardPayment
- now the response from confirmCardPayment will give me the paymentIntent's status and...
nevermind, I'm an idiot. So at this point I am SURE that there has been a resolution and I can just ping the server to provision subscription accordingly (which of course should check that there is indeed an active subscription) and then just refresh, right?
What through me off was point 7. of the tutorial you gave, where it says that to provision access to the server I should listen to those events
I understand it's important to also react to the hooks in case e.g. the client loses connection before the subscription is allocated and things like that. But then if I do get a reply from confirmCardPayment and PaymentIntent status is succeeded... then I know I can ping my server to provision the chosen plan/subscription features.
formal quest
So at this point I am SURE that there has been a resolution and I can just ping the server to provision subscription accordingly (which of course should check that there is indeed an active subscription) and then just refresh, right?
correct
however you should still use the webhook events to handle any post payment actions, because the user could close their browser windows on the frontend at the wrong time.
robust kite
Alright. I should comment that the documentation could be a bit more clear on the provisioning step, because it seems to indicate that the way to provision is via the hooks, when that can potentially hinder the user experience giving the behind the scenes nature of it (unless again, some "ping server for update" workaround is done)
Unless I am missing something :- )
formal quest
you should provision the Subscription using webhooks. and on the frontend, when the user reach teh return_url, simply check that the Subscription is active to display any type of success message you want.
robust kite
I'm using React so there is no return_url, it's all done without refreshing.
I can display a message saying it was successful, but at that point am I sure the hook has been called and handled?
or does confirmCardPayment only return once all hooks have been called and returned 200 OK?
nimble orioleBOT
wise root
no, it doesn't wait for webhooks
it's pretty normal to something like show the user "thanks, you'll receive an email shortly" on the frontend, then send them a receipt/'here is your product' email from your backend when the webhook handles it, and the webhook also updates the database that your frontend can make calls to or poll to check for access to some feature
robust kite
ya all that 100%. The key question was what exactly to do right after confirmCardPayment returns status succeeded. What I understand I will need to do to immediately update what the user sees correctly, is ping server side for confirming/provisioning the subscription (rather than wait for hooks), and provision it, because if confirmCardPayment has succeeded, then the subscription must already be active
wise root
well no, because the thing is the code that you're executing after confirmCardPayment succeeds might be invoked by a malicious client somehow
or a malicious client calls your /provision-access backend URL directly
robust kite
fair enough, but that's why I said that on my provision access endpoint I will check if indeed there is an active subscription :- )