In our last blog, we introduced one of the foundational pillars of Hyperswitch’s architecture: a clear hierarchy of Organization → Merchant → Profile that keeps the isolation of configurations, connectors, routing logic, roles, data, and operational boundaries. For most enterprises, that hierarchy is the bedrock needed to operate cleanly and securely.
But for Infrastructure platforms, SaaS providers, and Fintech companies (ISFs) building embedded payments, hierarchy is only the starting point. These businesses create, configure, and run payments on the merchant’s behalf within their own product experiences.
The question for these companies becomes:
How do we onboard and operate merchants programmatically, reliably, and at scale?
That’s where the standard organizational model evolves into something more powerful: a Platform Organization designed to automate everything that sits above and within that hierarchy.
That hierarchy solves a foundational need for all enterprises:
- Each merchant operates in its own sandbox
- PSP configurations don’t bleed across merchants
- Operational roles stay scoped correctly
- Analytics, disputes, and lifecycle events remain isolated
Platform Organization: A Programmable Merchant Control-Plane
The Platform Organization adds programmability, automation, and multi-tenant control.
This is the point where the standard Org → Merchant model evolves into something purpose-built for ISFs: a Platform Organization that behaves like a control plane, allowing you to onboard and configure merchants with the same rigor as the standard hierarchy, but driven entirely by APIs instead of human workflows.
A Platform Organization is a special operating mode in Hyperswitch designed for SaaS platforms, marketplaces, fintech infrastructure providers, and any business that needs to onboard and manage merchants at scale. Think of it as the “programmable version” of the hierarchy you learned about in the previous blog.
At the center of a Platform Organization are two core entities:
- The Platform Merchant: The parent, elevated-privilege merchant that acts as the control-plane. It can create merchants, generate their API keys, and manage onboarding workflows.
- Sibling Merchants: The merchants created programmatically under the platform. They behave like normal merchants with isolated profiles, routing, PSP configs, and operations, but their lifecycle is fully automated by the platform.
The Platform Organization introduces a clear separation between provisioning keys and operational keys.
- Platform API Key: A special dual-purpose key that allows you to:
- Create new merchants, and
- Generate merchant-specific keys
-
…but cannot perform payment operations for sibling merchants. It is a management key.
- Sibling Merchant API Keys: Each sibling merchant gets its own API key, which behaves exactly like the keys described in our earlier blog:
- Used to configure connectors for that specific merchant
- Used to initiate payments, refunds, captures, etc.
- Used to maintain strict isolation
-
Why Platform Mode Exists
In the ISF master blog, Challenge 3 highlighted one of the hardest architectural gaps ISFs face today: the need to programmatically onboard clients as merchants, while supporting both MoR and non-MoR models, without building and maintaining a fragmented payments stack for every customer.
Most platforms eventually run into the same bottlenecks:
- Manual onboarding must be automated: If every merchant has to be created through the dashboard, your onboarding pipeline slows to the pace of human operations. For ISFs onboarding hundreds or thousands of merchants, this is unusable.
- PSP setup must be configured through APIs not UI workflows: Every merchant needs its own PSP credentials, settings, and routing rules. Doing this manually, or worse, sharing configurations across tenants becomes operationally risky and expensive and error-prone.
- You shouldn’t need two architectures for MoR and non-MoR: If you are the Merchant of Record, you need to manage PSP credentials on behalf of your customers. If your customer is the MoR, they must securely upload their own PSP credentials. Most systems force you into one or the other, which makes it impossible for SaaS, marketplaces, and infra providers to support mixed business models.
- Payments must be executed “on behalf of” merchants without breaking isolation: Embedded finance platforms often initiate payments from their own backend, but every transaction still needs to be tied to the correct merchant account, with strict boundaries for state, analytics, and PSP interactions.
- Scaling merchants shouldn’t require scaling infrastructure: Adding 10 merchants shouldn’t require 10 stacks, 10 databases, 10 connector libraries, or 10 engineering projects.
Platform Mode is Hyperswitch’s answer to these realities.
It turns the standard merchant hierarchy into a fully programmable, multi-tenant control-plane where:
- Merchants can be created via API
- PSP configuration can be automated
- Keys can be managed securely, rotated, and managed centrally
- Payment operations run in the correct merchant context
- MoR and non-MoR models work on the same underlying architecture
Platform Mode gives ISFs the ability to scale merchant onboarding, PSP management, and payment operations the same way they scale the rest of their software programmatically.
Without programmatic merchant lifecycle management, your platform stalls.
With it, you unlock a scalable, compliant, secure embedded payments layer that grows with your business.
How the Platform Mode Lifecycle Operates
Once Platform Mode is enabled, the merchant lifecycle becomes entirely programmable. The platform begins with a single Platform Merchant, which is your control-plane, and everything else flows outward through APIs. The first step is generating a Platform API Key: a management key that provisions the entire system and can also act as a normal merchant API key used for payment initiation of that platform merchant. It creates merchants, issues their operational keys, and powers the onboarding flow your product exposes to customers.
Creating a merchant becomes a single API call. During onboarding, your system invokes the Merchant Create endpoint and receives a fully isolated merchant environment in return. This merchant comes with its own profiles, routing logic, PSP configurations, and analytics that mirrors the structure from our previous blog, but now instantiated programmatically rather than through dashboard interaction.
After creation, the Platform Key generates that merchant’s operational API key. This is the boundary where control shifts. The merchant key becomes the authority for all PSP configuration and payment operations. Every connector setup, credential upload, payment attempt, refund, and capture uses the merchant’s own key, ensuring strict isolation even when your backend initiates the call. The Platform Key never configures PSPs or touches live payments; its role is orchestration only.
Connector setup follows naturally from this model. Your platform uses each merchant’s key to attach processors, define capabilities, and configure routing. Whether you or your customer is the Merchant of Record, the process remains the same: apply PSP settings using the merchant-level key. This eliminates manual setup, prevents credential sharing, and ensures every merchant stays fully isolated at scale.
Payment operations are just as straightforward. When your platform initiates a transaction on behalf of a merchant, it injects that merchant’s key into the Payments API. This guarantees clean accounting, accurate analytics, and proper dispute handling that’s all tied to the correct merchant context. Meanwhile, the Platform Merchant retains the ability to run payments for its own account like any standard merchant.
In practice, this lifecycle turns merchant management into a predictable pipeline: provision with the Platform Key, operate with merchant keys, and maintain strict boundaries automatically. The result is a model that feels natural to modern ISFs where it’s API-driven, automated, and built for scale.
Where Platform Mode Shows Up in the Real World
Platform Mode maps directly to how modern ISFs operate. A SaaS platform onboarding a new customer can create a merchant during sign-up, attach the appropriate PSPs based on region or business model, and start processing payments immediately without support tickets or dashboard workflows. Marketplaces experience the same benefit: each vendor becomes a merchant with its own PSP configuration, routing rules, and analytics, giving the platform clean segregation without maintaining hundreds of brittle integrations.
Fintech infrastructure providers gain similar leverage. Many act as the Merchant of Record across multiple business units or client accounts. Platform Mode allows them to manage PSP credentials centrally while still enforcing merchant-level isolation. At the same time, they can support clients who want to be their own MoR by letting them upload credentials using the merchant’s key. The architecture remains consistent regardless of who owns the PSP relationship.
Embedded-finance platforms rely on this model heavily. Their backend often initiates subscriptions, usage-based billing, payouts, and other payment operations on behalf of merchants. Platform Mode ensures those operations always execute in the correct merchant context. Transactions, disputes, settlement events, and analytics remain segmented.
Across these scenarios, the pattern is identical: Platform Mode removes the operational burden of multi-merchant environments and replaces it with predictable, API-driven automation. This gives ISFs the ability to scale the payments side of their business with the same speed and reliability as the rest of their software stack.
Why This Matters for the Business
Platform Mode gives ISFs something powerful: a programmable, automated system for merchant lifecycle management. When merchant creation, PSP configuration, key governance, and operational boundaries become API-driven, onboarding accelerates, support overhead drops, and payment operations start behaving like any modern multi-tenant SaaS capability. Instead of custom integrations or per-merchant exceptions, platforms can offer a unified payments layer that adapts to each customer’s needs whether they are a MoR, non-MoR, or somewhere in between without branching architecture or creating operational drift.
The commercial impact is direct. Faster onboarding leads to faster revenue activation. Automated PSP setup reduces integration fatigue and minimizes long-tail operational errors. Clean merchant isolation simplifies compliance, improves reporting accuracy, and reduces dispute-handling complexity as platforms scale. And because all merchants run on the same orchestration engine, new capabilities with routing strategies, fraud providers, local payment methods that can all be launched once and made available to every merchant instantly.
This is the core promise of Hyperswitch’s Platform Organization model: the inbuilt structural clarity becomes the foundation, and Platform Mode turns that foundation into a scalable engine. It gives ISFs a payment architecture that grows with their product roadmap, supports global expansion, and removes the operational friction that usually slows monetization. For platforms operating across industries and regions, this combination of hierarchy and automation becomes the backbone of an ISF-ready orchestration layer that can adapt, scale, and evolve with the business.
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.
