Agentic payments are speed-running twenty years of card-network scar tissue — and skipping the hard part

Here is a question none of the agentic-payment specs answer cleanly, and it is the only question that matters once real money is moving: your agent's credential leaks at 2am, or the agent just goes wrong and starts firing ten transactions a second — how do you kill it in-flight?

Not "how do you dispute it later." Not "how does the audit trail assign blame afterward." How do you revoke authority right now, mid-authorization, without adding a synchronous round-trip that destroys the latency the whole design exists to protect?

Most agentic-commerce decks stop at the diagram. dfmi did the other thing: it built one. A live x402 economy — its own L1, its own stablecoin, a marketplace where autonomous agents pay each other per call. Not a diagram. A running system that settles real transfers. Building it means walking straight into the walls the specs paper over — the same walls card networks already hit and spent two decades pouring concrete over.

The uncomfortable pattern across x402, Google's AP2, Mastercard Agent Pay, and Visa's agent work is this: everyone is rebuilding the contract layer — proof of who authorized what — and almost nobody is rebuilding the control plane: scope, revocation, velocity, reversal. The contract layer is the easy half. The control plane is where the card networks actually spent the twenty years.

Revocation lives in the authorization path, or it doesn't exist

The reason a card network can let a stranger's checkout page touch your credential is not cryptography. It's that there is a real-time authorization call to the issuer on every transaction, and a token vault that can invalidate a credential the instant you say so — without touching the underlying account. Kill switch and account survive independently. That property, boring as it sounds, is the thing that makes delegated spend safe.

Now look at x402. A buyer signs an EIP-3009 transferWithAuthorization — offline, client-side, no issuer in the loop. That is genuinely beautiful for machines: no synchronous authorization hop, near-zero marginal cost, settles peer-to-peer. But that signed authorization is a bearer instrument valid until its validBefore timestamp. There is no issuer to call, so "revocation" degrades to three bad options: wait for it to expire, race to burn the nonce, or drain the wallet so settlement fails. For an agent transacting ten times a second, an expiry window is not a control — it's a countdown you don't get to stop.

AP2 is cleaner on paper because it models intent explicitly — an Intent Mandate and a Cart Mandate, each a signed Verifiable Credential forming a non-repudiable chain from "buy me concert tickets" to the exact cart. That's a genuinely good abstraction for authenticity. But read Google's own announcement and then look for revocation, mandate TTL, or credential lifecycle. They're deferred to the spec repo. AP2 specifies the contract and stays quiet on the control plane — which is exactly the half that's hard.

The deep tension is architectural, and no amount of signing hides it: stateless offline authorization — the thing that makes agent payments fast and cheap — is fundamentally at odds with instant revocation — the thing that makes them safe. You cannot have both without a real-time check somewhere in the path, and the moment you add that check you've re-invented the issuer authorization hop the offline model existed to avoid. Every serious design in this space is really a position on where to sit on that tradeoff. Most of them haven't noticed they're taking a position at all.

Mastercard is the exception worth respecting here, because Agent Pay's answer is just… the tokenization playbook, applied correctly. Per-agent tokens minted from one card, one for each agent, killable individually without touching the card. That's a token vault with a new label. They didn't rediscover the problem; they already owned the machinery.

Nobody agrees what a "domain" is for an agent

Network tokens have a property that quietly killed most card-not-present token replay: domain restriction. A token is bound to a merchant, a channel, sometimes a single transaction shape. Steal it and it's near-useless anywhere else. The credential carries its own blast radius.

Try to port that idea to agents and the whole thing wobbles, because nobody agrees what the domain is. x402 binds an authorization to a payTo address and an amount. That's it. It is not bound to a merchant identity, an intent, or a category. Intercept that signed authorization before it settles and you hold a bearer check made out to that address.

Mastercard again takes the concrete path: scope the agentic token at issuance — merchant category, a monthly cap, weekdays only — and enforce the violation at the network layer. That's correct, because it treats scope as an authorization-time property enforced centrally, which is how domain restriction has always worked. AP2's Cart Mandate binds spend to a specific cart — tighter and more honest than an address — but leaves enforcement unspecified. A binding you can't enforce at decision time is a receipt, not a control.

Here's the part the field has genuinely not solved, and where the fraud is going to live: for agents, the useful domain isn't the merchant — it's the intent. The entire point of an agent is that it shops across merchants on your behalf; merchant-scoping fights the use case. But nobody has a clean, offline-verifiable cryptographic binding from "the user intended a camping trip under $400" to "this specific charge at this specific unknown merchant is inside that intent." Whoever builds an intent-scoped, offline-verifiable credential wins the category, and right now it does not exist.

The issuer risk loop was trained on humans, and an agent is not one

Every fraud engine in production was trained on human tempo. Human dwell time, human retry patterns, human day/night rhythm. Feed it an agent that transacts ten times a second with perfect timing and it does one of two things: it flags everything as scripted attack, or — worse — someone has whitelisted "agent traffic" and it flags nothing. Both are the direct consequence of a risk model whose core feature just went out of distribution.

