Turn digital assets into a saved payment method.

A customer connects an exchange account or a self-custody wallet once. Your platform charges them afterwards - one time, on a schedule, or for an amount decided after the service is delivered. Funds move from the payer straight to your wallet or exchange account, so we are never in the path.

Map your payment stack See where it sits

Custody: None. A single transfer, payer to merchant. No float, no settlement lag, no balance owed to you.
Lifecycle: One-time, recurring, merchant-initiated variable charge, and refunds through one API.
Your stack: Keep your PSP. PayZap connects as one more payment method, not a replacement.
Sources: Exchange balances and self-custody wallets behind one contract.

01 / Architecture

You see one payment method.
The fragmentation is our problem.

Most crypto products ask a platform to adopt a crypto-specific flow. PayZap does the opposite: it arrives underneath the payment abstraction you already have, and behaves like the methods already in it.

Your customerconnects once

Authorizes an exchange account or wallet inside your product. Revocable by them at any moment.

Your platformunchanged

Checkout, subscriptions, post-service billing, and refunds keep their current logic.

Your internal PSPstays in place

PayZap registers beside the methods you already expose.

CardsApple PayLocal APMsPayZap

PayZapone contract

A normalized payment method: bind, mandate, charge, refund, status, webhook. Identical whichever source sits beneath it.

Identity & mandatesOrchestrationSettlement

Funding sourcesinterchangeable

A wallet and an exchange balance are both payment methods behind one API. Your code does not change when a customer switches between them.

Exchange accountsSelf-custody walletsStablecoinsNetworks

02 / Lifecycle

Connect once.
Pay once, subscribe, or charge later.

The hardest pattern for a platform is not the checkout. It is charging a customer who has already left, for an amount nobody knew when they authorized. That is the case PayZap is built for.

A payment the customer approves

A hosted page, a shareable link, or an embedded widget. The buyer picks a chain and a token. You get one webhook when the money lands.

Customer present: Yes
Amount known upfront: Yes
Typical use: Booking, game purchase, eSIM package
Rate: Locked when the order opens

01Create session→02Buyer pays→03Webhook

POST /v1/payments/session

// one integration, one object
{
  "amount": "49.90",
  "currency": "AED",        // priced locally
  "customer_ref": "cus_8121",
  "metadata": { "order": "A-5512" }
}

// → the buyer chooses chain + token
// → one webhook when it settles
{ "status": "settled",
  "rate_locked_at": "2026-08-25T09:14:02Z",
  "fee": 0.42 }

A predictable amount, on a schedule

One standing authorization per customer covers every later charge. It uses the token's own approval mechanism, so no contract of ours stands between the customer and their funds.

Customer present: Setup only
Amount known upfront: Usually
Typical use: Subscription, virtual number, membership
Revocation: From the wallet, without asking us

01Bind mandate→02Charge on cycle→03Retry or fall back

POST /v1/mandates

// once, with the customer present
{
  "customer_ref": "cus_8121",
  "limit": "200.00",
  "currency": "USD"
}

// afterwards, nobody present
POST /v1/payments/charge
{ "mandate_id": "mnd_2f91",
  "amount": "19.00" }

// customer revokes at any time
POST /v1/mandates/:id/revoke

The amount is decided after the service

A ride that ran long, a basket with substitutions, a rental with tolls and fuel. The customer authorized before any of it was known. This is the pattern card-on-file solved for cards, and the one most digital-asset products still do not cover.

Customer present: Setup only
Amount known upfront: No
Typical use: Ride, delivery adjustment, metered usage
Initiated by: Your backend, server to server

01Authorize once→02Deliver service→03Charge final amount

POST /v1/payments/charge

// the trip ended; now you know the fare
{
  "mandate_id": "mnd_2f91",
  "amount": "23.75",
  "currency": "BRL"
}
// header: Idempotency-Key: trip_99120

// failures arrive told apart, not lumped
{ "error": "mandate_reauthorization_required" }
{ "error": "insufficient_balance" }
// they need different handling, so they
// arrive as different codes

Full or partial, on every chain we accept on

A refund belongs to the same order lifecycle as the payment, which is what separates payment infrastructure from a transfer widget. Authorize once and we send them for you, or keep every outbound transfer under your own signature.

New consent: Not required
Scope: Full and partial
Signing: Delegated to us, or yours
Reconciliation: Same register as settlements

01Request refund→02Sign or delegate→03Webhook

POST /v1/payments/:id/refund

{
  "amount": "12.50",   // partial
  "reason": "order_adjusted"
}

// keep outbound transfers under your own
// signature instead:
POST /v1/payments/:id/refund/submit

// or delegate signing once
GET  /v1/merchant/refund-delegation

