Best Practice for Handling a Crash During A Stripe Based Checkout

As my app gets more usage, I’ve had a couple of cases where there was “crash” of some kind during the execution of the server action which implements my Stripe based payment process.

This meant that the Stripe payment was processed but my server action stopped working before my app got to record the payment. This resulted in the user going back into my booking form and paying a second time, but only a record in my app of a single payment.

I created the app before there was a Stripe interface in Wappler, so I have one big server action which processes the Stripe payment AND creates all the database records in my app.

I’m wanting to find a fix for this scenario, and I’d love to know how others have structured their checkout server actions to potentially protect against this situation!

Best wishes,
Antony.

Hey @Antony
Where is the app hosted?
Can you access a log file?

This sound strange, so the stripe step is executed but not the next ones?

What about a try/catch step?

In my experience, this happens commonly. Every once-in-a-while, some payment fails to be processed. Its either a missed webhook, or as you have seen in your case - random server issue.

A good solution could be to use queues. You still work on PHP from what I know, so not really an option for you with Wappler. Queues have option to “retry” a job if it fails.

Another suggestion would be to use transactions, which was recently introduced in Wappler. With that, you can at least be sure that your DB does not have weird data in case of SA failure.

One more option is using schedulers to monitor if a payment didn’t go through, using Stripe APIs etc and generate an alert. But again, can’t do it with PHP in Wappler (or otherwise from what I know).

In conclusion, there is no fool-proof fix (probably never can be) - given how computers work. There can only be monitoring and automated retires/alerts which help with handling such exceptions as quickly as possible.

1 Like