Skip to content
Try Hanzo
Language: English (United States)

Hanzo Payments

Payment orchestration

One integration, and the processor becomes a routing decision.

Order 6735usd

amount: 2000$20.00

  • Visa
  • Mastercard
  • Amex
  • PayPal
  • Apple Pay
  • Google Pay
  • iDEAL
  • Bancontact
  • SOFORT

hanzo.payments.create

Pay

A payment, routed01 / 04

Move a percentage first

The reason nobody switches is the rewrite. When the integration is here, moving is a routing change, and you can move a percentage first.

One traffic, two routes

second processor20%20 · $400.00

current processor80%80 · $1,600.00

attempt 2 · backup0 · $0.00A decline cascades to a backup rather than to your customer

second processorcurrent processorbackup

What sits behind the one integration

Unified Payments Suite

Each processor has its own API, its own idea of an error, and its own webhook format. This normalises all three, so your code sees one shape whichever of them took the payment.

  1. 01

    One integration

    Cards, wallets, bank debits, buy-now-pay-later and crypto through the same API

    Normalized webhooks

    Every processor announces a settlement differently. You subscribe to one event shape and keep it when you add or drop a provider.

  2. 02

    No card data

    Numbers are tokenized in the vault, so this service never holds one

  3. 03

    Route on outcome

    Send each payment to the processor most likely to approve it

    Smart routing

    Choose the processor per payment on cost, success rate or latency. The rule lives here, so tuning it is a config change rather than a deploy.

  4. 04

    Retry elsewhere

    A decline cascades to a backup rather than to your customer

    Cascading retries

    A soft decline is often a fact about one processor, not about the card. Failed attempts fall through to a backup automatically, and the customer sees one outcome.

One API in front of all of them

The connectors are the product. Each is a real implementation of one processor’s API, kept behind a single interface so your side never learns their differences.

The processor is not in your code

You ask for a payment. Which company took it is an answer, not an argument.

API Reference
javascript
// Take a payment. You do not name the processor.
const payment = await hanzo.payments.create({
  amount: 2000,
  currency: 'usd',
  customer: customer.id,
  metadata: { order_id: '6735' },
});

// The routing rule picked one, and says so.
// If it had declined, the cascade would already
// have tried the next and told you that instead.
console.log(payment.status);    // 'succeeded'
console.log(payment.connector); // 'adyen'

What you can see once it is one pipe

  • Approval rates, cost and latency compared across processors, on one screen.
  • 3D Secure where the issuer asks for it, without a second integration.
  • Open source, so the routing logic is readable before you trust it.

Customizable Checkout Experiences

Create beautiful, high-converting checkout flows that drive revenue growth and customer satisfaction.

Global Payment Methods

  • Visa
  • Mastercard
  • Amex
  • PayPal
  • Apple Pay
  • Google Pay
  • iDEAL
  • Bancontact
  • SOFORT
  • 01Cards, wallets, bank debits, buy-now-pay-later and crypto
  • 02Local methods handled by whichever processor supports them best
  • 03The method someone expects to see, in the country they are in

Automatic Global Tax Compliance

Focus on your business while Hanzo handles the complexity of global tax regulations and compliance.

When a switch earns its place

One processor and one country does not need one. These four do.

Put one paymentthrough it

Point it at the processor you already use, send a live payment, and add the second one when you want to see the difference. Nothing has to move on day one.

Contact Sales