# MVP-TASK-038 — Journey 004 checkout failure safety

**Status:** Implemented  
**Parent:** MVP-JRN-004; MVP-PAY-001-S02–S04; MVP-REL-001-S02–S03

## Objective and required behavior

Demonstrate definitive and unknown checkout outcomes with no false sales/queue success, no duplicate
blind charge, visible safe recovery, and an unrelated active queue left intact.

## Scope, areas, and non-goals

Expected focused Playwright cases using fake modes, backed by concurrency/outcome integration tests.
No live provider, invented reconciliation, or broad outage/load suite.

## Evidence and acceptance

Titles include `MVP-JRN-004` and applicable scenario IDs. Accept when both outcome classes and
repeat interaction are deterministic without contaminating existing orders, traceability is current,
and inherited DoD passes. Handoff records known provider-independent recovery limits.

## Implementation record

`tests/e2e/journeys.spec.ts` carries two focused headline tests tagged `MVP-JRN-004` and the exact
linked scenario IDs they directly prove. The definitive-refusal case drives the deterministic fake's
configured refusal amount through the real stack and proves the explicit unpaid recovery message, no
queue entry, no sales movement, the preserved reviewed draft, and a subsequent successful charge
that is queued and counted exactly once. The unknown-outcome case drives the configured unconfirmed
amount and proves the explicit unknown-outcome message that claims nothing about the money, the
blocked pay control (even a forced click starts no second attempt, proven by the durable unresolved
attempt count), the reload recovery path, and a different subsequent charge that succeeds while the
unresolved record stays durable and listed. Both cases keep an unrelated pre-existing non-commercial
queue entry intact and visible throughout, so a failed operation never disturbs unrelated active
service.

Durable outcome, concurrency, and sales-exclusion facts stay owned by the linked real-PostgreSQL
`postgres-order-repository.integration.test.ts` suite rather than being re-proven through the
browser. Known provider-independent recovery limits are recorded in the handover: definitive
refusals keep the draft for immediate safe retry, unknown outcomes cannot be resolved by the
application itself and rely on out-of-band verification, and the pay-control block is page-state
scoped and cleared by discarding the blocked draft while the durable unresolved record persists.
Full inherited validation and hosted CI remain outstanding, so the task is Implemented rather than
Done.