#mike-a_unexpected
gritty havenBOT
👋 Welcome to your new thread!
⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.
⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.
🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1483563445747187772
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
ruby grotto
Hi there 👋 hm, that does align with the preview of the expected behavior that I see here
iron notch
Yeah that's a good point, it does look like a redirect in that video with no modal first. In that case, in order to tell if the payment was successful I suppose we MUST rely on Stripe webhooks.
ruby grotto
Webhooks are the most reliable way to know, but if I'm not mistaken you should know the status by the time the customer hits your return_url.
iron notch
Do you mean because the return url will have params (the payment intent id and one other one, iirc, some sort of payment intent secret), we can query Stripe to check the payment status and perform whatever finalization operations we need to do if it was successful?
gritty havenBOT
ruby grotto
Yup, except for the last part.
I wouldn't recommend making your downstream fulfillment logic be dependent on the return_url being successfully hit and loaded, as we can't guarantee that will actually happen. The customer could close their browser or lose network connectivity unexpectedly.
Or am I wrong here and they're never returned to you?
iron notch
No, we do correctly end up at the return url with those two params.
Unfortunately we're integrating with Stripe via a third party service called Recurly and so we're having to work around their limitations, but that's not at all a Stripe problem and we'll be in touch with them.
So it was helpful to get this understanding of how the payment flow should be handled in this redirect / return url case. Now I feel more confident asking them how to achieve that from their end.
harsh crest
Hi there,
I am taking over from my colleague who had to step away.
I understand you are trying to implement RevolutPay as a Payment Method on the Payment Element. As my colleague already mentioned, when it comes to the question if a payment succeeded or not, we absolutely recommend relying on webhooks rather than the customer reaching the return_url.
iron notch
Thanks, it's good to have that confirmation from you and your colleague. I'll work with that 3rd party service (Recurly) to see what we should do when we receive the relevant webhooks.
It seems that there might be an alternative if we really want, though... in these Revolut docs (https://docs.stripe.com/payments/revolut-pay/accept-a-payment) it says we could "separate authorization and capture to create a charge now, but capture funds later". So that way it might be safe to wait for the return url to be hit, as we wouldn't capture funds until they do.
Do you agree with that? Any downsides to separating auth and capture like that?
harsh crest
Well, the purpose of the separate Auth and Capture is slightly different than this use case. You might still have the challenge with customers who don't reach the return url, due to user behavior (closing broweser), network issues, etc. In that moment there would be a hold on the customers card but no capture.
iron notch
Ok, that's not ideal.
harsh crest
The best way to handle post payment events, like we call out in our docs, would be through webhook events.
iron notch
Makes sense. I will get that working then. Thanks for your help!