Preventing duplicate webhook orders starts with a business rule: one accepted purchase should have one fulfilment outcome. A webhook endpoint can receive a message more than once, while the customer may also refresh a confirmation page. If every arrival creates another order, an ordinary recovery mechanism becomes a warehouse problem.
Imagine a hypothetical ticket purchase. The payment provider confirms a charge, the application records the booking, and the connection fails before an acknowledgement returns. The provider may deliver the notification again. The correct result is a traceable repeat delivery attached to the existing purchase, with no second ticket issued.
Choose the authority for each decision
The checkout page can explain what the customer sees, but it should not independently declare that money has been received. Decide which provider record and server-side transition authorise fulfilment. Give the business purchase its own identifier before redirecting the customer to an external payment flow.
Separate the identities of the purchase, provider transaction and webhook event. They answer different questions. A support operator may need to see several events related to one payment, while the warehouse should still see a single order eligible for dispatch.
Preserve the message before doing slow work
Define how the endpoint verifies a notification and records receipt before handing longer work to a queue. An acknowledgement and a completed shipment are different milestones. A failure between those milestones needs a recoverable record rather than an assumption that everything finished.
Agree how repeated event deliveries are recognised and how the business transition is protected. Recording an event identifier alone is insufficient if a crash can occur between creating an order and recording that identifier. Ask the engineering team to demonstrate the actual failure boundary in its chosen storage system.
Handle late and out-of-order information
A later-arriving message does not necessarily describe the latest business state. Keep a defined transition model for pending, confirmed, cancelled and refunded purchases. Decide how the application checks the authoritative transaction when messages conflict or arrive after an operator has already investigated.
Provide an operations view that explains the current state, the last checked provider state and any unresolved difference. Staff should not need to resend charges to repair a missing order. Reconciliation must be a controlled process with permissions and a record of what changed.
Test one purchase through several interruptions
Deliver the same test event repeatedly and confirm that only one fulfilment action occurs. Interrupt processing after receipt, after order creation and before acknowledgement. Resume the queue and inspect the final order, transaction link and delivery history.
Then test a delayed confirmation and a notification arriving after cancellation. Include customer messaging: a repeated email can be confusing even when the database has only one order. Use the provider's current documentation for its exact delivery and signature behaviour. When asking Brainbaby Labs to build a payment integration, include this recovery demonstration in acceptance, alongside the normal successful checkout.