AI assistants already help people compare products, check availability and plan purchases. Agentic commerce extends that role to placing the order: a customer sets a budget and a few conditions, then gives the software permission to complete the purchase.

McKinsey estimates that AI agents could orchestrate $900 billion to $1 trillion of US consumer retail revenue by 2030, with the global figure for goods reaching $3 trillion to $5 trillion. Even at the lower end, that is a lot of purchases passing through systems built around people making the decisions.

At checkout, the payment itself can look ordinary. It can arrive as a tokenised card transaction and pass through the same rails used for other online purchases. Most issuer-processing systems would handle it.

Yet successful processing can conceal how much remains unknown about the authority behind the purchase. The payment message may reveal very little about the agent involved, the customer who authorised it or the limits attached to that instruction.

That difference becomes more important as agents move from recommending products to completing transactions. Agentic commerce brings another participant into a process built around customers, merchants and financial institutions, and issuers need to make that participant visible while the payment is being assessed.

The instruction the issuer cannot see

An issuer sees the credential, merchant, amount and recent account activity. What it may not see is the instruction that led the agent to make the purchase.

If a customer asks an agent to book a Paris hotel for less than £600, a £580 hotel charge fits the instruction. A purchase for the same amount from an electronics retailer does not. The issuer needs enough context to identify the agent, confirm what the customer approved and check that the permission was still valid.

And it needs to know that the agent presenting those permissions is genuine and its credentials have not been compromised.

Mastercard’s work shows how these controls are beginning to move into live use. It has completed authenticated agent-led transactions in Australia and is working with partners across the region on AI-driven procurement, where agents source from approved suppliers, place orders and initiate payments. Its Verifiable Intent initiative is designed to record what the customer authorised and connect that permission to the agent’s actions.

Making permission readable

Delegated authority has to reach payment systems in a usable form. The record should identify the agent and customer, describe the task, set any spending or merchant limits and show when the instruction expires.

Google’s Agent Payments Protocol offers one way to carry that information. It records the customer’s request, then links the eventual payment to the cart and amount they approved. The receipt shows what was bought and paid.

Banks also need that record for governance. It can show who granted or changed the authority and when further approval was requested. Banks can then decide who is allowed to amend, pause or withdraw that authority.

Customers have to be able to change their minds too. They can pause a weekly grocery order, lower the spending limit or exclude certain products. A travel mandate may expire once the reservation is complete. Changes have to feed through promptly.

Consumers are already sensitive to how much control they retain. Visa research across the US, Australia and New Zealand found that around 85% wanted explicit control over the data an agent could access. Nearly 43% worried that an agent could select the wrong product, while about half were concerned about decisions being made without their involvement.

Fraud controls for automated spending

Agents can move between merchants far faster than a customer would. A burst of transactions could form part of a genuine travel booking or procurement task or indicate that an agent has been compromised.

To make that judgement, the issuer needs information about the agent, the customer’s mandate and the task being carried out, alongside the payment data it already uses. Those signals have to be available during authorisation. A review hours later can explain what happened, but by then the payment has already gone through.

An agent might compare prices across several merchants, abandon baskets, reserve stock or retry a payment after a decline. Activity that looks unusual when measured against human behaviour could still match the task the customer assigned.

The issuer then has to check whether the activity still matches a valid mandate. The customer may have withdrawn access or reduced the limit since the agent was first approved.

Resolving disputes when records are split

A wrong booking date, an unapproved price increase or an order from an excluded merchant can lead to a dispute. The evidence is scattered. The agent provider can show what the customer requested and how the software responded. The merchant has the offer and order details, while the issuer has the payment and account record. Reading them together should show whether the agent stayed within its brief.

Regulation runs into the same problem. Existing rules generally describe the responsibilities of consumers, merchants and regulated financial institutions. Autonomous software acts between those parties. Regulators will have to decide how liability is shared when an agent followed an instruction poorly, exceeded its authority or acted after being compromised. Early disputes are likely to test those boundaries.

Where issuer processing changes

Issuer processors already make authorisation decisions in milliseconds. With an agent involved, the usual card message tells only part of the story. The processor also needs a way to check the software behind the payment and the instruction it received from the customer.

One approach is to flag the agent’s involvement in the payment message and hold the customer’s approval and spending limits in a separate mandate record. Older card-processing systems usually look inside the transaction message. Agent-led payments also require them to pull in a separate record before deciding whether to approve. A service-oriented platform can bring both sources into the authorisation decision without forcing a full rebuild whenever the requirements change.

The same agent and payment method can operate across several markets, but the rules around them will differ. Banks still have to reflect local requirements for consent, authentication and liability, along with domestic scheme rules. The processing layer needs a common global foundation with enough flexibility to localise without requiring a separate technology stack for every country.

Cards provide the clearest example today, although the same controls will need to follow agents across account-to-account payments, wallets, stablecoins and other rails.

Early agent-led payments are likely to stay within narrow boundaries: known agents, approved merchants, capped amounts and permissions that expire.

Agent-led commerce asks customers to hand part of the purchasing decision to software. Their trust will depend on the controls around that authority: what the agent can do, how quickly permission can be withdrawn and whether the transaction can be explained afterwards.