Hyperswitch’s Connector Diversity That Adapts to Every Business Needs

How a modular connector ecosystem lays the foundation for Infrastructure/Platform providers, SaaS, and Fintech (ISF)-ready orchestration

While the introductory Hyperswitch article focused on modularity, transparency, and composability, this article introduces a related idea: ISF readiness. This is our framework for describing what Infrastructure/Platform providers, SaaS companies, and Fintech (ISF) enterprises require to operate in a constantly evolving payments landscape.

These businesses are expected to support an ever-growing mix of PSPs, MIDs, payment methods, and advanced payment flows. Their customers often want to bring their own PSP connections, yet still expect a menu of pre-integrated options that allow them to onboard and go live quickly. At the same time, ISFs must scale across regions, navigate regulatory differences, and adopt new processors or methods without destabilizing their platform.

To do this well, they need an interoperable payment architecture that can evolve without demanding constant refactors. This is where Hyperswitch’s connector ecosystem becomes a foundational advantage. Every connector is treated as a modular building block, something an ISF can swap, extend, or combine independently, enabling them to roll out new capabilities or markets with minimal disruption and engineering investment.

Hyperswitch supports a wide range of integrations out of the box, each covering a distinct part of the payments lifecycle. At the highest level, the connector ecosystem includes:

Core Connectors in the Payments ecosystem

Each connector works as a building block, so merchants can add, swap, or combine services without having to rebuild their entire payment stack.

Payins

Payins are the most diverse, multi-step flows in any payments stack, and Hyperswitch supports them across PSPs, acquirers, banks, and payment method providers. This section shows the real-world technical breadth Hyperswitch can handle. Payins lets a platform expand to new markets and support local methods without requiring a new integration each time that can take months to plan and build.

1. Cards (Customer-Present and Customer-Not-Present)

Each flow has different requirements around fraud checks, metadata, authentication, and relay. Hyperswitch abstracts these through standardized interfaces while still giving access to provider-specific capabilities.

• Card | customer present
  • For customer-present card payments, Hyperswitch processes raw card details entered directly by the user. These details include the full card number, expiration date, and a required CVC for authorization. The CVC is passed securely to the connector as part of the payment request to complete the transaction. This flow represents the traditional, on-session card experience
• Card | customer not present
  • For customer-not-present card payments, Hyperswitch relies on tokenized credentials instead of raw card details. Depending on what’s available, the system can use PSP tokens, network tokens or raw cards with network transaction IDs to securely complete the transaction. Hyperswitch selects the appropriate token type based on business objectives and the user’s stored payment method.

2. Wallets: Native SDK vs Redirect

Hyperswitch handles both native SDK and redirect wallet flows. Hyperswitch orchestration tracks each state transition and offers consistent status mapping regardless of PSP or wallet provider.

• Native SDK flow: Hyperswitch keeps the customer on the merchant’s page while the SDK makes multiple API calls to the wallet provider. Although this flow is complex to implement and unify across providers due to multiple handoffs between SDK and backend, Hyperswitch prefers this integration for:
  • Better UX
  • Lower customer drop-offs
  • More control and visibility to business
• Redirect Flow: Hyperswitch generates a redirect URL and hands control to the wallet provider, which owns the full payment experience before sending the customer back via a callback. Hyperswitch coordinates the hand-off to the service provider and then regains control to normalize the final status and update the overall payment flow. This flow is:
  • Simpler to implement
  • User is sent off-site
  • Harder to track drop-offs, fewer customization hooks

3. Buy Now Pay Later (BNPL) Providers

BNPL providers plug into Hyperswitch using the same two patterns used for wallets: native SDK flows (in-app) or redirect flows (provider-hosted). Both follow the same flows described above.

4. Bank Debits

Hyperswitch unifies bank debits by standardizing state transitions across sync and async systems.

• Async flows (ACH, SEPA): Asynchronous bank debit flows occur when the payment does not settle in real time and the final status arrives hours or days later. In this model, Hyperswitch creates the payment, updates it to a “pending” state, and waits for confirmation from the PSP. ACH bank debit follows this pattern. SEPA can also operate asynchronously when mandate confirmation or settlement runs on delayed cycles across EU banking networks. Hyperswitch standardizes these delayed updates by polling or consuming webhooks to map final statuses consistently across connectors.This flow:
  • Can take days to settle
  • May need micro-deposit verification
  • Terminal states arrive long after authorization

