Follow an order notification between systems
Receiving a notification and completing the related business action are separate steps. The receiver needs to authenticate the message, recognize duplicates and handle failures. Provider retry and ordering behavior must be checked; it is unsafe to assume that one delivery arrives exactly once or that all events arrive in business-process order.
Illustrative sequence: event evt_demo_17 reports payment completion for order ORD-DEMO-8. The receiver verifies it and records a pending work item. A worker creates the fulfillment task with an idempotency key, then marks the event complete only after the required work succeeds. A retry checks whether work is pending or complete. If processing fails, the item stays retryable; repeating it must not create a second shipment. The implementation needs a transaction or another durable recovery design for failures between these steps.
Plan retries duplicate messages and failures
The made-up identifiers describe a design, not a working integration. Stripe explicitly documents duplicate deliveries and ordering considerations; other providers may use different guarantees and identifiers. A successful HTTP acknowledgment alone does not prove the stock, email or fulfillment task completed.
Next, define the event, receiving owner, duplicate-handling rule and recovery path. Test a repeated message and a processing failure in an authorized environment, then reconcile the source event with the final business record.
Website field guide · Verify purchase and demo events after a website change · Inventory synchronization
Reference: Stripe documentation: webhooks and duplicate events. Checked November 4, 2026.