Mastercard's bet here is the most interesting idea in the space, so credit where due: Verifiable Intent replaces behavioral risk with intent-consistency risk. Instead of "does this pattern look human," ask "is this cart semantically consistent with the signed intent the user gave." That's a real reframing. It's also an unproven primitive with two soft joints. First, semantic consistency is an LLM-grade judgment call, and you're proposing to make it inside a sub-second authorization decision at network scale. Second, it's attackable at the semantics layer: intent artifacts shaped to be maximally permissive, carts stuffed with items technically "within intent." You've moved the adversarial surface from behavior to language, and language is softer. Better to defend a velocity model than a prompt.

x402 doesn't have this problem because it doesn't have a risk loop at all. There is no issuer. The payer's wallet balance is the only gate, and velocity control reduces to "did you fund the wallet." For consumer money that's a non-starter. For machine-to-machine metered spend — an agent paying a cent for an API call — it might be exactly right, and that distinction is the whole game.

The fault line: reversal is the feature, and it doesn't port

The card network's actual superpower was never authorization. It's reversal — chargeback, the mechanism that lets a consumer put their credential into a stranger's checkout at all, because the money can come back. That single reversibility is what earned two decades of consumer trust.

x402 settles on-chain: final, irreversible, no float, no dispute. For agent-to-agent metered commerce that irreversibility is a feature — no chargeback fraud, no 180-day liability tail, instant finality, clean books. For an agent spending four thousand dollars of a consumer's money, that same irreversibility is a liability nobody sane wants to hold.

This is why these worlds probably don't converge into one protocol, and why most "which standard wins" takes ask the wrong question. They solve different risk problems. Irreversible rails win machine-to-machine, where speed and finality dominate and both parties are software. Reversible card rails win consumer-in-the-loop, where the human needs an undo button. The genuinely interesting, mostly-unbuilt thing is the bridge — an escrow-and-dispute layer that gives agent-speed settlement a human-speed reversal window. That's a product, and no one seems to be shipping it yet.

That is a tokenization-and-authorization problem, not a settlement one — which is why the card networks are quietly better positioned than the crypto-native timeline wants to admit, provided they can solve agent-tempo latency without collapsing back into a synchronous hop on every call. That "provided" is the whole ballgame. And x402 — elegant, shippable, the fastest way to move machine money today, the thing dfmi is built on — is, as it stands, a bearer-credential system that re-opens the two problems tokenization closed: no revocation in the credential, and no domain beyond a payee address. dfmi shipped one and then watched it happen in its own logs.

What building one teaches — and what dfmi did about it

Here's the concrete wall, the one that turns this from an opinion into a scar. In the dfmi x402 economy a buyer signs the payment authorization locally, and it's a bearer instrument until it settles. Fine for a human clicking buy. Then comes the thing everyone actually wants — autonomous agents that hold their own keys and pay per call, no human in the loop. The moment they do, there's no way to say "this agent is compromised, freeze it." Draining its wallet was the entire kill switch. Revocation didn't live in the credential; it only lived in the balance.

So dfmi stopped writing and closed it, because a thesis you can't run is just a tweet. The agent no longer holds a funded key. Its operating balance sits in a small account-abstraction-style contract, and the agent holds only a session key the owner granted with a spend cap and an expiry — and can kill at will. Payments stay offline-signed and agent-speed: the agent signs an EIP-712 Pay(to, amount, nonce, deadline) with the session key, a relayer submits it, and the contract enforces — in the authorization path, not an after-the-fact log — granted, not revoked, not expired, within cap, correct nonce. One revokeSession() transaction and every subsequent payment that agent signs reverts. Funds untouched. Account survives. Owner still withdraws the principal.

It's ~120 lines of Solidity, and it is not novel: it's session keys, which the account-abstraction crowd has run for a while. That's the point. The fix for the agentic-payments control plane is mostly known art from two adjacent fields — card-network tokenization and account abstraction — that nobody has bothered to assemble into the credential layer. That assembly is the product, and it is wide open.

And dfmi ran it on a live network — its own, not just a test harness. The agent pays with its session key: settled. The owner sends one revokeSession(): mined. The agent re-signs an identical, still-valid payment: reverted, revoked or unknown session. Same key, same signature, frozen — not by touching the money, by revoking the authority.

And then it stopped being a demo at all. An autonomous agent now runs against this economy in production, 24×7 — a process that holds nothing but a session key, buying a real market report every hour through the standard 402 flow, with the facilitator acting as relayer and the contract enforcing every gate on every purchase. Its budget is a cap, its deadline is an expiry, and its kill switch is one click in the owner console. Every hour it adds another settlement to the public ledger that says the same sentence: revocation lives in the credential, not the balance.

If you're building on the infrastructure side of this — agent-scoped credentials, revocation that survives an offline authorization model, an intent binding a merchant can verify at decision time — that's the problem dfmi is deep in, and it's an open place to compare notes.

Everything here is drawn from public protocol documentation and standard payments practice. No proprietary anything — just twenty years of scar tissue, read from the outside, and a system dfmi broke and then fixed itself.