# Relay Market Hosted Checkout — Fictional Capstone Brief

Part of **W/ Builders: Payment Architecture Capstone** · WACK-BUILDERS-0001

A fictional marketplace uses a provider-hosted payment page, a serverless session API, an Internet-facing webhook receiver, a containerized order service, cloud identity, CI/CD, centralized logging, and a support console. The exercise contains no real card data, credentials, provider tenant, or production target.

## Starting architecture

- **Customer browser** (`browser` / experience) — owner: Product engineering
- **Storefront application** (`storefront` / customer-code) — owner: Web engineering
- **Checkout session function** (`session` / serverless) — owner: Payments engineering
- **Hosted payment provider** (`provider` / tpsp) — owner: Provider + customer relationship owner
- **Public webhook receiver** (`webhook` / public-interface) — owner: Payments engineering
- **Order service** (`orders` / container) — owner: Commerce platform
- **Cloud and workforce identity** (`identity` / control-plane) — owner: Identity + platform
- **CI/CD and artifact registry** (`pipeline` / deployment) — owner: Platform engineering
- **Logs, traces, and alerts** (`telemetry` / evidence-plane) — owner: SRE + security
- **Support and refund console** (`support` / administrative) — owner: Customer operations

## Declared relationships

- `browser` **LOADS** `storefront`
- `storefront` **REQUESTS_SESSION** `session`
- `browser` **SUBMITS_PAYMENT** `provider`
- `provider` **CALLS_PUBLIC_ENDPOINT** `webhook`
- `webhook` **UPDATES_ORDER** `orders`
- `identity` **ADMINISTERS** `session`
- `identity` **ADMINISTERS** `webhook`
- `pipeline` **DEPLOYS** `storefront`
- `pipeline` **DEPLOYS** `session`
- `pipeline` **DEPLOYS** `webhook`
- `session` **EMITS** `telemetry`
- `webhook` **EMITS** `telemetry`
- `support` **INITIATES_REFUND** `provider`
- `support` **READS_AND_UPDATES** `orders`

## Required deliverables

- [ ] **Behavior before boxes** — One-page data-flow narrative covering normal, alternate, failure, retry, refund, support, and administrative paths.
- [ ] **Two-path architecture** — A relationship graph with typed nodes, account-data edges, security-influence edges, owners, and unresolved candidates.
- [ ] **Provider claim boundary** — A service-and-activity responsibility record tied to current provider assurance, configuration, evidence, and change conditions.
- [ ] **Durable ephemeral ownership** — A revision lineage joining source, build, artifact digest, deployment, configuration, workload identity, runtime population, telemetry, and owner.
- [ ] **Tests from propositions** — A coverage matrix joining proposition, subject, population, material variants, environment, method, authorization, evidence, exceptions, and retest.
- [ ] **Release with consequences** — A release record that fans one change into affected flow, graph, inventories, ownership, public presence, test populations, evidence, claims, and reopening triggers.

## What this exercise does not claim

- A hosted payment page does not by itself decide the assessed entity's scope, validation instrument, or compliance result.
- A component without known account data is not automatically unrelated to the security of the payment environment.
- The provider's assurance does not certify the customer's implementation, configuration, retained responsibilities, or evidence.
- The capstone does not authorize testing of a provider, production system, or any environment the learner does not own and have permission to test.

## Working rule

The deliverables must agree with one another. A component, identity, public interface, provider handoff, test population, or change cannot disappear merely because another artifact omits it.

## Safety and authority boundary

W/ Builders is independent practitioner education and a fictional pilot. It is not PCI SSC guidance, not official training, not a provider certification, not an eligibility decision, not a PCI DSS assessment, not a compliance result, and not permission to test a real system. It does not substitute for assessor judgment or compliance-accepting-entity direction. Use only fictional or explicitly sanitized environments. Never enter account data, credentials, provider secrets, client evidence, restricted architecture, or targets the participant is not authorized to test.