The problem with thank-you pages
When a customer pays online, the payment provider usually sends their browser back to your site — a "success" or thank-you page. It's tempting to start the workflow there: send the receipt, start onboarding, mark the invoice paid.
The browser redirect is not a reliable signal, because:
- People close the tab or lose connection before the redirect, so a real payment never triggers anything.
- Anyone can visit the URL. If the page starts the workflow, a person who guesses or shares the link can trigger it without paying.
- Payments can still change. Some methods take time to settle, and payments can fail, be reversed or be disputed after the customer sees a success screen.
What a webhook is
A webhook is a message the payment provider sends directly to your system (server to server) when something happens: a payment succeeds, fails, is refunded or disputed. Because it comes from the provider, not the customer's browser, it can be verified.
Payment providers document this carefully — see Stripe's webhook guide and PayPal's webhooks documentation. Common themes in both:
- Verify the message. Providers sign webhook messages so you can confirm they're genuine. Unverified messages should be ignored.
- Expect duplicates. Providers may resend the same event. Your workflow must recognise an event it has already processed and do nothing the second time.
- Expect events out of order. Don't assume "created" always arrives before "succeeded".
- Respond quickly. Acknowledge receipt fast and do slow work afterwards, or the provider may retry.
What to trigger from which signal
| Action | Trigger it from |
|---|---|
| "Thanks — here's what happens next" on screen | Thank-you page |
| Payment receipt email | Verified payment-succeeded event (or the provider's own receipt) |
| Marking the invoice paid | Verified payment event |
| Starting onboarding or delivery | Verified payment event, if payment is a precondition |
| Refund or dispute alerts to your team | Verified refund/dispute events |
Questions to ask whoever builds it
- Which exact event starts the workflow, and is its signature verified?
- What happens if the same event arrives twice?
- What happens if the webhook endpoint is down for an hour? Will the provider retry, and will we notice?
- Where can we see a log of events received and actions taken?
- How do we test it without real money? Providers offer test or sandbox modes for this.
Limits
Webhooks make payment automation more reliable, not infallible. Endpoints go down, keys get rotated, and settings change. Monitor failures — see knowing when an automation silently fails — and reconcile against the provider's dashboard regularly. Handling card data yourself brings separate obligations under the PCI standards; hosted checkouts keep most of that with the provider.
Questions
Is the thank-you page useless then?
No. It's good for telling the customer what happens next. It just shouldn't be the only signal your systems use to decide that money has arrived.
Do no-code tools support webhooks?
Many connector platforms can receive webhooks or use native payment-provider triggers. Check that the trigger is based on the provider's confirmed event, and that duplicates are handled.
Sources and further reading
- Stripe's webhook guide docs.stripe.com
- PayPal's webhooks documentation developer.paypal.com
- PCI standards pcisecuritystandards.org
Official documentation changes. Check the current version before you rely on a rule, limit or setting.
Next step
Start with one workflow worth fixing.
Bring the real steps, the tools you already use and the place the handoff gets stuck. We review feasibility, access and approval points before quoting — no instant integration promise.
See Business Automations for what we scope, or prepare a custom quote brief.