Idempotency on every mutation
An Idempotency-Key header on every public mutation, and a correlation id that runs from the start of an operation through to the webhook you receive. Retrying is always safe.
Developers
The API, before it ships.
The merchant API is in design, and the contract is being written before the code — which is the useful moment to hear from you. Below is what is already decided.
Honestly: not yet
There is no public endpoint and no key to issue today. Everything on this page is a design commitment, and the reason it is published this early is that integrators are the right people to argue with about a wire contract while it can still change cheaply.
What is already decided
Webhooks that cannot be lost
Signed with HMAC, carrying a nonce, delivered with retries and a dead-letter queue. The event is written in the same database transaction as the state change it reports, so a delivery failure is a delivery problem and never a lost payment.
Money in integer minor units
Amounts cross the wire as integers with explicit decimals per token. No floats, anywhere, in any direction — your side formats, ours calculates.
Unhappy states are first-class
Underpaid, overpaid, expired, wrong network and reorged are documented statuses with defined transitions, not edge cases discovered in production.
OpenAPI is the source of truth
The specification is written first and the server is validated against it at runtime, so drift between docs and behaviour is rejected rather than discovered. Clients are generated from the same document.
API keys never sign
An org-scoped key can prepare a payout batch; it cannot approve one. Signing stays with a key holder on a device, which is the same boundary the wallet draws.
Roughly this shape
Illustrative — the published contract is what binds, and it is not published yet.
Want a say in the contract?
Tell us what you are integrating and what your last crypto integration got wrong. Early access goes out in the order those conversations happen.
Request early access