Payment orchestration infrastructure

Payments.
Orchestrated.

Connect once. Route payments across providers, countries and payment methods through one infrastructure layer — with failover, reconciliation and a decision trail for every transaction.

1
REST API, one contract
7
Payment method types
0
Merchant funds held
100%
Decisions recorded
How it works

One infrastructure layer between your platform and the payment providers.

Your systems talk to NATIO. NATIO talks to acquirers, banks, PSPs and local payment methods, decides where each payment goes, retries safely when a provider fails, and reports what happened.

Merchant
Your checkout, platform or backend. One integration, one contract, one set of credentials.
POST /v1/payments
NATIO · technology infrastructure layer
Universal Payment API
REST API: payments, refunds, payouts, transactions, settlements, webhooks.
  • Idempotency-Key
  • natio_sk_test_ / natio_sk_live_
  • Natio-Signature webhooks
Orchestration Engine
Deterministic, auditable decisions for every payment.
RoutingRiskRetry / Failover
timeline · double-charge protection
Payment providers
Licensed institutions connected to the platform.
  • Acquirers
  • Banks
  • PSPs
  • Local payment methods
Settlement
Performed directly by the licensed providers to the merchant. NATIO holds no customer funds.
custodian: false
Card data never touches NATIO. Hosted pages and tokenisation are handled by PCI-compliant providers; NATIO stores token references only.
Funds move between you and licensed providers. NATIO orchestrates the request and reads back settlement data; it does not hold or take customer funds.
Every decision is recorded. Risk, routing, provider attempts, failover and webhooks are written to a per-payment timeline.
One integration

Create a payment. NATIO does the rest.

A single request carries amount, currency and payment method. Risk evaluation, routing, provider calls and failover happen inside the request; the response tells you the outcome and the route taken.

01

Amounts in minor units

Integers only: 10000 is 100.00 USD. No floating point, no ambiguity across currencies.
02

Payment method as a type or a token

Send "card", or a stored payment method reference issued by a PCI-compliant provider. NATIO never receives card numbers.
03

Route object on every payment

Which provider processed the payment, how many attempts it took and which routing rule matched.
04

next_action for asynchronous rails

Redirects and QR codes are returned as a structured next_action; completion arrives by webhook.
Request
curl https://api.natio.me/v1/payments \
  -H "Authorization: Bearer natio_sk_test_..." \
  -H "Idempotency-Key: order-1001" \
  -H "Content-Type: application/json" \
  -d '{
    "amount": 10000,
    "currency": "USD",
    "payment_method": "card",
    "country": "US",
    "reference": "ORD-1001"
  }'
Response · 201 Created
{
  "id": "pay_7Kq2mN9xR4vL8wP1tY3z",
  "object": "payment",
  "status": "successful",
  "amount": 10000,
  "currency": "USD",
  "route": {
    "provider": { "code": "demo_acquirer_b", "name": "NATIO Demo Acquirer B" },
    "attempts": 2,
    "rule": "Cards → Acquirer A, fallback Acquirer B"
  },
  "next_action": null
}
Orchestration

Rules decide. Failover protects. The timeline explains.

The orchestration engine turns provider connectivity into a policy you control: where a payment goes, what happens when a provider declines or fails, and a complete record of every decision.

01

Routing rules

Conditions on country, currency, payment method, amount, risk score, transaction type and time select the eligible providers. Strategies: ordered, weighted or score-based.
02

Retry and failover

Soft declines and technical failures cascade to the next eligible provider. Hard declines stop. Timeouts are verified against the provider before any retry, so a customer is never charged twice.
03

Transaction timeline

Every payment carries an ordered narrative: risk evaluated, rule matched, provider selected, request sent, error, fallback, success, webhook queued.
Operations

Built for the teams who run payments every day.

Engineering integrates once. Finance and operations get a single place to monitor transactions, reconcile provider reports, follow settlements and compare providers.

01

Transaction monitor

Payments, refunds and payouts across all providers with status, route, attempts, fees and failure codes. Filter by provider, method, country, currency or reference.
02

Reconciliation

Import provider reports and match them against NATIO records: MATCHED, MISSING_PROVIDER, MISSING_NATIO, AMOUNT_MISMATCH, STATUS_MISMATCH.
03

Settlement visibility

Settlement batches reported by providers, with gross, fees, net and the transactions they cover. Funds are settled by the providers, not by NATIO.
04

Analytics

Volume, approval rate, latency and failure breakdowns per provider, method and country to inform routing decisions.
Built as infrastructure

Designed like the systems it connects to.

NATIO is a technology layer between merchants and licensed payment providers. It is engineered to be predictable, verifiable and narrow in scope.

Encryption at rest and in transit

Provider credentials and webhook secrets are encrypted with AES-256-GCM; all traffic is TLS.

Key hashing

API keys are stored as SHA-256 hashes and shown once. Prefixes identify keys without exposing them.

Role-based access control

Merchant users and operators act under explicit permissions; every action is attributable.

Audit logs

Configuration changes, manual reviews, refunds and resends are written to an immutable audit trail.

Signed webhooks

Every event carries a Natio-Signature header (HMAC-SHA256 with timestamp) so you can verify origin and freshness.

PCI scope minimisation

Card data never touches NATIO. Hosted pages and tokenisation are performed by PCI-compliant providers.

Idempotency

Idempotency-Key on every mutating request: retries replay the original response instead of creating duplicates.

No custody

NATIO does not hold or take customer funds. Providers settle directly with the merchant.

Who it is for

For teams operating across markets.

If your business accepts or sends payments in more than one country, through more than one provider, or via more than one payment method, orchestration replaces a growing set of integrations with one.

Fintech companies

Embed payments and payouts behind your own product without maintaining a provider integration per market.

Marketplaces & platforms

Collect from buyers across rails and pay out to sellers through licensed providers, with one ledger view.

E-commerce

Cards, wallets, bank transfers and local methods under one checkout contract, with automatic failover.

Subscription businesses

Stored payment method references, manual capture and retry logic for recurring charges.

Travel

High-value, multi-currency transactions where routing by amount, currency and provider limits matters.

Digital services

Fast integration, deterministic routing and full visibility of every attempt for support teams.

International merchants

Add countries and payment methods by configuration rather than by new integrations.

cardbank_transferqropen_bankingwalletinstantlocal

Supported payment method types. The architecture is prepared for connecting global and local providers behind each of them.

Ready to connect once?

Create a sandbox account, run test scenarios against demo providers and see routing, failover and reconciliation end to end.