Request flows
Three flows show how the planes cooperate end to end.
1. License activation & composition
A box exchanges a license key for an activation token, then installs only the packages its tier entitles.
The activation token is a short-lived RS256 JWT whose claims are
{ sub: customerId, tier, pkgs: [...] }. The registry verifies it against the
control plane’s public key (GET /license/jwks) and serves only packages named
in pkgs. See Control plane → Licensing.
2. Storefront render
One shared Next.js app (web) serves every bank’s public storefronts. A request
is resolved to a tenant, then data is fetched from that bank’s engine backend.
GET /boxes/resolve is the planned control-plane endpoint the render app
depends on for non-platform domains. Until it ships, the render app treats
box-resolve.ts as a client stub. See
Storefront render.
See Storefront render for caching, the proxy route, and headers.
3. Checkout
A storefront converts the active cart into an order through the engine.
Payment initiation is delegated to whatever payment provider adapter the box
has bound to the PAYMENT_PROVIDER port. Out of the box that is a noop adapter
that returns 503 Payments are not configured. See
Engine → Adapters.