Built for developers

The full integration guide, the edge cases
and every doc you'll need

How it works
From charge to payout

The flow, step by step
and the code behind each one

Charge createdAddress computedPayer sends directlyDetected & paid out
STEP 01 / 05

Install the SDK

One package, zero blockchain plumbing on your side.

terminal
npm install @klappay/node

Before you ask
The edge cases

The questions that 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.

The developer toolkit
Docs, SDK and schemas

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.