No. Do not fulfil orders only from the thank you page. A customer can pay and never load it. Fulfil from a verified server side event instead, and write the fulfilment step so it can run more than once for the same order without shipping twice.
Why the return page is unreliable
Stripe's guide to fulfilling orders states that you cannot rely on triggering fulfilment only from your checkout landing page, because it is not guaranteed customers visit it. Its example: a customer pays successfully and then loses their internet connection before the page loads. The guide also says automatic fulfilment with webhooks is required for subscriptions and for payment methods with delayed success notification, because their state changes after the checkout session completes.
There is a security angle too. A return page URL is something a buyer can type or alter. If your code ships goods because a request reached a success URL, a visitor may be able to trigger that without paying.
What a safe fulfilment path looks like
- Receive the payment event on a server endpoint and verify its signature before trusting it. See our guide to verifying payment webhook signatures.
- Look up the session or order from the payment platform by ID, rather than trusting values in the event body alone.
- Check the payment status field to decide if the order needs fulfilment.
- Fulfil the line items.
- Record that this order was fulfilled, in the same transaction if you can.
The guide says the fulfilment function may be called multiple times, possibly concurrently, for the same session, and that it must handle being called repeatedly with the same ID. Step 5 is what makes that safe.
Return page versus event: a comparison
| Question | Thank you page | Verified server event |
|---|---|---|
| Runs if the buyer closes the tab | No | Yes |
| Can a buyer trigger it by hand | Possibly | Not without a valid signature |
| Covers delayed payment methods | No | Yes |
| Needs repeat safe logic | Yes | Yes |
Use the page for what it is good at
The return page is fine for showing a message and clearing the cart. Treat it as display only. Anything that moves stock, grants access or sends goods belongs behind the verified event.
Quick check
Can I run fulfilment from both the page and the event?
Only if both call the same repeat safe function that records fulfilment. Otherwise you risk shipping twice.
What if the event arrives late?
Design for delay. The order stays pending until the verified event arrives, and your support team should see the pending state.
Sources
Safeguard can flag risky patterns in checkout code during review, which helps catch a fulfilment step that trusts a request parameter.
Last reviewed: 19 October 2026.
