#bodger
viral galleon
You should do this asynchonrously upon receipt of payment_intent.succeeded events with a webhook
We don't recommend handling fulfilment/post-payment actions in the confirmPayment handler: https://stripe.com/docs/payments/handling-payment-events
summer owl
OK - so I need to use the webhook. Why do you not recommend doing it when the confirmPayment returns successfully? It seems to work when I've tested it.
viral galleon
A few reasons:
- A user may close the browser before
confirmPaymentresolves. - If you code errors/fails, there's no opportunity to retry the fulfilment logic (where as there is with a webhook).
Sure it'll 'work', but it can be brittle and we just generally advise against it
summer owl
Ah OK - so would I then just redirect the user to a page which constantly checks the payment intent to see what it's status is before telling them that their payment was successful?
viral galleon
Sorry, I don't understand
You can still show a success page once confirmPayment resolves, sure
We just don't recommend doing any business critical logic there, like a database write or shipping fulfilment or whaetever
Do those parts in the webhook
summer owl
Right - I was just thinking of the situation (rare thought it might be) when the user sees the page that says "payment succeeded" but then, when they look at the page that lists all their payments, the one they just did isn't there (because it's waiting to be created by the webhook)
viral galleon
I guess you mean a list of 'payments' from your backend?
summer owl
Yeah, as I'm not "shipping" anything - just allowing people to pay others online.
viral galleon
Sure, I mean that could happen theoretically. But the webhooks are ~instant (most of the time). If that's a concern just mutate local app state to add the payment whilst the webhook actually persists it to your database
compact shardBOT