Idempotency keys before the first retry storm
Why payment and webhook flows need explicit idempotency before production traffic teaches you the hard way.
Retries are not optional on flaky networks. Without idempotency keys, retries become duplicate charges, duplicate shipments, or duplicate account links. Integration risk briefings at Content Leafcore almost always open with: where does the key live, who generates it, and how long do you remember it?
Client-generated keys
Let the caller supply a key for create-style operations. Persist the key with the resulting resource id. Replays return the original result instead of inventing a second one.
Webhook delivery
Partners will retry. Your receiver must treat the same event id as the same work item. Logging “processed” without storing the id is how duplicates sneak past dashboards.
Time bounds
Document retention for keys. Forever is expensive; too short invites double work when a delayed retry arrives. Match retention to your partner’s retry policy if they publish one.
If you are wiring a new partner soon, a short integration risk briefing can list the exact questions to ask before traffic flips.