The token proves the agent may pay. It does not prove you agreed.

Agentic payment tokens answer the merchant's question, which is: which agent is this, and may it use this card. They leave the issuer's question and the customer's question exactly where they were, which is: did a human actually agree to this. That gap is where the coming dispute wave lives.

The dispute nobody in the chain can settle

Picture a Tuesday in a card issuer's dispute team. A cardholder has called about a charge of three hundred and forty dollars to a merchant she does not recognise. She is not angry. She is confused, which is worse, because angry customers usually know what happened.

The analyst pulls the record. The transaction was made by an assistant operating on her behalf. There is a token, correctly formed, correctly registered, derived from her card under a network programme designed for exactly this. There is an agent identifier that resolves to a real, registered platform. There is a mandate object, cryptographically signed, that says this agent may spend up to five hundred dollars per transaction on restaurant and travel merchants until December. And there is a consent record: on the third of August at 21:14, an interface belonging to that platform recorded that the account holder clicked Allow this assistant to make purchases on my behalf.

Every artifact is valid. Every signature verifies. The chain is complete from the card to the token to the agent to the purchase.

And the analyst still cannot answer the only question that matters, which is whether the woman on the phone agreed to any of it. She may have clicked. She may have clicked without reading, at 21:14, on a phone, while doing something else. Someone holding her session may have clicked. All three produce byte for byte identical evidence. The dispute will be decided by policy rather than by proof, which is another way of saying it will be decided by whoever the rules favour that quarter.

This is not a criticism of the people who built the rails. They built the part that was theirs to build, and they built it well. It is an observation that the part nobody built is the part the dispute turns on.

What are agentic payment tokens, and what do they actually prove?

Over 2025 and 2026 the card networks and the large platforms built a genuinely impressive amount of infrastructure for a form of commerce that barely existed when the work started. It deserves to be described accurately before it is criticised, because the criticism only lands if the description is fair.

Visa Intelligent Commerce and the Trusted Agent Protocol

Visa announced Intelligent Commerce in April 2025, extending its tokenization infrastructure so that an AI agent can be issued a credential derived from a cardholder's card rather than handling the card number itself (Visa corporate announcements). In October 2025 it followed with the Trusted Agent Protocol, which gives merchants a way to recognise that an incoming request comes from a registered agent rather than from an unidentified script.

This solves a real and previously unsolved problem. Before it, a merchant faced with automated traffic had two bad options: block it and lose legitimate customers whose assistants were shopping for them, or allow it and lose the ability to distinguish a customer's assistant from a card testing bot. Token binding plus agent registration gives the merchant a third option. That is genuine progress and it took serious engineering.

Mastercard Agent Pay

Mastercard announced Agent Pay in April 2025, introducing what it describes as Agentic Tokens carrying verifiable intent, so that a payment made by an agent carries a machine readable statement of what the agent was permitted to do (Mastercard newsroom). In March 2026 Mastercard and Santander completed what was reported as Europe's first live agent payment on the scheme.

Again, credit where it is owed. The concept of carrying the permission alongside the payment, rather than leaving the permission implicit in a platform's database, is the correct architectural instinct. It moves the authorisation from something you have to ask a platform about into something that travels with the transaction.

The Agent Payments Protocol

Google published the Agent Payments Protocol, generally called AP2, and contributed it toward work in the FIDO Alliance with a large roster of partners including payment networks and processors (ap2-protocol.org). AP2 formalises the idea of a Mandate: a signed object expressing what a user authorised an agent to do, which merchants and payment providers can verify rather than trust.

AP2 is the most careful piece of thinking in this area. It separates the intent mandate, describing what the user wants, from the cart mandate, describing what is actually being bought, and it recognises that these can diverge. That distinction is exactly right, and we have written about the specifics elsewhere in our look at where AP2 leaves the human.

Stripe and the processor layer

Stripe shipped agent oriented payment primitives including shared payment tokens, which bridge the platform and network models so that a developer building an agent does not have to implement each network programme separately (Stripe documentation). Processors doing the integration work is what turns a network programme into something a startup can actually use.

