Get paid on-chain.
Settle to your wallet.
You give NATIO an extended public key. It derives a fresh address for every invoice, watches the chain and tells you the moment a payment confirms. The funds go from your customer to you. There is no intermediate balance, because there is no account for one to sit in.
curl -X POST https://api.natio.me/v1/payments \
-H "Authorization: Bearer natio_sk_test_..." \
-H "Idempotency-Key: order-5512" \
-H "Content-Type: application/json" \
-d '{
"amount": 149900,
"currency": "EUR",
"method": "crypto",
"settlement": {
"asset": "USDT",
"network": "tron",
"account": "wal_acct_7Kd2"
},
"reference": "ORDER-5512",
"customer": { "reference": "cus_8812" }
}'The shortest path between your customer and your treasury.
Most crypto gateways take custody, net their fee and pay you out later. That turns a payment into a credit exposure: your money sits on someone else's balance sheet until they choose to release it.
- One address per invoice
- Derived from your own extended public key at a recorded path. Two customers never share an address, so attribution is exact rather than inferred from amounts.
- Confirmations are a status, not a guess
- The payment moves through pending → processing → successful as confirmations accumulate against the threshold set for that asset. Every transition is recorded and immutable.
- Underpayment and overpayment are first-class
- A short payment does not silently fail and a long one does not silently vanish. Both produce a recorded outcome you can act on, with the observed amount against the expected one.
- Reconciliation is the same machinery
- On-chain receipts land in the same reconciliation and settlement reports as card and bank transactions, so the month closes in one place.
The same API you already have.
Crypto is a payment method on the existing endpoint, not a second platform bolted alongside. The object, the idempotency guarantees, the timeline and the webhooks are the ones your integration already handles.
A merchant that has integrated cards through NATIO adds on-chain acceptance by sending a different method and a settlement account. The response carries the address to display, the exact expected amount and the confirmation threshold, so a checkout page can render a QR code without knowing anything about chains.
Everything downstream is unchanged. The payment appears in the same transaction monitor with the same timeline, the same signed webhook contract fires, and it reconciles in the same report as every other method.
{
"id": "pay_9Xq4mB7tLz",
"object": "payment",
"mode": "test",
"status": "pending",
"amount": 149900,
"currency": "EUR",
"method": "crypto",
"settlement": {
"asset": "USDT",
"network": "tron",
"address": "TW7k...derived-per-invoice",
"derivation": "m/44'/195'/0'/0/418",
"expected": "1631.204000",
"confirmations_required": 19
},
"expires_at": "2026-09-22T10:14:02.118Z",
"created_at": "2026-09-22T09:44:02.118Z"
}What the engine enforces, and what it does not yet.
Non-custodial does not mean unregulated. Two of these controls are in the engine today and a merchant cannot configure their way out of them. Two are not built, and are named here rather than left to be discovered during an audit.
- Append-only audit trail
- Every state change, routing decision and administrative action is written to a log the application's own database role cannot alter. The constraint is a database trigger, not a convention, so it holds even if the application is wrong.
- Provider eligibility by country
- Routing will not hand a payment to a provider that does not support the country, currency or method involved; the attempt is refused with a recorded reason rather than sent and declined. This is provider capability, not a licensing control — it is listed here for what it is.
- Sanctions and watchlist screening
- Designed, not implemented. NATIO does not screen accounts or counterparties against published lists today, and nothing in the platform should be read as doing so. Said plainly because a screening claim is the kind a merchant would rely on without re-checking.
- Business verification (KYB)
- A KYB decision can be recorded against an account today; the verification behind it cannot. It is intended to run through an identity provider, so the provider holds the evidence and NATIO holds only the outcome, its reference and its timestamp. No provider is integrated, so the record exists and the check does not.
What exists, and what does not.
A landing page is a promise. These are the parts of it we can currently keep.
Built
Built
Not built
Not yet decided
NATIO is a payment technology platform. It is not a bank, an acquirer, a payment institution or an electronic money institution, it holds no such licence, and it neither accepts nor holds customer funds. Payment processing and settlement in fiat are performed by licensed providers connected to the platform.
Tell us what you are selling and where.
Market, volume and method mix decide what gets built first. A short description is more useful to us than a signup, and more useful to you than a waitlist.