MultiTenancy

DragonPay's Tenant model is simpler than a typical multi-tenant SaaS: at launch there is one Tenant (one credit union) and one Product (P2P). Multi-CU/multi-Product breadth is real future scope, but the architecture below is deliberately not over-built for it yet — see ENG-01 §3's standing rule against premature abstraction.

Isolation Model

Every payment-domain record is tenant_id-scoped (PH-01's Tenant record is the isolation anchor everything else attaches to), with production/non-production kept as fully separate infrastructure boundaries per STD01-03. Enforcement mechanics at the persistence layer are ENG01-04's deliverable — not yet built, no ADR recorded.

Tenant Context

Governed by STD01-04 (standard command/event context) and PH-02 (effective Tenant Product configuration resolution). Not yet built.

White-labeling

Applies to the Sender/Recipient-facing product surface (CX-01's Web SDK and hosted claim experience), not DragonPay's own operational tooling — see CX01-04. Not yet built.