Fraud Controls
Part of Checkout integrations
Testing webhooks for payment success and failure
Check payment webhook verification, durable acceptance, order updates, repeated events and recovery.
Test payment webhooks across the full chain: provider event, authenticated delivery, durable acceptance, handler outcome and order transition. Exercise success and failure separately, then test repeated and interrupted delivery. An HTTP acknowledgement alone does not prove the order changed correctly.
Set the expected order result
For each case, record the store order reference, provider payment reference, event type, provider status and expected store transition. Check the customer message and fulfilment queue as well as the endpoint response.
| Case | Result to inspect |
|---|---|
| Payment succeeds | The linked order reaches its permitted paid state once. |
| Payment fails | The order stays out of fulfilment and retains the failed attempt. |
| Payment is processing | The order remains pending until the required later outcome. |
| Delivery is repeated | There is no second transition or fulfilment action. |
| Events arrive out of order | The handler checks current state and retrieves or investigates missing context. |
Stripe's hosted Checkout fulfilment guidance says to check payment_status before fulfilment. A completed Session is not automatically a paid order: Stripe exposes a separate payment_status field, and the release rule must fit the offered method.
Verify and accept the delivery
Use the provider's permitted test tools. For Stripe, configure the endpoint's signing secret for the handler. Check that an invalid signature cannot change an order. Keep test and live secrets matched to their respective endpoints.
After verification, accept the event durably before returning a successful HTTP response. This may mean completing the small order operation or storing work reliably for a worker.
Return promptly. If the application cannot retain the event or work, do not acknowledge it as accepted. A worker failure after acknowledgement needs an internal retry or investigation path.
Check duplicates and recovery
Make the order transition safe when it is called multiple times with the same Checkout Session ID; Stripe's hosted Checkout guidance requires this. Protect the order transition itself against a second release. A late event should be interpreted against the current payment and order state rather than overwriting a valid later result.
Interrupt delivery in a permitted test setup and inspect the provider's delivery record and the recovered order. Test a retry or resend where available, and confirm the same order remains correct after repeated delivery.
Compare the records
For each case, compare the provider event, endpoint delivery, handler outcome and order timeline. Check amount and currency when they govern the transition. Investigate an unmatched event instead of creating an order from a loose amount match.
Stripe's testing guidance describes successful and declined sandbox payment scenarios, and its webhook guidance mentions Stripe CLI for local testing. A triggered sample event checks delivery and parsing; a complete permitted payment path is needed to check the actual order reference, amount and customer message. Record which kind of check was run. Neither establishes production settlement timing.
Key Facts from Stripe Documentation
- Stripe’s hosted Checkout guidance
- Always check `payment_status` before fulfilment.
- Completed Session ≠ Paid Order
- A completed Checkout Session does not guarantee payment success.
- Test tool availability
- Use Stripe CLI for local testing of webhooks.
- Sample event usage
- Triggering a sample event validates delivery and parsing.
