Crypto payments that never touch our hands.
No custody, no money-transmitter license, no counterparty risk — the payment lands straight in your wallet.
Klappay is a non-custodial crypto payments API. You create a charge, we compute a deterministic on-chain split address, your customer pays directly into it — we just detect and route it. We never hold a single cent.
import { createClient } from '@klappay/node'// reads KLAP_BASE_URL and KLAP_API_KEY from process.envconst klap = createClient()const charge = await klap.charges.create({amount: 49.9,expiresIn: 900,acceptedPayments: [{ token: 'USDC', network: 'base' }],})const paid = await charge.waitForConfirmation()console.log('Paid:', paid.amountReceived)
How it works
Four steps, and the money never touches a Klappay vault.
You create a charge
One API call with an amount and accepted tokens. A deterministic id is born with it.
Klappay computes the address
A split address (0xSplits v2) is derived for that exact charge — recipients frozen and immutable since creation.
The payer sends directly
Your customer sends funds straight to that on-chain address. It never passes through a Klappay-controlled account.
Klappay detects and distributes
We watch the chain, confirm the transfer, and trigger the payout to the merchant wallet — no custody at any step.
Not built like the rest of the market
Most crypto payment processors still behave like a bank: they hold your money before passing it on. Klappay holds nothing.
KlappayNo on-chain chargebacks — but also no processor standing between you and your funds. They're yours the moment they land.
Audit it yourself: the Node SDK and the shared types package are open source (MIT) on GitHub — read exactly what runs in your backend before you trust it with a single charge.
One API, a growing suite of products
The Core API is the foundation — everything above it ships as a standalone product.
Klappay Core
The non-custodial payments API — charges, distributions, and webhooks for any crypto checkout.
- Swap-to-paydone
- Escrowdone
- Fiat Off-ramp-
- Sanctions Screening-
- White-label-
Klappay Link
Shareable payment links and product pages — create one from a dashboard, get paid non-custodially, no API integration required.
Klappay Fund
Pooled fundraising with on-chain, non-custodial escrow.
Klappay Give
Tipping and donations, split and settled non-custodially.
Klappay Recurring
Subscription and recurring billing on crypto rails.
Klappay One
One button, one wallet for every payment address you own — approve from a push notification, wherever you are.
And much more
A few examples of what's next:
- Klappay Commerce — Embeddable checkout widget for your site or app.
- Klappay Payroll — Pay your team globally in USDC, on a schedule.
- Klappay Streams — Pay by the second — continuous money flow.
Zero to first payment in 5 steps
Real example, straight from the official Node SDK.
Install the SDK
One package, zero blockchain plumbing on your side.
npm install @klappay/node
Before you ask: the edge cases
The questions that actually decide whether an integration ships. Full detail in the docs.
Sent more? The charge still confirms — charge.isOverpaid and amountReceived tell you exactly how much extra arrived, no separate status to branch on. Sent less? It sits partially_paid until the rest arrives or the charge expires.
The charge moves to expired, but the address keeps working — a late transfer is still credited and the charge resolves to underpaid with the real amountReceived, never silently dropped.
Yes. A charge paid in installments sits in partially_paid, summing every transfer against the total, until it either clears (confirmed) or the deadline passes.
No — and it's structural, not a missing feature. The on-chain split address is frozen to [merchant, treasury] at creation; the payer is never one of its recipients, so there's no contract call that can send funds back to them. You decide the remedy from your own side: partial delivery, manual refund, or credit toward a future charge.
Every webhook and SSE event carries the exact (token, network) pair that paid — acceptedPayments lists what the charge was configured to accept, paidWith lists what actually arrived. Your handler never has to guess which chain to reconcile against.
Everything to integrate
Live API reference, a ready-to-import Postman collection, and full SDK docs — no account required to look around.
Open source on GitHub
The Node SDK and the shared @klappay/types schemas are MIT-licensed — read exactly what runs in your backend.
API reference
Interactive docs generated straight from the live OpenAPI schema — try any endpoint from the browser.
Postman collection
Ready to import, regenerated fresh from that exact instance — never drifts from the code actually running.
Node SDK docs
Client setup, charges, webhooks, sandbox testing, error handling — the full @klappay/node reference.
@klappay/types
The Zod schemas and TypeScript types both the API and SDK share. MIT-licensed, published standalone.
Built for developers
Everything you'd expect from a modern payments API.
Non-custodial by design
Every charge gets its own deterministic split address. Funds never sit in a Klappay-controlled wallet.
Type-safe SDK
The Node SDK and the API share the same Zod schemas — no hand-written types drifting out of sync.
Webhooks + realtime SSE
Get notified the moment a charge is confirmed, partially paid, or settled — push, not poll.
Sandbox testing
Simulate any charge event end-to-end, no real on-chain activity or testnet faucet required.
Multi-network, multi-token
A live capability matrix tells you which (token, network) pairs are accepted — build the picker, don’t hardcode it.
Precise settlement
Overpay, underpay, partial payments — handled as an exact decimal state machine, never floating-point guesswork.