Skip to main content
Dutch Ministry of Justice pilots mintBlue for fraud signal exchangeRead the story
TECH POLICY

Agentic Commerce: What It Is, and the Layer Nobody Has Built Yet

Agentic commerce explained: how AI agents pay via x402, AP2 and card networks, and the identity, mandate and audit-trail layer the race skipped.

NvdB

Niels van den Bergh

CEO

July 16, 2026

Agentic Commerce: What It Is, and the Layer Nobody Has Built Yet

Introduction

Software is starting to buy.

Not recommend, not compare options and hand a shortlist to a purchasing manager. Buy: discover a supplier, select the best option, place the order, settle the invoice, and move to the next task with no human clicking approve. The rails for that arrived fast, from several directions at once, across 2025, and consolidated in 2026.

The question underneath is harder: how do you keep a grip on transactions that sit further and further from any human hand?

What is agentic commerce?

Agentic commerce is commerce where an autonomous software agent, acting on behalf of a person or organisation, initiates and completes a transaction from end to end. The agent discovers the option, selects or negotiates it, and pays, with no human at the checkout.

That last part is the defining move.

A chatbot that recommends a supplier is not agentic commerce. A comparison engine that ranks options and hands a shortlist to a buyer is not agentic commerce. Both stop at the moment of decision and return control to a human. Agentic commerce means the agent crosses the payment line itself: selects, commits, settles. The human's role shifts from deciding each transaction to setting the parameters inside which an agent decides all of them.

The distinction matters legally before it matters commercially. When a human clicks a purchase button, they accept the terms, take responsibility for the choice, and create an implicit record of intent. When an agent crosses that line, the questions of who is responsible and what evidence exists of what was intended are open from the start. Those questions do not disappear because the payment was successful. They surface when something goes wrong.

How does agentic commerce work?

Between April and October 2025, three distinct layers of agent payment infrastructure arrived near-simultaneously. They were built by different organisations, from different starting points, and they are not mutually exclusive. A real transaction can touch all three.

The open-protocol layer: x402

The HTTP specification has carried status code 402, "Payment Required", since the early days of the web. It was reserved for future use and never formally deployed. Coinbase revived it. The x402 protocol lets one machine pay another directly over web protocols, with no accounts, no sessions, and no human intermediary. A service returns HTTP 402 when it requires payment; the requesting agent pays immediately in the same protocol layer; settlement is irreversible and the parties move on.

On 2 April 2026, x402 was formalised under the Linux Foundation as the x402 Foundation, with a launch roster that included Adyen, American Express, AWS, Fiserv, Google, Mastercard, Microsoft, Shopify, Stripe, and Visa. The breadth matters: this is not a niche protocol backed by a single player. It is effectively the web's payment primitive for machines, built on a dormant specification that was waiting decades for a use case.

The mandate layer: AP2

Google announced the Agent Payments Protocol on 16 September 2025. AP2 structures every purchase as three signed mandates. The Intent Mandate captures what the user wants and is signed by the user; the agent cannot exceed its scope. The Cart Mandate captures what the agent assembled from that intent. The Payment Mandate authorises the amount, names the funding instrument, and carries a cryptographic hash tying it back to both the intent and the cart.

The word "mandate" is doing real work here. Each mandate is signed. Each is bound to the one above it. The chain traces every purchase back to what the user actually instructed. AP2 is notable precisely because it was designed with auditability as a first-order requirement, not an afterthought.

The card-network layer

Mastercard announced Agent Pay on 29 April 2025. It issues Agentic Tokens: tokenised card credentials bound to a specific agent, a specific merchant scope, and a specific consent policy. The agent completes checkout without ever holding the raw card number. The token is scoped to what was authorised; structural limits prevent the agent from exceeding them.

Visa followed with its Trusted Agent Protocol, announced September 2025, which issues a Verified Agent ID alongside a consent record signed by the consumer's issuing bank. The agent carries a verifiable identity when it transacts, and the issuer holds a record of what was consented to at the time consent was given.

