REST API Crypto Payment Gateway: Build Checkout on Your Terms

Why finding a crypto payment gateway API is harder than it should be

If you run a custom cart, a marketplace, a SaaS billing system, or any checkout your team built in-house, plugins don't help you. You need an API: something your backend calls to create a charge, and something that calls you back — reliably, verifiably — when the money arrives.

Search for a "crypto payment gateway API" and you'll find two frustrating piles. The first is custodial gateways with an API bolted on: the REST surface looks familiar, but every payment lands in the provider's balance, and your actual money arrives later — after their payout schedule, their risk review, their withdrawal threshold. You integrated an API; you got a bank-shaped intermediary.

The second pile is raw chain infrastructure: node providers, wallet SDKs, and "just watch the mempool" tutorials. Now your roadmap includes address generation, confirmation tracking across nine networks, underpayment handling, reorg awareness, and key management on a production server. That's a payments team, not an integration ticket.

What the wrong integration costs you later

The gateway decision looks reversible from the outside. In practice, whatever you wire into your order lifecycle hardens fast — webhooks drive fulfillment, finance reconciles against it, support workflows grow around it. Pick wrong and you pay in three currencies:

• Engineering time you never get back. DIY chain-watching starts as a sprint and becomes a permanent on-call rotation. Every new network your customers want doubles the surface. Meanwhile the feature you actually wanted — "customers can pay in USDC" — still isn't shipped.
• Custody risk you didn't sign up for. With a custodial gateway API, your revenue sits in someone else's ledger between payout runs. A compliance flag, a policy change, or the provider's own banking trouble can freeze money you already earned. If the provider shuts down, so does your access — we've written about what happens when a crypto payment provider closes.
• Reconciliation debt. APIs without proper charge objects — exact amounts, references, expiration, overpayment detection — turn every mismatched payment into a support ticket and a spreadsheet row. At volume, "someone sent 49.97 instead of 50.00" becomes a part-time job.

The cost of inaction compounds too: while the integration waits, card rails keep charging ~3% per sale, cross-border cards keep declining, and chargebacks keep landing on goods you already delivered.

Why card PSP APIs and custodial gateways can't fix this

The problem is structural, not cosmetic. A card PSP API — however clean — inherits the card network underneath: authorization vs. settlement gaps of 1–3 days, disputes that reopen a sale up to ~120 days later, acquirer risk teams that can hold or terminate the account, and FX spreads on anything cross-border. Your API integration is only as final as the rail it rides.

Custodial crypto gateways swap the card network for a ledger the provider controls — which reintroduces the same failure mode at a different layer. The on-chain payment is final, but your claim on it is an IOU in their database until the payout executes. Finality that stops one hop short of your wallet isn't finality.

What a developer actually needs is a gateway where the API manages the checkout mechanics (charges, amounts, confirmations, callbacks) while settlement goes straight to an address the merchant controls. That's the definition of a non-custodial crypto payment processor — and it's the architecture Payzum exposes over REST.

What the Payzum REST API gives your backend

Payzum is a non-custodial, crypto-only payment processor with a developer surface designed to feel like the PSP APIs your team already knows — minus the custody. The pieces:

Charges and invoices as first-class objects

Your server creates a charge for an exact amount and reference, authenticated with an API key. Invoices carry an expiration window and overpayment detection, so the classic crypto edge cases — paid too late, paid too much, paid slightly short — are platform behavior with defined states, not custom code in your order service.

Signed webhooks for the order lifecycle

When a payment confirms on-chain, Payzum calls your endpoint with a cryptographically signed webhook. You verify the signature (an HMAC over the payload — the pattern standardized in RFC 2104) and only then flip the order to paid. No polling, no trusting unauthenticated callbacks, no marking orders paid off a redirect URL.

An integration playground before real money moves

The integration playground lets you rehearse the full lifecycle — create charges, trigger confirmations, receive and verify webhooks, exercise expiration and overpayment paths — before your first real transaction. Your test suite can cover the payment flow the way it covers everything else.

Settlement that skips the gateway entirely

Here's the architectural difference: the API orchestrates the payment, but the funds move on-chain to your wallet — Payzum never holds them. Turn on auto-convert and whatever coin the customer pays with settles as USDC or USDT, so the dollar amount you charged is the dollar value you keep. Payments confirm in seconds on fast networks: ~0.4s on Solana, ~2s on Base and Polygon.

