The EMVCo agentic payments framework: cards are building a registry for something a wallet already knows

What EMVCo published on September 1, 2026

EMVCo is not a startup with a thesis. It is the technical body owned by the six card networks that writes the specifications the entire card world implements — EMV chip, EMV 3-D Secure, payment tokenization. When EMVCo publishes a framework, it is describing the shape of card payments five years out.

On September 1, 2026, it released a draft titled EMV® Agentic Payments – Framework for Specifications v1.0 and opened it for public comment through September 30, 2026. The stated goal is secure, interoperable and scalable card-based agentic payments — AI agents buying things with a human's card credential.

The centrepiece is a new concept: Intent Services. In the words of Clinton Allen, chair of the EMVCo Agentic Payments Task Force, it is "a shared, interoperable layer that enables payment participants to register, reference, retrieve and manage consumer-authorised intent before, during and after a transaction." The draft sketches the ecosystem roles and the data fields needed for three jobs: registering intent, maintaining its lifecycle and state, and enabling authorised parties to retrieve it.

EMVCo says it focused on card scenarios where intent must be managed over time — recurring purchases, cumulative budgets, post-transaction activity — and that the layer would "complement cryptographic assurance provided by existing industry solutions, such as Verifiable Intent, with a common coordination point." Two capabilities are flagged for possible future publications: Know Your Agent and Agentic Transaction Indicators, so the rail can identify which agent was involved and flag that a transaction was agent-initiated at all.

The sentence that gives the whole game away

Buried in the framing is the most honest sentence any card body has published about agentic commerce. As PYMNTS summarised it: a valid card credential may tell an issuer that an AI agent can pay — it does not tell the issuer whether the agent should make this particular purchase.

EMVCo's own example is a consumer who authorises an agent to spend up to $300 a month on groceries. The credential stays valid all month. The fourth order is the one that breaks the mandate — and nothing in the authorisation message knows that. The card network sees a well-formed request with a good token and no reason to decline.

Read that carefully, because it is not a software gap. It is a property of the rail. A card payment is a pull: the merchant presents a credential and asks an issuer to advance money the payer does not currently hold at the point of sale. The authority to do that lives in an agreement between the cardholder and their bank, not in the transaction. So when you delegate a slice of that authority to a piece of software, there is nowhere in the payment for the slice to live. Someone has to keep a separate ledger of how much mandate is left.

That separate ledger is exactly what Intent Services is. And it has to be shared, because the agent platform, the merchant, the acquirer and the issuer all need to consult the same state — which is why EMVCo describes it as a common coordination point rather than a feature any one participant can ship.

What "Intent Services" would actually cost to exist

Count the moving parts a card-based agentic purchase would need under this architecture:

• A credential — the tokenized card, proving the instrument is valid.
• Verifiable Intent or an equivalent — cryptographic proof that a human authorised a mandate.
• Intent Services — a shared, stateful registry that knows what is left of that mandate right now, and survives across participants and across time.
• Know Your Agent — identity for the software, so you know which agent is acting. (We covered the Visa · Mastercard · Ant effort in Know Your Agent: card rails are issuing passports to AI agents.)
• Agentic Transaction Indicators — a flag in the message saying "an agent did this".
• And underneath it all, the existing authorisation and dispute machinery.

Six coordinated systems, four of which do not exist yet in shipped form, to answer one question: was this specific purchase inside the authority the human granted?

There is a second-order consequence worth naming, because it gets very little attention. EMVCo says intent must be managed after a transaction, covering "post-transaction activity". A persistent record of what the consumer instructed, when, and for how long is, among other things, evidence. It will be pulled into disputes. Which means the most likely near-term effect of the intent layer on merchants is not that agentic card purchases stop being reversible — it is that reversing them gets a richer evidentiary file. We wrote about who ends up holding that bag in agentic commerce chargeback liability.

None of this makes EMVCo wrong. If agents are going to buy flights and groceries on consumer credit, that machinery genuinely has to exist. The point is narrower and more useful: it is the price of keeping the payment a pull.

Why a push payment needs no intent registry

Now run the same $300-of-groceries mandate on a wallet instead of a card.

The human funds an agent wallet with $300 of USDC. The agent goes shopping. Each purchase is a push: the agent signs a payment for a specific amount to a specific address, and it settles on-chain. The fourth order that would have broken the mandate doesn't need to be caught by a registry — if it exceeds what is left, there is nothing to sign with. The remaining budget is not a number in a shared database that four parties have to agree on. The remaining budget is the balance.

This is the difference the EMVCo draft is implicitly working around. A credential can prove a mandate existed. It cannot tell you how much of it is left, because the money isn't there. A wallet can only tell you how much is left, because that's all a wallet is.

The same property shows up one level down, at the level most agent traffic actually lives: paying for an API call. The x402 protocol revives the long-dormant HTTP 402 Payment Required status code. The server answers an unpaid request with a 402 that quotes a price for that exact resource. The agent signs a payment for exactly that amount and retries. The request succeeds.

