The final ticket was held, but capture counted it twice

Guest checkout created an important identity boundary

Guest checkout was an intentional product decision. Requiring an account before purchase would add friction at the most important point in the customer journey, particularly for buyers arriving from an event link and trying to secure limited inventory.

The system therefore supports two related but distinct concepts:

Most of the time, those identities remain aligned. This incident exposed the case where they legitimately diverged.

A guest could enter an email already associated with an account, allowing the resulting purchase to appear in that account's history, while the inventory reservation still belonged to the guest checkout session.

The production evidence narrowed the failure

The affected sales window was open and the tier configuration had not changed. The remaining inventory had already been reserved by the buyer's guest session.

The request sequence was consistent:

Multiple confirmed incidents shared this sequence. Broader availability errors were not treated as proof because retries, expired holds, and genuine buyer contention can produce the same generic response.

The defect required a specific combination:

• The checkout originated as a guest.
• The submitted email belonged to an existing account.
• Inventory was at the sellout boundary.
• Capture performed the final locked revalidation.

Spare availability could hide the duplicated demand, which is why preview and confirmation could both appear healthy.

Root cause: account association was mistaken for authority

Preview stored the hold against the guest-session identifier.

Confirmation associated the order with the existing account so the purchase could be delivered and included in account history.

Capture then saw that the order had a user and searched for a user-owned hold. It did not consume the validated guest-session hold that had originated the checkout.

The untouched guest hold still reduced availability. When capture requested the same inventory for the order, the system effectively counted the intended purchase twice.

The inventory protection behaved safely, but incorrectly. It prevented overselling and stopped before payment, while rejecting a buyer who already held the inventory they were trying to purchase.

The obvious fix would have widened authority

A broad lookup using either the account ID or the session ID would have removed the visible symptom, but it would have introduced a more serious authorization problem.

A signed-out buyer must not gain access to an account's unrelated inventory holds simply by entering that account's email address.

An email match can support order association and purchase history. It cannot prove that the guest controls the account or its existing checkout state.

The safe source of truth was therefore not the order's final identity. It was the validated checkout session that originated the hold.

The implemented fix

Payment capture now derives hold ownership from the validated CheckoutSession.

• A guest-origin checkout consumes only the active hold belonging to its validated guest session.
• An authenticated-origin checkout consumes only the hold belonging to that authenticated user.
• An authenticated legacy flow without a checkout session may fall back to the current signed-in user.
• Invalid, expired, or mismatched checkout sessions fail closed instead of falling back to weaker identity inference.
• An account inferred from an email address never grants ownership of account-held inventory.

Hold consumption remains:

• active-only;
• row-locked;
• quantity-bounded;
• transactional; and
• scoped to the proven checkout owner.

Foreign holds and excess matching quantity remain untouched. The previous broad post-payment deletion path was removed because exact hold consumption already performs the required conversion without widening ownership.

Checkout sessions, route orders, and idempotent capture replays are also bound to the same proven owner. A replay must belong to the route order before an existing payment result can be returned.

Verification focused on boundaries, not only the repaired path

The regression coverage verifies that:

• A guest checkout using an existing-account email consumes its own hold, captures once, and issues the expected ticket.
• Multi-ticket and shared-tier forms of the same boundary complete correctly.
• A guest cannot consume an account-owned hold.
• Holds belonging to another session or account remain untouched.
• Genuine inventory loss still returns an availability error before gateway contact.
• Partial and multi-option hold consumption remains quantity-bounded.
• Capture replay remains idempotent.
• Authenticated checkout and guest checkout without account reconciliation remain green control paths.

The focused checkout and payment coverage, full backend suite, payment and inventory invariants, static analysis, operational validation, and merge gate all passed.

The exact verified commit was then deployed through the multi-service release workflow and confirmed in production.

The failure now leaves durable, privacy-safe evidence

The inventory-preflight event is emitted outside the failed database transaction so rejection evidence survives rollback.

Its allowlist records only the information needed to understand the system's behavior:

• the shape of the checkout identity;
• the proven hold-owner source;
• matched and consumed quantities;
• capacity scope;
• the result of the preflight; and
• whether the gateway was contacted.

It excludes customer and payment data, including order IDs, user IDs, session values, cookies, email addresses, IP addresses, and payment tokens.

Production monitoring can now distinguish a successfully reconciled guest/account handoff from genuine inventory contention without retaining customer-identifying data.