Imagine you're building a payments platform as an Infrastructure, SaaS or Fintech platform (ISF). You onboard a new client, and they show up with their own PSP contracts, specific payment methods for their markets, and demands for isolated dashboards and data. Sound familiar?
Most payments stacks force trade-offs: either duplicate entire infrastructures per client (costly and slow) or bolt on brittle custom scoping that leaks data and breaks isolation. This is Challenge 2 from our ISF series: logically isolating clients across PSPs, payment methods, end-user data, payment experiences, routing/retry workflows, user access, operations, and analytics without rebuilding your stack for every new client.
Platforms either compromise security and visibility or get stuck managing duck taped hierarchies that lead to inconsistent dashboards and compliance nightmares. Juspay Hyperswitch fixes this with a clean Tenant → Organization → Merchant → Profile model that enforces isolation by design.
The Hyperswitch Hierarchy
Hyperswitch enforces isolation through a simple but powerful four-level hierarchy. Each level defines a clear boundary for configuration, access, and data:
Tenant → Organization → Merchant → Profile
Tenant | Your Deployment Boundary
A Tenant represents a full Hyperswitch deployment (for example, EU-prod, US-prod, or sandbox). Isolation at this level guarantees:
- Dedicated infrastructure and database schemas
- Each deployment has its own databases, analytics, and storage
- Region-specific compliance, encryption keys, and data residency
- Multiple environments with zero shared risk
Tenants are ideal for ISF platforms operating across regions or serving enterprise customers with strict regulatory requirements.
Organization | Your Platform
Within a tenant, the Organization represents your SaaS platform and acts as the control plane. This is where you manage:
- Platform users and roles (admins, ops, support, finance)
- Shared or pre-integrated connectors offered by your platform
- Branding, defaults, and global settings inherited by all merchants
The organization defines what your platform governs centrally versus what clients control themselves.
Merchant | Each Client, Fully Isolated
Every customer you onboard becomes a Merchant—an isolated container for:
- PSP configurations (BYO keys or platform-controlled keys)
- Payment method availability
- Business settings (currency, region, settlement rules)
- Operational workflows (refund permissions, capture rules, reconciliation views)
- User roles (finance, support, engineering)
Merchants never share:
- PSP keys
- Payment or customer data
- Routing and retry logic
- Reporting or operational state
This eliminates the “shared PSP configuration” problem that commonly breaks isolation in ISF architectures.
Profile | The Execution Layer
A Profile is the most granular isolation layer and where payments actually execute. Profiles allow a single merchant to operate multiple independent payment stacks by separating:
- PSPs or MIDs
- Payment method groupings
- Workflows (auth/capture behavior, retries, SCA posture)
- Regions and currencies
- Experience surfaces (web, mobile, marketplace storefronts)
This lets one client safely run multiple business units, brands, or regional payment setups inside your platform, without overlap.
In this diagram we have a company that has:
- 1 Tenant: One Hyperswitch deployment (SaaS region or your self-hosted cluster)
- 1 Organization: Your platform/ISF (the one overseeing all clients)
- 3 Merchants: Each client you onboard (with their own API keys)
- 5 Profiles: Their business units, brands, countries, or payment stack
- 11 connectors: Merchant’s connector configurations with logic for retries, routing and more
Every payment tags to exactly one Profile and rolls up cleanly with no data leaks, perfect isolation and infinite scale:
Profile → Merchant → Org → Tenant.
Each level owns specific knobs - Org sets platform defaults, Merchants customize for clients, Profiles execute the actual payments:
- Platform (Org) knobs: Shared PSP catalog, risk policies, MoR vs BYO-PSP decision
- Client (Merchant) knobs: Their API keys, webhooks, user roles and more
- BU (Profile) knobs: Exact PSPs + methods (example - Giropay primary), currencies, 3DS rules, checkout branding, default routing
Here’s one flow example:
- Org: "3DS always + Stripe/Adyen available"
- Merchant: "UK SCA strict + our logo"
- Profile: "Giropay 70% / Stripe fallback + EUR only"
Payments execute at Profile → route perfectly → data scopes cleanly back up in the hierarchy. No overlap, no conflicts.
Profile | Where Business Differences Live
A Profile represents a distinct business context inside a single client. It’s how one merchant can safely run different brands, regions, or payment strategies, without duplicating infrastructure or risking configuration bleed.
Profiles allow the same client to operate multiple payment setups side by side, each with its own rules, experiences, and reporting boundaries.
This makes it possible for a single merchant to:
- Support different markets or regions independently
- Separate brands, business units, or storefronts
- Run different payment strategies without conflicts
- Evolve one setup without impacting the others
All activity stays cleanly isolated, while still rolling up into unified visibility for the platform.
Hyperswitch Isolation Layer Gives Clean Boundaries & Infinite Scale
For ISF platforms, isolation is no longer optional. It is table stakes for winning larger deals, passing diligence, and keeping your own engineering roadmap sane. If every new merchant means another bespoke hierarchy, another shared PSP configuration, or another set of leaky dashboards, you eventually hit a wall on cost, compliance, or both.
The Tenant → Organization → Merchant → Profile model gives you clean boundaries at every layer, so you can support BYO PSP, multi region, and multi-brand setups without re- architecting your core. Each payment executes in exactly one Profile, rolls up cleanly through the hierarchy, and preserves isolation for keys, data, routing, and operations by design.
If you are an infrastructure, SaaS, or fintech platform and you are already feeling the limits of one-off scoping and custom isolation, now is the right time to fix the foundation instead of patching the symptoms. Talk to us about modeling your actual tenant, organization, merchant, and profile structure in Hyperswitch, or start a test deployment and run one real client through it end to end. You will quickly see whether your current duct-taped hierarchy survives the next 10 merchants, or whether you need a payments stack built for isolation and scale from day one.
About Juspay: Juspay is a trusted payments leader processing billions of transactions annually for major global brands. Hyperswitch extends that expertise, giving merchants a transparent, customizable orchestration layer built for scale. Check out hyperswitch.io for more information.
