Owning the Experience, Outsourcing the Complexity

Hosted checkouts no longer meet the needs of modern fintech and platform teams that want to orchestrate every step of the payment experience themselves. When the user experience is the product, developers need full control over UX, data, and routing, without inheriting the integration chaos that comes with every new PSP.

Juspay Hyperswitch’s stateless connector is a backend-only payment orchestration layer that runs entirely on the server as a passthrough, accepting a single unified request from your backend, translating it into PSP‑specific calls, and returning a normalized response across providers. This lets your developers own the customer journey and payment logic end‑to‑end while delegating connector complexity to Hyperswitch.

This model resolves the core tension: product and developers keep full control of UX, data models, workflows, and reporting, while Hyperswitch provides connector breadth and orchestration plumbing. The rest of this blog will break down how the stateless connector works in practice, what changes for developer teams adopting a backend‑only approach, and how to integrate it into existing architectures

Understanding the Concept of a Stateless Connector

The stateless connector is a backend passthrough and orchestration layer that accepts a standardized request from your system, translates it into PSP‑specific API calls, and returns a normalized response without storing any state along the way. In other words, it focuses purely on translation, routing, and technical payment orchestration, not data persistence or UI.

In this architecture, Infrastructure, SaaS and Fintech platforms (ISFs) fully own the UI, the end‑to‑end customer journey, and their dashboards, while Hyperswitch powers the backend connectivity. Each connector behaves as a stateless translation layer between your common format and the individual PSP’s requirements, avoiding any additional data storage.

This blog is about the stateless connector: no SDK‑driven UI, no customer‑facing components. It’s just a direct API‑to‑API translation. The focus is on integration nuances like how requests are structured, how responses are normalized, and how connector abstraction gives you a uniform interface despite PSP differences.

The stateless connector is best suited when you want:

• minimal latency via direct PSP communication
• no data duplication
• need full control over how payment methods and customer data are stored

It is designed for engineering teams that want pure routing and translation capabilities without vaulting, which is different from Hyperswitch’s standard mode where payment methods can be stored and tokenized in a vault for reuse.

The Importance of Backend Payments

Backend-only payments with a stateless connector are not for everyone. They shine in a few clear situations.

When UX Is Your Product

You’ve already decided that hosted checkouts and non-customizable third-party dashboards are not acceptable because branding, experimentation, and deep funnel analytics are core to your product. You need full freedom to design flows, A/B test journeys, and wire every event into your own analytics and reporting stack, without a provider specifying how the experience should look or behave.

When PSP Sprawl Is Slowing You Down

You’re adding or swapping PSPs regularly across regions, use cases, or payment methods and every new integration or version bump is turning into a recurring tax on your engineering roadmap. What you want is a single backend surface area that absorbs these connector differences so your team is not constantly relearning APIs, dealing with edge cases, or rewriting routing logic.

When You’re an ISF, Platform, or Aggregator

You run a multi-tenant platform for many merchants and think of payments as “invisible infra” that should power your product, not define it. You want to present a fully owned, white-labeled experience to your merchants and their customers, while quietly plugging into a broad network of PSPs and geographies behind the scenes without rebuilding your payments stack every time you expand.

Core Principles of the Stateless, Backend-only Model

Pure Passthrough, Merchant-owned Experience

In this model, Juspay Hyperswitch behaves as a pure passthrough layer: it receives a standardized request from your backend, talks to the PSP, and returns a normalized response without persisting payment data or owning any part of the customer journey. All user-facing payment screens, flows, dashboards, SDK, workflows, and analytics remain in your stack, along with payment method storage and tokenization.

Request/Response Translation Only

Hyperswitch’s role is strictly technical: convert a single merchant-facing format into PSP-specific APIs, then map the raw PSP response back into a consistent structure your systems trust and readily ingest. It does not implement business logic, enforce UX decisions, or manage long-lived payment state in this mode; those responsibilities stay with your services.

Statelessness for Clear Boundaries

Because no customer or session state is stored, each call is processed independently using self-contained payloads. This stateless behavior simplifies compliance and data-ownership questions, reduces duplication of sensitive data, and makes it easier to scale horizontally.

Backend Connectivity and Intelligence

Behind the scenes, Hyperswitch still provides a lot of heavy lifting on the backend: a connector abstraction layer over multiple PSPs and acquirers, authentication handling, consistent error and response normalization, and webhook forwarding without storing state. You get a single integration surface while Hyperswitch absorbs the protocol and behavior differences across providers.

Fully API-driven Integration

Everything in this model is driven by APIs: merchants set up connector accounts, configure profiles, and process payments via standard REST endpoints. Connector definitions declare which PSP to talk to and how to authenticate, while payment calls reuse the same unified schema regardless of the underlying processor. This makes the stateless connector especially useful when you need compliance-friendly data ownership, minimal latency, and a translation layer that fits into an existing payments stack rather than replacing it.

Modeling the Backend-only Payment Flow

End-to-end flow overview

In a backend-only setup, the customer interacts with the merchant’s or ISF’s surfaces: web or app screens that collect payment details and guide the user through the checkout. The frontend sends this information to the merchant backend, which orchestrates all pre-processing steps, then makes a single, standardized API call to Juspay Hyperswitch. Hyperswitch, through the stateless connector, translates that request into the right PSP-specific format, sends it to the chosen processor, and returns a normalized response that the merchant uses to update its own systems and UI.

Throughout this flow, Hyperswitch does not own any UI or customer-facing components. The merchant is responsible for showing success and failure states, handling retries visible to the user, and recording the final outcome in its own dashboards and reporting systems.

Where 3DS, FRM, and tokenization happen

In the stateless, backend-only model, 3DS, FRM, and tokenization are all handled on the merchant side before calling Hyperswitch. The ISF either runs these via in-house services or specialist providers, then includes the results, such as 3DS authentication data, fraud risk signals, or tokens, in the payment request payload sent to Hyperswitch.

Because Hyperswitch is stateless in this mode, the payload must be self-contained: it needs to carry any 3DS authentication values, fraud assessment outputs, and payment method tokens required by the PSP. Hyperswitch then uses these fields purely as inputs when translating and routing the request to the connector based on the merchant/ ISF guidelines, without persisting them or triggering its own 3DS, FRM, or tokenization flows.

The Breakdown of Merchant vs. Juspay Hyperswitch Responsibilities

What the merchant/ISF owns

• All customer-facing experiences: checkout flows, error and success screens, emails, and dashboards.
• Orchestration for 3DS, FRM, and tokenization, including which providers to use and how their outputs affect business rules.
• Storage and lifecycle of customer data and payment method tokens, as well as analytics, reconciliation, and reporting.

What Juspay Hyperswitch owns

• Translation from a single, standardized payment request into PSP-specific APIs, and normalization of the PSP responses back into a consistent format.
• Connector abstraction and lifecycle: managing multiple PSPs, authentication formats, and connector-specific nuances.

Ready for a stateless backend?

If you already run, or plan to run, your own 3DS, fraud checks, and tokenization, a stateless backend-only model is likely a strong fit. You keep all the sensitive logic and data in your stack, and use Juspay Hyperswitch purely as the translation and routing layer to PSPs.

If your team is looking to reduce engineering overhead without sacrificing control of the customer experience, try launching a backend-only flow with a single provider. Once you validate the benefits, you can expand quickly across regions and processors using the same unified setup. You can contact us here or check out our docs.

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.