# Checkout

**Flow key:** `checkout`

## Outcome

A shopper converts the intended cart into exactly one truthful order with authorized payment, correct totals, committed inventory, and recoverable confirmation.

## Actors

- Guest or authenticated shopper
- Cart/checkout service
- Pricing/tax/shipping/inventory services
- Payment processor
- Notification service

## Preconditions and entry points

- Use a staging/test processor only.
- A synthetic cart has deterministic products, quantities, price, and inventory.
- Shipping, tax, promotion, payment, and order policies are known.

## Required test data

Use synthetic, isolated, resettable data. Never use real credentials, payment instruments, private customer records, or production notifications.

| Data | Canonical valid seed | Critical variations |
|---|---|---|
| Shopper | `carbon.checkout+001@example.test` | guest, signed in, new account, returning saved data, restricted region |
| Cart | `CARBON-SKU-001` qty 1 at `$20.00` and `CARBON-SKU-002` qty 2 at `$5.00` | digital-only, mixed fulfillment, out-of-stock, price change |
| Address | `1 CARBON Way, Testville, CA 94000, US` | PO box, apartment, international, invalid, unsupported region |
| Shipping | standard test shipping | express, pickup, unavailable, rate timeout |
| Promotion | `CARBON10` if configured | expired, exhausted, conflicting, gift card, removes shipping threshold |
| Payment | processor-provided success test token | decline, insufficient funds, 3DS challenge, timeout-after-authorization, duplicate |
| Expected totals | item subtotal `$30.00` before configured discounts/tax/shipping | rounding, tax-inclusive, currency conversion, zero-total |

## Canonical steps

Treat this as the ordinary successful path inferred from common product behavior. Adapt it to observed labels, business rules, APIs, and implementation evidence; do not invent a requirement.

| Step | User or system action | Expected evidence |
|---:|---|---|
| 1 | Enter checkout from the prepared cart. | Checkout shows the exact cart identity, items, quantities, currency, and provisional totals. |
| 2 | Choose guest or authenticated identity and provide contact data. | Identity policy is clear and no duplicate account is created. |
| 3 | Enter/select shipping and billing addresses. | Validation preserves user intent and supports required international forms. |
| 4 | Choose an eligible delivery/fulfillment option. | Price and promised delivery update for the exact address and inventory. |
| 5 | Apply promotion or gift value when applicable. | Eligibility, allocation, remaining balance, tax basis, and totals recalculate coherently. |
| 6 | Enter a processor-provided test payment method. | Secrets stay processor-scoped and the final payable amount is explicit. |
| 7 | Review the complete order. | Items, addresses, shipping, discounts, tax, currency, payment consequence, and policies are final and understandable. |
| 8 | Submit Place order exactly once. | One idempotent order attempt authorizes/captures per policy, commits inventory, and creates one order. |
| 9 | Observe confirmation and retrieve the order. | Confirmation, persisted order, payment, inventory, receipt, analytics, and notification all agree. |

## Alternate paths

- Guest checkout
- Signed-in checkout with saved data
- Digital-only or zero-total order
- Multi-shipment or pickup
- 3DS/step-up payment
- Express wallet checkout

## Failure and recovery paths

- Inventory changes before commit
- Tax or shipping quote expires
- Promotion becomes invalid
- Payment declines or requires challenge
- Processor times out after authorization
- Double submit/retry
- Order commits but confirmation/receipt fails

## Completion oracle

- The stated outcome is true in visible UI and authoritative persisted state.
- Exactly one intended business result and no unintended side effect occurred.
- Identity, tenant, authorization, money/data, lifecycle, notifications, integrations, analytics, and audit agree where applicable.
- Refresh, retry, back/forward, and a second authorized read do not reveal a contradictory result.
- Any partial, delayed, canceled, failed, or unknown outcome is labeled truthfully and has a safe recovery path.

## Evidence to capture

- Entry context, actor, tenant, role, feature flags, locale, time zone, and initial identifiers/state.
- Step-level screenshots or DOM state plus request/response, correlation, job, event, and stable business IDs where available.
- Before/after authoritative records, versions, totals, permissions, lifecycle states, and downstream side effects.
- Notifications, audit events, integration deliveries, retries, deduplication, latency, and recovery evidence.
- Untested branches, unsafe-to-run cases, product decisions, and evidence tier.

## Product decisions to resolve

- Exact eligibility, required data, authorization, and validation rules.
- Which steps are synchronous, asynchronous, optional, skippable, reversible, or irreversible.
- Idempotency, concurrency, timeout, retry, cancellation, and compensation semantics.
- Retention, privacy, notification, audit, performance, accessibility, and localization commitments.

## Related CARBON items

- [payment](../../items/records/payment.md)
- [invoice](../../items/records/invoice.md)
- [currency price totals](../../items/data/currency-price-totals.md)
- [address](../../items/controls/address.md)
- [concurrency and idempotency](../../items/quality/concurrency-and-idempotency.md)

[Back to Commerce and billing flows](index.md)