These three layers stack. A real procurement flow might carry a Mastercard Agentic Token as the funding instrument, route settlement through an x402-enabled API endpoint, and operate inside an AP2 Intent Mandate that caps spend to an approved band. Each layer does a different job; each makes the overall transaction more traceable.

The payment problem is being solved from several directions at once. That speed is the point, and also the reason the layer beneath it deserves more attention than it is getting.

What changes when agents transact?

Three things shift when agents replace humans at the checkout, and only one of them is the obvious one.

Speed is obvious. Machine-to-machine settlement removes every human latency: no session, no approval queue, no inbox waiting for sign-off. A procurement decision that once took a purchasing manager three days can complete in milliseconds. For high-frequency, low-value purchases, this is simply more efficient.

Volume follows from speed. Agents run continuously. A single agent managing procurement for a mid-size enterprise might initiate thousands of micro-transactions across dozens of suppliers in a week, paying per call for data, per unit for stock, per query for compute. The transaction layer becomes a background process, invisible and constant.

The third shift is accountability, and unlike the first two it is easy to miss.

The click that used to sit between intent and payment was never only friction. It was the moment when a human being took responsibility. A person reviewed the cart, accepted the price, and pressed the button. That act created an implicit record: a human chose this, consciously, at this moment. Remove the click, and the question of who owns the decision has no default answer.

Nobody designed the checkout click as an accountability mechanism. It was just how commerce worked. Agents strip it out because it is in the way. The accountability problem it was accidentally solving does not leave with it. Speed and volume compound the gap: an erroneous or fraudulent agent transaction that a human would have caught at the checkout moment can replicate across thousands of orders before anyone notices.

What does agentic commerce look like in practice?

The most natural enterprise use case is procurement. A procurement agent monitors stock levels against demand forecasts, identifies the preferred supplier from an approved list, negotiates within a pre-approved price band, places the order, and triggers payment on confirmed delivery. The purchasing manager sets the parameters once: approved suppliers, a spend band, a budget code, an escalation threshold. The agent runs continuously inside them. Individual transactions are invisible unless one breaches a threshold or a supplier raises a dispute.

For software systems consuming external services, the model is even more granular. An agent processing data or running compute pays per API call, per query, or per model token. The x402 protocol was designed for exactly this: a service states its price, the agent pays, both sides move on. No accounts receivable, no monthly invoicing cycle, no relationship management required. The commercial relationship between software systems becomes fully automated.

Consumer-facing agents are less mature but approaching. A shopping agent working inside a properly scoped AP2 mandate can complete a purchase on a consumer's behalf: the Intent Mandate defines what the consumer wants and what total spend is authorised; the agent finds the product, assembles the cart, and pays within scope. The consumer receives a receipt. They were not at the checkout. They may never review individual line items unless something prompts them to ask.

Across all three contexts, the transaction is real, the settlement is final, and no human was present when it happened. That is the point of agentic commerce. It is also the source of every risk worth naming.

What are the risks of agentic commerce?

The accountability gap is concrete, not theoretical, and several liability and fraud problems follow directly from removing the human checkpoint.

Liability settles badly by default. Card networks treat agent-initiated transactions as card-not-present, with no liability shift equivalent to chip-and-PIN authentication. When something goes wrong, the exposure tends to land on the merchant unless the agent's authorisation can be demonstrated clearly. The dispute profile changes too: fewer stolen-card claims, more "I did not authorise that scope", "the goods were not as described", or "the agent was authorised and still bought the wrong thing." Each of those is an evidence problem, not an authentication problem. They are harder to resolve without a clear record of what the agent was mandated to do, what it actually did, and whether the two match.