So what do all four have in common?

Every one of them is excellent at binding a payment instrument to an agent, and every one of them takes the human's authorisation as an input rather than producing it. The mandate says what the user authorised. It does not, and was not designed to, establish that the user authorised it.

What is the difference between an authentic document and authentic consent?

This is the intellectual centre of the problem and it is worth going slowly, because the two things sound identical and are not.

Think about a notary. When a notary notarises your signature on a document, they are not attesting that the document is true, or wise, or a good deal for you. They are attesting to something much narrower and much more useful: that a person, whose identity they checked, signed this specific document in front of them at this specific time. The document's authenticity and the signing's authenticity are separate facts, and the notary supplies the second one.

Now imagine a notary who works entirely by post. Documents arrive already signed. The notary checks that the paper is genuine, that the seal matches, that nothing has been altered since it was sealed, and stamps it. Everything the notary attests is true. The stamp is worth something. But the notary has not seen anyone sign anything, and if you ask whether the person named actually signed it, the honest answer is that the stamp does not speak to that.

A signed mandate is the second notary. The signature proves the mandate was issued by a particular party and has not been altered since. That is real and valuable: it stops a merchant from inventing a permission that was never granted, and it stops an agent from quietly expanding its own limits. It is a document integrity property.

Consent authenticity is a different property. It asks whether a specific living person formed the intention the document describes, at the moment the document says they did. No amount of integrity on the document establishes it, because the document's integrity is downstream of the moment of consent. If the consent moment was a click in a hijacked session, the mandate faithfully and verifiably records an intention that was never formed by the person it names.

Put it in one line: signing a statement of intent proves the statement, not the intent.

Why does a click in a session not prove a human agreed?

Because a session is not a person. A session is a credential the server accepts as standing in for a person, and it can be stolen with tooling that is now sold as a service.

We have gone through the mechanics of this at length in the piece on adversary in the middle session theft, and the summary is short. An attacker proxies the real login page. The victim authenticates against the genuine identity provider, with real multi factor authentication, and the attacker captures the resulting session token. From that point forward the attacker does not need the password, does not need the second factor, and does not trigger a new login. They hold the thing the application actually checks.

Now apply that to agentic consent. The consent screen sits inside the platform's authenticated web application. It is protected by whatever protects that application, which is the session. So the consent screen inherits the security of the session and nothing more. An attacker with the session can open the agent settings, authorise an agent they control, set a generous limit, and walk away with a valid mandate that will verify perfectly for ninety days.

There is a second, quieter version of the same problem that does not involve any attacker at all. An agent operating a browser on the user's behalf is, from the application's point of view, inside the session too. If the consent step is a page with a button, and the agent can reach that page, the agent can grant itself permission. That is the approval theater pattern: any control an agent can reach is a control an agent can satisfy.

What happens when the customer disputes an agent purchase?

Here is where the abstraction becomes money.

In the United States, Regulation E governs electronic fund transfers and gives consumers strong protection against unauthorised transfers, with the burden falling substantially on the institution (Consumer Financial Protection Bureau, 12 CFR Part 1005). In the European Union, PSD2 and its regulatory technical standards impose strong customer authentication and dynamic linking requirements, tying an authentication to a specific amount and payee. Legal commentators have flagged, repeatedly through 2025 and 2026, that neither framework was drafted with a delegated software agent in mind, and that whether an agent's action counts as authorised by the consumer is genuinely unsettled.

The practical consequence is that a dispute over an agent purchase is decided on evidence, and the evidence available today has a structural defect: all of it was generated by the parties with an interest in the outcome.

The merchant produces logs. Those are merchant logs. The platform produces a consent record. That is a platform record. The agent produces a signature under a mandate the platform issued. That is a platform assertion, signed with a platform controlled key. The cardholder produces a memory, which is the weakest evidence of all and also the only piece that comes from the human whose intent is in question.

We wrote about the merchant side of this in the piece on agentic chargeback liability, and the same structural point appears from the consumer side in the piece on first party misuse. The pattern is identical: when the only evidence is self generated, disputes are settled by rules rather than facts, and rules can change with a bulletin.

