Payment orchestration

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.

What is payment orchestration?

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.

How PAID orchestrates

Every payment intent passes through a deterministic five-stage router before anything executes:

1. Context assembly — the intent is joined with merchant configuration and connected-rail state.
2. Jurisdiction resolution — where the payment legally sits, resolved before any candidate is considered.
3. Candidate filtering — rails that cannot execute this payment are removed.
4. Ruleset hook — an optional merchant policy layer that may narrow candidates or refuse the intent outright.
5. Cost evaluation — the surviving candidates are priced and one execution plan is selected.

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.

What executes underneath

Today one rail runs underneath: card payments through Stripe, charged on the merchant's own Stripe account. No other rail is offered — not ACH, not USDC. Which providers exist and exactly what "live" means is documented honestly on integrations and multi-PSP. We publish that status rather than implying a larger network than exists.

The audit trail underneath every decision

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.

What PAID's orchestration will never do

• Never hide a failure — failed payments are first-class, disclosed events. See failover & multi-rail resilience.
• Never fabricate a counterfactual — PAID does not claim "this decline would have succeeded elsewhere"; no such data exists.
• Never use heuristics where determinism is possible — same inputs, same routing decision, every time.

Explore the capability graph

• Intelligent routing — the five-stage decision pipeline
• Multi-PSP — what it takes for a provider to be genuinely live
• Failover & multi-rail resilience — structural fallback, honestly framed
• Architecture — intent to settlement, event by event
• Agentic commerce — payments for AI agents
• Integrations — live provider status
• Developer docs · B2B billing