An agent that pays for your API by itself

Priced API calls an autonomous agent can settle without a human, over the open x402 standard. Verification and settlement are ours; you keep the endpoint. It runs on the same facilitator as everything else on this page, which means an agent paying your API is the same settlement path as a checkout.

Customer present: No human at all
Standard: x402, open
Typical use: Priced API calls, agent-to-service
Settlement path: Shared with checkout

01Price the call→02Agent pays→03Settlement recorded

GET /v1/merchant/x402/settlements

// your endpoint answers 402 with a price
HTTP 402 Payment Required
{ "price": "0.004", "asset": "USDC" }

// the agent pays and retries; we verify
// and settle, you keep serving the call

GET /v1/merchant/x402/stats
{ "settled": 1284, "period": "24h" }

03 / Capabilities

One integration covers the whole acceptance surface.

Checkout, saved payment methods, partner top-ups and machine payments run on the same sessions, the same webhooks and the same ledger.

Checkout

Widget · link · embed

A hosted page, a shareable link, or an embedded widget. The buyer picks a chain and a token; you get one webhook when the money lands.

/v1/payments/session

Saved payment methods

Off-session charging

A customer authorizes once and you charge them per order afterwards, with nobody present. One standing authorization, revocable by them at any moment.

/v1/mandates

Partner top-ups

B2B deposits

Business partners fund their balance by sending stablecoins. Each deposit gets a figure that identifies it, so simultaneous transfers to one address never credit the wrong account.

/v1/deposits

Machine payments

x402

Priced API calls an autonomous agent can pay for by itself, over the open x402 standard. Verification and settlement are ours; you keep the endpoint.

/v1/x402

Local pricing

Rate locked at creation

Quote an order in bolivianos, dirhams or reais. The rate is fixed the moment the order opens and stored with it, so what the customer saw is what settles.

/v1/fx

Refunds

Partial · cross-chain

Full or partial, on every chain we accept on. Authorize once and we send them for you, or keep every outbound transfer under your own signature.

/v1/payments/:id/refund

Fees the buyer never sees

Gasless

A buyer holding stablecoins but no native token still pays. We sponsor the network fee and show you exactly what each one cost.

EIP-2612 permit

Registers for accounting

Daily · API or CSV

Settlements and refunds in one file, in your finance team's own field names, with the fee charged on each. Re-requesting last month returns last month.

/v1/reports

04 / What makes it different

Most of this industry rebuilt the acquirer model on new rails.

Take custody, net it off, pay out on a cycle. We took the opposite decision at each of these points, and the consequences run through the whole product.

Typical

The processor receives your money and remits it on a schedule.

Float, settlement lag, and a balance they owe you at period end.

PayZap

Funds move payer to merchant in a single transfer. We are never in the path.

Nothing to reconcile, nothing owed, nothing to lose if we have a bad day.

Typical

Recurring charges need a custom contract deployed on-chain.

An audit, an upgrade path, and a contract your customers must trust.

PayZap

Saved methods use the token's own approval mechanism. No contract of ours exists.

The customer revokes it from their wallet, without asking us.

Typical

On-chain wallets and exchange accounts are two separate integrations.

Two sets of webhooks, two reconciliations, two failure modes.

PayZap

A wallet and an exchange balance are both payment methods behind one API.

Your code does not change when a customer switches between them.

Typical

Reports are generated from current pricing when you ask for them.

Change a rate and last quarter quietly changes with it.

PayZap

The rate and the fee are written onto each transaction as it settles.

A register re-run a year later returns the figures it returned then.

Typical

Agent and machine payments are on the roadmap.

A pilot, a waitlist, a separate product when it arrives.

PayZap

x402 runs on the same facilitator as everything else, today.

An agent paying your API is the same settlement path as a checkout.

05 / Who it is for

Fit is decided by payment architecture, not by industry.

The strongest fit is a platform whose customers already save a method and come back, and whose backend can charge after the customer has gone. Crypto enthusiasm is not the qualifier.

Ride-hailing and super-apps

A+

The final fare is known after the service, users pay frequently, and the internal payment layer is mature.

Mandate + flexible charge

Delivery and quick commerce

A+

Final baskets, substitutions, tips and post-order adjustments all change the amount after checkout.

One-time + flexible charge

Car sharing and rental

A+

Duration, tolls, fuel, damage and extras are determined long after the customer authorized.

Mandate + flexible charge

Micromobility, parking, tolls, EV

Metered usage produces naturally variable final amounts on every single transaction.

Mandate + flexible charge

Usage-based cloud, AI and dev infra

Consumption is measured first and billed later, and the audience is already digital-asset relevant.

Recurring + flexible charge

eSIM, telecom and travel connectivity

