Agent-Initiated Payment

also known as Autonomous Agent Settlement, Pay-Per-Call Agent, Agentic Commerce Payment, x402-style Payment

Give an agent a bounded wallet so it can settle a payment mid-request to unlock a resource — answering a payment-required challenge with a verifiable proof — instead of routing every purchase through a human.

Context

A team is running an agent that needs paid resources at runtime: a premium data feed, a metered API, compute or model inference, or a service offered by another agent. These resources increasingly expose a machine-payable endpoint — for example an HTTP 402 'Payment Required' response — that returns the data the moment a valid payment proof arrives. The team has to decide how the agent obtains and spends money for these calls without a person approving each one.

Problem

Pre-provisioning every possible paid resource with an account, an API key, and a billing relationship does not scale to an agent that discovers what it needs as it runs, and it leaves spend untracked across dozens of providers. Putting a human in the loop for each purchase defeats the point of an autonomous run and stalls on sub-second resource calls. But handing an agent an open-ended payment instrument invites runaway spend, fraud, and purchases no one can later reconstruct or attribute.

Forces

Autonomous runs cannot pause for human approval on every paid resource call.
An open-ended payment instrument invites runaway spend and fraud.
Machine-payable endpoints settle in well under a second; account-and-invoice billing cannot keep that pace.
Every payment must be reconstructable and attributable after the fact for audit and dispute.
Resources are discovered at runtime, so pre-provisioning an account per provider does not scale.

Example

A research agent hits a premium market-data API that responds 402 Payment Required with a price of a few cents. Instead of stopping to ask its operator, the agent — holding a wallet capped at five dollars for the run — signs a stablecoin micro-payment, attaches the proof, and retries; the API returns the data in under a second. The settlement is logged with the run id so the operator can later see exactly what was bought and why.

Diagram

sequenceDiagram participant Agent participant W as Capped Wallet participant R as Paid Resource participant L as Ledger Agent->>R: request resource R-->>Agent: 402 Payment Required (price) Agent->>W: check caps + sign payment W-->>Agent: payment proof Agent->>R: retry with proof R-->>Agent: resource unlocked Agent->>L: record settlement (amount, counterparty, run id)

Solution

Therefore:

Provision the agent with a constrained wallet: a balance or credit line, a per-transaction ceiling, a total budget per run, and an allow-list of payable counterparties or resource classes. When a resource returns a payment-required challenge, the agent constructs a payment (for example a signed stablecoin transfer referenced in a payment header) and retries; the resource verifies the proof and releases the data. Each settlement is recorded to a ledger with the amount, counterparty, run id, and the action that triggered it, so spend is observable and attributable. Spend caps and the counterparty allow-list are enforced outside the model, so a compromised or confused agent cannot exceed them.

What this pattern forbids. The agent cannot spend beyond its enforced per-transaction and per-run caps, cannot pay counterparties outside its allow-list, and may not settle a payment that is not recorded to the ledger.

The smaller patterns that complete this one —

generalisesSession-Scoped Payment Authorization·— Bound an agent's autonomous spending by having it open a payment session with a pre-approved cap, stream many micropayments inside that session, and settle once on close, instead of seeking approval for every transaction.

And the patterns that stand alongside it, or against it —

complementsCost Gating★★— Block actions whose expected cost exceeds a threshold without explicit user (or operator) acknowledgement.
complementsInter-Agent Communication★— Define a protocol for agents to exchange tasks, capabilities, and results across process or vendor boundaries.
complementsVerifiable Purchase Mandate★— Anchor agent-initiated payments in a cryptographically signed mandate that captures the user's authorization and travels with the transaction, so a merchant or payment network can independently verify the agent acted on genuine user intent.