Engineering evaluates a payment rail on whether it works. Finance evaluates it on whether the resulting entries can be explained to an auditor eighteen months later. Those are different tests, and machine payments passed the first for a year before anybody built for the second.
This guide is the second test. It assumes the protocol works and asks what has to sit around it.
Question 1: where does the limit live?
The only acceptable answer is: somewhere the agent cannot reach. A budget expressed in a system prompt is a budget that can be argued with, because anything reaching the model's context is a candidate instruction and the model has no reliable way to tell an instruction from data it was asked to process.
| Placement | Enforced by | Holds under attack? |
|---|---|---|
| System prompt | The model, statistically | No |
| Agent framework logic | Application code | Only if the agent cannot rewrite it |
| Funded wallet ceiling | The wallet | Yes — the funds are not there |
| Scoped card credential | The card network | Yes — the authorisation fails |
The bottom two rows share a property worth naming: the limit is enforced by something that never reads prose. That is the whole design principle, and everything else in agent spending controls follows from it.
Question 2: what does the record contain?
A transaction record is not enough. Three fields decide whether an entry can be explained later.
- Which agent made the payment — not which service account, which agent instance.
- On whose behalf it was acting, traceable to a person or a cost centre.
- What instruction caused it, so the entry can be tied back to a decision rather than to a timestamp.
The third is the one products get wrong. A log that records what the agent did without recording what it was asked to do produces an audit trail that answers «this happened» and cannot answer «why». For an unusual charge, the second question is the only one anybody asks.
Question 3: how does it reach the ledger?
Exporting a file is not integration. If reconciliation requires somebody to open a spreadsheet monthly, per-request payments will produce more manual work than they save — which is the arithmetic that kills adoption regardless of how elegant the protocol is.
What working deployments do instead is attach categories at the moment of payment, so entries arrive already classified. Ramp's alpha, opened in August 2026, does exactly this: customers fund USDC agent wallets, grant agents permission to spend on x402-gated resources, and see which agent paid, for what, with the transaction accounted for. It builds on the same company's Agent Cards, which issued tightly constrained corporate card credentials for the same purpose.
Question 4: what happens when the resource fails?
Every deployment we have examined handles the successful case and improvises otherwise. There is no established mechanism for one machine to dispute another, and no convention for what a refund looks like when the buyer is a program.
For a procurement function this is disqualifying on its own for anything material. A seller who cannot be held to delivery is a seller who does not get approved, and the absence of a dispute path is the honest reason machine payments will stay confined to small amounts for a while yet.
Question 5: who is accountable when it overspends?
This is the question that decides whether a pilot becomes a policy, and it is not technical. Somebody signs for the agent's spending the way somebody signs for a corporate card. Until an organisation has named that person, every control above is a technical measure with no owner.
The useful framing is the one already used for cards: an agent is a spender with a limit, an owner and a statement. Nothing about it being software changes who answers for the line item.
A checklist for evaluating a vendor
| Question | Weak | Strong |
|---|---|---|
| Where is the limit enforced? | In the agent's configuration | In the wallet or credential, before the agent is consulted |
| Can you show which instruction caused a charge? | We log all transactions | The instruction is in the record |
| How does this reach our ledger? | CSV export | Categorised entries, via an integration |
| What if the resource is not delivered? | Not addressed yet | A defined dispute path |
| Who owns an agent's spending? | The engineering team | A named owner with a limit, like a cardholder |
Why this changed in 2026 and not earlier
Because three parties concluded the same thing in the same week. Ramp opened the alpha above; AWS announced agent transactions through Bedrock AgentCore Payments; Stripe acquired OpenRouter. None of them was building a payment rail — all three were building the accounting around one that already existed.
That is the signal worth acting on. The interesting competition in machine payments is no longer about settlement, and a vendor still pitching you on the elegance of its protocol is answering a question your finance function did not ask.
Questions
- Can we just give an agent a corporate card and be done?
- That is close to what the working deployments do, with two additions. The credential is scoped tightly enough that exceeding it is not a decision the agent gets to make, and each charge carries the agent identity and the instruction behind it. A plain card gives you the payment without the attribution, and attribution is the part finance needs.
- Do we need a stablecoin for this?
- Not necessarily. Stablecoin settlement is used because it is currently the cheapest way to move small amounts between parties with no prior relationship, which is the defining condition of machine purchasing. Where the seller accepts cards and the amounts are not tiny, a scoped card credential answers the same requirement with fewer moving parts.
- What is the realistic first use case?
- Paid API access, metered data lookups and inference capacity sold per call — all three share the property that the buyer is a program, the amounts are small and no prior relationship exists. That last point is what conventional payment rails handle worst, and it is where per-request payment earns its place.
- How do we limit exposure while we are still learning?
- Fund the wallet rather than connecting a credit line, cap it at an amount you would accept losing entirely, and require the same monthly review you would give a new corporate card. The controls that matter are the ordinary ones; what is new is that the spender is software, not that the risk is exotic.