Keeping Inventory and Payment States Consistent During Checkout
A reference commerce architecture for stock reservations, asynchronous payment confirmation, duplicate events and operational reconciliation.
On this page +
This reference engineering case study explores a representative retail checkout. It is an architectural analysis, not a report of a client deployment or a quantified sales improvement.
The failure scenario#
A customer pays while the store is processing a stock reservation. The payment provider confirms success, but the storefront times out. The customer retries. Meanwhile, another buyer attempts to purchase the final unit.
A reliable design must explain which system owns stock, which evidence confirms payment and how operators resolve disagreement. A success page in the browser cannot answer all three questions.
Use separate state models#
The proposed design separates the order, stock reservation and payment attempt. An order may be awaiting payment while a reservation is active. A payment attempt can be pending, confirmed or failed without rewriting the historical meaning of earlier attempts.
Reserve stock using an operation that remains correct under concurrent requests. Give reservations an expiry policy and define who releases them. Avoid a detached “read availability, then subtract” sequence that can race with another checkout.
A repeated checkout submission should refer to the same logical attempt when appropriate. It must not create a new charge simply because the network response was lost.
Process payment events as business evidence#
Validate provider notifications according to the provider's documented signature mechanism. Persist a verified event durably before acknowledging it when using asynchronous processing. The worker applies only a valid business transition and records enough identity to recognize repeat deliveries.
Stripe documents that webhook events may be duplicated and are not guaranteed to arrive in creation order. For a Stripe integration, this means processing cannot depend on one delivery or a convenient ordering. Other providers require review of their own contracts.
When the correct state cannot be established from the event alone, reconcile against the provider through an authorized server-side integration. Keep payment credentials outside the storefront.
Decide the awkward cases before launch#
What happens when payment succeeds after a reservation expires? The business might attempt to reserve again, hold the order for review or initiate a refund workflow. The appropriate policy depends on fulfillment promises and available stock. It should not emerge accidentally from whichever callback runs first.
Likewise, define cancellation races, partial fulfillment and refund ownership. These policies belong in the scope and customer support guidance as well as in code.
Proposed acceptance scenarios#
- Two simultaneous buyers compete for one remaining unit.
- The customer retries after a timeout with the original attempt identity.
- A valid payment event arrives twice and creates no duplicate fulfillment.
- A later payment event arrives before an earlier event.
- The worker stops after changing local state and resumes safely.
- Payment succeeds after stock has been released.
For each scenario, compare order state, stock movement, provider state and fulfillment actions. These are proposed tests; this case study reports no measured implementation outcome.
Operations and next steps#
Provide an exception queue for unresolved orders, with a safe reconciliation action and an audit trail. Monitor the age of unresolved payment states rather than relying only on HTTP error rates.
BRIVOX's eCommerce development service can assess checkout integrations and operating requirements. Read the related transactional outbox engineering record for event-delivery trade-offs.