Global users, top-ups, pay-as-you-go and renewals across many fragmented markets.

One-time + recurring

Travel and OTA

B+

High-value international payments with modifications, ancillaries and frequent refunds.

One-time + selected mandates

Gaming and digital goods

B+

Digital-native users, repeat purchases and global distribution from day one.

One-time + recurring

PSPs and orchestrators

Channel

Expose digital assets to many downstream merchants as one alternative payment method, through a single integration.

Distribution partner

Five questions that settle it quickly

If the answer to the first four is yes, the architecture already fits and the rest is commercial. If it is no, a different product is probably the honest answer.

01Do customers already save a payment method and reuse it across transactions?
02Can your backend initiate a payment after the customer has left the checkout?
03Is the final amount ever unknown when the customer first authorizes?
04Do you have a standardized internal payment method API that new methods connect to?
05Would you prefer one integration to direct work with several exchanges and wallets?

06 / What it runs on

Where the money actually moves.

Contracts and decimals are resolved on our side and never supplied by the caller, because a caller-supplied contract address is a class of incident nobody needs.

Networks: Ethereum · Polygon · Arbitrum · Base · BNB Chain · Tron
Tokens: USDT · USDC · DAI
Exchange balances: Binance Pay · Bybit Pay · Coinbase · OKX · Crypto.com
Pricing currencies: USD · EUR · GBP · AED · BRL · MXN · BOB · VES · ARS · TRY · LBP

07 / Integration

The details that decide whether it survives production.

Anyone can move a stablecoin once. What a payments team actually evaluates is what happens on the second attempt, the ambiguous transfer and the delivery that never lands.

Retries

Safe by design

Every money-moving call takes an idempotency key. A repeat returns the original answer instead of charging twice, which matters because your retry logic will fire eventually.

Idempotency-Key: trip_99120

Webhooks

Five attempts, then visible

Five seconds to one hour, backing off. A delivery that never lands stays readable through the API rather than being quietly lost.

Failures

Told apart, not lumped

"Needs re-authorization" and "not enough balance" arrive as different codes, because they need different handling. One is a prompt to the customer, the other is a retry.

Money that arrives unattributed

Queued, never guessed

A partner who rounds an amount ends up in a review queue. Assigning the nearest open deposit would be wrong exactly as confidently as it would be right.

/v1/deposits/unmatched

Sessions and matching

Bounded, and tolerant where it should be

A payment session has a fixed lifetime rather than staying open forever, and amount matching carries a defined tolerance so a rounding difference does not strand a real payment. Both are constants in the codebase, not per-deal improvisation.

08 / Where it runs

Proven as an architecture, not a logo wall.

The useful proof is not a brand mark. It is that a large platform kept its own PSP, connected PayZap as one more payment method, and used it for the hardest pattern there is: charging after the service, server to server.

01Live with one of the largest ride-hailing and gig-economy platforms globally.
02Phase 1 running in two countries: in-app payments, on-chain treasury and cross-border settlement.
03The platform's existing PSP stayed in place. PayZap connected beneath it as one payment method.
04Underlying exchange, wallet, gas and routing logic never reached the platform API.

09 / Talk to us

Map your payment stack.

Thirty minutes with the team that built it. We look at what you take today and what it costs you, then say plainly whether this helps. If it does not, that is a faster answer than a pilot.

Where custody and float are costing you today
Which corridors and currencies you actually need
What saved payment methods change for your repeat volume
A pilot scoped to one flow, with terms fixed before any build

Turn digital assets into a saved payment method.

You see one payment method.The fragmentation is our problem.

Connect once.Pay once, subscribe, or charge later.

A payment the customer approves

A predictable amount, on a schedule

The amount is decided after the service

Full or partial, on every chain we accept on

An agent that pays for your API by itself

One integration covers the whole acceptance surface.

Checkout

Saved payment methods

Partner top-ups

Machine payments

Local pricing

Refunds

Fees the buyer never sees

Registers for accounting

Most of this industry rebuilt the acquirer model on new rails.

Fit is decided by payment architecture, not by industry.

Ride-hailing and super-apps

Delivery and quick commerce

Car sharing and rental

Micromobility, parking, tolls, EV

Usage-based cloud, AI and dev infra

eSIM, telecom and travel connectivity

Travel and OTA

Gaming and digital goods

PSPs and orchestrators

Five questions that settle it quickly

Where the money actually moves.

The details that decide whether it survives production.

Safe by design

Five attempts, then visible

Told apart, not lumped

Queued, never guessed

Bounded, and tolerant where it should be

Proven as an architecture, not a logo wall.

Map your payment stack.

You see one payment method.
The fragmentation is our problem.

Connect once.
Pay once, subscribe, or charge later.