There is no mandate state to look up, because the scope of the authority is the amount signed, and it's spent in the same breath it's granted. There is no "should it?" left over for an issuer, because nobody is being asked to advance anything. There is no post-transaction lifecycle, because the transaction has no tail. This is why we keep saying the split in agentic commerce is registration-first versus payment-first — and why it maps almost exactly onto consumer goods versus machine services.

How to let AI agents pay your API today, step by step

Payzum's role here is specific and worth stating precisely: we are the middleware/proxy in front of your API — not the facilitator. Payment settlement runs through an external facilitator (currently Coinbase's). What Payzum removes is the part where you implement a payment protocol.

1. Configure the endpoint. In the Payzum dashboard, point at the API endpoint you already run and paste the API key or bearer token it expects. Nothing changes on your side — no SDK, no middleware in your stack, no protocol to implement.
2. Set a price per call. Denominated in USDC. Different routes can carry different prices, which is how sellers with real agent revenue tend to price: cheap reads, expensive computation.
3. Payzum publishes an x402 URL. An agent hits it, gets the 402 with the price, signs a USDC payment on Base, and retries. Settlement is handled via the external facilitator; the funds land directly in the wallet you control — Payzum never holds them.
4. Payzum proxies the paid call. Once payment clears, the request is forwarded to your real endpoint with your key attached, and your response goes back to the agent. From your server's point of view it is an ordinary authenticated request.

Pricing on the agentic side is roughly ~1,000 transactions per month free, then ~$0.001 per transaction plus gas. // confirmar pricing actual

The whole thing is dashboard configuration. An API provider can be agent-payable the same day — which is the entire argument of this post compressed into one sentence. For the longer walkthrough see let AI agents pay for your API and x402: pay per API call.

Who this actually changes something for

Three concrete readings of the September 1 draft, depending on what you sell.

• You sell an API, dataset, model endpoint or MCP tool. You are not a participant in Intent Services — you are downstream of it. Nothing in the framework is a task on your roadmap, and nothing in it blocks you either. Your bottleneck is having an endpoint an agent can pay without a human opening an account. That is a config change, not a standards process.
• You run a SaaS or a developer platform with metered usage. The interesting question the EMVCo draft raises for you is cumulative budgets — the thing they need a registry for. On a wallet you get it free: a customer's agent funds a wallet, spends it down per call, and tops it up. No mandate lifecycle, no dunning, no expired card killing a subscription mid-month. If you also sell to humans, subscriptions, hosted checkout, payment links and invoices run on the same non-custodial settlement.
• You sell physical goods to consumers. Here the card track is the one that matters, and you should read the framework — but read it for what it does to your dispute exposure, not your revenue. Meanwhile, the customers who already hold stablecoins can pay you finally and irreversibly today, online or at the counter with QR-per-sale POS and PIN cashiers.

Intent registry vs signed payment: the comparison

The honest counter-arguments

"You're comparing a draft standard to a product — of course the product ships sooner."

Fair, and worth conceding cleanly: EMVCo is doing exactly the right job for its remit. Cards are near-universal; agents paying in stablecoins are not. If consumer agentic commerce is going to be safe on credit rails, an interoperable intent layer beats twelve proprietary ones, and EMVCo is the only body positioned to write it. Anyone dismissing the framework as bureaucracy is not paying attention.

The argument here isn't that the card track is wrong. It's that the two tracks answer different questions for different goods, and a seller of machine services is being told to wait for a solution to a problem they do not have. Nothing in Framework for Specifications v1.0 becomes revenue for an API provider — and the long lead time from EMVCo framework to merchant-visible reality is well documented by every previous EMVCo specification.

"On-chain finality means a misbehaving agent can't be undone. That's worse."

For consumer purchases with refund expectations, that's a real cost, and we won't pretend otherwise. If an agent buys the wrong thing with a card, the dispute process exists to unwind it; on-chain, the payment is final and the recourse is the seller's refund policy. Agent-side spend caps and a funded-wallet model limit the blast radius, but they don't recreate a chargeback.

What we'd push back on is applying that framing to sub-dollar machine payments. Nobody disputes a $0.002 API call — the cost of the dispute exceeds the transaction by three orders of magnitude. Reversibility is a feature you pay for on every transaction whether you use it or not, and for per-call machine commerce it is pure overhead. Choose the rail that matches the good.

"Can't I just use a virtual card for my agent instead?"

You can, and plenty of teams do — we compared the approaches in AI agents with virtual cards vs x402. The short version: virtual cards give you familiar controls and reversibility, at card economics with a per-transaction floor that makes sub-cent pricing impossible, and they still leave the seller doing card-style onboarding. That's the trade the EMVCo framework is trying to improve — for the buyers, not the sellers.