Sync flows (certain regions/banks): Synchronous bank debit flows occur when a connector or bank can validate the account and authorize the payment in real time. In these cases, Hyperswitch receives an immediate approval or failure response and moves the payment directly into a terminal state. SEPA supports synchronous confirmation more commonly. Hyperswitch abstracts these real-time validations behind a unified API, ensuring merchants experience a consistent flow. This flow can include chargeback flows where refunds can happen independently from the merchant by the issuer banks without prior intimations.

5. Bank Account Linking & Verification (Plaid, MX, Finicity)

These connectors verify and link bank accounts so bank debits (ACH, SEPA Direct Debit, EFT) can be completed without friction.

Hyperswitch would classify Plaid-like providers as supporting:

• Instant account verification (no micro-deposits)
• Ownership validation for compliance
• Balance checks before pull payments
• Routing/account extraction for ACH
• Fraud reduction via bank data signals
• Fewer payment failures due to insufficient funds

This connector type removes heavy operational friction for bank debits and is often used alongside ACH.

6. Bank Redirects

• Bank redirect payments in Hyperswitch follow a three-phase flow where the customer is redirected to their bank, returns after approval, and then awaits asynchronous updates. Hyperswitch initiates the process by generating a redirect URL and handing control to the bank’s interface, then processes the bank’s synchronous response when the customer returns. Because many banks do not provide immediate final statuses, Hyperswitch uses a scheduler service to periodically poll connectors, apply configurable retry intervals, and perform status reconciliation. These background sync tasks ensure eventual consistency. Each connector (e.g., Adyen, TrustPay, Nuvei) implements bank redirect flows differently, but Hyperswitch unifies them under consistent state management and retry handling.

7. Vouchers (LATAM, APAC, EU)

Connector implementation of vouchers differ widely, but Hyperswitch unifies them under a single orchestration model that ensures consistent status handling, expiry management, and eventual consistency. Hyperswitch tracks expiry logic to avoid silent failures.

• Voucher payments in Hyperswitch support a wide range of regional methods across LATAM, APAC, and Europe, each with different data requirements, formats, and settlement behaviors. Depending on the provider, vouchers may be returned as QR codes, barcodes, downloadable links, or instruction pages, all normalized through a consistent voucher response structure. Because many providers do not proactively notify expiry or payment completion, Hyperswitch tracks voucher expiry timestamps and uses background scheduler jobs to update statuses. Address requirements may also vary by region. For example, APAC vouchers often require full customer details, while LATAM vouchers typically do not.

8. Gift Cards

Gift cards behave like card-based payments but introduce extra rules:

• Gift cards in Hyperswitch function as a specialized card-based payment method with added logic for balance checks, split payments or multi-tender usage. Each issuer, has unique data requirements, but Hyperswitch unifies them under a consistent model.

Split payments are handled intelligently by allocating amounts across gift card and allowing non-gift card method to be combined in a transaction. This orchestration ensures merchants can support complex gift card scenarios with consistent behavior across different issuers and connectors. Some restrictions on usage are:

• Product/category restrictions
• Basket-level limits
• Multi-tender usage
• Refund logic with partial or split payments

9. RTP (Instant Bank Payments): Pix and UPI

We support core real-time payment systems including:

• Pix (Brazil): Pix is implemented as a bank transfer method that primarily uses dynamic QR codes with short-lived expiry windows (typically 15 minutes). Payments include regional identifiers like CPF/CNPJ and support initiation through multiple connectors, which return QR codes as image data or URLs. Because settlement may take a short time to complete, Hyperswitch tracks Pix payments through polling, expiry validation, and callback-based updates. This ensures merchants receive consistent status handling even across diverse PSPs.
• UPI (India): UPI in Hyperswitch supports three distinct flows: Intent (app-to-app invocation), QR (scannable static or dynamic codes), and Collect (VPA-based pull requests). Each flow uses timestamps, polling configuration, and next-action instructions to manage user interactions and payment expiry. Hyperswitch orchestrates settlement through real-time status polling and webhook callbacks, maintaining accurate state transitions throughout the flow. With support from multiple connectors, Hyperswitch provides a unified experience across all UPI payment paths.