Regulation has already begun to address this. The CFPB advisory and Regulation Z guidance of January 2026 places agent-initiated card transactions inside the existing dispute and chargeback regime. A consumer's right of recourse is not removed by the presence of an agent mandate. Where the mandate is properly scoped and documented, that recourse narrows to what the agent was permitted to do. Where the mandate is vague or unrecorded, the consumer's full recourse remains open. The practical implication for merchants and intermediaries: the quality of the mandate documentation determines the exposure profile, and vague mandates are expensive ones.

Two attack vectors deserve a brief mention. First, faked agent identities, where a bad actor presents a spoofed agent credential to initiate an unauthorised transaction. The Visa Trusted Agent Protocol and Mastercard Agentic Token are direct structural responses to this problem. Second, first-party fraud via agents, where a consumer uses an agent's autonomy as cover for a false chargeback claim, arguing they never authorised what the agent did. Both are treated in depth in Know Your Agent.

The pattern across all of these risks is the same: each is answered not by a faster payment but by a better record of what happened, who authorised it, and whether the agent stayed inside its mandate.

The infrastructure agentic commerce still needs

Payment is nearly solved. Three things beneath it are not. Parts of each exist, but nothing yet that is neutral across networks, recognised by every counterparty, and able to bind who the agent is, what it may do, and what it did into one evidentiary record.

Verified agent identity: not the identity of the person who owns the agent, but the identity of the agent itself. What software it is, which version, who deployed it, what scope it carries. Visa's Verified Agent ID and AP2's signed mandate chain are steps in this direction. Neither is a portable, universally recognised credential that travels across networks, jurisdictions, and counterparties. An agent transacting across a supply chain spanning multiple countries and multiple card networks needs something more durable than a per-network token.

Explicit, machine-readable mandate: what may this agent do, for whom, up to what limit, and under what conditions. In enterprise terms that means concrete parameters: approved counterparties, a spend cap, a budget code, an expiry, a revocation rule. A broad instruction like "buy what we need" is not a mandate. It is a risk. The mandate must be legally binding, visible to the counterparty at the moment of transaction, and auditable after the fact. An agent arriving at a merchant carrying only an implicit "my owner authorised this" is not a basis for commerce at scale. The industry has already recognised this. AP2, Agent Pay, and the Trusted Agent Protocol are all, at their core, mandate frameworks. The gap is that each exists within one network, one jurisdiction, or one protocol stack.

An immutable audit trail: not logs held unilaterally by one party and unavailable to the other. A record that all sides can read and none can rewrite, created at the moment each event occurs, carrying a legally binding signature from the party who performed it. This is the piece most conspicuously absent from current infrastructure. It is also the piece that matters most the moment a dispute arises.

Identity, mandate, audit trail: none of these is a payment problem. They sit underneath payment. Payment rails move value; these rails move accountability.

This is where mintBlue's work sits, and it is worth being precise about what that means. mintBlue is not building another wallet or another payment button; its slice is the layer beneath payment, the rails between parties. The agent-specific identity and mandate work is at the pilot and experiment stage. The underlying rails and audit layer are the mature part of what mintBlue does, proven at scale in pilots. Every party seals their own envelope, and mintBlue is the postman who moves it and never looks inside. Keys stay with the parties who own them. Every event carries a legally binding signature and lands in a record all sides can read and none can rewrite, with no central honeypot that becomes a liability or an attack surface. The credential layer that underpins this is covered in verifiable credentials, and the full identity-and-audit argument in Know Your Agent.

The larger observation is this: the card programmes and the open protocols are not ignoring the accountability problem. They are discovering it mid-build, solving it piecemeal, in parallel. AP2's mandate chain, Visa's Verified Agent ID, Mastercard's scoped tokens: each is a partial answer to the same underlying question. A complete answer requires a layer that holds all three, is not owned by any single network, and persists across every counterparty the agent encounters.

Payment speed will become table stakes once the protocols settle. Several will. The durable advantage belongs to whoever can prove, after the fact and to everyone's satisfaction, what the agent actually did.

If one of your agents transacted on your behalf and the counterparty disputed it, what record would you reach for, and would they accept it?