the same order, twice

Payment providers retry. Customers double-tap. Networks drop the acknowledgement, not the request. On a platform that turns a payment acknowledgement into order state, the failure mode is not an error page — it is a second order, a second kitchen ticket, a second charge, and a support conversation that begins with an accusation.

Two guards were added, and they are deliberately not the same guard. The first is a replay check: before applying an acknowledgement, the system reads whether that acknowledgement was already processed, and if it was, the work does not happen again. That handles the ordinary case. It does not handle two identical acknowledgements arriving at the same instant and both reading not-processed before either writes. So a uniqueness constraint over the source and the order exists as a race backstop: the database is the arbiter, and one of the two transactions loses cleanly instead of both succeeding.

The same reasoning was applied at the front of the funnel. A submitted checkout can carry an idempotency key, and a retried submit returns the order it already created, marked as replayed, rather than creating a second order and a second queue entry. Three regression tests cover the round trip, the rejection of a reused key, and the uniqueness claim itself.

Neither guard is clever. Both are boring, and that is the quality being demonstrated: the invariants are enforced where timing cannot bypass them, and the tests are written against the race rather than around it. What it proves is that money-touching paths here are designed around duplication as the expected condition, not the exceptional one.