Infrastructure, SaaS, and Fintech platforms (ISFs) increasingly want merchants to complete payments onboarding, PSP credential submission, and operational tasks inside the platform’s own dashboard.
In an earlier blog, we showed how Juspay Hyperswitch enforces client-level separation across PSPs, payment methods, data, access, and operations without duplicated stacks or brittle scoping layers. We also introduced how platforms can programmatically create merchants and configure PSPs through APIs instead of manual steps.
This blog tackles a different requirement: how ISFs can embed Hyperswitch’s operational UI directly into their own dashboards, allowing merchants to set up PSPs, connectors, routing, and operations from within the ISF’s product, without rebuilding UI or exposing sensitive flows.
Hyperswitch’s embedded components give platforms a way to deliver a cohesive, branded payments experience while still relying on Hyperswitch’s secure, pre-built, and continuously updated operational modules.
The Gap in Traditional Approaches
When a platform wants to let its merchants configure payments, set up PSP keys, or manage operations, it usually faces an uncomfortable tradeoff. The simplest option is to redirect merchants to the Hyperswitch Dashboard, but that breaks the continuity of the platform’s own product experience and often creates friction during onboarding. The alternative is to build custom UI screens on top of Hyperswitch APIs, which demands ongoing engineering investment, deep domain knowledge, and constant maintenance as PSP requirements and compliance rules evolve.
Neither option is ideal for an ISF that needs to balance speed, consistency, and control. What platforms truly want is a way to offer a seamless, native experience inside their own dashboard while still relying on Hyperswitch to handle the complexity of payments configuration and operations.
This is where embedded components become the third path. They allow platforms to place fully functional pieces of the Hyperswitch dashboard directly into their product, preserving their UX while avoiding the cost and risk of rebuilding sensitive or frequently changing payments UI.
What Embedded Components Actually Are
Embedded components are self-contained UI modules provided by Hyperswitch that cover both payment collection and payments configuration. Instead of recreating complex payment service provider configuration screens, connector setup flows, routing controls, or operational tools, a platform can load these components through a lightweight software development kit and present them as part of its native experience.
Each component arrives with its own logic, validation rules, error management, and state handling. Merchants interact with these modules exactly as they would inside the Hyperswitch dashboard, while all sensitive actions, including payment service provider credential submission and configuration updates, are processed securely by Hyperswitch.
This gives platforms a powerful combination. Merchants receive a unified and brand consistent experience, and the platform avoids the ongoing cost of rebuilding and maintaining intricate payments user interfaces that change frequently as providers, regulations, and requirements evolve.
How Embedded Components Work
Embedded components operate through a simple but carefully structured architecture that lets a platform present advanced payment configuration tools inside its own product while keeping all sensitive logic, verification, and data processing within Hyperswitch.
The process is driven by a short-lived, merchant-scoped token created specifically for the component the merchant is allowed to render. This token contains the merchant identifier, organization identifier, permitted component list, and an expiry value. Once the platform backend retrieves this token from Hyperswitch, it passes the token to its own frontend.
Step 1–2: Platform Requests a Scoped Token
The platform backend requests a short-lived token from Hyperswitch using its API key. Hyperswitch returns a merchant-scoped token that defines exactly which embedded components the merchant is authorized to load.
Step 3–4: SDK Loads the Component
The platform’s frontend injects the token into the Hyperswitch SDK. The SDK uses this token to securely initialize the embedded component inside a controlled sandbox. Every request the component makes carries this token, ensuring that all activity is authenticated at the merchant level and that sensitive information never leaves the Hyperswitch boundary.
Step 5: Token-Verified API Calls
As the merchant interacts with the component, the Hyperswitch frontend (HS FE) makes token-authenticated API calls back to Hyperswitch. These calls retrieve data, validate steps, and apply configuration updates without exposing internal platform logic or requiring the platform to recreate complex payment workflows.
Hyperswitch also manages the token lifecycle. If a token expires during a session, the SDK signals the platform to fetch a new one. The user continues exactly where they left off, creating a seamless, interruption-free experience.
What This Enables
With this structure, platforms can deeply embed operational and configuration experiences like routing rules, PSP onboarding, payment method selection, retry settings. It does this without rebuilding the logic, security posture, or update pathways that payments orchestration typically demands.
What Platforms Can Embed
Hyperswitch’s embedded components are portable slices of the dashboard, each focused on a specific area of payments configuration or operations. Platforms can embed onboarding flows to collect PSP credentials, verify accounts, and map processors to merchant profiles. Configuration surfaces expose controls for enabling payment methods, defining regional availability, and managing profiles. Operational views surface real-time status, errors, and guided actions backed by Hyperswitch’s diagnostics, while still feeling native to the platform’s product.
Platforms can start with a single embedded surface and expand over time, adding new capabilities as their payments program matures without redesigning their dashboard or re-architecting their stack.
In practice, platforms embed different surfaces at different points in the merchant lifecycle. Payment collection experiences are typically embedded into checkout or payment initiation flows, while configuration and operational experiences live inside merchant dashboards and admin interfaces. Both rely on the same underlying Hyperswitch APIs and enforcement model, but serve different user moments.
Why Token Scoping Matters at Scale
The embedded component flow already shows how tokens are issued, scoped, and verified. What matters for ISFs is what this enables once you move beyond a handful of merchants.
Token scoping turns payments configuration into a controlled surface rather than a shared system. Every embedded session is tied to a single merchant context, with permissions defined up front. That means isolation is enforced automatically, even when hundreds or thousands of merchants are configuring payments inside the same platform UI.
This is critical for platforms that support different operating models side by side. Some merchants may bring their own PSP contracts, others may rely on the platform as merchant-of-record. Some require advanced routing controls, while others should only see basic setup. Token scope allows the platform to expose exactly the right level of capability without branching UI logic or duplicating dashboards.
It also changes how platforms think about access control. Instead of implementing complex role-based logic in the frontend, authorization is pushed down into the payments layer. If a token does not include a component or action, it simply cannot be accessed. The platform does not need to guard every edge case.
At scale, this becomes an operational advantage. Support teams can safely embed diagnostic views without granting configuration access. Sales or onboarding teams can enable temporary setup flows without opening long-lived permissions. Merchants can self-serve within tightly defined boundaries.
In practice, token scoping is what allows embedded components to scale from a single onboarding flow to a full payments configuration surface.
Embedded vs Redirect vs Native UI
When platforms expose payments configuration to merchants, there are three common approaches: redirecting to an external dashboard, building native UI on top of APIs, or embedding components directly into the platform experience. Each comes with different trade-offs.
Redirect-based approaches are the fastest to implement. Merchants are sent to an external dashboard to complete setup or manage operations. While functional, redirects break product continuity, dilute branding, and often increase drop-off during onboarding. They also make it harder for platforms to guide merchants through payments as part of a larger workflow.
Fully native UI offers maximum control. Platforms build their own screens and workflows on top of payments APIs, tailoring the experience exactly to their product. The cost is long-term ownership: maintaining UI logic, keeping up with PSP changes, handling validation edge cases, and staying compliant as requirements evolve. For many ISFs, this becomes a recurring engineering tax.
Embedded components sit between these two extremes. They allow platforms to present payments configuration and operations inside their own dashboard, preserving a cohesive user experience, while delegating complexity to Hyperswitch. The platform controls layout, navigation, and access, but does not own the underlying payments UI or logic.
This makes embedded components especially well-suited for ISFs operating at scale. Platforms can start with a small surface area, such as PSP onboarding, and expand over time. They avoid the fragility of redirects and the maintenance burden of custom-built payments UI, while still delivering a native-feeling experience to merchants.
In practice, most mature platforms end up using a mix of approaches. Embedded components become the default for merchant-facing configuration and operations, APIs remain the backbone for backend workflows, and redirects are reserved for edge cases. Hyperswitch’s architecture supports this progression without forcing platforms into a single model.
Embedding Payments as a Platform Capability
Embedded components complete the picture of what it means to build payments as a platform capability rather than a one-time integration.
Earlier in this series, we showed how Hyperswitch enables ISFs to isolate clients cleanly and onboard merchants programmatically. Embedded components extend that foundation into the product experience itself. They allow platforms to expose payments configuration and operations directly inside their own dashboards, without redirecting users, rebuilding sensitive UI, or taking on long-term maintenance risk.
Taken together, this model gives platforms a practical way to scale payments alongside their business. Merchants can self-serve within clearly defined boundaries. Platforms retain control over branding, access, and user experience. Hyperswitch continues to handle the complexity that changes most frequently: PSP requirements, validation logic, compliance rules, and operational workflows.
This approach also changes how platforms think about ownership. Payments no longer sit outside the product as a black box, nor do they require a fully bespoke internal system. Instead, payments become a modular surface that can evolve incrementally. Platforms can start with a single embedded flow, expand to configuration and operations, and adjust exposure as merchant needs grow.
For Infrastructure providers, SaaS platforms, and Fintechs, this is the difference between payments being a drag on product velocity and payments becoming an integrated, scalable part of the platform itself.