Consumer research has picked up the resulting unease. Riskified's consumer work in early 2026 reported that a substantial share of consumers were uncomfortable with the idea of agents making purchases on their behalf, and while survey numbers on new behaviours should be treated as directional, the direction is unambiguous. People are willing to let software shop for them and unwilling to carry the risk of being unable to prove they did not agree to something.

What would a human mandate receipt actually look like?

The missing artifact is not complicated. It is a signature, produced on the cardholder's own enrolled device, over the exact mandate the agent will operate under. Call it a human mandate receipt.

Start with the mandate itself. This is the object the networks and AP2 already conceive of, expressed here in a neutral form. Amounts are in minor units to avoid the classic rounding argument.

{
  "mandate_id":  "mnd_01J9X4K2QF",
  "issued_at":   "2026-09-14T09:12:44Z",
  "expires_at":  "2026-12-14T09:12:44Z",
  "principal":   "did:manav:z6Mk...9Xr",
  "delegate": {
    "agent_id":     "agent:acme-assistant:v4",
    "delegate_key": "ed25519:4kQ...2Bn"
  },
  "scope": {
    "actions":             ["purchase"],
    "merchant_categories": ["5812", "4722"],
    "currency":            "USD"
  },
  "constraints": {
    "max_per_transaction": 50000,
    "max_total":           250000,
    "step_up_above":       25000,
    "region":              ["US", "CA"]
  },
  "revocation_id": "rev_01J9X4K2QG"
}

Read the constraints block carefully, because it is where the design earns its keep. The cardholder is not agreeing to let an agent spend money. They are agreeing to a specific envelope: five hundred dollars per transaction, two thousand five hundred in total, restaurants and airlines only, in the United States and Canada, until the fourteenth of December, and anything above two hundred and fifty dollars needs a fresh confirmation. That is a set of decisions a person can actually make and understand.

Now the receipt. This is what does not exist today.

{
  "mandate_hash": "sha256:9f2c8b1e...4a77",
  "signed_at":    "2026-09-14T09:12:44Z",
  "authenticator": {
    "credential_id":     "AXk9...",
    "user_verification": true,
    "liveness":          "companion-device"
  },
  "signature": "ed25519:8Jd...",
  "key_ref":   "https://manav.id/.well-known/manav-keys#2026-09"
}

Three properties matter here and each one is doing specific work.

First, mandate_hash binds the receipt to this exact mandate. Change a single digit of a spending limit and the hash changes and the receipt no longer applies. The signature is not over a general permission to use an agent, it is over these limits.

Second, user_verification records that the authenticator required the human to present something, a fingerprint, a face, a device passcode, rather than merely being present. This is the standard WebAuthn user verification flag and it is the difference between the device signing and the human signing.

Third, key_ref points at a published key. Anyone can fetch it. Verification requires no call to us, no API key, no account. The receipt is checkable in ten years by a party we have never heard of, which is the property that makes it evidence rather than a service.

How would an issuer or a merchant verify one?

The verification is deliberately boring, which is the point. Boring verification is verification that gets implemented correctly.

def verify_mandate_receipt(mandate, receipt, published_keys, now):
    canonical = canonicalize(mandate)            # deterministic JSON, RFC 8785
    if sha256(canonical) != receipt["mandate_hash"]:
        raise Invalid("receipt does not cover this mandate")

    if not receipt["authenticator"]["user_verification"]:
        raise Invalid("authenticator did not verify the human")

    key = published_keys[receipt["key_ref"]]     # fetched once, cached
    if not ed25519_verify(key, canonical, receipt["signature"]):
        raise Invalid("signature does not verify")

    if now > parse(mandate["expires_at"]):
        raise Expired(mandate["mandate_id"])

    return Verified(principal   = mandate["principal"],
                    constraints = mandate["constraints"])

Then, at the moment of a specific purchase, the agent's own signature is checked against the envelope the human signed:

