Developer Preview · In Development
Agent Payment Rails
Agent Payment Rails is an in-development reference architecture for how autonomous agents can evaluate and use payment and settlement paths. It is a route planning and interoperability surface, not a claim that every rail listed here is production supported by Autheo today.
Why agent payment rails matter
An autonomous agent that wants to pay for a product, an API call, a subscription, or a settlement transfer faces a fragmented landscape. Mandates, checkout protocols, HTTP payments, card network agent programs, stablecoin transfers, and chain settlement each address a different job. None of them are interchangeable. A developer cannot assume that one protocol covers identity, authorization, intent, execution, and settlement at once.
Agent Payment Rails is designed so that a developer can describe an intent, supply a Know Your Agent mandate, and receive a recommended rail across these families instead of stitching them together by hand. The planner is the same shape as the Protocol Router; the rail view is the settlement and payment focused projection of that model.
What the rail planner evaluates
The rail planner takes the same inputs as the Protocol Router and produces a payment and settlement focused route. Inputs include the intent, the agent and controller KYA credentials, a mandate credential, the merchant target and merchant manifest, policy constraints from the controller, and soft preferences such as settlement currency, latency tolerance, cost ceiling, and privacy posture.
- Intent. Examples include buyProduct, buyApiAccess, subscribe, payForResource, and transferValue.
- Identity. Agent credential, controller credential, and mandate credential references resolved through KYA.
- Merchant. Merchant identifier, manifest URL, supported rails, and declared trust metadata.
- Policy. Spend limits, jurisdiction, allowed rails, time windows, and disallowed counterparties from the controller policy.
- Preferences. Preferred settlement family, latency tolerance, cost ceiling, privacy posture, and reputation thresholds.
The output is a recommended rail, ranked alternatives, ruled out rails with reasons, the credentials and proofs the rail requires at execution time, the policy checks that were performed, optional warnings, an expiry, and a stable plan id for telemetry.
Rail categories at a high level
| Rail family | What the planner does with it |
|---|---|
| AP2 style mandates | Payment mandates that authorize a class of payments for an agent within a defined scope. The route planner treats a mandate as the authorization input for any downstream rail. |
| ACP and UCP checkout and cart flows | Agentic checkout sessions and universal cart flows that connect an agent intent to a merchant program. The router selects ACP or UCP as the interface layer when a checkout style flow is preferred. |
| x402 and HTTP native payments | HTTP native payment required responses that allow paid resource access and machine to machine settlement at request time. |
| Card network and tokenized payment rails | Agent initiated card payments through merchant of record adapters, tokenized credentials, and issuer programs from networks running agent commerce pilots. |
| Stablecoin and chain settlement | Programmable transfers between agent controlled wallets and merchants, including chain native settlement on chains compatible with the Autheo stack and post quantum aware paths over time. |
| THEO utility token and Autheo ecosystem fee contexts | Where consistent with current Autheo product surfaces, THEO is the utility token used for network access, compute, storage, AI inference, and identity related fees. THEO is not a governance token. |
How KYA and mandates fit
Every rail in this reference architecture is designed to bind to a Know Your Agent mandate before value moves. The mandate is the authorization input. A rail does not accept an instruction from an agent in isolation; it accepts an instruction together with a verifiable mandate that names the controller, the agent, the scope of the authority, the limits, and the expiry.
- Agent credential proves the identity of the autonomous agent.
- Controller credential proves the identity of the user, enterprise, or organization that owns the agent.
- Mandate credential expresses the delegated authority, including scope, spend limits, jurisdiction, and expiry.
- Merchant credential carries identity and trust metadata for the merchant receiving the payment.
The rail planner is designed to verify each credential at plan time and reject a rail that would violate a mandate constraint. Mandate verification is the boundary between the route planning surface and any execution surface, including AP2 mandates, ACP and UCP checkout sessions, x402 payment required responses, and chain transfers.
Settlement and audit trail considerations
Settlement decisions are persisted so they can be reconstructed after the fact. The rail planner records the chosen rail family, the adapter, the mandate proof reference, the policy checks that ran, and the ranking rationale. This record is what Agent Mission Compliance Reporting consumes when it reconstructs a mission across identity, mandate, route, merchant, settlement, timestamps, signatures, and proof artifacts.
Persistence happens at the compute and storage layer of the stack. The audit trail is designed to support a procurement audit, a merchant dispute response, a settlement reconciliation across stablecoin, card networks, x402, and chain rails, a regulator or internal compliance review, and a developer debugging session.
Where this sits in the seven layer stack
Agent Payment Rails is the settlement and clearing focused projection of the agentic commerce stack and reaches across the layers because a single mission can touch identity, checkout, settlement, and protocol routing in one motion.
- L7 Trust and Identity. Agent, controller, merchant, and mandate credentials are resolved and verified at plan time.
- L4 Checkout Execution. Cart, checkout sessions, delegated authentication, payment handoff, returns, and order events across ACP, UCP, and AP2 style mandate flows.
- L3 Settlement and Clearing. Settlement route planning across stablecoin, card networks, x402 HTTP payments, and chain rails. Mandate verification links a KYA mandate to a settlement intent.
- L1 OS and Protocol Abstraction. Cross protocol routing, route planning APIs, and adapter interfaces sit here. The rail planner is the payment focused projection of the Protocol Router.
How this maps to the five gaps
- Commerce OS. A neutral foundation that ties identity, route selection, and settlement into one developer facing model. Agent Payment Rails is the settlement facing surface of that model.
- KYA (Know Your Agent). The credential model that every rail decision binds to. No rail is authorized without a verifiable mandate.
- Protocol Router. The rail planner shares the planning model and the adapter interface with the Protocol Router. The rail view is a settlement focused projection of the same architecture.
- Post-Quantum Security. Mandates, merchant credentials, and settlement authorizations may persist for months or years. The reference architecture is designed with a roadmap backed path toward post quantum cryptographic agility.
How this relates to Protocol Router
Agent Payment Rails is the payment and settlement focused projection of the Protocol Router. The Protocol Router is the broader route planner across MCP, A2A, ACP, UCP, AP2, x402, card networks, and chain settlement. Agent Payment Rails reuses the same inputs, the same decision model, and the same adapter interface, and concentrates on the rail selection question.
A developer building checkout, settlement, or paid API access can read this page for the rail focused view, and read the Protocol Router documentation for the full route planning model including non payment protocols such as MCP and A2A.
Related docs
Protocol Router
Broader route planning model that the rail planner projects from.
KYA (Know Your Agent)
Credentials and mandates the rail planner verifies before authorizing value movement.
Merchant Agent Readiness
How a merchant declares the rails and policies it supports.
Agent Mission Compliance Reporting
Reconstructs the rail decision, mandate, and settlement after the fact.
The Agentic Commerce Stack
Where rail planning fits inside the seven layer stack and the five gaps.
Grants and prototype bounties
Rail adapters, mandate verifiers, and audit tooling are eligible grant tracks through Autheo Foundation.