Agent-to-business commerce has a bootstrapping problem: cards assume a human at a checkout page. Three rails have emerged to solve it, and Forward implements all three, so it's a useful concrete case study.
1. Prepaid credits — the default
The simplest rail and the right default. The account holds a dollar balance; each verified result deducts its exact price; reversals refund the balance. No token exchange at purchase time, trivially auditable, and it composes with free-tier onboarding: every new Forward account starts with $25 of credits, so an agent's first purchase needs no payment step at all — {"payment":{"rail":"credits"}} and done.
2. x402 — pay-per-call over HTTP
x402 revives HTTP status 402 (Payment Required) as a protocol: the server answers a request with a 402 challenge that includes the amount, asset (typically USDC), and pay-to address; the agent settles on-chain and retries the call with an X-PAYMENT header carrying the proof; the server verifies with a facilitator and proceeds. It's the right rail for agents with wallets and no standing relationship — top up credits or fund a checkout in one settle, no account dance.
3. Stripe ACP — delegated human authority
The Agentic Commerce Protocol pattern: a human authorizes a scoped payment token; the agent presents it at checkout; the merchant confirms and captures per charge, bounded by a max_charge_usd the human set. This is the rail for "my agent buys on my company card, within limits" — auditability and delegation without sharing card numbers.
What matters more than the rail
Whatever the rail, agents should demand the same billing invariants: a hard cap enforced server-side, itemized charges tied to identifiable results, idempotency (the same result can never bill twice), and reversibility when the deliverable fails later checks. Forward enforces all four on every rail — the rail moves money; the invariants are what make autonomous spending safe. The full flow is documented for agents in llms.txt and runnable over MCP.