# MVP-TASK-011 — Checkout facade and deterministic fake

**Status:** Done **Parent:** MVP-TECH-001-S01–S03

## Objective and required behavior

Introduce a provider-neutral application boundary for checkout request, success, definitive
failure/cancellation, unknown outcome, and stable provider reference when available. Supply a
deterministic no-network fake for local/automated use.

## Scope, areas, and non-goals

Expected backend application contract, integration adapter/composition/configuration, and tests.
Provider APIs must not enter domain/application. No real Surfboard adapter or generic integration
framework.

## Evidence and acceptance

Use all three scenario IDs in unit/integration/static-review evidence. Accept when all outcomes are
deterministic, hosted configuration cannot accidentally use the fake, architecture/traceability are
current, and inherited DoD passes. Handoff documents composition and result semantics.

## Delivered evidence

`backend/src/application/checkout.ts` defines the provider-neutral `CheckoutGateway` port and its
request/result contract; `backend/src/application/checkout-service.ts` owns the boundary and is the
only application code that initiates checkout. `backend/src/integrations/` holds
`fake-checkout-gateway.ts` (deterministic, no network, no clock, no randomness) and
`checkout-composition.ts`, the single configuration-to-adapter mapping.

`backend/src/application/checkout-service.test.ts`, `fake-checkout-gateway.test.ts`,
`checkout-composition.test.ts`, and `config.test.ts` carry every exact scenario ID.
`tests/ci/checkout-boundary.test.mjs` carries `MVP-TECH-001-S03` as executable static evidence:
provider names, hosts, and credential vocabulary are scanned out of backend domain/application and
frontend sources, the neutral contract is proven to import nothing provider-specific, the fake is
proven network-free, and the ESLint adapter-import boundary is exercised against the new files.

All three scenario IDs appear: `MVP-TECH-001-S01` covers deterministic per-scenario outcomes,
reference stability, the `disabled` composition, and hosted rejection; `MVP-TECH-001-S02` covers
neutral delegation, unchanged outcome classes, unknown normalization, and pre-adapter validation;
`MVP-TECH-001-S03` covers the static boundary evidence above.

## Result semantics

`succeeded` is the only class that authorizes a paid commercial order. `rejected` and `cancelled`
are both definitive: the provider decided no money was captured. `unknown` means certainty was lost;
the service produces it for a thrown, malformed, or out-of-contract adapter result, and the
unavailable gateway produces it because no provider was contacted. `unknown` must never be reported
as success, silently downgraded to failure, or blindly retried; retry, reconciliation, and duplicate
suppression belong to tasks 028–030. A `providerReference` may accompany any class, including
`unknown`; it identifies an attempt and never confirms capture.