Building a Full‑Stack, Modular Payments Product for ISFs

From Connectors to Full‑Stack

Over the past few blogs, the focus has been on connector depth, geographic coverage, and the underlying payment infrastructure that software platforms and fintechs can expose to their merchants. Those blogs were primarily about “what you can plug into”, processors, methods, and schemes, and how to abstract that complexity behind a unified layer. This blog zooms out to the full picture: how those connectors, orchestration capabilities, and experience layers come together into a full‑stack payments product that ISFs need.

The goal here is to showcase the end‑to‑end capabilities of the full‑stack payments product: from device‑aware front‑end SDKs and hierarchical onboarding models, intelligent routing, smart retries, and non‑payment workflows, like risk, compliance and fraud checks. It highlights how each of these components can be adopted independently, but also how they compound when used together. Equally important, this blog is about modularity: how ISFs can start with a single block of functionality and expand over time without re-architecting their entire stack.

Understanding Full‑Stack

When we say full-stack, we mean a payments platform that brings together four core layers: front‑end SDKs, orchestration workflows, reporting and analytics dashboard, and a broad connector layer. Each of these layers solves a different part of the payments problem, but they are designed to work as a single system rather than as isolated tools.

Altogether, it allows a payment platform that can power everything from checkout experiences and merchant onboarding to real‑time routing decisions and post‑transaction analytics. Each layer is independently adoptable (same concept as the connectors). An ISF can choose to start only with the SDKs or only with orchestration, but the compound value appears when they are combined: better conversion, lower cost, and less operational overhead with a unified control surface.

Front-End Experience Overview

Device‑aware payment methods in Hyperswitch

Hyperswitch checks the device in the session flow to decide when to surface wallets like Apple Pay and Google Pay, so these options only appear on devices that can actually use them. ​

Under the hood, the same flow also prepares everything those wallets need, like tokens,decryption flows, configuration, and connector‑specific details like certificates or special billing rules. From a merchant’s point of view, none of that complexity is visible: they plug in the SDK once, and it automatically returns the right wallet data based on what the customer’s device supports.

Geo-specific filtering

Hyperswitch uses a configuration‑driven system to decide which payment methods appear in which regions, so customers only see options that actually work for their country and currency. Behind the scenes, each method is mapped to allowed country and currency combinations, and the SDK checks those rules before anything is shown in the UI.

Config-based enable/disable:

Config-based controls in Hyperswitch let teams switch payment features on or off through configuration instead of code, covering payment methods, card scanning, and third‑party SDKs at global, environment, and connector levels.​

Hyperswitch controls which payment methods are available through two main configuration layers that work together. At the connector level, tokenization merchant settings that define what each provider can do: which broad method types are allowed (cards and bank debits), which specific variants are enabled or disabled (for example, turning off Google Pay while keeping other wallets), and whether long‑lived tokens are supported for use cases like subscriptions or mandates.

On top of that, the payment‑link layer decides what customers actually see in a given flow by listing the methods that should be available on each kind of link, such as which card types, bank transfer rails, or wallets are offered.

Third‑party SDKs in Hyperswitch are controlled entirely through connector configuration, so each provider can define how its experience should run without custom code per merchant. For Klarna, for example, a simple setting decides whether the customer stays on the page and the native Klarna SDK is invoked, or is redirected to a hosted Klarna checkout, and that choice can vary by environment.​

Other SDK‑driven providers, such as Netcetera, plug in as first‑class connectors and follow the same pattern: they declare whether they support client‑side token generation and which payment methods can use it, and Hyperswitch uses those declarations at runtime to decide which SDK flow to trigger. This connector‑driven model lets ISFs mix and match experiences, SDK‑first, redirect, or hybrid, while keeping the integration surface for merchants consistent

In Hyperswitch, configuration follows a cascading priority: defaults at the bottom, then base config files, then environment‑specific files, then connector configs, and finally environment variables on top. This means higher layers simply override lower ones, so teams can tweak behavior per environment or connector, and use env vars for sensitive or last‑minute changes, without touching the underlying defaults.

Dynamic Ordering

Merchants can enable the ordering of payment methods based on their internal logics and preferences. During merchant configuration, merchants decide which payment methods to enable/ disable for each PSP in any profile. During the session/ transaction they can dynamically ingest the payment method order which will engage the SDK to present those eligible payment methods in that order. For example, BNPL payment methods on top for high ticket purchases and more.

Dynamic Fields

Hyperswitch uses a central configuration system to decide exactly which fields to show for each connector, payment method, and transaction type, instead of hard‑coding a single checkout form. For some connectors, that might mean only card number, expiry, and CVC; for others, it can include full billing and shipping addresses, email, phone, or even extra details like date of birth and nationality.​

