When Agents Buy APIs, Data and Compute: How Machine-to-Machine Payments Differ From Consumer Agentic Checkout
Most of the conversation about agentic commerce and payments is still about shopping: a consumer asks an assistant to find a product and, perhaps, buy it. A different kind of payment is arriving at the same time, and it is easy to mistake for the first. An agent that pays for an API call, a dataset or a block of compute is not a shopper. It is a piece of software buying an input to its own work. Our position is that platform teams should treat the two as separate design problems, because the questions that matter (who has authority, what the limits are, and what record exists afterwards) have different answers in each.
This is a commentary, not a market survey. The evidence behind it is thin and mostly vendor-led, and we say where that matters.
Two problems that look like one
From a distance, both cases involve an AI agent, a payment and a counterparty. Up close they diverge.
In consumer agentic checkout, a person delegates a purchase. The person has a card or an account, a view about what they want and a right to dispute what they did not agree to. The merchant has to decide whether to trust an agent it has never met. Much of the current debate is about this authorisation and liability question, and the reporting we hold describes it as the dominant agentic-commerce theme for the third consecutive review period.
In machine-to-machine payments, there may be no person at the moment of purchase. A software agent working through a task discovers that it needs a service, such as a data feed, a model endpoint or compute capacity, and pays for it. The counterparty is usually another piece of software: a service that wants to be paid per request, not an online shop with a basket and a returns policy. The "customer" is a budget and a policy set by a human or a team earlier, not a person at a screen.
That difference is the whole argument. Consumer checkout is a delegation problem. Machine payments are a metering and policy problem. The same word, "agent", hides it.
What is shipping and what is only announced
It helps to separate three states: shipping, piloting and announced. The evidence for this article supports only a few firm statements.
Early access, not general availability. Mastercard has opened Early Access to what it calls Agent Pay for Machines. As reported, it comes with buyer-side and seller-side APIs and a sandbox. That is a developer-facing product and explicitly about machines paying for services, not only consumer shopping. Early access with a sandbox is a test environment for builders. It tells you the card network is investing in the category. It does not tell you how many machine payments are flowing, and we have seen no volume figures.
A live pilot in accounts payable. Visa, BILL and Billtrust have run a live pilot of AI agents paying business-to-business invoices through Visa Intelligent Commerce. Visa describes it as a first; that is Visa's own claim, and we have not verified it. The pilot is useful for a different reason: it sits where approvals, supplier records and audit trails already exist. That is closer to a machine paying than to a consumer checking out, although it is invoice payment between businesses rather than an agent buying API calls. We would call it adjacent evidence, not proof that machine-to-machine payments for APIs are in production.
Announcements on stablecoin and onchain rails. Reporting describes machine-to-machine agent payments developing on stablecoin and onchain rails, naming Tether and AIsa, Circle's CPN Managed Payments, and x402. We rate this as medium confidence. Separately, the reporting on Mastercard's early-access product notes that stablecoin infrastructure firms appeared in the demonstration. It is tempting to conclude that stablecoin settlement is part of Mastercard's design. That is an inference; Mastercard has not said so, and we would not repeat it as fact.
Standards that keep multiplying. The same period's reporting lists a growing set of approaches, including Mastercard's Agent Pay for Machines, American Express's Intent Intelligence framework, Proof's x401 and x402. Each sponsor is pushing its own approach and none is displacing the others. For a platform team, the practical reading is caution: a commitment to one scheme today may mean rework later.
Put plainly, the summary is this. One card network has opened a developer sandbox. One live pilot exists in a back-office invoice flow. Several stablecoin-based efforts are in motion. We have not seen evidence of material machine-to-machine payment volume.
Five differences that change the design
What follows is our analysis, not reported fact. It is a way to test whether a machine-payment use case really needs a different design from consumer checkout.
1. Who holds the authority
In consumer checkout, authority comes from a person at the point of delegation: "buy me this, up to this price". In a machine payment, authority comes from a policy written in advance: which services the agent may buy, from whom, up to what amount, for which task. The person is upstream and absent. That moves the weight onto the policy: how it is expressed, who can change it and how it is enforced when the agent is mid-task.
2. How big and how frequent the payments are
A consumer basket is occasional and sizeable. A machine buying API access could be many small payments, one per request or per block of usage. We would not state a typical size or frequency, because the evidence does not give one. The design consequence is still clear: a rail that works well for a handful of consented purchases a week may not suit a high-frequency pattern, and costs that are invisible on a basket become material on a very small payment.
3. What counts as proof
For a consumer, proof is a confirmation the person saw. For a machine, proof is a record linking the payment to the task, the policy and the agent that was acting. The agent identity market is forming quickly. The same October review recorded a cluster of tooling for agent identity and delegated authority appearing within a week, with no standard emerging. For a machine payment, that identity question is not a nice-to-have. A seller deciding whether to serve a request needs to know which agent is calling and under whose authority.
4. What a dispute looks like
A consumer can say they did not order it. A machine-to-machine dispute is closer to a service dispute: the call was made, the response was poor or the price was not the one quoted. That argues for a different evidence trail, closer to usage logs and quotes than to a card-not-present chargeback. The right answer depends on the rail and on contract terms, and we would not generalise from the current evidence.
5. Who the counterparty is
A consumer agent faces merchants who already have checkout, fraud tools and a returns process. A machine agent faces services that may have no such processes and may only want to be paid and to serve the response. That is partly why developer-facing interfaces, sandboxes and per-request pricing show up in this category. It is also why stablecoin and onchain rails are being tried: they suit software counterparties that have no merchant account.
Why authorisation and liability still matter
It would be a mistake to read the machine-payment story as "no humans, no liability". The reverse is more likely. When a person is removed from the moment of purchase, the question of who is responsible becomes more important, not less.
The reporting we hold on consumer checkout shows how much attention this attracts: a large US bank has reportedly blocked outside agents from direct access to customer accounts and backed open-banking routes instead, and the FCA has published AI good and poor practice while, as the reporting puts it, applying existing frameworks such as the Consumer Duty and senior-manager accountability to AI rather than writing new agent-specific rules. We would read that as a signal for machine payments too. If a UK business lets an agent spend, a named person or function remains accountable for the policy that allowed it. Whether a particular machine payment falls inside a regulated payment service depends on how it is structured, and that is a question for legal and compliance advice rather than a blog post.
Where the first use cases are likely to be
Two themes in the evidence point to where machine payments become practical first.
The first is finance operations. Reporting this period describes accounts payable and finance operations as the first beachhead for delegated payments, because approvals, supplier relationships and audit already exist and are easier to authorise and insure than open-web consumer purchases. The BILL pilot fits that pattern. It is a medium-confidence synthesis, not a measured trend.
The second is internal platform spend. A team running agents that need data, model access or compute has a natural, bounded problem: how do you let the agents buy what they need without opening an unlimited tab? That is a policy and limits question first and a rail question second. It is also a safe place to experiment, because the counterparties and the budget are under your control.
Neither of these requires you to pick a winner among the competing standards on day one. That is the point of the next section.
What a platform team should prototype first
If the question on your desk is "do we need something different for agents buying services?", we would prototype in this order, using a sandbox and a fixed budget, and without committing production money.
Write the spending policy before choosing the rail. List which services an agent may buy, the maximum per task and per day, who approves exceptions and who is notified when a limit is hit. If you cannot write this in plain language, no payment rail will rescue it.
Separate identity from payment. Decide how the seller will know which agent is calling and under whose authority. Keep that layer swappable. With competing identity approaches in the market, a design that hard-wires one is a design that may need rebuilding.
Log for a dispute you have not had yet. For each payment, record the task, the policy version, the agent, the quote and the response. It costs little to capture now and a great deal to reconstruct later.
Use the sandbox the networks are offering. Where a card network has opened early access with a sandbox, it is a low-risk way to learn what the interfaces look like. Treat anything you learn as provisional, because the product is still in early access.
Keep the rail abstract. Given that standards are multiplying, build a thin layer between your agent and whichever rail it uses. The aim is that changing the rail does not mean changing the policy, the identity layer or the logs.
Set a stop rule. Decide in advance what result would make you stop: for example, no seller that supports the rail, or a cost per payment that is out of proportion to the value of what is bought. A prototype with a stop rule is a decision tool; one without it becomes a project.
What we do not know
We would rather be clear about the limits of the evidence than let the argument sound firmer than it is.
We do not have volume data for machine-to-machine payments. We do not have evidence of how UK businesses are using them; the reporting is global and vendor-led, with no UK-specific framing. The stablecoin angle rests on medium-confidence reporting and, for Mastercard, an inference that Mastercard itself has not confirmed. The "first" in the Visa pilot is Visa's claim. And a standards landscape that is still fragmenting means any specific recommendation on a rail would date quickly.
What we can say with more confidence is the structural point. Paying for a service as a machine and buying a product as a consumer are different problems, and a team that designs one while believing it is designing the other will end up with the wrong controls.
Where Innovify fits
Innovify is a technology partner with deep expertise in banking, financial services, fintech and insurance. We help mid to large businesses build AI-native products, modernise their technology stack and launch fintech products, and we design compliance in from day one.
For teams working through this question, the useful starting point is usually a bounded prototype rather than a platform decision. Our Agentic Commerce & Payments work covers how delegated payments are authorised, limited and recorded, and Innovify AI Labs lets enterprise teams run several proofs of concept in parallel, test with real users and finish with a business case ready for funding. If you want to test a machine-payment use case against a written policy and a fixed budget before committing, talk to us about what a first prototype would look like.
FAQ
What are machine-to-machine payments for AI agents?
Machine-to-machine payments for AI agents are payments made by one piece of software to another, without a person completing the purchase. A typical example is an agent paying for an API call, a data set or compute capacity it needs to finish a task. The authority for the payment comes from a policy set in advance, not from a person at a checkout.
How do machine-to-machine payments differ from consumer agentic checkout?
In consumer agentic checkout, a person delegates a purchase and can dispute it. In machine-to-machine payments, the buyer is software acting under a pre-set policy and the counterparty is usually a service. The design focus shifts from consent and delegation to limits, identity and records of usage.
What is Agent Pay for Machines?
Agent Pay for Machines is a Mastercard product, reported as opened to Early Access with buyer-side and seller-side APIs and a sandbox. It is aimed at machines paying for services, not only consumer shopping. Early access is a developer test stage, and we have not seen volume or general-availability dates.
Do machine-to-machine payments use stablecoins?
Some do, but the evidence is partial. Reporting describes machine-to-machine agent payments developing on stablecoin and onchain rails, including through x402, and the reporting on Mastercard's early-access product notes stablecoin firms in the demonstration. Whether stablecoin settlement is part of Mastercard's design is an inference, not something Mastercard has stated.
Are machine-to-machine payments live in production?
There is limited public evidence of production use at scale. Visa, BILL and Billtrust have run a live pilot of agents paying business invoices, which Visa describes as a first. That is a pilot in accounts payable, not proof of agents buying APIs in production.
What should a UK platform team prototype first?
Start with a written spending policy for a bounded internal use case, then add agent identity and logging, and test against a sandbox with a fixed budget. Keep the payment rail swappable, because standards are still multiplying. Take legal and compliance advice on how any payment is structured before moving beyond a prototype.
Conclusion
Agents buying APIs, data and compute are not shoppers. They are software buying inputs, under a policy a human wrote earlier. That makes machine payments a problem of limits, identity and records, where consumer checkout is a problem of consent and delegation. The evidence today shows a developer sandbox, a back-office pilot and several stablecoin-based efforts, but no proof of scale. The sensible response is a small, bounded prototype with the rail kept swappable and a stop rule agreed in advance.
