Compare webhook redelivery and idempotency guarantees across POS/aggregator providers to design a reliable order-ingestion layer that doesn't process the same event twice

Steps

1. Inventory each provider's redelivery behavior separately — retry backoff schedule, maximum retry count, and whether a unique event id or delivery id is included — rather than assuming a shared model across DoorDash, Uber Eats, Toast, and Square
2. Persist a dedup key per inbound webhook (provider-supplied event/delivery id, or a hash of the payload if no id is given) and check it before processing, rejecting duplicates as a no-op rather than an error
3. Make order-state transitions idempotent at the business-logic level too, not just at the webhook layer — e.g., 'mark order accepted' should be safe to apply twice without double-charging or double-printing a ticket
4. For providers that guarantee at-least-once but not exactly-once delivery, size your dedup key retention window to comfortably exceed the provider's maximum redelivery/retry window
5. Log and alert on webhook signature-verification failures separately from ordinary duplicates, since a spoofed or malformed request should never be silently treated as a harmless replay