10. QR-Based Payments

• Hyperswitch supports QR-based payments through a unified architecture that manages QR encoding, display, expiry, and status polling across different connectors. QR codes are generated as base64 PNG images, Each connector may return QR data differently, but Hyperswitch normalizes these responses into a consistent format that includes image URLs, embedded data, and expiry timestamps. Payment status is tracked through configurable polling, with expiry handled via connector-provided timestamps or default time windows. This abstraction allows Hyperswitch to deliver seamless QR payment experiences across diverse methods like Pix, WeChat Pay, Cash App, and other regional QR systems. With this payment method, you can expect:
  • QR encoding
  • Displaying QR via SDK
  • Polling for status
  • Handling expiry

11. Crypto Payments

• Hyperswitch supports crypto payments through a dedicated payment method type designed to handle blockchain-specific challenges such as volatility, confirmation delays, and inconsistent payment amounts. The system manages overpay and underpay scenarios using a special status, which is triggered when the received amount differs from what was requested due to user edits, network fees, or fluctuations. Because blockchain confirmations can take time, Hyperswitch keeps payments in a processing state and uses async background services to reconcile final settlement. Refunds and post-processing rely on stored crypto-specific transaction fields, allowing Hyperswitch to standardize crypto flows alongside traditional payment methods. In this payment method, you can expect:
  • Overpay/underpay due to volatile exchange rates
  • Quote expiry (valid for different times depending on the underlying crypto PSP)
  • Dual-currency volatility
  • Refund complexities due to price fluctuations

Hyperswitch’s Unified API Layer Supports Any Providers

Across cards, wallets, bank transfers, crypto, vouchers, and real-time payments, one principle stays constant:

Hyperswitch simplifies global, multi-step payment flows into one consistent, modular layer that works with any PSP or payment method anywhere in the world. If you need a provider we don’t support yet, we can usually build it within two weeks.

Other Connector Types

Payouts

Hyperswitch supports payouts across bank transfers, card payouts and RTP. Payouts often involve multi-hop settlement, async callbacks, and beneficiary validation all abstracted behind a unified API. Payouts help you connect to faster creator/vendor settlements and better marketplace NPS, not just ACH/SEPA/PIX support.

Types of Payout Connectors Supported

Hyperswitch supports a wide range of payout connectors, including:

• Global processors: Adyen, Stripe, Worldpay, Nuvei
• Marketplace/Platform variants: Adyen Platform
• Regional processors: Ebanx (LATAM), Nomupay (Asia), Payone (EU)
• Banking/transfer specialists: Wise (international FX), Gigadat (Canada Interac), Loonio (Interac/EFT/PIX)
• Wallet-based payout providers: PayPal
• Legacy or XML-based variants: Worldpay XML

Payouts do vary by connector; some regions require recipient creation; card payouts need eligibility checks; wallet payouts require access tokens; async settlement depends on scheduler-driven reconciliation; and all methods must meet strict security and compliance requirements.

Fraud & Risk Management (FRM)

The fraud and risk management connector helps reduce fraud loss and chargeback costs, preserves conversion by avoiding over-aggressive rules, lowers engineering and compliance overhead, and gives ISVs flexibility to standardize risk controls across PSPs and merchants.

Here are the different types of fraud engines:

PSP Fraud Engines: These fraud checks run directly through the payment processor’s own fraud system (e.g., Stripe Radar, Adyen Risk). They use the same authentication and connector infrastructure as the payment flow, making them easy to enable without additional integrations.

Standalone Fraud Engines: These are third-party or specialized fraud platforms integrated as dedicated FRM connectors like Signified, Riskified, Sift, Forter and more . They provide independent risk scoring, device fingerprinting, rules-based decisioning, and are selectable per merchant configuration.

