Payout Processors

Distribute funds programmatically to bank accounts, cards, and wallets via Hyperswitch's unified payout infrastructure, with smart routing, bulk operations, and independent tokenization.

Overview

The Juspay Hyperswitch Payouts infrastructure allows you to programmatically distribute funds to third parties, including affiliates, contractors, and merchants, across a variety of payment methods. By integrating with global processors, Hyperswitch helps you manage the entire payout lifecycle from a single point of control.

• Automate at scale: Orchestrate high-volume bulk payouts. Schedule when each payout is created from your application.

• Optimize reliability: Use smart retries and routing to minimize failed transfers.

• Maintain compliance: Reduce your PCI burden with secure, processor-agnostic tokenization.

• Unified visibility: Track every payout across different regions and connectors in one dashboard.

Key Features

High-velocity distribution

Move funds to bank accounts, cards, or digital wallets through your preferred connectors. Whether you are using funds collected through Hyperswitch or external sources, our API ensures a seamless transfer experience.

Intelligence and routing

Maximize payout success with Smart Retries. If a payout fails due to a temporary connector error, Hyperswitch automatically retries the transaction through the most viable path, ensuring your partners get paid on time without manual intervention.

Flexible data handling

• Independent Tokenization: Securely store card and bank data using our processor-independent vault. This gives you the flexibility to switch payout partners without losing your users' payment credentials.

• Bulk Operations: Effortlessly manage large-scale disbursements by uploading .xlsx or .csv files directly via the dashboard.

• Account Verification: Ensure the validity of recipient bank accounts through Stripe or other supported verification providers.

Supported payout connectors

The payout connector enum defines 21 wire values: adyen, adyenplatform, cybersource, deutschebank, ebanx, gigadat, gotyme_sanlam, loonio, nomupay, nuvei, payone, paypal, stripe, truelayer, trustly, wise, worldpay, worldpayxml, envoy, itaubank, and santander. See the PayoutConnectors enum and its snake_case serialization.

Helcim is not a payout processor in this list. Connector-specific payment methods can differ, so check the relevant payout processor page before integration.

Supported connectors

Payouts run through 21 connectors. The names below are the variants of PayoutConnectors, so the list is exactly what the router accepts.

Connector	Regions	Cards	Bank Rails	Wallets
Adyen	Global	-	SEPA	PayPal
Adyen Platform	Global	Visa, Mastercard	SEPA	-
Cybersource	Global	Major Networks	-	-
Deutsche Bank	Europe	-	SEPA	-
Ebanx	Brazil	-	Pix (Key)*	-
Envoy	UK, EU & US	-	SEPA, BACS, ACH	-
Gigadat	Canada	-	Interac	-
GotymeSanlam	South Africa	-	PayShap, PayShap Proxy	-
Itaubank	Brazil	-	Pix, Pix Key, Pix EMV	-
Loonio	Canada	-	Interac	-
Nomupay	Europe	-	SEPA	-
Nuvei	Global	Visa, Mastercard, Amex, Discover, Diners Club, JCB, UnionPay, Interac	-	-
Payone	Europe	Major Networks	-	-
PayPal	Global	-	-	PayPal, Venmo**
Santander	Brazil	-	Pix, Pix Key, Pix EMV	-
Stripe	Global	Debit Cards	ACH	-
Truelayer	UK & Europe	-	Open Banking	-
Trustly	Europe	-	Trustly (A2A)	-
Wise	Global	-	ACH, BACS, SEPA	-
Worldpay	Global	-	-	Apple Pay
Worldpay XML	Global	Visa, Mastercard	-	Apple Pay, Google Pay

The regions and method columns are maintained by hand and are not derived from the connector declarations, so treat them as a guide and confirm with your connector. The connector names are the part tied to the source.

Payout fields and wire values

Use these request values when you create or update a payout:

• payout_type: card, bank, wallet, or bank_redirect. These values come from PayoutType with snake_case serialization.

• payout_method_data: card, bank, wallet, bank_redirect, passthrough, or bank_transfer. These values come from PayoutMethodData with snake_case serialization. bank is deprecated in the source, which directs new integrations to bank_transfer instead; prefer bank_transfer unless you are maintaining an existing integration.

• For bank_transfer, payout_method_type: ach, bacs, sepa, pix, pix_key, pix_emv, trustly, open_banking, payshap, or payshap_proxy. The field is the tagged discriminator on BankTransfer.

"payout_type": "bank",
"payout_method_data": {
  "bank_transfer": {
    "payout_method_type": "ach",
    "bank_account_number": "<account number>",
    "bank_routing_number": "<routing number>"
  }
}

payout_type is a plain string. payout_method_data is not: it is an object keyed by the method name, because PayoutMethodData carries the method's details and is externally tagged. Sending "payout_method_data": "bank_transfer" is not a valid request. Inside bank_transfer, the method type is a field rather than another level of nesting, because BankTransfer is tagged on payout_method_type.

Crypto assets are not modeled as payout methods. This includes USDT. The payout method enums have no crypto or USDT wire value.

FAQ

Can I use Hyperswitch solely for payouts without payments?

Yes. Hyperswitch is modular. You can use our infrastructure to handle payouts independently of your payment collection. You can initiate payouts via direct payment info or by using an existing Token ID.

Can Hyperswitch schedule recurring payouts?

The payout service can reuse a saved payout method for a later payout, but your application must decide when to create each payout. The create validator treats a request with payout_method_id as a recurring payout and requires confirm: true; it does not define a schedule or recurrence interval. See the validate_create_request check. Follow Payouts with Saved Payment Methods for method reuse.

What is the benefit of independent tokenization?

It prevents vendor lock-in. By tokenizing sensitive data independently of the underlying processor, you retain ownership of your data and can route payouts to any supported connector without asking your users to re-enter their information.