def authorize_purchase(purchase, mandate, receipt):
    v = verify_mandate_receipt(mandate, receipt, KEYS, now())

    if purchase["amount"] > v.constraints["max_per_transaction"]:
        return DECLINE("exceeds per transaction limit")
    if purchase["mcc"] not in mandate["scope"]["merchant_categories"]:
        return DECLINE("merchant category outside mandate")
    if purchase["amount"] > v.constraints["step_up_above"]:
        return STEP_UP(reason="above threshold the human set")

    return APPROVE(evidence=[receipt, purchase["agent_signature"]])

Notice what the STEP_UP branch does. The cardholder decided, at mandate time, the amount above which they want to be asked again. The system is not guessing at a risk threshold on their behalf. It is enforcing a threshold the human chose, which is a different and much more defensible thing to tell a customer during a dispute.

The chaining model here is the same one described in the piece on delegation chain depth: the human signs an envelope, the agent signs each action inside it, and a verifier walks from the action back to the human without contacting anyone.

What does each artifact in the chain actually prove?

It is worth laying these side by side, because the industry conversation tends to treat them as interchangeable and they are not.

The last row is deliberately honest. A receipt is proof of authorisation, not proof of good judgment, and any vendor telling you otherwise is selling something.

Who wins the chargeback?

This is the question that will actually drive adoption, because payment infrastructure does not change on the strength of an architectural argument. It changes when someone is losing money in a way a change would stop.

Work through the four cases.

The customer genuinely did not authorise it. Their account was compromised, an attacker created the mandate, and an agent spent within it. Today the merchant holds a valid token and a consent record, the customer holds a denial, and the issuer generally eats the loss under Regulation E. With receipts, there is either no receipt, in which case the absence is itself informative, or there is a receipt bound to an authenticator the cardholder can demonstrate is not theirs. Either way the fact pattern becomes checkable.

The customer authorised it and forgot. This is more common than the industry likes to admit and it is the heart of first party misuse. Today it is unfalsifiable. With a receipt, the issuer can show the customer the exact limits they signed and when. Most of these disputes end at that point, which is better for everyone including the customer, who learns something about their own settings.

The agent exceeded what the customer intended. The customer meant groceries and the agent bought a television. With a mandate carrying merchant categories and per transaction caps, this either did not happen because the constraint blocked it, or it happened outside the mandate, which makes it the platform's problem rather than an ambiguity.

The customer authorised it and objects to the outcome. The dinner was bad, the flight was cancelled. This is an ordinary commercial dispute and no identity technology touches it. Saying so plainly matters, because a large fraction of what gets called agentic dispute risk is actually just commerce.

The pattern across all four is that the receipt does not decide who is right. It makes the facts determinable, which collapses the expensive middle where both parties are asserting and neither can demonstrate.

Honest limits

Several, and they are not small.

This requires network and issuer participation. A receipt nobody accepts is a receipt. The artifact only has dispute value if the party adjudicating the dispute will look at it, and that means network rule changes, which no vendor can make unilaterally. Anyone claiming to have solved agentic dispute liability by shipping a library is overstating the case, and we are not going to.

Manav has not shipped an AP2 adapter or card network integration. The delegation chains, the per action signatures and the offline verifiable receipts are shipped and in production use. Mapping them onto AP2 mandate structures and network agentic token metadata is design work we have done and integration work we have not. Treat this piece as a proposal with running parts, not a product announcement.

A signature does not survive a compromised device. If the phone that holds the key is fully compromised, the attacker can sign. This raises the cost of the attack from stealing a cookie to compromising a specific person's hardware, which is a very large increase, and it is not infinity.

Enrollment is the remaining trust bottleneck. Someone, once, has to establish that this key belongs to this cardholder. Get that wrong and everything downstream is confidently wrong. This is the same bottleneck described in the piece on injection attacks against identity verification, and it is genuinely hard.

Consent fatigue is real. If every purchase requires a signature, people will stop reading and start tapping, and you have rebuilt cookie banners with money attached. The entire design depends on signing once per envelope rather than once per purchase, and on choosing step up thresholds that trigger rarely enough to stay meaningful.

What to do this week

Concrete steps, for whichever seat you are in.

