2

You shouldn’t run the ‘create a transaction’ workflow, or any other post-purchase actions in the same workflow as the Stripe checkout is created, as the user may not even complete the payment, but your transaction will still be created, and access given to the (non)customer for download.

You should also NOT rely on using a success page on your app for post-purchase workflows (like creating transactions, or giving access to certain parts of your app).

A payment might successfully go through, but there could be any number of reasons why the customer may not reach the thank-you (success) page (connectivity issues, hitting the back button, a power-cut etc.), so your workflow will not be triggered and the customer won’t get access to what they’ve just paid for.

Conversely, it’s also possible for people to reach the success page when they haven’t made a purchase (perhaps a buyer shares the success url, including any parameters with a friend, or a buyer bookmarks the page and revisits it several times).

In these cases you’ll end up with transactions created for people who haven’t paid, or duplicated transactions for the same buyer.

So using ‘in browser’ workflows based on users visiting a particular page in your app is not best practice for handling post-payment processes which must only be done upon a successful payment.

Instead, use a Stripe Webhook to trigger an API Endpoint in your app, and run the necessary actions there (create the transaction, allow download access to the user etc.). You can pass all necessary data needed for the workflow through to Stripe, and back to your app via a Webhook, using URL parameters in your initial checkout call.

1 Like