Checkout links Soon
Generate a payment link or a QR. Your customer pays in USDT, and the page works on a bad connection and a broken webview — a payment page that only renders with a perfect browser is not a payment page.
For business
A payment page, a cabinet and an API on the same rails the wallet runs on — and payments that settle to an address you control rather than to a balance we hold.
The merchant track is being built and runs through a licensed partner. It is not in the first release, and we would rather say so here than in a sales call. What that means in practice: early merchants shape it, and the way to be one is a conversation.
Generate a payment link or a QR. Your customer pays in USDT, and the page works on a bad connection and a broken webview — a payment page that only renders with a perfect browser is not a payment page.
Invoices, transaction history, payout settings, roles and API keys. Approval thresholds by amount rather than blanket four-eyes, because a hundred small payouts turn blanket approval off on day one.
A REST API with idempotency keys and signed webhooks with retries and a dead-letter queue. A "paid" event cannot be lost by construction — it is written in the same transaction as the state change it reports.
Mass payouts by CSV or API, on the same routing the wallet uses. Signing stays with you: we prepare unsigned batches and never hold the key that approves them.
What you can check without trusting us
Every payment is a transaction you can look up in an explorer, independently of anything we display.
Your data leaves in a format you can reconcile elsewhere. There is no central ledger of ours to disagree with the chain.
The reserve that pays network costs is a public address with a visible balance and burn rate. You should not have to ask support whether it runs dry tomorrow.
Volume, corridors, the payout side, and what your finance team needs out of it. That conversation shapes what ships.
Talk to us on Telegram