The rest of the platform, same account

The API is one door into a full stack: hosted checkout (redirect, modal, or inline) when you'd rather not render payment UI, no-code payment links, recurring subscriptions, donations, and POS. And if your product is itself an API, the same dashboard can publish an x402 endpoint so AI agents can pay per call in USDC on Base — no protocol work on your side.

How the integration works, step by step

1. Create your account, pass KYC, and generate an API key. Sign up at merchant.payzum.com, complete verification, and issue keys from the dashboard. Secrets are stored encrypted, the account supports 2FA, and every action lands in a full audit log.
2. Point settlement at a wallet you control. Any address you hold the keys to — hardware wallet, MetaMask, Phantom, a treasury multisig. Optionally enable auto-convert to USDC/USDT for volatility protection.
3. Wire charges and webhooks into your order flow. Create a charge server-side when checkout starts; verify the signed webhook to mark it paid. Rehearse the whole loop in the integration playground. Exact schemas and endpoints live in the API docs.
4. Go live. Customers pay in USDC, USDT, or any supported asset across Bitcoin, Ethereum, Solana, Polygon, Base, Arbitrum, Optimism, BNB Chain, and Avalanche. The webhook fires on confirmation and the funds are already in your wallet.

Conceptually, the whole round trip is:

# 1) Your backend creates a charge (API-key auth)
POST /charges          → { amount, asset, reference, expires_in }
                       ← { charge_id, payment_details, status: "pending" }

# 2) Customer pays from any wallet; the network confirms in seconds

# 3) Payzum calls you back — signed
POST https://yourapp.com/webhooks/payzum
X-Signature: <HMAC of payload, your webhook secret>
{ "charge_id": "...", "status": "confirmed", "reference": "order_1842" }

# 4) You verify the signature → mark the order paid → fulfill
#    Funds are already in YOUR wallet — there is no payout step.

Step 4 is the part that should feel strange if you're used to PSPs: there is no "waiting for payout" state anywhere in the lifecycle. Settlement is the payment.

What teams build on a crypto payment gateway API

Four setups we see engineering teams ship, all on the same REST surface:

• Marketplace with a custom cart: a LATAM marketplace creates one charge per order, keys webhooks to order IDs, and fulfills the moment payments confirm on Polygon. Cross-border buyers whose cards used to decline now pay in USDC, and finance reconciles against charge references instead of bank statements.
• SaaS with in-house billing: a B2B SaaS adds "pay in stablecoins" next to cards in its own billing UI. Invoices carry expiration windows, renewals ride recurring crypto billing, and revenue stops dying to disputes — there is no chargeback window on-chain.
• Headless storefront: a DTC brand on a headless stack embeds hosted checkout inline for the payment step but drives everything else — order creation, status, receipts — through the API and signed webhooks. No payment UI to build, full control of the flow.
• API company monetizing agent traffic: a data provider already using the REST API for human customers configures its endpoint, key, and price in the dashboard, and Payzum publishes an x402 URL in front of it. AI agents pay USDC on Base per call — settled, like everything else, straight to the company wallet.

Payzum API vs custodial gateway APIs — what changes

Common developer objections — answered

"I don't want to run blockchain infrastructure."

You don't. Payzum handles address management, payment detection, and confirmation tracking across all nine supported networks. Your side of the integration is HTTPS: create charges with an API key, verify webhook signatures with your secret. There are no nodes, no RPC providers, and no private keys on your servers — settlement goes to a wallet you manage wherever you already manage it.

"Payments are final — how do refunds and disputes work?"

Finality removes involuntary reversals: no bank can claw back a settled sale four months later, which is exactly why on-chain revenue reconciles so cleanly. Customer service stays yours: when a refund is warranted, you send funds back from your wallet under your policy. You keep the decision; you lose the dispute quota, the arbitration fees, and the "item not received" fraud on delivered goods.

"We already run a card PSP — is this a migration?"

No. The standard pattern is additive: crypto runs alongside cards as one more payment method, driven by the same order lifecycle. Your card flow doesn't change. The customers who reach for it first are the ones cards currently lose you — cross-border buyers, stablecoin-native customers, and anyone whose local rails don't work.

"What does it cost per transaction?"

Settlement rides on-chain network fees — cents on Base, Polygon, and Solana — rather than a percentage of the sale. // confirmar pricing actual — book a call for current pricing on your expected volume.