# MVP-TASK-030 — Duplicate checkout initiation protection

**Status:** Implemented  
**Parent:** MVP-PAY-001-S04

## Objective and required behavior

Ensure repeated taps/concurrent requests for one checkout operation do not intentionally initiate
independent charges; UI progress protection complements server/application idempotency.

## Scope, areas, and non-goals

Expected stable operation identity, application/repository concurrency behavior, provider boundary,
UI disabled/progress state, and tests. No claim of provider idempotency until Surfboard discovery.

## Evidence and acceptance

Use `MVP-PAY-001-S04` in concurrency integration and E2E evidence. Accept when simultaneous/repeated
initiation produces one effective provider operation under the fake and safe replay behavior,
traceability is current, and inherited DoD passes. Handoff distinguishes local from provider safety.

## Delivered

- The checkout operation identity is minted by the caller, reused across every transport attempt of
  one draft, and used as the immutable order identity.
- New append-only `checkout_operations` table (migration `0014`, update/delete trigger) with the
  identity as primary key and a fingerprint of the priced request. `claimCheckoutOperation` inserts
  with `ON CONFLICT DO NOTHING`, so exactly one initiator is admitted across processes and
  instances, before the provider boundary is crossed.
- A duplicate replays the finalized order, replays `CHECKOUT_UNRESOLVED` for a durably unresolved
  attempt, and otherwise returns the new `409 CHECKOUT_IN_PROGRESS`. A fingerprint mismatch is
  refused rather than charged.
- The KDS keeps both finalization controls disabled while a request is pending and reuses one
  operation identity until a definitive refusal, after which a retry is a genuinely new operation.
- The identity is minted with `crypto.getRandomValues` rather than the secure-context-only
  `crypto.randomUUID`, because the tablet reaches this application over plain HTTP.

## Evidence

`MVP-PAY-001-S04` is carried by `postgres-order-repository.integration.test.ts` ("admits one
provider operation under concurrent and repeated checkout initiation": two real repositories, one
blocked provider call, one effective charge, safe replay, refused identity reuse),
`order-service.test.ts`, `order-http.test.ts`, `KdsPage.test.tsx`, `kds.spec.ts`, and
`checkout-operation-id.test.ts`. Local validation is recorded in
[current-state.md](../../../current-state.md). Hosted CI and `pnpm validate:docker` were not run, so
this is Implemented and awaiting CI rather than Done.