Introduction
In the current digital economy, relying on a single payment processor is a limitation that a few software platforms and fintechs can afford. To win large enterprise contracts, you must meet your customers where they are. Often, this means integrating with specific local banks, legacy processors, or region-specific Payment Service Providers (PSPs) that the enterprise has deeply entrenched relationships with.
However, the "Integration Effort" - the time and engineering resources required to build and maintain these connections is staggering. Integrating with multiple PSPs is time and resource-intensive. A basic card authorization integration alone can take months, with a variation of 50% more effort across PSPs based on their API and flow maturity, developer documentation clarity, support responsiveness, sandbox capability, and more.
At Hyperswitch, our objective is to fundamentally alter this equation. We don't just "build connectors"; we have engineered a unified, open-source payment switch capable of delivering a wide range of connectors in a matter of weeks, or even days. This speed is not achieved by cutting corners. It is the result of seeing and unifying sufficient diversity already, streamlining our teams and workflows, and leveraging advanced AI.
This article explores the technical reality of payment fragmentation and how Hyperswitch’s architecture, process, and AI capabilities normalize the chaos of global payments diversity.
A Look at the Real Complexity Behind a “Simple” 3DS Card Payment
To understand the magnitude of the engineering challenge, we must look beyond high-level abstractions. Let us examine a single, standard scenario: A 3DS Card Payment (Auth + Capture).
This may seem like a solved problem. However, even if we look only at 3DS card payments, Hyperswitch handles this diversity across 200+ connectors. Each connector represents a unique combination of transport protocols, security mandates, and data shapes.
Diversity in Transport & Authentication
Before a single byte of payment data is processed, the method of establishing a connection varies wildly between PSPs.
- Header Variations: The dominant pattern involves API keys or Bearer tokens in headers. However, we frequently encounter legacy gateways that mix merchant credentials with card data directly in the request payload.
- Security Overheads: Banks and other processors often require Signed Requests (HMAC), necessitating signatures over the payload and timestamp to prevent tampering and replay attacks.
- mTLS (Mutual TLS): This is common with banks and requires Client Certificates, Certificate Signing Request (CSR) generation, managing certificate chains, and handling rotation per environment.
- Multiple Credential Sets: It is not uncommon to see flows requiring a merchant key, a gateway key, and sub-account keys all on the same flow.
The Complexity of Endpoints & Serialization
Once authentication is established, the logical action - charging a card - is implemented through completely different API structures across connectors.
- Endpoint layouts: For the same logical action (let’s say a charge operation), one PSP might use `/payments`, another `/charges`, and a third `/transactions` each with its own request and response shape.
- Flow structure: Some PSPs support a one-step "auth+capture," while others force an explicit `authorize` followed by a separate `capture` call. Some even require separate endpoints entirely for 3DS completion, such as `/payments/details` vs `/payments/complete`.
- Data serialization formats: While JSON over HTTPS is the norm for most modern PSPs, older enterprise gateways still rely on XML over HTTPS with SOAP-like envelopes. We even encounter legacy flows using application/x-www-form-urlencoded payloads or multipart form-data.
- Data formatting quirks: Even basic data fields lack consistency. Amounts may be in minor units ($100 = 10000) or major units ($100 = 100.00), and can be typed as numerics or strings. Currencies might be separate fields or nested inside an amount object. Card data can be flat fields, nested under `payment_method.card`, or provided as encrypted blobs or tokens. 3DS context moves around: `browserInfo` objects, `three_d_secure` sub-objects, or inline flags with optional extra fields.
All of this complexity exists just to move the same $100 transaction from A to B. As you add more payment methods, recurring flows, refunds, disputes, and new PSPs, the integration surface doesn’t grow linearly; it completely snowballs.
Hyperswitch abstracts payment complexity
Hyperswitch acts like a payments kernel. Instead of hardcoding new logic for every bank or PSP, it takes all their differences and normalizes them into one consistent model built from years of product hardening and IP.
One model for all connectors
- All PSP endpoints, flows, and payloads map into a single request/response schema.
- Whether a PSP expects XML, JSON, or form data, Hyperswitch adapts it behind the scenes.
- Impact: Merchant teams get a stable foundation and can add markets or PSPs without touching billing, ledger, risk, or core platform code.
Standard primitives
- Amounts always use minor units plus ISO currency codes.
- Connector adapters handle each PSP’s unit conversions, decimal rules, and schema quirks.
- Impact: Your systems work with predictable fields and states across all regions and processors.
Pluggable authentication
- Auth methods (API keys, OAuth, Basic Auth, mTLS) are modeled as plug-ins behind a single interface.
- mTLS becomes configuration: upload cert and key; the core HTTP stack manages TLS at runtime.
- Impact: No more one-off infra projects every time a bank changes auth or rotates certificates.
Unified 3DS lifecycle
- 3DS differences (frictionless vs. multi-step, redirects, webhooks) all map into one state machine: Created → RequiresCustomerAction → Charged or Failure.
- Impact: You implement 3DS logic once and reuse it globally.
Standard webhooks layer
- Hyperswitch enforces a single webhook contract while adapters handle PSP-specific HMAC/JWT, IP allowlists, schemas, and retries.
- Impact: One webhook integration instead of bespoke implementations for every PSP.
Engineering Quality: The Process Behind the Speed
Delivering fast integrations is valuable, but delivering fast, stable, and scalable integrations is what ISF companies actually need. Our ability to deliver robust integrations is the product of deeply engineered processes, hardened workflows, and repeatable systems.
The Integration Factory
We utilize cross-functional teams comprising SMEs, architects, and engineers. The workflow is designed for precision:
- Semantic Review: We review documentation to understand integration semantics and flows, with an optional solutioning step for complex flows led by a Tech Lead or Architect
- Code Generation: Engineers write code using templates to auto-generate boilerplate structures
Multi-Level Review: PRs undergo reviews at multiple levels - first via AI, then by humans - before being added to the merge queue
The Future: Accelerating with GRACE (AI)
To further accelerate step 2 (coding) and step 3 (testing), we are pioneering the use of AI. We call this framework GRACE: Global Rapid Agentic Connector Exchange.
GRACE is a set of tools working toward enabling rapid connector integration for all types of payment methods and flows. Our goal is to bring down the time from a "request-for-connector" to "available in sandbox" to a couple of hours, a process that currently takes a few weeks.
The Payoff: 3 Months of Work in Days
Why does this matter? Because for an ISF, time to availability means more clients, faster onboarding and go-to-market. The standard industry timelines for building these connections internally are prohibitive. Here’s what we can deliver today
- 2 Weeks: A new PSP integration for cards including refunds and disputes
- 1 to 2 Weeks: Payment authentication and 3DS integrations
- 1 to 2 Weeks: Alternate payment methods using cards (ApplePay, GooglePay)
- 1 to 2 Weeks: Alternate payment methods for global markets (PayPal, Klarna, ACH, etc.).
By leveraging Hyperswitch, Infrastructure/ Platform providers, SaaS, and Fintech (ISFs) can bypass these months of cumulative engineering effort as well as any ongoing enhancement or maintenance. We accelerate growth by providing seamless PSP and Acquirer integrations that are ready to deploy.
The 4 Pillars of Rapid Integration
The possibility to deliver super-fast integrations and enhancements is not accidental; it is driven by four specific pillars.
- Product Robustness and IP: We have already seen and normalized the diversity of PSP flows in key areas, from complex 3DS journeys to varied settlement cycles.
- Team Expertise: Our cross-functional teams and streamlined review processes ensure that speed never compromises architectural integrity
- Automation Frameworks: Comprehensive regression and system testing in sandboxes guarantee that new connectors are stable from Day-1.
- AI Acceleration (GRACE): With our agentic frameworks, we are optimizing the end-to-end pipeline to reduce manual intervention and slash delivery times from weeks to hours.
The combination of Hyperswitch’s underlying architecture and these four pillars fundamentally changes what “integration effort” means. What once required months of custom engineering becomes a repeatable, reliable process that delivers production-ready connectors in days.
For Infrastructure Providers, SaaS platforms, and Fintechs, the payoff is simple: faster market entry, broader PSP coverage, and the ability to scale globally without carrying the weight of ongoing integration and maintenance work.
Instead of building payments infrastructure forever, you can plug into the world’s most robust open payment switch and start processing across markets immediately.