Hyperswitch supports these methods across both pre-payment (before authorization) and post-payment (after authorization) flows, allowing merchants to block, approve, or manually review transactions.

3D Secure (3DS)

Hyperswitch supports multiple patterns for integrating 3D Secure (3DS), each demonstrating modularity, separability, and flexible routing:

• External Authentication + HS Authorization: The 3DS challenge is performed by an external 3DS provider, while Hyperswitch handles the downstream authorization and routing.
• Hyperswitch Standalone Authentication (External Authorization): Hyperswitch 3DS solution performs the authentication step independently, and a separate external entity handles authorization.
• Hyperswitch Standalone Authentication + HS Authorization: Hyperswitch orchestrates both authentication and authorization, enabling full routing, retries, and decisioning within its own stack.
• PSP-Provided Authentication (HS Authorization): The PSP manages 3DS authentication as part of its native flow, while Hyperswitch consumes the authentication result and proceeds with authorization.
• Hyperswitch Standalone Authentication + HS Authorization (Headless SDK): Hyperswitch 3DS SDK remains headless and becomes headful only when the 3DS challenge has to be provided/ handled during the payment journey. This flow gives full control to merchant in terms of user experience

Vault / Tokenization Connectors

Hyperswitch’s vault reduces compliance cost and reduces risk. With a vault solution, you can reduce the PCI scope and audit burden because sensitive card data can be tokenized before it touches the system. This shrinks the PCI-DSS scope and reduces the audit complexity. The vaults supported by Hyperswitch are - Standalone Hyperswitch vault, VGS and TokenEx.

Types of Vault Integrations Supported

Vault SDK Standalone & Card Forwarding: Merchants can integrate external vault SDKs (e.g., VGS, TokenEx) to capture the card data and tokenize with the external provider and use their card forwarding API to send the transaction to Hyperswitch. This pattern enables direct card vaulting, multi-token generation (card number, expiry, CVC), and card-forwarding flows.

Vault SDK with Tokenize / Detokenize flow: Merchants can collect and tokenize card data using an external vault and SDK. Once the card is tokenized, the merchant can make a S2S call to Hyperswitch with that token. Hyperswitch will further connect with the vault to detokenize the token and obtain raw PAN which will then be used for transactions. This option allows the merchant to continue with their current vault provider while taking advantage of the unified API and related capabilities offered by Hyperswitch without the need to maintain PSP specific pay loads.

Hyperswitch SDK Loading External Vault SDK: Hyperswitch can load external vault SDKs while maintaining a single integration surface. The Hyperwitch SDK loads the external vault (e.g., VGS or TokenEx) and wraps them under a unified tokenization workflow.

Subscription Engines

Subscription businesses typically have some sort of recurring billing - usage-based, periodic recurring, tier-based and more. Most subscription platforms (Chargebee, Recurly, Stripe Billing, etc.) allow decoupling payments from billing. This essentially allows a business to leverage other payment platforms for payment processing and leveraging the subscription platforms for core subscription creation and management.

Hyperswitch integrates with different subscription engines and decouples billing from payments. Your subscription provider continues to manage the ledger, scheduling, and invoices, while Hyperswitch takes full control of payments, vaulting, retries, routing, and multi-provider orchestration. Businesses have better control with recurring payments, reliability with failover and routing options, and improved authorization rates and costs with a configurable intelligent routing system.

Tax Connectors

Hyperswitch integrates with external tax engines through pluggable connector modules that can be invoked during checkout or recurring billing. These connectors help with compliance and risk. Businesses can have real-time tax calculations at checkout and on subscription renewals to help ensure the correct rates are applied across jurisdictions. This helps reduce the risk of under or over collection and any regulatory penalties.

Built for Enterprises Navigating Constant Banking Change

For ISFs, the hardest part of scaling payments is keeping up with constant changes: new PSPs, new payment methods, new regulations, and new markets your customers want to enter. Hyperswitch is built for exactly this world. Its connector ecosystem lets you plug in local processors, support BYO-PSPs and MIDs, or offer a broad catalog of pre-integrated options so your clients can onboard and go live quickly. If a connector doesn’t exist yet, Hyperswitch can build it in as little as two weeks.