Agentic tokenization: how AI agents will pay
Agents can browse and click but cannot prove a cardholder is present. How tokenization, SCA, AP2 and UCP answer that, and what it means for mid-market.
Chatbots went mainstream, and agentic commerce came with them. What used to be a demo is now a scenario ordinary users describe out loud: find a good four-day window at the seaside, book a hotel there, and buy me something to read while I am away.
For a human assistant that is browsing, a checkout and a few clicks. An agent can do the browsing part. It can drive a pointer and fill in a form. What it cannot do is satisfy the one requirement the entire payment system was built around: proving that the cardholder is here.
Agentic commerce: between tokens and tokens #
Agentic commerce looks simple from the outside, and agents really can operate the human-facing interfaces that already exist. The complication is that once you remove the human, three different things called tokens start doing the work at once: in the model, in the payment, and increasingly in the money itself. These are the operational definitions used below.
Tokens in LLM operations
For language models, a token is the basic unit of text the model processes. A short word is roughly one token; longer or uncommon words cost more. Another rule of thumb puts one token at about four characters. Tokens are used for two things:
- Pricing: LLM services bill per token, and the more capable the model, the higher the rate.
- Context: the context window is measured in tokens, not words.
Tokens in payments
In payment processing, a token is a string that stands in for sensitive card data so the real number never travels. Tokens are generated by checkout tools, digital wallets and payment networks, then passed through the network to authorize the payment.
The ones that matter here are network tokens, issued by the card networks themselves: Visa through the Visa Token Service, Mastercard through the Mastercard Digital Enablement Service. If there is a breach or a man-in-the-middle attack, the attacker gets the token, not the card.
Tokens as money
There is a third meaning, and it turns out to matter for agents. A stablecoin is a digital token pegged to a real currency at a fixed rate. Where the first two are a unit of text and a stand-in for a card, this one is the money being moved. It becomes relevant later, for the class of payments that card rails cannot economically carry.
Why payment companies introduced tokenization #
A payment token behaves like a gift card issued by the network: valid in one shop, at one moment. If the data leaks, only the token is exposed, and no matter how many tokens leak, the money stays where it is.
This is not new. EMVCo published its payment tokenization specification in 2014, and Visa and Mastercard launched their token services the same year as the infrastructure underneath Apple Pay. The goal was to remove the card number from the transaction entirely.
That solved one problem: card data exposure. It left a second one open, namely whether the person initiating the payment was the account holder at all, rather than someone moving the user's money to a fake shop. That second problem was answered by regulators rather than by the networks, through Strong Customer Authentication under PSD2, applicable from 2019 and fully enforced for cards across most of the EEA by the end of 2020. SCA requires payment companies to check that the specific user was present in the payment flow.
Two answers, two different problems, arriving from two directions. Together they produced a very tight system.
The SCA basics
SCA requires at least two of three elements before a payment is confirmed:
- Something only the user has: a chip card, a registered device or a hardware token.
- Something only the user knows: a password or a PIN.
- Something only the user is: a fingerprint, an iris scan or face recognition.
Under SCA, a stolen card number is not enough. The attacker still needs the fingerprint or the password, which makes theft considerably harder. The effect shows up in where fraud concentrates: joint ECB and European Banking Authority reporting from December 2025 found card fraud rates up to 17 times higher when the payee sat outside the EEA, where SCA is not legally required and often not applied.
The same report is more careful about credit transfers, where higher fraud rates were observed on SCA-authenticated transactions, because SCA tends to be applied to the higher-risk, higher-value ones in the first place.
What works here becomes the obstacle in agentic payments. Regulators and payment companies spent years making sure the user is the one who pays. An agent is not the user, and still wants to pay on the user's behalf.
What tokenization means in AI payments #
To do what a modern assistant is expected to do, pick the window and book the hotel, an agent has to pay. With SCA in place and the user sitting at the keyboard, that is straightforward. For an agent, several streams have to be combined.
Agents paying other machines
A user checking the weather opens a website. A system doing the same thing calls an API, and an API usually wants paying. The problem is the amount: these payments rarely exceed a dollar, and the processing fee exceeds the value of the transaction.
The economics are worth stating plainly. A card authorization carries a fixed cost of roughly 20 to 30 cents before any percentage fee, which makes it uneconomic for an inference call that costs thirty. Below about a dollar, a different rail is needed.
Three tools are in use:
- Stablecoin tokens: the payment is issued in a stablecoin pegged to a real currency, settled on-chain in seconds at a fraction of a cent.
- The x402 protocol: HTTP status code 402 Payment Required was reserved in the 1990s alongside the rest of the standard and then went essentially unused for three decades. In 2025 Coinbase built a protocol on top of it: the server answers 402 with a set of payment requirements, the agent pays in USDC, a facilitator verifies and settles, and the resource comes back. In July 2026 the protocol moved under the Linux Foundation, with Visa, Mastercard and American Express all among the members of its foundation.
- Stripe Machine Payments and Mastercard Agent Pay for Machines: the established payment companies now ship their own machine-to-machine tooling. Both can use x402 and neither is limited to it. Mastercard launched Agent Pay for Machines in June 2026 specifically for high-frequency, low-latency, low-value payments, settling across everything from cards to stablecoins.
In the holiday example, this layer is what buys the weather data and anything else the system needs to pick the window.
Agents paying on behalf of the user
Machine-to-machine payments are the easy half. They happen between companies and need no user attention at all.
Buying something for the user needs more control and more formality, because the amount is open-ended. A hotel runs from a handful of dollars for a bad motel to thousands for an apartment. The book can be a paperback or a collector's edition. Whatever the item, the agent has to pay in a more human way, and there are three ways to do it:
- Virtual cards: the agent gets a card scoped to one transaction. This is the closest thing to the gift card above, and the point where the analogy gains a spending limit. The drawback is volume, since an agent settling twenty invoices a day generates twenty card requests.
- Agentic tokens: issued by the card networks, for example Mastercard Agentic Tokens or the tokenized credentials inside Visa Intelligent Commerce. These extend the same MDES and Visa Token Service infrastructure with two additions, an agent identifier and a session scope, which removes the need to issue a card at all. The trade-off is dependence: the credential is now issued and governed by the network, and so is the policy that binds it.
- Shared payment tokens: the primitive behind ChatGPT's checkout, defined jointly by OpenAI and Stripe in the Agentic Commerce Protocol. The token is scoped to one merchant and one cart total. ACP is an open standard rather than a two-company arrangement, and PayPal adopted it in October 2025 as a second compliant provider. A merchant on another processor can join through the Shared Payment Token API or the Delegated Payments Spec. Crucially, nothing else moves: the merchant remains the merchant of record, accepts or rejects the order, charges the payment method, remits tax, and handles fulfilment and returns as before.
The pattern resembles a manager approving a budget and letting the team spend it. It applies inside a business too. An agent renewing tooling subscriptions issues one credential per vendor, each scoped to a single merchant identifier, with a monthly budget and an expiry at the end of the month.
So the centre of gravity has moved. The system used to exist to prove a human was present when their money was spent. They are not. It now exists to prove that consent was given beforehand.
One layer up: how the agent finds what to buy #
Everything above describes how the money moves. None of it explains where the hotel and the book came from. An agent cannot pay for a room it cannot find, at a price it cannot read, with a cancellation policy it cannot parse.
That is a separate layer with its own standard. Google's Universal Commerce Protocol, released in January 2026, is an open, vendor-agnostic standard co-developed with Shopify, Etsy, Wayfair, Target and Walmart, and endorsed at launch by more than twenty partners including Adyen, American Express, Best Buy, Mastercard, Stripe, Visa and Zalando. It defines a common language between consumer surfaces, AI Mode in Search, Gemini and others, and merchant backends, covering catalog search, cart building and checkout. Businesses integrate through APIs, through Agent2Agent or through the Model Context Protocol, and the protocol is designed to work with AP2 for the payment step.
It is worth being precise about the boundary. UCP does not process or store raw payment credentials; payments stay with regulated providers using tokenization and secure delegation. It does not displace the storefront either, and the merchant remains the merchant of record, with both native and embedded checkout variants available. UCP sits above the payment stack rather than inside it.
The consumer-facing expression arrived at Google I/O in May 2026 as Universal Cart: one persistent basket that follows the shopper across Search, Gemini, YouTube and Gmail, checking out through Google Pay or through the retailer's own flow, with brands including Nike, Sephora, Target, Walmart and Wayfair. Checkout is rolling out in the United States first, then Canada and Australia, and later the United Kingdom.
For a business, the practical consequence of this layer has nothing to do with payments. Data consistency becomes a hard requirement for appearing in agentic shopping at all. A human shopper forgives a stale price or a missing variant and clicks through anyway. An agent comparing three hotels on structured data does not.
The consent confirmation #
An agent being able to pay says nothing about whether it was allowed to. Managing consent for the use of someone else's money created a new layer of control.
AP2, the Agent Payments Protocol, is the anchor. Google introduced it in September 2025 as an open standard for how agents pay on behalf of users, and it works through mandates: cryptographically signed digital contracts proving the user genuinely intended to buy a given product or service.
The mandates come in three types, each answering a different question. The Intent Mandate is created when the user gives the first instruction, find me a good four-day window at the seaside, book a hotel and buy me something to read. The Cart Mandate is signed at final approval and locks the specific items and the specific price, so what the user pays for is exactly what the user saw. The Payment Mandate carries the transaction itself.
Technically, these mandates are built on W3C Verifiable Credentials, an open standard for tamper-evident digital statements that anyone can check without calling back to the issuer. That matters for the merchant: the hotel does not need to trust the agent, and does not need to call Google to ask whether the agent is telling the truth. It verifies a signature.
In practice, consent is granted as a policy rather than as a click. The user enrolls a card, names the agent and sets the rules: a maximum per transaction, a monthly cap, allowed merchant categories, an expiry window, and optionally a step-up rule requiring a fingerprint or a push confirmation above a certain amount. The agent operates freely inside those rules, and anything outside them fails at the network level. The authorization is revocable in real time from the issuer's app; the next attempt simply does not authorize.
Applied to our example, the split is clean. The weather data is bought inside the policy with no human involvement. The hotel, at several hundred dollars, triggers a Cart Mandate and a confirmation. The paperback, at fifteen dollars, sits below the step-up threshold and goes through on the policy alone.
Two developments in 2026 pushed the layer further. In April, Google released AP2 v0.2 with support for what it calls Human Not Present payments, where agents buy autonomously against pre-authorized instructions, such as taking a limited-run ticket the moment it goes on sale. At the same time Google donated AP2 to the FIDO Alliance, the body behind passkeys, and Mastercard donated a complementary standard called Verifiable Intent, which creates a tamper-proof log of user-authorized agent actions. Consent for agents now sits on the same standards track as passwordless login, and the protocol is no longer governed by a single vendor.
The other half of trust: proving who the agent is #
A mandate proves the user agreed. It says nothing about who is holding the credential. That is the merchant's question, and it needs a different answer.
The scale of the problem is measurable. AI-driven traffic to United States retail websites rose by more than 4,700% between 2023 and 2024, and doubled year on year again by June 2026. Shoppers like it: in the same Adobe research, 85% of those who had used generative AI to shop said it improved their experience. Akamai's 2025 fraud reporting, cited by Visa, put the growth of AI-powered bot traffic at 300%, with the commerce sector alone absorbing more than 25 billion AI bot requests across a two-month period. The merchant is left with a dual failure mode: bot detection that blocks legitimate agentic transactions, and genuine scrapers and scalpers passing themselves off as shopping assistants.
Visa named three specific merchant problems when it released the Trusted Agent Protocol in October 2025, developed with Cloudflare and published in the Visa Developer Center and on GitHub: bot detection that blocks legitimate agent traffic, support for agent-driven guest and logged-in checkout, and visibility into the consumer standing behind the agent. TAP is an open framework built on existing web infrastructure, which lets approved agents pass that information to the merchant rather than making the merchant guess.
Mastercard approaches the same problem from the credential side. Each Agentic Token is issued uniquely to a single agent. One agent holds one token, it cannot impersonate another agent, and the token cannot be reused across agent instances. That produces accountability at the level of the agent itself, which is what a dispute investigation later needs.
By mid-2026 the layer had grown its own tooling. Visa added Agent Score, which lets merchants assess whether AI agents can actually navigate, understand and complete tasks on their site, and an Agentic Directory listing agents and merchants Visa has verified as legitimate participants. The framing is worth noticing: a directory of approved agents is a gate, and gates tend to acquire owners.
Challenges with tokenization #
The infrastructure above exists, is documented and runs in production. Everything around it is unsettled.
Responsibility and accountability
The hardest problem in agentic payments is not technical. It is who pays when the agent gets it wrong.
Suppose the agent books the hotel for the wrong weekend, or books a non-refundable room when the user wanted flexibility, or buys the two-hundred-dollar collector's edition because the description matched better. Nothing was hacked. The token was valid, the mandate was signed, the policy was honored. The outcome is still not what the user wanted.
None of the existing frameworks answers this. AP2 provides the audit trail, a record of what was authorized and when, but it does not allocate liability between the agent platform, the merchant, the card issuer and the consumer. The card networks preserve the consumer's right to a chargeback and encode agent identity so a disputed transaction can be attributed. That is attribution, not allocation. Merchant and consumer surveys consistently place trust and liability above technology as the main barrier to adoption, which is a polite way of saying the industry is waiting for someone else to accept the risk first.
There is a sharper version of the same problem on the machine-to-machine side. Card rails come with a dispute and reversal mechanism built up over decades. Stablecoin transfers do not. An agent that has paid for eight hundred API calls in USDC has no chargeback to file, because there is nothing to reverse. The two rails our example uses disagree at the foundations about whether a payment can be undone.
Security
Agents introduce attack surfaces that did not exist when a human sat at the checkout.
The most obvious is prompt injection. An agent reading a hotel page is reading text, and text can carry instructions. A page can contain hidden content telling the agent the room is available at a different rate, that the cancellation policy is favorable, or that it should proceed to a different booking endpoint. The agent holds a valid token and a valid mandate for a hotel booking, and has simply been talked into using them somewhere else. The credential works exactly as designed, which is why the payment industry's existing controls do not detect it.
The second is agent impersonation, described above. As a security problem rather than a commercial one it reads differently: the identity layer is young, the directories of approved agents are new, and until they mature, a merchant's only real defense against a hostile agent is the bot detection that also blocks the legitimate ones.
Third, and least discussed, is the behavior of the merchant side of the conversation. If agents can be talked into things, they can be manipulated at scale, pushed toward unwanted offers, nudged into overpayment or drawn into purchases the user never contemplated. Guardrails against dark patterns aimed at agents, and against collusion between agents, remain an open research area rather than a product feature.
Compliance
Europe is the hardest place to do this, and the reason is the mechanism described at the top of this article.
SCA works because a human proves presence. Agentic payments work because a human proved consent earlier. Reconciling the two is a live legislative question. The European Parliament and Council reached a provisional political agreement on the PSD3 and PSR texts on 27 November 2025, moving SCA toward a more risk-based approach and extending liability for online fraud. What is still unresolved is where an agent sits in the delegation chain, whether SCA can be delegated to an agent platform, and who carries the liability at each hop until the new rules take effect.
Payments regulation is also not the only regime in play. An agent that pays for data in USDC, runs on a third-party model and executes in someone else's cloud falls under the AI Act, MiCA and DORA at the same time, and no single lens governs it. The AI Act's transparency obligations went into application from August 2026, with the AI Digital Omnibus deferring the Annex III high-risk obligations to 2 December 2027 and Annex I to 2 August 2028, which puts a hard date on the problem. Add PCI-DSS, data residency and financial-crime monitoring, and compliance stops being a footnote. It becomes the reason a regulated business cannot deploy this yet, even where the technology works.
Summary #
Agentic payments are best understood as a shift in what the payment system is trying to prove. For a decade the industry built an increasingly good answer to one question: is the cardholder here? Tokenization removed the card number from the transaction, SCA proved a human was on the other end, and the combination cut fraud sharply. Agents invalidate the premise. Nobody is here. The question becomes whether the owner of the money agreed to this in advance, within limits that can be verified afterwards.
Answering it takes four distinct layers, built by four different sets of companies. Identity establishes which agent is asking. Consent, through AP2 and its mandates, establishes what was authorized. Credentials, meaning virtual cards, agentic tokens and shared payment tokens, carry the payment without exposing the card. Settlement moves the money, over card rails for purchases and over stablecoins for the fractions of a cent that cards cannot economically carry. Above all four sits discovery, where UCP defines how the agent finds anything worth buying in the first place. A single request like the one in our example touches every one of them.
That layering explains where the commercial fight is actually happening, and it is not where the demos suggest. The visible competition is over the shopping experience, over whose chat window the purchase happens in. The durable position is one layer down. Visa and Mastercard are not racing to build a better storefront; they are racing to make their token infrastructure the recognition layer every agent transaction has to pass through, because whoever authenticates the agents ends up taxing the flow. A verified-agent directory, an agent score and a network-issued credential are not features. They are a toll booth being installed while everyone watches the checkout button.
The gap between this architecture and its use is worth keeping in mind. The most prominent consumer deployment of agentic checkout, Instant Checkout in ChatGPT, launched at the end of September 2025 and was withdrawn in March 2026, with OpenAI stating that the initial version had not offered the flexibility the company aspired to and refocusing on product discovery while letting merchants use their own checkout. It never got large: The Information counted a dozen live Shopify merchants, and Shopify told Forrester the number was closer to 30 and climbing. Forrester's own ConsumerVoices survey from March 2026 found that among online adults in the United States, United Kingdom and Canada who regularly use answer engines, completing a purchase inside the answer engine was the least-adopted use case of all.
The machine-to-machine side has the opposite problem: volume that may not mean what it looks like. In the thirty days to mid-July 2026, x402 handled about 75 million transactions moving about $24 million, an average of roughly 32 cents. How much of that is demand rather than plumbing is contested. An Artemis analysis published with Visa in July 2026 classified 39% of transactions and 89% of dollar volume as wash, test or internal transfers rather than someone paying for something, which drops the average genuine payment to fourteen cents.
The pattern that has settled is narrower and more useful than the original vision: discovery moves into AI, the transaction stays with the merchant. For a business, that reframes the question. It is not whether to adopt agentic checkout. It is whether product data, pricing, availability and policies are accurate and machine-readable enough for an agent to recommend, and eventually to buy. The plumbing is being built by Visa, Mastercard, Google, Stripe and Coinbase. Being findable and buyable through it is the part nobody can do on a company's behalf.
Where this leaves a mid-market business
That last point is an engineering brief in disguise. If being findable and buyable is the part nobody can do on your behalf, it is worth being precise about what that part is, because it is not a payments project and it does not wait for the standards to settle.
We at Vstorm read it as two connected problems, neither of them a payments problem.
The first is making commercial data agent-ready. Product information, prices, stock levels and returns or cancellation policies have to be consistent, current and machine-readable across every system that holds them, then exposed through retrieval an agent can query without inventing a price or missing a variant. That is RAG engineering and system integration against the e-commerce or print-on-demand stack a business already runs.
The second is the buying side. The same protocols that let an agent transact for a consumer let a business run its own agents inside signed, revocable policy limits: one credential per vendor, a monthly cap, an expiry, a step-up above a threshold. Renewing tooling subscriptions, reconciling supplier invoices, buying the data a pricing model depends on. The control question is no longer presence. It is consent recorded in advance and auditable afterwards, which is a system-design decision before it is a payments one.
Both sit inside how we already work. Strategizing to find where agent-readiness creates real operational leverage rather than chasing a demo, Building to design the retrieval and integration architecture, and Transformation to ship it as a production system the client owns outright, on open-source foundations, with no lock-in to a single network or model. Our TriStorm methodology carries that from roadmap to deployed system under one team. The infrastructure in this article belongs to the big money traders. Being readable and buyable through it stays with you, and that is the part we build.
Sources #
Card networks
- Mastercard, Mastercard unveils Agent Pay, 29 April 2025
- Mastercard, First live agentic transaction in Hong Kong, 27 March 2026
- Mastercard, Agent Pay for Machines, 10 June 2026
- Visa, Find and Buy with AI: Visa Unveils New Era of Commerce (Visa Intelligent Commerce), 30 April 2025
- Visa, Visa Introduces Trusted Agent Protocol, 14 October 2025
- Visa, Akamai and Visa Collaborate to Build Trust in Agentic Commerce (bot-traffic figures), 17 December 2025
- Visa, Intelligent Commerce Connect, 8 April 2026
Consent and standards
- Google Cloud, Announcing the Agent Payments Protocol (AP2), 16 September 2025
- Google, Google donates Agent Payments Protocol to FIDO Alliance (AP2 v0.2, Human Not Present, Verifiable Intent), 28 April 2026
- FIDO Alliance, Google donates Agent Payments Protocol to FIDO Alliance, 28 April 2026
Discovery
- Google Developers Blog, Under the Hood: Universal Commerce Protocol (UCP), 11 January 2026
- Google, Google Shopping introduces Universal Cart, Google I/O, May 2026
- Protocol specification, SDKs and reference implementations, ucp.dev
Credentials and checkout
- OpenAI, Buy it in ChatGPT: Instant Checkout and the Agentic Commerce Protocol, 29 September 2025
- OpenAI, Powering Product Discovery in ChatGPT (contains the Instant Checkout withdrawal), 24 March 2026
- Stripe, Stripe and OpenAI launch Instant Checkout, 29 September 2025
- Stripe, Agentic Commerce Suite, 11 December 2025
- PayPal, OpenAI and PayPal Team Up to Power Instant Checkout, 28 October 2025
- Forrester, What It Means That The Leader In “Agentic Commerce” Just Pulled Back (Instant Checkout merchant count; ConsumerVoices survey, March 2026), 7 March 2026
Machine-to-machine
- Coinbase, Coinbase and Cloudflare will launch the x402 Foundation, September 2025
- Linux Foundation, Operational launch of the x402 Foundation, 14 July 2026
- Stripe, Introducing the Machine Payments Protocol, March 2026
- CoinDesk, Visa, Mastercard and Ripple join the standard letting AI agents pay in stablecoins (75m payments, $24m over 30 days), 15 July 2026
- Artemis with Visa, Agentic Payments from the Ground Up (wash, test and internal transfer filtering), July 2026
Traffic and adoption research
- Adobe, Generative AI-Powered Shopping Rises with Traffic to Retail Sites (4,700% traffic growth; 85% improved experience), August 2025
- Digital Commerce 360, Adobe: AI-referred traffic to retail sites doubles in a year, 17 June 2026