When a customer selects a payment method, the SDK asks the backend what that specific combination requires and then renders only those fields on the page in case the merchant has not already collected and passed them as part of their payments create call. The same mechanism also distinguishes between one‑time and mandate‑based payments, so recurring flows can ask for additional details and customer approvals when needed. Because all of this is configuration‑driven, field requirements can be updated centrally without code changes, and customers only ever see relevant inputs. This reduces friction and improves completion rates.

Cross‑Platform & Multi‑Tenant Architecture

Hyperswitch offers one SDK family that works across web and mobile. All SDKs share the same API model and configuration patterns, which means behaviors like method filtering, routing, and theming stay consistent whether the checkout runs in a browser, a native app, or a Flutter/React Native shell.​

Underneath that, Hyperswitch uses a true multi-level hierarchy model: each merchant/ profile has its own branding, configuration, and data boundaries. Profiles can customize themes languages, and feature toggles; add their own plugins or integrations; and manage their own analytics and operations under a merchant within an isolated hierarchy, all while sharing the underlying infrastructure for efficiency.​

This design works for both hosted SaaS and self‑hosted setups. Some platforms consume Hyperswitch as a managed service, while others deploy it in their own cloud or data center, but in all cases they inherit the same multi‑tenant semantics, sandbox environments for safe testing, and white‑labeled endpoints for APIs, dashboards, and payment pages that they can present under their own brand.

Hyperswitch offers four main ways to integrate payments, all backed by the same APIs and configuration model. This lets ISFs pick the right balance between speed of integration and control over the checkout experience.​

Integration Options in Hyperswitch

• SDK Integration (Hyperswitch handles UI and payment flows)
  • Use the full-featured SDKs for Web, Android and iOS
  • The Web SDK (HyperLoader.js) and native mobile SDKs share a common API surface, so behavior is consistent across browsers and mobile apps.
  • They support device‑aware payment methods, dynamic fields, and theming out of the box, with appearance and behavior controlled through configuration rather than custom code.​
• Headless SDK (deeply-customizable UI)
  • This option allows merchants to have full control of the UI but still rely on Hyperswitch for payment logic, tokenization, and wallet handling.
  • Your app builds its own screens and forms, while the headless SDK exposes functions to initialize sessions, fetch saved payment methods, and confirm payments using client secrets.
  • Ideal for merchants who want design freedom without re‑implementing payment flows.
• Payment Links (shareable URLs)
  • These shareable URLs encapsulate a payment request and a configured set of methods.
  • They can be sent via email, SMS, or chat and open either a hosted checkout or an SDK‑powered page, depending on configuration.
  • Links inherit the same payment‑method controls and UI settings as other integrations, giving a lightweight way to launch campaigns, one‑off collections, or long‑tail merchant use cases.

Multi‑Level Hierarchy and Account Structure

Hyperswitch lets businesses mirror their real‑world structure using organizations, merchant accounts, and profiles, so they can decide exactly where payments should be accepted and how much control sub‑merchants get.

A single deployment securely serves multiple independent clients (tenants). It lets every tenant operate a customized version of the Hyperswitch payments stack without owning or maintaining any of the underlying software or infrastructure.

Hyperswitch uses a single application, multi-schema storage model where:

• Tenants share the same high-performance infrastructure.
• Each tenant’s data, configuration, and extensions remain logically isolated and secure.
• Upgrades, fixes, and new features are delivered instantly across all tenants with zero ops, zero drift.

Enterprises delivering embedded payments operate in environments where:

• Regulatory requirements change constantly
• Payment methods evolve region-by-region
• New markets require rapid GTM without re-architecture
• Merchant onboarding must be repeatable and scalable

Multi-tenancy in Hyperswitch gives these companies a reliable backbone to scale payments across geographies, business lines, and customer tiers.

Dashboard

The Hyperswitch Control Center is a web dashboard that lets teams run their entire payment stack without touching application code. It sits on top of the same multi‑level hierarchy ( → organization → merchant → profile with platform capabilities), so what each user sees and can change depends on their role and scope.​

Here are the things you can do in the control center or execute them via an API:

Operations & day‑to‑day management

• Configure connectors and processors per profile or merchant, including credentials and core settings.
• Review payments, refunds, and disputes, using unified transaction timelines for quick debugging.
• Manage user roles and permissions so each team has the right level of access.

Workflow & orchestration configuration

• Use visual, no‑code controls to set up smart routing, retries, 3DS, fraud checks, and surcharge rules.
• Experiment with different flows or A/B tests and roll out changes directly from the dashboard.

Insights, analytics & reporting

• Analyze performance by method, connector, geography, merchant, or profile to spot success rates and drop‑offs.
• Use funnel and time‑series views or export reports to give finance and product clear, actionable insights.

Multi‑tenant, configurable experience

• Enforce tenant, organization, merchant, and profile boundaries so teams see only the data they should.
• Turn modules like reconciliation, payouts, fraud/risk, test processors, sample data, or branding on or off per tenant or environment.