1. Write down what your consent step actually proves. Not what it is called. If it is a button inside an authenticated session, write that sentence down and show it to whoever owns dispute policy.
2. Find out who holds the key that signs your mandates. If the answer is the platform, then your mandates are platform assertions, which is fine as long as everyone knows it.
3. Ask your dispute team what evidence they currently submit for an agent initiated transaction, and ask who generated each item on the list. The exercise is short and clarifying.
4. Model the four dispute cases above against your current evidence pack. For each, decide whether you could demonstrate the fact pattern or merely assert it.
5. Define the constraint vocabulary you would want a customer to be able to sign: per transaction cap, cumulative cap, merchant categories, geography, expiry, step up threshold. Getting this vocabulary right is most of the design.
6. Pick a step up threshold and defend it. If you cannot explain to a customer why that number, the customer will not accept it during a dispute.
7. Read the AP2 mandate specification and decide which fields you would want a human presence attestation to cover if you were to attach one.
8. Run a pilot on one merchant category. Travel is a good candidate: high value, high dispute rate, and customers already expect a confirmation step.

If you want to see what a device bound signature over a specific payload feels like in practice, the signing demo takes about thirty seconds, and the developer documentation covers the receipt format and offline verification.

Frequently asked questions

Do Visa and Mastercard agentic tokens prove the customer authorised the purchase? No. They prove that a registered agent holds a payment credential derived from a specific cardholder's card, and that the agent is operating under a mandate. Proving the human authorised it requires a signature produced on the cardholder's own enrolled device, bound to the mandate, and carried with the transaction as evidence.

What is verifiable intent in Mastercard Agent Pay? It refers to carrying a machine readable, signed statement of what the agent was permitted to do alongside the payment, rather than leaving that permission implicit in a platform database. It makes the permission verifiable. It is a separate question from whether the human who supposedly granted the permission was actually present when it was granted.

How do I dispute a purchase my AI agent made? Through the ordinary dispute process with your issuer. Regulation E in the United States gives strong protection for unauthorised electronic transfers. The practical difficulty is that whether an agent's action counts as authorised by you is unsettled, and the evidence on both sides is usually generated by the merchant or the platform rather than by you.

Does AP2 solve the human presence problem? AP2 does the hard and valuable work of formalising mandates and separating intent from cart contents. It does not itself guarantee that a live, unique human was present when a mandate was created, because that depends on how the issuing party captured consent. A human presence attestation attached to mandate issuance would close the gap.

Would this mean signing every purchase? No, and that would be a bad design. The human signs an envelope, with limits and an expiry, and the agent signs each purchase inside it. A fresh human signature is required only when the agent attempts something above a threshold the human chose, or outside the scope they granted.

Is this the same as 3-D Secure? No. 3DS authenticates a cardholder within a payment flow and shifts liability accordingly. In a delegated flow the challenge is typically answered by the platform or routed around, and 3DS was never designed to establish that a third party agent is acting on a human's current instruction. The two compose rather than compete.

What happens if the customer loses their device? The mandate is revocable by the cardholder or issuer using the revocation identifier, and re-enrollment follows the ordinary recovery path. Recovery is a genuinely hard part of any device bound design, and it deserves the same scrutiny as the signing path.

Sources

1. Visa, corporate newsroom, on Intelligent Commerce and the Trusted Agent Protocol: usa.visa.com/about-visa/newsroom.html
2. Mastercard, newsroom, on Agent Pay and agentic tokens: mastercard.com/news
3. Agent Payments Protocol (AP2) specification: ap2-protocol.org
4. FIDO Alliance: fidoalliance.org
5. Stripe documentation on agentic payment primitives: docs.stripe.com
6. Consumer Financial Protection Bureau, Regulation E, 12 CFR Part 1005: consumerfinance.gov/rules-policy/regulations/1005
7. European Banking Authority, regulatory technical standards on strong customer authentication: eba.europa.eu
8. EMVCo, 3-D Secure specifications: emvco.com
9. Riskified consumer research on agentic commerce: riskified.com
10. W3C Web Authentication, user verification: w3.org/TR/webauthn-3

Signing a statement of intent proves the statement, not the intent.