A payment webhook once ack=timeout -> retry -> reorder -> duplicate ack can look healthy in logs while applying the same intent twice. The common handler invariant — “return 200 fast, then process asynchronously” — is not sufficient unless a stronger invariant holds:
Invariant: for one intent_id, at most one externally visible effect may commit, no matter how many deliveries, retries, or reorderings occur.
This article gives a small canary workflow you can run before scaling webhook traffic. It uses a free model option and free server option from MonkeyCode only as a low-friction place to generate adversarial traces and execute a disposable harness. Disclosure: This article was prepared as part of MonkeyCode's product outreach. I am not claiming specific model names, quotas, hardware, duration, permanence, or benchmark results; treat free access as an operator-supplied availability option, not a dependency of the method.
Assumptions
One producer emits business intents with stable intent_id; delivery to the consumer is at-least-once.
