PAID is the payment intelligence and orchestration platform for the agentic economy. This page explains what orchestration means concretely — what the router does, what it refuses to do, and where its limits are today.
A payment processor gives you one set of rails: its cards, its payouts, its rules. A payment orchestrator sits one level above — you bring payment service providers and rails, and the orchestrator decides, per payment, which one executes. The practical difference: with a processor, changing rails means re-integrating; with an orchestrator, it means changing configuration. Your integration stays the same.
Every payment intent passes through a deterministic five-stage router before anything executes:
The router performs no retries, spawns no background work, and does no cost arithmetic outside stage five — every decision is synchronous, inspectable, and reproducible. The full stage-by-stage detail is on intelligent routing.
Cards, ACH debit, and USDC run on the same checkout through one API. Which providers are live for each rail — and exactly what "live" means — is documented honestly on integrations and multi-PSP: today cards execute through one live card acquirer, USDC disbursement is a real on-chain send, and ACH payouts are built but awaiting credentials. We publish that status rather than implying a larger network than exists.
Every financial event the orchestrator produces is written to a cryptographically hash-chained ledger — each event signed and chained to the previous one, verifiable offline. Routing decisions are not a black box that ends in a settlement number; they are a chain of events an auditor can replay. See architecture and the hash-chained ledger docs.