Idempotency

Idempotency means an operation can be repeated without changing the outcome. Charge a card once, receive the webhook three times because the network retried, and the customer should still have exactly one purchase and one grant of access.

Payment providers retry deliberately. They assume you handle repeats. An app that grants an entitlement every time a webhook arrives will hand out three of them, and an app that inserts a row every time will show three charges to a customer who paid once.

The usual answer is an event id stored on first receipt and checked before any write. It is simple and it is almost never there in a first version. No external check can see it, so payment handling stays Not verified until someone replays a webhook and watches what happens.

No incident in the library maps to this one yet.