What actually needs isolating — and what doesn't
Look closely at why people open account #2 and it's never the treasury. It's the surfaces a customer or an integration touches: the checkout needs the right logo, the webhooks need to hit that store's backend, the API key in that store's config shouldn't be able to act as a different store. The balance? You'd rather it were all in one place — that's the whole point of being one business.
Multi-Brand draws exactly that line. Each brand carries its own name, slug, logo, theme and color (the hosted checkout renders the paying brand, not your parent company), its own webhook endpoint and signing secret, and its own scoped API keys. Funds from every brand settle into one account-level balance per coin — one treasury, one payout schedule, one settlement policy, regardless of how many faces the business wears.
The key-scoping detail that matters
The mechanism doing the real work is brand-scoped API keys. Create a brand, then mint a scoped key bound to it — every payment created with that key is tagged to the brand automatically. No per-request brand field for an integrator to forget; the credential itself carries the identity. Three consequences:
- Blast radius. A key leaked from store A's config can only create payments as store A. Combined with per-key IP allowlists and coin allowlists, each storefront's credential is exactly as powerful as it needs to be.
- Attribution for free. Listings and exports filter by brand tag, so per-brand revenue is a query, not a spreadsheet reconstruction from order-ID prefixes.
- Clean handoffs. Give a client's developer their brand's key and nothing else. They integrate against the standard API; everything they create wears their brand.
Webhooks that respect the brand boundary
Each brand can point at its own webhook URL with its own HMAC secret — a client's orders hit the client's infrastructure, signed with a secret only that pipeline holds. Brands without their own endpoint fall through to the account-level webhook, so defaults stay safe and there's no double delivery. Rotating one brand's secret doesn't touch any other brand's integration.
Three operators, one pattern
- Agencies: one brand per client. The client sees their identity end-to-end — checkout, webhooks, reporting — while you run one dashboard and one balance. Pair with revenue splits to route your commission on every client payment automatically.
- Multi-store operators: every storefront gets its own checkout identity and its own key. Launching store #4 is two clicks and a key mint, not a new account with a new balance to babysit.
- White-label resellers: ship "your own" payment product on OrbChain rails — your customer's brand on every surface their buyers see, your account underneath.
When you genuinely want separate accounts
Multi-Brand unifies the treasury on purpose — identity isolates, funds don't. If two ventures need genuinely separate balances (different owners, different books, different risk), run them as separate accounts; that's the right tool, and zero-fee internal transfers make settling between them instant anyway. The test is one question: should this money be one pot? Yes → brands. No → accounts. Both compose with everything else on the platform.
Every account already has a default brand, so adopting this is incremental: create the second brand when the second storefront shows up, mint its key, and stop choosing between your client's logo and your own sanity.