Payment orchestration as a single infrastructure layer.
NATIO sits between your platform and the licensed payment providers you use. It exposes one API, decides where each payment or payout goes, protects you from provider failures, and gives finance and operations one view of everything that happened.
What the platform consists of.
Each module is exposed through the API and the dashboard. Everything is scoped to a merchant, a project and a mode (test or live).
Universal Payment API
One REST API for payments, refunds, stored payment method references and transaction history across every connected provider.
- POST /v1/payments with amount, currency, payment_method
- Capture, cancel, refund
- Hosted pages and QR via next_action
- Idempotency-Key on every mutating call
Orchestration engine
Risk evaluation, routing and provider attempts run inside the request. Every step is written to the payment timeline.
- Strict state machine per payment, refund and payout
- Retry and failover with double-charge protection
- Provider status lookup after timeouts
- Timeline endpoint for support and audit
Routing
Deterministic, rule-based provider selection. Conditions on country, currency, method, amount, risk and time; ordered, weighted or score-based strategies.
- Priority-ordered rules
- Eligibility by method, currency, country and limits
- Transparent scoring (cost, approval rate, uptime, latency)
- Architecture prepared for ML ranking later
Payouts
Send funds to beneficiaries through licensed providers selected by payout routing rules. Destinations are tokenised references.
- POST /v1/payouts
- bank_account, wallet, card_token destinations
- Cancel while pending
- Payout events by webhook
Reconciliation & settlement
Match provider reports against NATIO records and follow the settlement batches providers report.
- CSV import today, provider APIs next
- MATCHED / MISSING_PROVIDER / MISSING_NATIO / AMOUNT_MISMATCH / STATUS_MISMATCH
- Settlement batches with gross, fees, net
- Processed vs settled per currency
Webhooks
Signed, retried event delivery for payments, refunds, payouts and settlements, with delivery logs and manual resend.
- Natio-Signature HMAC-SHA256 with timestamp
- Backoff 30s → 2h, up to 6 attempts
- Delivery attempts visible in the dashboard
- Test endpoint from the API
Risk rules
Configurable rules score each payment before routing: allow, review or block. Reviews wait for an operator decision.
- Amount, velocity and attribute rules
- Score and decision stored with the payment
- Manual approve / reject with audit trail
- Blocked payments fail with risk_blocked
Analytics & monitoring
Transaction monitor and analytics across providers, methods and countries, computed from your own data.
- Volume and approval rate over time
- Provider comparison: approval, latency, fees
- Failure breakdown by code and category
- Filters by provider, method, country, currency
What NATIO does, and what it deliberately does not.
NATIO is a technology infrastructure layer. The regulated parts of a payment stay with the licensed providers connected to the platform.
NATIO does
- Provider connectivity
- Adapters normalise provider APIs, statuses and failure codes into one model.
- Routing
- Selects eligible providers per payment using your rules and provider capabilities.
- Retry and failover
- Cascades soft declines and technical failures to the next provider without double charges.
- Payment operations
- Transaction monitor, timeline, reconciliation, settlement visibility, analytics.
- Event delivery
- Signed webhooks with retries, logs and manual resend.
NATIO does not
- Hold funds
- Funds move between the merchant and licensed providers, which settle directly. The balances endpoint reports custodian: false.
- Touch card data
- Card entry happens on provider hosted pages or via provider tokenisation. NATIO stores token references only.
- Act as a bank or acquirer
- Processing, acquiring and settlement are performed by the licensed providers connected to the platform.
- Hide decisions
- Every routing, risk and retry decision is recorded on the payment timeline and in the audit log.
Seven method types, one request shape.
The payment_method field takes a type or a stored reference. Which providers can serve a given type, currency and country is configuration, not code.
Synchronous rails
Asynchronous rails
Test and live
Ready to connect once?
Create a sandbox account, run test scenarios against demo providers and see routing, failover and reconciliation end to end.