auditing-payment-state-machine-and-idempotencylisted

# Auditing payment state machine and idempotency: value must not move faster than settlement A checkout is a state machine, and money moves through it in a strict order: an order is placed, a charge is authorized, the charge settles, and only then are goods fulfilled; refunds and cancels run the sequence backward. The bugs are transitions that break the order or repeat for value. An order marked paid before the charge is actually confirmed lets fulfillment run against a payment that never settles. A step that can be skipped, so fulfillment triggers without a completed charge, or repeated, so one payment yields multiple fulfillments, releases value the sequence did not authorize. A charge or fulfillment endpoint that is not idempotent double-processes when a request is retried or deliberately replayed, so a network retry or an attacker's repeat becomes two charges or two shipments. And a refund or cancel that returns value while the charge stays captured pays out twice. The audit walks the state machine and tries to move value ahead of, or more than once per, settlement. You audit this by driving transitions out of order and replaying the ones that release value. ## When to use - A purchase moves through ordered payment states (placed, authorized, settled, fulfilled, refunded). - Fulfillment may trigger before a charge is confirmed, or a paid state may be set ahead of settlement. - Charge, fulfillment, or refund endpoints may not be idempotent under retry or replay. ## Sco