Visa TAP + Mastercard Verifiable Intent: The Merchant's Evidence Playbook

AI agents are buying things on behalf of real people, and the card networks have decided this is happening with or without them. Visa shipped the Trusted Agent Protocol in October 2025. Mastercard answered in 2026 with Verifiable Intent, co-developed with Google. Both solve the same problem: how does a merchant know the request coming from an agent is legitimate?

That problem is mostly solved. The one nobody solved is what happens 45 days later, when the cardholder calls their bank and says "I never authorized this." This post is about that second problem, because it lands on you, the merchant.

What Visa TAP actually does

The Trusted Agent Protocol, live since October 14, 2025, gives AI agents a cryptographic way to prove who they are and who authorized them. The spec is open source on GitHub. In practice, an agent acting for a user sends HTTP requests that are signed, and the merchant can verify the signature against known agent issuers before the order goes through.

Think of it as TLS for the buyer. TLS proved the server was real. TAP proves the agent is real, and that a real human vouched for it. Visa's framing is blunt: block malicious bots, let legitimate agents check out smoothly.

For a merchant, the immediate win is fraud screening. Requests arrive with a verifiable identity instead of a suspicious user-agent string you have to eyeball. But TAP gives you something else that most merchants are throwing away: a receipt. A cryptographically signed artifact proving this specific agent, authorized by this specific user, placed this specific order.

What Mastercard Verifiable Intent adds

Mastercard's Verifiable Intent, part of the Agent Pay program, pushes the proof one step earlier in the chain. Where TAP focuses on the agent's identity, Verifiable Intent documents the human authorization behind the transaction: the user's intent and explicit consent, captured before the payment happens, in a form that can be verified later.

It is standards-based and co-developed with Google, which matters because the agent ecosystem is not going to rally around one network's proprietary format. Both networks are racing to become the trust layer for agentic commerce, and merchants get to benefit from the overlap: signed agent identity on one side, documented human consent on the other.

Now the uncomfortable part.

The gap: disputes do not read protocols

When a chargeback lands on a transaction made by an AI agent, the dispute process works exactly like it always has. The issuer asks the merchant for evidence. The cardholder's story is simple and hard to beat: "I did not make this purchase." In a strict sense, they are right. Their fingers never touched the keyboard.

Industry analysts have been flagging this all year. Chargebacks911 warned that Visa, Mastercard and Amex are activating agent payments in 2026 while the dispute infrastructure to support them does not exist yet. Liability is genuinely unresolved: when an agent purchase goes wrong, no current rule cleanly assigns fault between the consumer, the AI provider, and the merchant.

In the absence of rules, evidence decides. And here is the thing most merchants miss: if you ran TAP verification at checkout, you are already generating the strongest evidence that exists for these disputes. The signed request headers, the verification result, the agent identity, the linkage to the authorizing user. Every piece of it is exactly what an issuer needs to see to rule in your favor.

The catch: none of it helps if it is gone by the time the chargeback arrives. Which, for most merchants, it will be.

Why the evidence evaporates

The typical order pipeline keeps what it needs to fulfill the order and nothing else. HTTP headers get logged for a few days for debugging, then rotated away. Verification results are computed, consumed, and discarded. By the time a dispute arrives, the average merchant has the order record, the delivery confirmation, and a gap where the agent proof used to be.

Compare that with what you keep for human orders: the IP address, the device fingerprint, the terms-of-service acceptance, the email threads. Merchants learned over two decades of card-not-present fraud that every scrap of context at transaction time is ammunition at dispute time. Agentic orders are about to re-teach that lesson, at higher stakes, because "a bot bought it" is a more sympathetic dispute story than "I changed my mind."

So the playbook is simple to state: treat every agent transaction as a future chargeback, and preserve the proof while you have it. In practice it breaks into four moves.

Move 1: capture at transaction time

When an agent places an order, grab everything the protocol gives you, before your middleware throws it away. The signed TAP request headers. The agent identifier. The signature itself. The timestamp and the verification result. If the flow includes Verifiable Intent consent artifacts, store those too.

This is a capture problem, not an analysis problem. You do not need to understand the cryptography to keep the artifacts. You need a hook at ingestion that says: this request came from an agent, persist the proof, keyed to the order.

Move 2: verify at ingest, not at dispute time

Verifying a signature 45 days after the fact is worse than verifying it in real time. Keys rotate. Specs evolve. The honest answer to "is this receipt valid" is the answer you computed when the request arrived, against the keys that were live then.

So verify at ingest and store the verdict: verified, verification failed, or no protocol data at all. That classification is what you will actually use under dispute pressure. An order marked tap_verified with a stored receipt is a dispute you fight with confidence. An order marked agent_ua_only, where all you had was a suspicious user-agent string, is a dispute you might want to refund cheaply rather than lose expensively.

Move 3: classify every order by proof strength

Once you capture and verify, every order falls into one of three buckets. Human order: classic evidence, nothing new. Verified agent order: protocol receipts exist and check out. Unverified agent order: it smells like an agent, but you have no proof.

The third bucket is where chargeback losses concentrate, and it is also where a decision lives: do you decline unverified agent traffic, or accept it and price the risk in? Networks will push you toward accepting verified traffic. What you do with the rest is a business call. But you cannot even have that conversation without the classification.

Move 4: bundle for the issuer, not for yourself

When the chargeback arrives, the clock is short and the format matters. Issuers process evidence documents, not git repositories. What wins is a clean bundle: the order record, the delivery proof, the timeline, and the protocol receipts, assembled in the order a dispute reviewer reads them, with the "this purchase was made by a verified AI agent authorized by the cardholder" claim up front and the signatures to back it.

The first dispute you fight this way will feel like bringing a flamethrower to a knife fight. Most merchants responding to "unauthorized transaction" claims bring an order confirmation and hope. You bring cryptographic proof that the request was signed by a recognized agent and the signature verified against a live key at transaction time. That is a different weight class.

What we built, and what we did not

ChargeGuard now does the four moves for you. An SDK captures TAP artifacts at checkout. Every receipt is verified at ingest using RFC 9421-style HTTP message signatures, then classified and stored against the order. When a dispute arrives, the matcher pulls the order, attaches the receipts, and generates the evidence bundle as a PDF, ready to submit. See how the pipeline works.

What we did not build is a prediction about how the networks will rule on agent disputes. Nobody can, because the rules do not exist yet. What we know is how disputes actually get decided: on evidence, by reviewers who see hundreds a day. The merchant with signed, timestamped, verified proof of agent authorization is the merchant who wins those reviews, whatever the liability rules become later.

The networks solved identity at checkout. Evidence at dispute time is still your job. It always was.