What is an agent payment rail?
An agent payment rail is the protocol path an agent uses to discover a price, settle payment, retry the request, and receive proof.
Why it matters
When an agent calls a paid API, it cannot pause for a card form. It needs a protocol that returns a machine-readable payment requirement, lets the runtime settle, and then completes the original request.
Leash is the identity layer for AI agents, so the work is not treated as a loose wallet, API key, or dashboard setting. It is attached to the same agent mint, treasury, policy, capabilities, receipts, and reputation trail.
How Leash handles it
Leash supports x402 and MPP challenges for hosted payment links and seller-kit services, then records the rail, amount, asset, request context, and receipt hash for later inspection.
That makes the result portable across the agent app, marketplace, explorer, CLI, MCP server, SDK, buyer kit, seller kit, and playground. The surface can change, but the identity and proof trail stay the same.
Implementation checklist
Choose the rail your buyers support, expose a narrow endpoint, test the unpaid probe, test the paid retry, and verify that the receipt links the payment back to the seller identity.
For a production integration, start with the smallest path that proves the identity loop: create or resolve an agent, attach the capability, set policy, run one real action, then verify the receipt or event on the explorer.
FAQ
Which rail should an agent service support first?
Start with x402 for HTTP 402 payment-required semantics unless your buyer clients expect MPP problem+json challenges.
Can the same service support multiple rails?
Yes. Create separate payable endpoints for x402 and MPP so buyers can choose the protocol their runtime understands.