The big idea
Most payment infrastructure bundles coordination, liquidity, and rail access into one opaque system. When something breaks or costs too much, you have no leverage — you’re locked in. Atum separates these concerns into four distinct layers. Each layer has a clear owner and a clear responsibility. You integrate once at the top; everything below is Atum’s problem to coordinate.What Atum does
When you submit a payment request, Atum:- Authorizes — validates the request, checks credentials and policy
- Selects a quote — settlement providers submit competing price quotes to fulfill the request, and the Gateway selects one
- Orchestrates — coordinates multi-rail value transfer from source to destination
- Confirms — returns a settlement receipt with delivery proof from both rails
Who can initiate a payment
Atum accepts payment requests from any application layer:- Traditional apps — server-side services, payment backends, PSP integrations
- AI agents — autonomous workflows that call Atum
- Merchant endpoints — checkout flows and B2B invoice acceptance
Where Atum fits
Who owns what
What you can build
Multi-rail wallet apps
User sends USDT on one rail, recipient receives USDC on another.
Payout products
Tokenized currency payouts, remittances, or B2B transfers through your existing customer base.
Merchant acceptance
Accept any tokenized currency from buyers, regardless of which rail they’re on.
Treasury tooling
Move liquidity across rails with competitive pricing instead of routing through correspondent banks.
Agentic workflows
AI agents can pay with Atum and receive structured receipts without managing rail infrastructure.
What Atum is not
Atum is the coordination layer. By design, Atum does not:Next steps
How a payment works
End-to-end flow from request to settlement receipt
Try it (CLI)
Send a real payment on sandbox in minutes
Use cases
Treasury, payouts, merchant acceptance, and agentic workflows
Payment idempotency
Retry a payment safely, and what to do while one is still settling