Crypto payments that never touch our hands.
You create a charge, we generate a deterministic on-chain address, and your customer pays straight into it. We just detect and route — we never touch the funds.
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.
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.
How it works
From a charge to a payout — the flow, and the code behind it.
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.
Built for developers
Everything you'd expect from a modern payments API — plus the docs to back it up.
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.
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.