Product
Take it in, hold it, move it, send it out
Four things happen to money here, and each of them is written down twice in a ledger that has to balance. Accept a payment. Hold a balance you can see the parts of. Convert between assets without touching a chain. Pay one address, or a thousand.
Supported today
BTC
Bitcoin
bitcoin
8 decimals · 2 confirmations
ETH
Ethereum
ethereum
18 decimals · 12 confirmations
LTC
Litecoin
litecoin
8 decimals · 6 confirmations
MATIC
Polygon
polygon
18 decimals · 30 confirmations
That is the whole list. Confirmation counts are held per asset and are the window in which a chain reorganisation could take a deposit back after we had already credited it, so they are set conservatively rather than for a fast demo.
Accepting payments
Two ways in, one behavior
A link you paste into an email, or a POST from your backend. Both create the same object, and both give the payer the same hosted page.
Payment links
A fixed-amount invoice with an expiry, or an open-amount donation link that never expires. The payer gets a QR, the exact amount, a live countdown and a status that updates itself as the payment confirms.
How payment links workREST API
POST /payment-requests with a key,
and a signed webhook tells you the moment it settles. Four endpoints
in total; you can read the whole reference in one sitting.
An address per request
Every payment request is given its own freshly derived receive address. That address is what makes an inbound payment attributable — sharing one across invoices would make two customers paying the same amount indistinguishable.
Underpayment is not payment
Send less than the invoice and it stays partial, with the remainder shown on the page. Auto-settling a short payment would let anyone buy anything for one satoshi.
Overpayment is credited and flagged
The full amount reaches your balance and the request is marked overpaid, so you can refund the difference deliberately rather than discovering it in a reconciliation.
Holding balances
Three numbers, not one
A single balance figure hides the two things you most need to know: what is still confirming, and what is already spoken for.
-
Available
Yours to spend right now. A payout, a swap or a transfer comes out of this.
-
Pending
Seen on chain but not yet confirmed. Deliberately not spendable — an unconfirmed deposit can be taken back by a reorg, and letting it be spent would be lending money to whoever sent it.
-
Held
Reserved against a payout in flight. The hold is taken the moment the payout is requested, so the same balance cannot be promised twice while it waits.
Estimated fiat value is shown across priced assets only. An asset with no current price is left out and marked, never counted as zero — no price is not a price of nothing.
One deposit, in entries
Once the chain confirms it, a second balanced group moves the same amount from pending to available. A group that does not sum to zero is refused before it is written, an account name that is not on the allowlist throws, and a movement that would take a balance below zero rolls the whole thing back.
The balance row is a cache of those entries, written in the same transaction. An hourly job re-derives every balance from the entries and compares. A mismatch is logged as critical rather than quietly corrected.
How funds are handledConverting between assets
A swap that never touches a chain
Both sides of the trade are balances we already hold, so a conversion is two balanced ledger groups and nothing else. No transaction is broadcast, so there is no network fee and no confirmation wait.
Quote, then confirm
A quote holds for 60 seconds and moves nothing on its own. Only confirming executes it, and the quote is re-checked under a lock at that moment — an expired one is refused rather than filled at a stale rate.
Priced from a public feed
Rates are crossed from USD prices refreshed every five minutes. A price older than an hour is treated as no price at all and the swap is refused, rather than executed against a number nobody should trust.
The fee is the spread
A spread is taken on the receiving side and shown in the quote before you confirm. It is configured per asset, so what you pay is visible rather than inferred.
Because we are on both sides of it, a swap is an inventory position we carry, not an order routed to an exchange. The exact spread applied to your account is part of your commercial terms — see pricing.
Paying out
One address, or a thousand
A single send, a batch from a CSV, or a schedule that runs itself. All three end up on the same reviewed withdrawal path — a second implementation of the send routine would be a second set of bugs.
Single send
Pick an asset, paste an address, confirm with your authenticator. The address is structurally validated for that chain first, and an amount below the asset minimum is refused before anything is held.
Bulk batches
Up to 1,000 recipients from a CSV. Every row is validated and the whole total is checked against your balance before the batch is accepted — finding out on row 400 that the balance ran out would leave 399 payments on chain and the rest stranded.
Scheduled payouts
Daily, weekly or monthly, with an optional run limit. After an outage a schedule skips the periods it missed rather than firing all of them at once.
Nothing broadcasts on its own
There is no path in this system where software decides, unattended, to put a transaction on a chain. A payout is created, then approved, then broadcast by a person — and whoever approved it is not permitted to be the one who broadcasts it.
See it with your own invoice
Create a payment link in a minute, or read the API docs and integrate this afternoon.