# MVP-PAY-001 — Complete commercial checkout

## Story

As an operator, I want checkout outcomes handled exactly once and safely so that confirmed sales
enter fulfillment without false payment claims or duplicate charges.

## Scenarios

### MVP-PAY-001-S01 — Successful checkout

- **Given** a valid current order
- **When** checkout succeeds
- **Then** it is finalized commercial, enters `Queued`, contributes to sales, and yields a new empty
  cart
- **Evidence:** E2E plus application/database integration.

### MVP-PAY-001-S02 — Definitive failure or cancellation

- **Given** checkout was attempted
- **When** the provider definitively rejects or cancels it
- **Then** it is not paid, not queued as a successful commercial order, does not affect sales, and
  the operator can continue safely
- **Evidence:** E2E plus integration.

### MVP-PAY-001-S03 — Unknown outcome

- **Given** checkout was initiated
- **When** certainty about the provider result is lost
- **Then** the attempt is unresolved/unknown, is not silently failed, and cannot be blindly retried
- **Evidence:** E2E for visible state plus integration for durable outcome/retry policy.

### MVP-PAY-001-S04 — Duplicate interaction protection

- **Given** one checkout operation is pending
- **When** the operator repeats the action because of latency
- **Then** multiple independent charges are not intentionally initiated for that operation
- **Evidence:** application/integration concurrency test plus E2E disabled/progress behavior.

### MVP-PAY-001-S05 — Commercial contents are immutable

- **Given** successful commercial finalization
- **When** later fulfillment or metadata changes occur
- **Then** item contents and commercial snapshots remain unchanged
- **Evidence:** database integration.

### MVP-PAY-001-S06 — Checkout metadata remains associated

- **Given** a checkout attempt returns a stable provider reference or result facts
- **When** the order/attempt is stored
- **Then** those facts remain associated with the internal order/checkout identity
- **Evidence:** integration.

## Invariants and exclusions

Surfboard is the selected provider, but payment-method options remain values verified through its
adapter contract rather than guessed in this story. The application never handles card numbers, CVV,
or track data. Local and automated evidence uses the deterministic fake; staging integration
evidence uses Surfboard Demo. No split/partial payments, tips, refunds, or out-of-band settlement.

## Implementation tasks

[MVP-TASK-011](../tasks/MVP-TASK-011.md), [MVP-TASK-013](../tasks/MVP-TASK-013.md), and
[MVP-TASK-028–030](../tasks/README.md#phase-7-checkout-safety-and-reliability).