Cancel vs a late or duplicate payment confirmation

Background

Payment confirmation arrives asynchronously. A buyer can cancel an unpaid checkout at the same moment the payment confirmation is on its way, the confirmation can arrive twice, or it can never arrive.

How it works

• Buyer cancels: before cancelling, the system asks the payment provider whether the payment actually went through. If paid, it marks the checkout paid and rejects the cancel. If the provider cannot be reached, it does not cancel. Otherwise it locks the session, re-checks, cancels the unpaid orders and releases the holds.
• Confirmation arrives: verify the signature, confirm with the provider, lock the session. Already paid means do nothing (duplicate). Cancelled means revive: mark paid, restore the orders, and settle the stock.
• Confirmation never arrives: a background job checks pending payments with the provider and runs the same mark-paid path.

Design decisions

• One locked mark-paid path shared by the callback and the background check, so all three triggers serialise on the same row lock.
• Revive instead of auto-refund when money arrives after a cancel: the buyer paid, so the order should continue.
• Fail safe on uncertainty: an unreachable provider means don't cancel, because a wrong cancel on a paid order is worse than a slightly longer pending state.
• Re-check after acquiring the lock, because the state may have changed while waiting.