Natio Business

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.

In developmentThe orchestration platform is live; the crypto layer is being built.
Create an invoice
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" }
  }'
Settlement

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.

Nothing to withdraw, no payout schedule, no counterparty risk on the settlement leg — because the settlement leg never existed.
0
Funds held by NATIO
Structurally, not by policy
1
Hop from payer to merchant
Customer address → your address
xpub
What you hand over
Watch-only; cannot sign
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.
Integration

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.

Response
{
  "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"
}
Compliance

Built into the engine, not bolted onto the sales process.

Non-custodial does not mean unregulated. The controls below are enforced by the platform on every transaction, and a merchant cannot configure their way out of them.

Sanctions screening
Accounts and counterparties are screened against published lists. This runs on the platform side and is not configurable away by a merchant.
Business verification
KYB through Didit: the provider holds the evidence, the platform holds the decision, its reference and its timestamp.
Jurisdiction rules
Which markets a merchant may serve is a configuration backed by legal advice for the operating entity, enforced in the engine rather than left to sales.
Full audit trail
Every state change, routing decision and administrative action is written to an append-only log that the application itself has no privilege to alter.
Status

What exists, and what does not.

A landing page is a promise. These are the parts of it we can currently keep.

01

Live

Payments, payouts, routing across providers, retry and failover, reconciliation, settlement reporting, signed webhooks, the merchant dashboard and the developer portal. Tested end to end.
orchestration
02

In progress

Address derivation from a merchant xpub, per-invoice addresses, chain watching and confirmation handling, and the underpayment and overpayment outcomes described above.
crypto
03

Not yet decided

Supported assets and networks, and which jurisdictions can be served. Both follow from where the operating entity is incorporated and what its counsel advises. Published when settled.
scope

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.