# MVP-TECH-001 — Provider-independent checkout boundary

## System story

As the application, I need checkout expressed through a narrow provider-neutral boundary so that
normal ordering is testable and Surfboard details remain replaceable.

## Scenarios

### MVP-TECH-001-S01 — Deterministic fake covers outcome classes

- **Given** configured success, definitive failure/cancellation, or unknown behavior
- **When** checkout is invoked in tests/local development
- **Then** a deterministic fake returns the selected provider-neutral outcome without network access
- **Evidence:** unit/integration.

### MVP-TECH-001-S02 — Normal order flow is provider-neutral

- **Given** the application checkout use case
- **When** it initiates and processes checkout
- **Then** it depends on the neutral request/result contract rather than Surfboard APIs
- **Evidence:** unit/integration and architecture/static review.

### MVP-TECH-001-S03 — Provider details remain in adapters

- **Given** provider authentication, formats, protocol, credentials, or reconciliation logic
- **When** adapter code is inspected
- **Then** those details do not leak into domain/application or unrelated frontend code
- **Evidence:** architecture/static check and review.

## Invariants and exclusions

Checkout uncertainty and stable operation identity remain provider-neutral application concepts;
Surfboard payment, ECR, receipt, terminal, webhook, and authentication details remain adapter
concerns. Do not create a generic integration framework or a networked provider dependency in local
or automated application acceptance tests.

## Implementation tasks

[MVP-TASK-011](../tasks/MVP-TASK-011.md).