Workflows

Intelligent Routing Workflows

Hyperswitch’s Intelligent Routing (IR) engine brings several routing strategies under one roof so merchants can tune for success rate, cost, or contractual needs without changing their core integration. It can run as part of the wider orchestration stack or as a standalone module, giving ISFs and merchants flexibility in how they adopt it. Below is a short description of the routing options:

Auth‑rate based routingThis routing method uses a reinforcement‑learning approach to continuously learn which processors perform best for different transaction patterns. It “explores” by sending a small share of traffic to multiple PSPs, then “exploits” the best performer by directing more volume there, using dimensions such as card type, network, and other payment attributes to guide decisions.

Least‑cost routingFor eligible debit transactions, least‑cost routing steers payments through local debit networks when that reduces fees, while keeping compatibility with existing processors. This helps merchants capture savings on regulated and unregulated debit traffic without manually micromanaging network choices.

Rule‑based routingWith rule‑based routing, businesses define explicit “if‑this‑then‑that” logic for where transactions should go. Rules can key off billing or business country, labels, payment method families (cards, wallets, bank transfer, pay later, open banking, and more), BIN ranges, amount, currency, auth method, capture method, one‑time vs recurring, and custom metadata, combined with operators like “is”, “contains”, and logical AND/OR.

Volume‑based routingVolume‑based routing lets teams split traffic across PSPs by percentage. This is useful for honoring volume commitments, running controlled experiments, or spreading risk. For example, a merchant can pin 60% of traffic to one gateway, 30% to another, and 10% to a new entrant for testing.

Default fallback orderingA default fallback layer defines a simple priority order of PSPs that acts as a safety net whenever no other rule applies or a primary gateway is unavailable. The engine walks this ordered list from highest to lowest priority, so there is always a deterministic “next” option.

Together, these modules make intelligent routing a flexible routing product that can either sit at the heart of a full orchestration setup or be used on its own as a focused decision engine for where to send payments.

Retries

Hyperswitch treats retries as a transaction‑level workflow that kicks in only when it makes sense, rather than a blind “try again” on every failure. PSP responses are first classified as retriable or non‑retriable, and only retriable errors are attempted again, typically by routing the same payment through an alternative processor. These retries run silently in the background, so the customer is not asked to re‑enter details or click “pay” again.​

Which processor is tried first and which ones act as fallbacks is determined by the routing setup (mentioned above), so the retry engine always respects the merchant’s primary and backup preferences. From the Control Center, merchants can turn smart retries on or off, set how many attempts are allowed, and decide how conservative or aggressive the strategy should be, balancing recovery of soft failures against processor limits and risk policies. Hard declines (e.g., stolen card, insufficient funds) are never retried regardless of configuration.

Non‑Payment Workflows in Hyperswitch

Hyperswitch lets businesses define non‑payment workflows that sit alongside Intelligent Routing to control how each transaction is evaluated for risk, authentication, and exemptions before and after authorization. These workflows are fully configurable per profile, so different segments, markets, or merchants can have different policies without code changes.​

Fraud & Risk workflowsMerchants can decide where in the flow to invoke a Fraud & Risk provider, either before authorization (to block risky attempts upfront) or after authorization (to act on confirmed fraud signals). Based on the provider’s response, workflows can automatically approve, cancel, or flag a transaction for manual review, giving a structured way to balance protection and conversion.​

3DS decisioning workflows3DS rules determine when to step up a transaction for additional authentication, using parameters such as billing and business country, card attributes (BIN, type, network), amount, currency, capture method, and custom metadata fields. This allows merchants to trigger 3DS where regulation or risk requires it, while avoiding unnecessary friction for low‑risk or exempt traffic.​

3DS exemption managementAn exemption manager layer can request 3DS exemptions when conditions allow, using inputs like issuer name and country, acquirer country and fraud rate, customer device platform and type, card network, amount, and currency. This helps merchants and ISFs take advantage of low‑value, trusted‑beneficiary, or corporate exemptions, keeping journeys smooth while staying compliant.​

Together, these non‑payment workflows give merchants fine‑grained control over how each transaction is screened, authenticated, or exempted, all orchestrated through configuration and visual tools rather than embedded business logic.

Connectors

Hyperswitch integrates with a wide set of connectors across the entire payments stack, including pay‑ins, payouts, buy‑now‑pay‑later providers, fraud and risk management services, 3DS, vault/tokenization, subscription billing, and tax systems. You can read more details about these connectors here.

Bringing the Full Stack Together

By unifying checkout, routing, workflows, and governance into one modular platform, Hyperswitch enables ISFs to launch markets faster, onboard merchants at scale, optimize costs through intelligent routing, and reduce maintenance across payment surfaces. Each layer compounds in value when combined, creating a full-stack product that grows without constantly re-architecting.

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.