Mastercard, Verifiable Intent: maintained by Mastercard, contributed to the FIDO Alliance on 2026-04-28
Status
Pilot Mastercard has enabled issuers at network level in several regions (all European issuers by 2026-06-02), but the transactions it names are pilots, controlled trials or first transactions, and it publishes no volume data. The developer documentation went live as an early preview on 2025-10-16.
Latest version
No program version numbers. Verifiable Intent 0.1 (tag v0.1.0 on 2026-03-05; breaking renames on main on 2026-04-20 under the same label),
State as of
Verified (verified under 30 days ago)
Card network
Multi-rail
Payment credential (primary layer)
Identity and trust
Intent and authorization
Checkout and orders
A. TL;DR and key facts
Mastercard Agent Pay is a proprietary card-network program. Registered agents get scoped agentic tokens, sign their web requests, and can carry Verifiable Intent proof of what the user approved. Named transactions are pilots.
Why it exists
A card network cannot tell an agent purchase from a human one, or from fraud, when the agent types a stolen-looking card number into a form. Agent Pay gives the network a way to know which agent is buying, under whose authority and within which limits: agents register and are certified, they receive tokens instead of card numbers, the tokens carry the consumer's limits, and merchants can check a signature on the agent's web request. Verifiable Intent adds a signed record of what the user approved, so issuers and merchants have evidence when a purchase is questioned.
What it is not
Not AP2. AP2 is Google's open protocol; Agent Pay is Mastercard's card-network program. They meet only through Verifiable Intent, which reuses AP2's mandate type strings. Source [1, 5, 20, 21]
Not the same thing as a Visa agentic token. Both networks use the words, but Mastercard Agentic Tokens and Visa's agentic network tokens are separate products from separate networks. Source [23]
Not an open protocol. Mastercard sets the rules alone, and the Acceptance Framework specification it refers developers to is not public. Only Verifiable Intent is open. Source [1, 2, 3, 6, 10]
Not at scale yet. The transactions Mastercard names are pilots, controlled trials or first transactions, and it publishes no volume or value figures. Source [12, 13, 14, 16, 17]
Mastercard's agentic-token pages say the tokens build on Mastercard tokenization and do not name MDES; developer pages name MDES only for Virtual Card Tokens and Token Connect enrollment. Source [1, 8, 26, 27, 28]
Not a new liability regime. Standard chargeback rights apply, and no agent-specific reason code, liability shift or interchange category has been published. Source [8, 17, 19]
Not a payments SDK. The Mastercard Developers Agent Toolkit is an MCP server that reads documentation and makes no payment calls. Source [29, 30, 31]
Key facts as of 2026-10-11
Steward
Mastercard (proprietary program); Verifiable Intent maintained by Mastercard and contributed to the FIDO Alliance Source [1, 2, 3, 4, 5]
What it is
A card-network program, not an open protocol and not AP2; the Acceptance Framework specification is not public Source [1, 2, 5, 6]
First announced
2025-04-29, as the Agentic Payments Program with Mastercard Agentic Tokens Source [1]
Credential
Agentic tokens built on Mastercard tokenization, issued only to registered agents; single-use, merchant-specific or time-limited Source [1, 7, 8]
Agent identity
RFC 9421 signed requests with tag Agent-pay-auth, checked against a Mastercard key directory whose public location is unknown Source [8]
Intent proof
Verifiable Intent: SD-JWT layers L1, L2 and L3 with ES256; label 0.1, no commits since 2026-04-20 Source [3, 9, 10, 11]
Status
Pilots or first transactions; network-level enablement in Europe since 2026-06-02; no public volume data Source [12, 13, 14, 15, 16, 17]
Rails
Card rails; Agent Pay for Machines (2026-06-10) adds settlement across cards, accounts and stablecoins Source [18]
Costs
No agent-specific price, interchange, liability rule or reason code published; card economics unchanged Source [8, 17, 19]
Composes with
AP2 (shared mandate types via VI), UCP (VI in the AP2 extension), ACP (via Stripe SPTs), MPP (Tempo's statement), x402 (premier member) Source [18, 20, 21, 22, 23, 24, 25]
How to read this explanation
ELI5 is a short plain-language version. Practitioner is the full text. Spec-deep adds field tables and wire examples. STE shows the Simplified Technical English version instead.
B. Detailed explanation
ELI5 mode: plain-language version only.
Practitioner mode: the full explanation.
Spec-deep mode: the full explanation plus 1 field table or wire example.
STE mode: section B is hidden; the Simplified Technical English version (section D) is shown first.
Imagine you give a helper robot permission to buy movie tickets for you. The shop does not know the robot, and robots that sneak around shops are often up to no good. So the robot first goes to the card company’s office, shows who built it, passes a test, and gets a name badge. The card company keeps a list of every robot with a badge.
When you say yes, the card company gives the robot a special stand-in card. It is not your real card. It only works for the shops, the amounts and the days you allowed, and some of these cards work only once. If the robot loses it, a thief gets very little.
At the shop door the robot shows its badge, and the door guard checks it against the card company’s list. Then the robot pays with the stand-in card at the normal till, just like a person. The bank that gave you your real card still makes the final yes or no.
There is also an optional signed note, a bit like a permission slip you sign, that says exactly what you allowed: which shops, how much in total, and until when. The robot carries the slip, and the shop and the card company can both read the parts meant for them and check that nobody changed them.
That is Mastercard Agent Pay. The badge is a signature on the robot’s web requests, the stand-in card is an , and the permission slip is called . Most of the purchases so far have been careful tests with a few banks, not everyday shopping.
Mastercard Agent Pay answers a card network’s question: when software buys something, which agent is it, who allowed it, and within which limits? Agent Pay is a proprietary Mastercard program, not an open protocol and not Google’s AP2.Source [1, 2, 5] Only registered agents can transact: each agent passes a security review, joins a , and registers a public key.Source [7, 8] The consumer authorizes the agent, and the network issues an agentic token built on Mastercard tokenization, which may be single-use, merchant-specific or time-limited.Source [1, 8, 26, 27, 28] At the merchant, the agent signs its web requests with and the Agent-pay-auth, and the edge or the merchant checks the signature against a Mastercard key directory.Source [8, 35] The agent then pays with the token through the existing checkout and card rails, and the issuer still decides.Source [8, 9] Verifiable Intent, a separate open specification, adds signed evidence of what the user approved.Source [3, 9, 10] What Agent Pay does not give you yet: a public specification, a key directory URL that resolves, agent-specific dispute rules, or any volume data.Source [2, 6, 8, 16, 17, 19]
Problem and design goals
Mastercard announced Agent Pay on 2025-04-29 as its Agentic Payments Program, introducing Mastercard Agentic Tokens.Source [1] The launch release ties those tokens to tokenization Mastercard already runs for contactless payments, card-on-file and Mastercard Payment .Source [1] It sets three goals. Agents must be registered and verified before they pay for anyone, and every party in the chain must be able to recognize an agent transaction. There must also be a process to clarify agent transactions a cardholder does not recognize.Source [1]
The problem is familiar to anyone who runs card fraud. An agent typing a card number into a web form looks like a bot, and a bot with a card number looks like fraud. Agent Pay replaces the card number with a token that only a registered agent can obtain, so the network can mark the transaction as agentic and the merchant never handles the real card.Source [8] Mastercard says agents may not even use a card the consumer already stored at the merchant, because the network could not then see that an agent was involved.Source [8]
Two things to keep apart from the start. The word “agentic token” means different things at Mastercard and at Visa: they are separate products on separate networks.Source [23] And Mastercard’s pages describe the tokens as built on Mastercard tokenization; the launch, regional and developer-guide pages do not name (Mastercard Digital Enablement Service). Developer pages mention it only for Virtual Card Tokens and Token Connect enrollment, so this page does not call agentic tokens MDES tokens.Source [1, 8, 26, 27, 28]
Actors and roles
The program has seven roles, all described in Mastercard’s merchant-facing developer guides rather than in a specification.Source [1, 2] The consumer authenticates with the agent platform, authorizes purchases and sets limits; regional releases name Mastercard Payment Passkeys for that step.Source [12, 15] The agent platform registers its agent and key, passes certification, requests tokens and signs its web requests.Source [7, 8] Mastercard registers and certifies agents, keeps the trusted agent lists, issues and detokenizes tokens, and since 2026-09-30 tests a for agent-initiated transactions in the US.Source [7, 16]
On the selling side, merchants register through their acquirer or PSP (payment service provider), not with Mastercard directly.Source [7] They accept tokens in existing forms or through APIs, and they can verify agent signatures in their own backend or leave that to a CDN (content delivery network).Source [8] Cloudflare describes doing exactly that at the edge for both Agent Pay and Visa’s Trusted Agent Protocol.Source [35] The issuer keeps the final authorization decision.Source [9] Since 2026-09-30, Skyfire is named as a partner that helps recognize trusted agents.Source [16]
Verifiable Intent defines its own roles. An issuer signs the first credential (a bank, or Mastercard acting for the bank), and a credential provider hosts the user’s wallet; the user, the agent, the merchant and the payment network as verifier complete the set.Source [3, 9] The network checks the chain before authorization, but the issuer still decides.Source [9]
Core objects
Agent Pay’s objects come in two kinds, and the difference matters. The program objects below are named in Mastercard’s developer guides, which publish field names but no schema files, no types and no required flags; the guides refer readers to the , which is not public.Source [2, 6] Verifiable Intent objects, by contrast, come from an open specification with normative field tables.Source [3, 9, 20]
The first program object is the signature on the agent’s HTTP request. Signature-Input carries keyid, alg, created, expires, nonce and tag.Source [8] Mastercard’s guide gives the Mastercard tag as Agent-pay-auth, while its testing glossary writes agent-pay-auth in lower case; the letter case is unresolved.Source [8, 36] The same guide says Visa uses agent-browser-auth and agent-payer-auth, and generic agents such as ChatGPT use web-bot-auth.Source [8]
The second is the token itself. At Levels 1 and 2 it looks like a card number to the merchant.Source [8] For guest checkouts with a simple form, Mastercard points integrators to Mastercard Virtual Card Tokens, which come with a one-time for the security code field.Source [37] A DTVC is a security code issued with a Virtual Card Token, not an agentic token; Mastercard’s pages expand it both as Dynamic Token Validation Code and as Dynamic Token Verification Code.Source [28, 37, 38] At Level 3, the Mastercard payload contains a DSRP () and card metadata.Source [2]
Level 2 adds two signed objects in the request body. The object carries mastercardIdToken, a Mastercard-issued JWT (JSON Web Token) that identifies the consumer and is compatible with OpenID Connect ID Tokens.Source [6] The Payment Data object carries paymentData, a hash of the tokenized payment data typed into the form, signed with the same key and as the HTTP signature.Source [6] Level 3 adds the Intent API: the agent registers the consumer’s intent and receives an intentId with tokenized credentials.Source [2]
Verifiable Intent is a chain of (Selective Disclosure for JWTs) credentials.Source [3, 9, 39] L1 is signed by the issuer and binds the user’s key; L2 is signed by the user and holds mandates; in Autonomous mode, L3a and L3b are signed by the agent.Source [20] Each layer binds the key that signs the next through the cnf claim.Source [9, 40]
Field tables. Program objects follow Mastercard’s developer guides as read on 2026-10-11; these guides are unversioned and publish no schema, so “Required” means only that the guide lists the field. Verifiable Intent tables follow spec/credential-format.md and spec/constraints.md on main at commit 356c296 (2026-04-20), labeled 0.1. At tag v0.1.0 several names were different (see Versioning). Descriptions are paraphrased.
Signature-Input parameters for Agent Pay requests (no public schema)Spec version Agent Pay developer guides, unversioned, read 2026-10-11
The main flow on this page is a Level 1 purchase with edge verification, because it is the path Mastercard calls no-code for merchants.Source [41, 42] Before it starts, the agent developer has registered a key and been certified, and the consumer has authorized the agent.Source [7, 8]
The agent requests a merchant page and signs the request with RFC 9421 HTTP Message Signatures. Signature-Input lists the , in Mastercard’s example @authority and @path, plus keyid, created, expires, nonce, alg and the tag.Source [8, 43]
The CDN or the merchant backend fetches the public key for keyid from the directory Mastercard hosts.Source [8, 35] Cloudflare names no Mastercard directory URL, and the only host in Mastercard’s example, agentpay-key-directory.mastercard.com, did not resolve on 2026-10-11.Source [8, 35]
The verifier checks that both headers are present, that created and expires bracket the current time, that the nonce is unused and the tag is valid, then rebuilds the and verifies the Ed25519 signature.Source [35] The guide also lists ecdsa-p256-sha256 as an example algorithm.Source [8]
The agent types the token into the normal card form. To the merchant it looks like any card number, and PCI (Payment Card Industry) scope does not change.Source [8]
The merchant’s processor sends the authorization. The network detokenizes and routes to the issuer.Source [8] Stripe, which carries these tokens, says the network maps them to the latest funding PAN (primary account number) and includes additional information in the authorization message.Source [23]
The issuer approves or declines. Standard chargeback rights apply afterwards.Source [8]
Mastercard’s decision table for step 3 is short: a request without Signature-Input and a scheme tag goes to the ordinary bot policy, and a missing field or a key not found in the directory means block.Source [8] One oddity is worth knowing before you copy code: the Level 1 guide’s sample verifier accepts only the two Visa tags, not the Mastercard tag.Source [8]
The DTVC path differs only in step 4. After user validation and consent, the integrator gets a Virtual Card Token, its expiry and a fresh DTVC, and the agent types all three into the form. Mastercard validates the DTVC during authorization and tells the issuer whether it did so.Source [37, 38] Level 3 replaces the form with a merchant API: the agent registers intent, sends the intentId and credentials, and the merchant checks that intentStatus is ACTIVE, that the total does not exceed orderTotalAmount and that srcDpaId matches.Source [2] Mastercard itself calls intent exchange between agent and merchant future facing.Source [7]
In Verifiable Intent’s Autonomous mode, the user signs L2 with open mandates that carry and the agent’s key, and leaves.Source [20] Later the agent signs L3a for the network and L3b for the merchant, and L3a’s transaction_id must equal L3b’s checkout_hash.Source [9, 20] The network checks the payment constraints, allows one L3 pair per mandate pair and tracks cumulative spend.Source [9, 44]
Lifecycle and states
Mastercard publishes no state model for agentic tokens. The guides describe a sequence (agent registered, certified, consumer authorized, token provisioned, token used, authorized or declined) and token limits by merchant, amount or time window.Source [7, 8] The state machine on this page uses descriptive labels for that sequence and marks expiry as inferred; there is no public revocation API, suspend state or lifecycle endpoint for agentic tokens.Source [27, 44, 45]
The Intent API has more structure. orderExecutionType is IMMEDIATE or DEFERRED, orderExpiry is in UTC epoch seconds, and validation needs intentStatusACTIVE.Source [2] Other status values are not published.Source [2, 6]
Verifiable Intent recommends lifetimes per layer: L1 about one year, L2 Immediate about 15 minutes, L2 Autonomous 24 hours to 30 days (never beyond L1), and L3 five minutes. Only the L3 ceiling of one hour and the rule that Autonomous L2 must not outlive L1 are hard limits.Source [20] For Autonomous mandates the network must keep state, because budgets and occurrence counts cannot be enforced by cryptography alone.Source [44, 46] The spec says networks must hold that state but defines no API for it.Source [9, 44]
Security and trust model (summary)
Mastercard’s security claims rest on five things. Only registered and certified agents transact, agents never see card numbers, and tokens are scoped. Agent requests are signed with a nonce and a short window, and consumers authenticate with passkeys in the live pilots.Source [7, 8, 12, 15, 35] Section H covers the threats in detail.
The weak points are the parts that are not public. The key directory location is unknown, the full Acceptance Framework is unpublished, and Mastercard’s 2026-09-30 probability score for AI-initiated transactions implies that agent involvement is not always marked reliably in authorization traffic.Source [2, 6, 8, 16] The Level 1 and DTVC paths also keep agents filling human checkout forms, so merchants still see agent traffic as page scraping with a signature attached.Source [8, 37]
Verifiable Intent has a written threat model covering replay, cross-merchant replay, constraint stripping, checkout and payment mismatch, algorithm confusion, clock skew, disclosure withholding, type confusion and split-agent attacks.Source [44] It is also candid about gaps: no revocation protocol in 0.1, an always-visible sub that links a user’s transactions for a year, and reference keys suitable only for testing.Source [44] An open issue reports that L2 lists each mandate digest twice, which RFC 9901 says verifiers must reject.Source [20, 39, 47] No CVE or published attack specific to Agent Pay was found.Source [8, 11]
Versioning and governance
Agent Pay has no version numbers, no public changelog and no governance body; Mastercard changes the program alone.Source [1, 2] Its history is a sequence of announcements, regional rollouts and sub-brands. The developer documentation went live on Mastercard Developers on 2025-10-16 “for early preview”.Source [27] The current Agent Pay page could not be read: its markdown source returns 404 and the HTML is a JavaScript shell.Source [2, 6, 8, 27]
Date
Event
Status as stated
Source
2025-04-29
Launch with Microsoft, IBM, Braintree and Checkout.com
Read the status column carefully: the named transactions are pilots or first transactions, and Mastercard publishes no volume or value figures.Source [12, 13, 14, 16, 17] The US plan to enable all issuers by November 2025 is not confirmed complete by any later primary source found.Source [42] No white paper for the Trust Framework was found.Source [16]
Verifiable Intent is the only versioned artifact, and its version history needs care. The CHANGELOG dates 0.1.0 to 2026-02-19, the spec documents say 0.1-draft dated 2026-02-18, and the tag v0.1.0 points to the initial commit of 2026-03-05.Source [9, 50, 51] Pull request 23, merged on 2026-04-20, renamed constraint keys (for example payment.amount became mandate.payment.amount_range), added .1 suffixes to mandate types and moved cnf.kid to cnf.jwk.kid, all without a new version number.Source [34, 46, 52] Field names on this page follow main; code written against tag v0.1.0 uses the older names.Source [46, 52, 53] The repository has had no commits since 2026-04-20.Source [10, 11] Mastercard contributed VI to the on 2026-04-28, where it goes to the existing Payments Technical Working Group.Source [4, 5, 54]
Extensibility
The program offers few public extension points. The documented ones are the three integration levels, the two body objects at Level 2, and the Intent API at Level 3.Source [2, 6, 8] Sub-brands extend the program’s reach rather than its wire format: Agent Pay for Machines adds credentialing, permissioning, transacting and settlement across cards, accounts and , and the Trust Framework groups identity, intent, controls, execution and intelligence.Source [16, 18]
Verifiable Intent is built to be extended. It has a registry of eight constraint types, a STRICT and a PERMISSIVE validation mode, and an optional agent_attestation claim with no scheme defined yet.Source [9, 46] Verifiers must still reject open mandates that contain unknown constraint types, whatever the mode.Source [46] The CHANGELOG still says five constraint types while the spec registers eight.Source [46, 50]
How it composes with the other seven
Agent Pay touches the other protocols mostly through Verifiable Intent and through partners. On main, VI uses the same four mandate vct values as AP2 v0.2, with aligned constraint meanings but different key prefixes: AP2 writes payment.amount_range, VI writes mandate.payment.amount_range.Source [20, 21, 46] VI says its credentials can ride in UCP’s AP2 mandate extension; UCP renamed that extension to dev.ucp.common.payment.ap2_mandate in v2026-08-25.Source [22, 55, 56] Stripe’s Shared Payment Tokens (SPTs) carry Mastercard agentic network tokens, so an ACP checkout processed by Stripe can use an Agent Pay token.Source [23] Visa TAP uses the same edge pattern with different tags and a different directory.Source [35] Section P has the details.
Limitations and open issues
The Acceptance Framework, the token lifecycle and the Intent API schema are not public, so independent implementers cannot build against them.Source [2, 6]
The key directory location is unknown, and the tag’s letter case differs between two Mastercard pages.Source [8, 36]
No agent-specific dispute reason codes, liability shift or interchange categories have been published.Source [17, 19]
Verifiable Intent has no revocation protocol, an unresolved duplicate-digest conflict with RFC 9901, and no commits since 2026-04-20.Source [10, 11, 39, 44, 47]
Mastercard says VI is being embedded in the payment flow, but no public document shows a VI chain checked in a live authorization.Source [12, 33]
Networks and are still developing 3DS (3-D Secure) support and decoupled authentication for agentic flows, per Mastercard’s own guide.Source [8]
What changed in 2025 and 2026
The 2025 work set the program up: the launch in April, the US plan in September, the Acceptance Framework in October, the PayPal wallet integration on 2025-10-27, and the first agentic transaction reported on the Q3 earnings call.Source [1, 26, 41, 42, 48, 57] 2026 brought regional pilots, Stripe SPT support on 2026-03-03, Verifiable Intent on 2026-03-05 and its FIDO contribution on 2026-04-28.Source [4, 5, 10, 23, 33] Mastercard then enabled all European issuers on 2026-06-02, launched Agent Pay for Machines on 2026-06-10 with 32 named participants, and named the Trust Framework on 2026-09-30.Source [15, 16, 18] EMVCo’s draft agentic payments framework of 2026-09-01 names VI as an existing cryptographic solution its Intent Services would complement.Source [58, 59]
C. Diagrams
Main flow: Agent Pay Level 1 purchase with edge verification
A registered agent signs its web requests with RFC 9421 and the tag Agent-pay-auth. The CDN or merchant checks the signature against the Mastercard key directory, the agent types its agentic token into the normal card form, and the authorization runs over the existing card rails. Mastercard publishes no wire schema for the network leg.
Agent platform
CDN or edge (Cloudflare)
Mastercard key directory
Merchant
Acquirer or PSP
Mastercard network
Issuer
1
Crosses a trust boundary
Use the left and right arrow keys to step, space to play or pause, Home and End to jump.
Step 1 of 9Agent platform toto CDN or edge (Cloudflare)
Signed GET with tag Agent-pay-auth
The agent signs each request with HTTP Message Signatures (RFC 9421). Signature-Input carries keyid, alg, created, expires, nonce and the tag. Mastercard's guide gives the Mastercard tag as Agent-pay-auth; its testing glossary writes agent-pay-auth. The guide's example Signature-Agent host does not resolve, so this example uses a placeholder host.
Step 1 of 9: Agent platform to CDN or edge (Cloudflare). Signed GET with tag Agent-pay-auth. Crosses a trust boundary.
Sequence diagram: Agent Pay Level 1 purchase with edge verification
Scroll to see the whole diagram
Generated from the flow definition (spec version Agent Pay developer guides (unversioned, read 2026-10-11), 2026-10-11). The player above uses the same data.
Text alternative
Sequence diagram: Agent Pay Level 1 purchase with edge verification. 7 participants: Agent platform, CDN or edge (Cloudflare), Mastercard key directory, Merchant, Acquirer or PSP, Mastercard network, and Issuer. 9 steps, 6 crossing a trust boundary, 7 failure branches. Based on mastercard-agent-pay Agent Pay developer guides (unversioned, read 2026-10-11) (2026-10-11). Step 1: Agent platform to CDN or edge (Cloudflare): Signed GET with tag Agent-pay-auth. This step crosses a trust boundary. If No Signature-Input with a scheme tag: Treat as an ordinary bot and apply the non-agent bot policy. If A required parameter is missing: Block the request. Step 2: CDN or edge (Cloudflare) to Mastercard key directory: Fetch public key for keyid. This step crosses a trust boundary. If Key not found in the directory: Block the request. Step 3: CDN or edge (Cloudflare) to CDN or edge (Cloudflare): Verify window, nonce, tag, signature. If Window expired or nonce reused: Block the request. If Signature does not verify: Block the request. Step 4: CDN or edge (Cloudflare) to Merchant: Forward as a trusted agent. Step 5: Agent platform to Merchant: Fill card form with agentic token. This step crosses a trust boundary. If Agent uses a card on file instead of an agentic token: The network cannot recognize the transaction as agentic. Step 6: Merchant to Acquirer or PSP: Submit authorization. This step crosses a trust boundary. Step 7: Acquirer or PSP to Mastercard network: Authorization request. This step crosses a trust boundary. If Token used outside its merchant, amount or time limits: Decline (exact response code not published). Step 8: Mastercard network to Issuer: Route to issuer. This step crosses a trust boundary. Step 9: Issuer to Merchant: Approve or decline.
Step 1: Agent platform to CDN or edge (Cloudflare): Signed GET with tag Agent-pay-auth. This step crosses a trust boundary. If No Signature-Input with a scheme tag: Treat as an ordinary bot and apply the non-agent bot policy. If A required parameter is missing: Block the request.
Step 2: CDN or edge (Cloudflare) to Mastercard key directory: Fetch public key for keyid. This step crosses a trust boundary. If Key not found in the directory: Block the request.
Step 3: CDN or edge (Cloudflare) to CDN or edge (Cloudflare): Verify window, nonce, tag, signature. If Window expired or nonce reused: Block the request. If Signature does not verify: Block the request.
Step 4: CDN or edge (Cloudflare) to Merchant: Forward as a trusted agent.
Step 5: Agent platform to Merchant: Fill card form with agentic token. This step crosses a trust boundary. If Agent uses a card on file instead of an agentic token: The network cannot recognize the transaction as agentic.
Step 6: Merchant to Acquirer or PSP: Submit authorization. This step crosses a trust boundary.
Step 7: Acquirer or PSP to Mastercard network: Authorization request. This step crosses a trust boundary. If Token used outside its merchant, amount or time limits: Decline (exact response code not published).
Step 8: Mastercard network to Issuer: Route to issuer. This step crosses a trust boundary.
Lifecycle: Agentic token lifecycle (as described, not a published state model)
A filled dot marks the initial state; terminal states have a double border; dashed lines go back to an earlier state. Numbers on the lines match the transition list.
Transition
Agent registered to Agent certified
Trigger
Security review and certification pass
API call
None named in the spec
Spec reference
The Rails for Agentic Commerce
About Agent certified
Security review passed; on the trusted agent list.
State notes
Agent registered
Public key in the Mastercard key directory.
Agent certified
Security review passed; on the trusted agent list.
Consumer authorized
Consumer authenticated (passkeys in regional pilots) and set limits.
Token provisioned
Single-use, merchant-specific or time-limited.
Presented at checkout
Typed into a card form or sent through a merchant API.
Authorized
Issuer approved.
Declined
Issuer or network declined. Response codes are not published.
Expired or no longer usable
Inferred from time-limited and single-use tokens. Mastercard publishes no revocation API or state names.
Spec version Agent Pay developer guides (unversioned, read 2026-10-11).
State diagram: Agentic token lifecycle (as described, not a published state model)
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
Generated from the state machine definition (spec version Agent Pay developer guides (unversioned, read 2026-10-11)).
Text alternative
State diagram: Agentic token lifecycle (as described, not a published state model). 8 states: Agent registered, Agent certified, Consumer authorized, Token provisioned, Presented at checkout, Authorized, Declined, and Expired or no longer usable. Starts in Agent registered. Ends in Authorized, Declined, and Expired or no longer usable. 8 transitions. From Agent registered to Agent certified when Security review and certification pass. From Agent certified to Consumer authorized when Consumer authenticates with the platform and authorizes the agent. From Consumer authorized to Token provisioned when Platform requests an agentic token (Not published). From Token provisioned to Presented at checkout when Agent fills the card form or calls the merchant API. From Presented at checkout to Authorized when Network detokenizes and issuer approves (Card authorization message). From Presented at checkout to Declined when Outside token limits or issuer declines (Card authorization message). From Token provisioned to Expired or no longer usable when Time window passes or single use consumed. From Authorized to Expired or no longer usable when Single-use token cannot be used again.
From Agent registered to Agent certified when Security review and certification pass.
From Agent certified to Consumer authorized when Consumer authenticates with the platform and authorizes the agent.
From Consumer authorized to Token provisioned when Platform requests an agentic token (Not published).
From Token provisioned to Presented at checkout when Agent fills the card form or calls the merchant API.
From Presented at checkout to Authorized when Network detokenizes and issuer approves (Card authorization message).
From Presented at checkout to Declined when Outside token limits or issuer declines (Card authorization message).
From Token provisioned to Expired or no longer usable when Time window passes or single use consumed.
From Authorized to Expired or no longer usable when Single-use token cannot be used again.
Five trust zones. The consumer and agent platform hold consent and the token; the edge and merchant verify signed requests; acquirers carry the payment; Mastercard registers agents, runs the key directory and issues tokens; the issuer decides. Verifiable Intent adds a signed chain alongside. The key directory location is not public.
Text alternative
Flowchart. The consumer authorizes the agent platform with a passkey. The agent platform registers its key in the Mastercard key directory and gets certified, and requests an agentic token from the Mastercard network. The agent sends signed requests to the CDN, which fetches keys from the key directory, then forwards to the merchant. The merchant sends authorizations through the acquirer to the Mastercard network, which detokenizes and routes to the issuer. Verifiable Intent credentials flow from issuer to user to agent and are checked by merchant and network.
Left: Agent Pay program objects as named in Mastercard developer guides, with no public wire schema. Right: Verifiable Intent credentials and mandates from the open spec (main at 356c296, 2026-04-20). Field names on main differ from tag v0.1.0.
Text alternative
Class diagram. Program objects: SignatureInput with keyid, alg, created, expires, nonce, tag; AgentUserIdentity with mastercardIdToken, signature, kid, nonce, alg; PaymentData with paymentData, signature, kid, nonce, alg; Intent with intentId, intentSummary, intentStatus, orders, consumer, digitalAccountCredentials; Order with orderId, orderExecutionType, orderStatus, orderExpiry, orderTotalAmount, items, merchants; Merchant with srcDpaId. VI objects: L1 credential binds user key; L2 holds checkout and payment mandates; L3a holds a final payment mandate; L3b holds a final checkout mandate; open mandates hold constraints.
Agent enrollment, certification and token provisioning
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
Before any purchase, the agent developer registers a public key and passes a Mastercard security review, merchants register through their acquirer, and the consumer authorizes the agent so the platform can request a scoped agentic token. Mastercard documents these steps in prose only.
Text alternative
Sequence diagram: Agent enrollment, certification and token provisioning. 7 participants: Agent platform, Mastercard network, Mastercard key directory, Consumer, Merchant, Acquirer or PSP, and Issuer. 8 steps, 7 crossing a trust boundary, 2 failure branches. Based on mastercard-agent-pay Agent Pay developer guides (unversioned, read 2026-10-11) (2026-10-11). Step 1: Agent platform to Mastercard key directory: Register agent public key. This step crosses a trust boundary. Step 2: Mastercard network to Agent platform: Security review and certification. This step crosses a trust boundary. If Agent not registered or not certified: It cannot transact through the network. Step 3: Mastercard network to Mastercard network: Add to trusted agent list. Step 4: Merchant to Acquirer or PSP: Merchant registers for Agent Pay. This step crosses a trust boundary. Step 5: Consumer to Agent platform: Authenticate and authorize agent. This step crosses a trust boundary. Step 6: Agent platform to Mastercard network: Request agentic token. This step crosses a trust boundary. If Consumer authentication fails: No token is provisioned. Step 7: Mastercard network to Issuer: Issuer enabled for Agent Pay. This step crosses a trust boundary. Step 8: Mastercard network to Agent platform: Return scoped token. This step crosses a trust boundary.
Step 1: Agent platform to Mastercard key directory: Register agent public key. This step crosses a trust boundary.
Step 2: Mastercard network to Agent platform: Security review and certification. This step crosses a trust boundary. If Agent not registered or not certified: It cannot transact through the network.
Step 3: Mastercard network to Mastercard network: Add to trusted agent list.
Step 4: Merchant to Acquirer or PSP: Merchant registers for Agent Pay. This step crosses a trust boundary.
Step 5: Consumer to Agent platform: Authenticate and authorize agent. This step crosses a trust boundary.
Step 6: Agent platform to Mastercard network: Request agentic token. This step crosses a trust boundary. If Consumer authentication fails: No token is provisioned.
Step 7: Mastercard network to Issuer: Issuer enabled for Agent Pay. This step crosses a trust boundary.
Step 8: Mastercard network to Agent platform: Return scoped token. This step crosses a trust boundary.
Source of truth: Specification (external link) Generated from src/content/flows/mastercard-agent-pay-enrollment-provisioning.json.
Play this flow step by step
Agent platform
Mastercard network
Mastercard key directory
Consumer
Merchant
Acquirer or PSP
Issuer
1
Crosses a trust boundary
Use the left and right arrow keys to step, space to play or pause, Home and End to jump.
Step 1 of 8Agent platform toto Mastercard key directory
Register agent public key
The agent developer creates a key pair and registers the public key in the Mastercard Agent Pay key directory during onboarding (registration process not public).
Step 1 of 8: Agent platform to Mastercard key directory. Register agent public key. Crosses a trust boundary.
The two acceptance paths: Level 1 and 2 versus Level 3
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
Mastercard describes a no-code path, where an edge provider checks agent signatures and agents type tokens into existing forms, and a deeper path with consumer identity objects and the Intent API. Level 3 intent exchange is labeled future facing.
Text alternative
Flowchart. A merchant chooses a path. The no-code path, Levels 1 and 2: Web Bot Auth verification at the CDN, agentic token or virtual card token with DTVC typed into existing card forms, optional Agent User Identity and Payment Data objects in the request body at Level 2. The deeper path, Level 3: merchant agentic API, Intent API with intentId, tokenized credentials with DSRP cryptogram, merchant validates intent. Both end in a normal card authorization.
Mastercard's Level 1 guide gives merchants a short decision table, and Cloudflare lists the same checks at the edge. Untagged traffic falls back to the ordinary bot policy; a missing field or an unknown key blocks the request.
Text alternative
Flowchart. Does the request carry Signature-Input with a scheme tag? If no, apply the non-agent bot policy. If yes, are all required fields present? If no, block. Is the key found in the directory? If no, block. Are created and expires valid and the nonce unused? If no, block. Does the signature verify? If no, block. If yes, treat as a trusted agent.
Guest checkout with a Virtual Card Token and a DTVC
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
For web guest checkouts with a simple card form, Mastercard points integrators to Mastercard Virtual Card Tokens. After user validation and consent the integrator gets a token number, expiry and a one-time DTVC, which the agent types into the form. Mastercard validates the DTVC at authorization.
Text alternative
Sequence diagram: Guest checkout with a Virtual Card Token and a DTVC. 6 participants: Consumer, Agent platform, Mastercard network, Merchant, Acquirer or PSP, and Issuer. 7 steps, 7 crossing a trust boundary, 1 failure branch. Based on mastercard-agent-pay Agent Pay developer guides (unversioned, read 2026-10-11) (2026-10-11). Step 1: Consumer to Agent platform: User validation and consent. This step crosses a trust boundary. Step 2: Agent platform to Mastercard network: Request checkout for merchant domain. This step crosses a trust boundary. Step 3: Mastercard network to Agent platform: Return token, expiry and DTVC. This step crosses a trust boundary. Step 4: Agent platform to Merchant: Type values into card form. This step crosses a trust boundary. Step 5: Merchant to Acquirer or PSP: Submit authorization. This step crosses a trust boundary. Step 6: Acquirer or PSP to Mastercard network: Authorization with token. This step crosses a trust boundary. If DTVC wrong or already used: Validation fails and the issuer is told (outcome and response code not published). Step 7: Mastercard network to Issuer: Tell issuer DTVC result. This step crosses a trust boundary.
Step 1: Consumer to Agent platform: User validation and consent. This step crosses a trust boundary.
Step 2: Agent platform to Mastercard network: Request checkout for merchant domain. This step crosses a trust boundary.
Step 3: Mastercard network to Agent platform: Return token, expiry and DTVC. This step crosses a trust boundary.
Step 4: Agent platform to Merchant: Type values into card form. This step crosses a trust boundary.
Step 5: Merchant to Acquirer or PSP: Submit authorization. This step crosses a trust boundary.
Step 6: Acquirer or PSP to Mastercard network: Authorization with token. This step crosses a trust boundary. If DTVC wrong or already used: Validation fails and the issuer is told (outcome and response code not published).
Step 7: Mastercard network to Issuer: Tell issuer DTVC result. This step crosses a trust boundary.
Source of truth: Specification (external link) Generated from src/content/flows/mastercard-agent-pay-dtvc-guest-checkout.json.
Play this flow step by step
Consumer
Agent platform
Mastercard network
Merchant
Acquirer or PSP
Issuer
1
Crosses a trust boundary
Use the left and right arrow keys to step, space to play or pause, Home and End to jump.
Step 1 of 7Consumer toto Agent platform
User validation and consent
The user is validated and consents before a security code is requested.
Step 1 of 7: Consumer to Agent platform. User validation and consent. Crosses a trust boundary.
Level 3 programmatic checkout with the Intent API
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
At Level 3 the agent registers the consumer intent with Mastercard's Intent API, receives an intentId and tokenized credentials, and sends both to the merchant's agentic API. The merchant validates the intent against the checkout. Mastercard names the fields but points to the non-public Acceptance Framework for the full schema.
Text alternative
Sequence diagram: Level 3 programmatic checkout with the Intent API. 6 participants: Consumer, Agent platform, Mastercard network, Merchant, Acquirer or PSP, and Issuer. 7 steps, 6 crossing a trust boundary, 3 failure branches. Based on mastercard-agent-pay Agent Pay developer guides (unversioned, read 2026-10-11) (2026-10-11). Step 1: Consumer to Agent platform: State purchase intent. This step crosses a trust boundary. Step 2: Agent platform to Mastercard network: Register intent (Intent API). This step crosses a trust boundary. Step 3: Mastercard network to Agent platform: Return intentId and credentials. This step crosses a trust boundary. Step 4: Agent platform to Merchant: Checkout via merchant API. This step crosses a trust boundary. Step 5: Merchant to Merchant: Validate intent. If Total exceeds orderTotalAmount or srcDpaId differs: Reject the checkout. If SKU, quantity or address mismatch: Flag for review. If Deferred order fails validation: Ask the agent to obtain explicit consumer confirmation. Step 6: Merchant to Acquirer or PSP: Submit authorization. This step crosses a trust boundary. Step 7: Acquirer or PSP to Issuer: Authorize through network. This step crosses a trust boundary.
Step 1: Consumer to Agent platform: State purchase intent. This step crosses a trust boundary.
Step 2: Agent platform to Mastercard network: Register intent (Intent API). This step crosses a trust boundary.
Step 3: Mastercard network to Agent platform: Return intentId and credentials. This step crosses a trust boundary.
Step 4: Agent platform to Merchant: Checkout via merchant API. This step crosses a trust boundary.
Step 5: Merchant to Merchant: Validate intent. If Total exceeds orderTotalAmount or srcDpaId differs: Reject the checkout. If SKU, quantity or address mismatch: Flag for review. If Deferred order fails validation: Ask the agent to obtain explicit consumer confirmation.
Step 6: Merchant to Acquirer or PSP: Submit authorization. This step crosses a trust boundary.
Step 7: Acquirer or PSP to Issuer: Authorize through network. This step crosses a trust boundary.
Source of truth: Specification (external link) Generated from src/content/flows/mastercard-agent-pay-level3-intent.json.
Play this flow step by step
Consumer
Agent platform
Mastercard network
Merchant
Acquirer or PSP
Issuer
1
Crosses a trust boundary
Use the left and right arrow keys to step, space to play or pause, Home and End to jump.
Step 1 of 7Consumer toto Agent platform
State purchase intent
The consumer tells the agent what to buy and within which limits; the agent captures it as structured intent.
Step 1 of 7: Consumer to Agent platform. State purchase intent. Crosses a trust boundary.
Verifiable Intent layer stack with lifetimes
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
Each layer binds the key that signs the next through the cnf claim. Immediate mode stops at L2 with final values; Autonomous mode adds L3a for the network and L3b for the merchant, linked by checkout_hash. Lifetimes are the spec recommendations.
Text alternative
Flowchart from top to bottom. L1, signed by the issuer, typ sd+jwt, about one year, binds the user key. It leads either to L2 Immediate, typ kb-sd-jwt, 15 minutes, final checkout and payment values, user present; or to L2 Autonomous, typ kb-sd-jwt+kb, 24 hours to 30 days, constraints and the agent key. L2 Autonomous leads to L3a, payment mandate to the network, and L3b, checkout mandate to the merchant, each 5 minutes recommended and 1 hour maximum. L3a transaction_id equals L3b checkout_hash.
Verifiable Intent Immediate mode (two layers, user present)
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
The user reviews a final cart and signs L2 with final checkout and payment mandates. The agent forwards L1 and L2; the merchant sees the checkout side and the network sees the payment side. No L3 is created.
Text alternative
Sequence diagram: Verifiable Intent Immediate mode (two layers, user present). 5 participants: Issuer (L1 signer), User, Agent platform, Merchant, and Mastercard network. 5 steps, 5 crossing a trust boundary, 2 failure branches. Based on mastercard-agent-pay Verifiable Intent 0.1 (main at 356c296) (2026-04-20). Step 1: Issuer (L1 signer) to User: Issue L1 (sd+jwt). This step crosses a trust boundary. Step 2: Agent platform to User: Present final cart and checkout_jwt. This step crosses a trust boundary. Step 3: User to Agent platform: Sign L2 Immediate (kb-sd-jwt). This step crosses a trust boundary. Step 4: Agent platform to Merchant: L1 + L2, checkout disclosed. This step crosses a trust boundary. If checkout_hash does not match the merchant checkout: Reject. Step 5: Merchant to Mastercard network: L1 + L2, payment disclosed. This step crosses a trust boundary. If L2 exp passed (300 second skew recommended): Reject.
Step 1: Issuer (L1 signer) to User: Issue L1 (sd+jwt). This step crosses a trust boundary.
Step 2: Agent platform to User: Present final cart and checkout_jwt. This step crosses a trust boundary.
Step 3: User to Agent platform: Sign L2 Immediate (kb-sd-jwt). This step crosses a trust boundary.
Step 4: Agent platform to Merchant: L1 + L2, checkout disclosed. This step crosses a trust boundary. If checkout_hash does not match the merchant checkout: Reject.
Step 5: Merchant to Mastercard network: L1 + L2, payment disclosed. This step crosses a trust boundary. If L2 exp passed (300 second skew recommended): Reject.
Source of truth: 3 (external link) Generated from src/content/flows/mastercard-agent-pay-vi-immediate.json.
Play this flow step by step
Issuer (L1 signer)
User
Agent platform
Merchant
Mastercard network
1
Crosses a trust boundary
Use the left and right arrow keys to step, space to play or pause, Home and End to jump.
Step 1 of 5Issuer (L1 signer) toto User
Issue L1 (sd+jwt)
The issuer, a bank or Mastercard on its behalf, signs L1 binding the user's public key in cnf.jwk. Lifetime about one year.
The user signs open mandates with constraints and the agent key, then leaves. Later the agent signs L3a for the network and L3b for the merchant, bound to each other through checkout_hash and transaction_id. The network checks constraints and keeps state for budgets.
Text alternative
Sequence diagram: Verifiable Intent Autonomous mode (three layers, agent delegated). 5 participants: User, Agent platform, Merchant, Mastercard network, and Issuer. 6 steps, 5 crossing a trust boundary, 3 failure branches. Based on mastercard-agent-pay Verifiable Intent 0.1 (main at 356c296) (2026-04-20). Step 1: User to Agent platform: Sign L2 Autonomous (kb-sd-jwt+kb). This step crosses a trust boundary. Step 2: Agent platform to Merchant: Shop and get checkout_jwt. This step crosses a trust boundary. Step 3: Agent platform to Agent platform: Sign L3a and L3b. Step 4: Agent platform to Merchant: Present L1 + L2 + L3b. This step crosses a trust boundary. If Merchant not in allowed list: Constraint violation, reject. Step 5: Merchant to Mastercard network: Present L1 + L2 + L3a. This step crosses a trust boundary. If Amount above amount_range max: Violation: amount exceeded. If cnf.jwk differs between the two L2 mandates: Reject (split-agent attack). Step 6: Mastercard network to Issuer: Assurance data to issuer. This step crosses a trust boundary.
Step 1: User to Agent platform: Sign L2 Autonomous (kb-sd-jwt+kb). This step crosses a trust boundary.
Step 2: Agent platform to Merchant: Shop and get checkout_jwt. This step crosses a trust boundary.
Step 3: Agent platform to Agent platform: Sign L3a and L3b.
Step 4: Agent platform to Merchant: Present L1 + L2 + L3b. This step crosses a trust boundary. If Merchant not in allowed list: Constraint violation, reject.
Step 5: Merchant to Mastercard network: Present L1 + L2 + L3a. This step crosses a trust boundary. If Amount above amount_range max: Violation: amount exceeded. If cnf.jwk differs between the two L2 mandates: Reject (split-agent attack).
Step 6: Mastercard network to Issuer: Assurance data to issuer. This step crosses a trust boundary.
Source of truth: 4.5 (external link) Generated from src/content/flows/mastercard-agent-pay-vi-autonomous.json.
Play this flow step by step
User
Agent platform
Merchant
Mastercard network
Issuer
1
Crosses a trust boundary
Use the left and right arrow keys to step, space to play or pause, Home and End to jump.
Step 1 of 6User toto Agent platform
Sign L2 Autonomous (kb-sd-jwt+kb)
Open mandates mandate.checkout.open.1 and mandate.payment.open.1 both carry the same agent cnf.jwk with kid, and constraints. The payment mandate must include mandate.payment.reference. Lifetime 24 hours to 30 days, never past L1 exp.
Spec version Verifiable Intent 0.1 (main at 356c296) (2026-04-20). Sources: [9], [20], [44], [46]
Step 1 of 6: User to Agent platform. Sign L2 Autonomous (kb-sd-jwt+kb). Crosses a trust boundary.
Verifiable Intent mandate pair state held by the network
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
Generated from the state machine definition (spec version Verifiable Intent 0.1 (main at 356c296)).
Text alternative
State diagram: Verifiable Intent mandate pair state held by the network. 5 states: Unfulfilled, Fulfilled, Recurring (agent_recurrence), Exhausted, and Expired. Starts in Unfulfilled. Ends in Fulfilled, Exhausted, and Expired. 5 transitions. From Unfulfilled to Fulfilled when Network accepts the first L3a for the pair (None defined in the spec). From Unfulfilled to Recurring (agent_recurrence) when First L3a accepted with mandate.payment.agent_recurrence present. From Recurring (agent_recurrence) to Recurring (agent_recurrence) when Further L3a within counters and budget. From Recurring (agent_recurrence) to Exhausted when Counter, budget or end_date limit reached. From Unfulfilled to Expired when L2 exp passes before fulfillment.
From Unfulfilled to Fulfilled when Network accepts the first L3a for the pair (None defined in the spec).
From Unfulfilled to Recurring (agent_recurrence) when First L3a accepted with mandate.payment.agent_recurrence present.
From Recurring (agent_recurrence) to Recurring (agent_recurrence) when Further L3a within counters and budget.
From Recurring (agent_recurrence) to Exhausted when Counter, budget or end_date limit reached.
From Unfulfilled to Expired when L2 exp passes before fulfillment.
A filled dot marks the initial state; terminal states have a double border; dashed lines go back to an earlier state. Numbers on the lines match the transition list.
Transition
Unfulfilled to Fulfilled
Trigger
Network accepts the first L3a for the pair
API call
None defined in the spec
Spec reference
security-model.md 4.2
About Fulfilled
One L3a and L3b pair accepted (base model).
State notes
Unfulfilled
L2 Autonomous signed; no L3 pair accepted yet.
Fulfilled
One L3a and L3b pair accepted (base model).
Recurring (agent_recurrence)
Counters occurrence_count and cumulative_spent advance with each L3a.
Exhausted
max_occurrences, budget max or end_date reached.
Expired
L2 exp passed; the user should be prompted to authorize again.
Spec version Verifiable Intent 0.1 (main at 356c296).
Agent Pay token inside a Stripe Shared Payment Token
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
Stripe provisions a Mastercard agentic network token scoped to the customer's intent and hands it to the agent as a Shared Payment Token. This is how an ACP checkout processed by Stripe can carry an Agent Pay token.
Text alternative
Sequence diagram: Agent Pay token inside a Stripe Shared Payment Token. 6 participants: Consumer, Agent platform, Stripe, Mastercard network, Merchant, and Issuer. 6 steps, 6 crossing a trust boundary. Based on mastercard-agent-pay Agent Pay developer guides (unversioned, read 2026-10-11) (2026-03-03). Step 1: Consumer to Agent platform: Authorize agent purchase. This step crosses a trust boundary. Step 2: Stripe to Mastercard network: Provision agentic network token. This step crosses a trust boundary. Step 3: Stripe to Agent platform: Share as SPT. This step crosses a trust boundary. Step 4: Agent platform to Merchant: Pay with SPT. This step crosses a trust boundary. Step 5: Merchant to Mastercard network: Authorize. This step crosses a trust boundary. Step 6: Mastercard network to Issuer: Issuer decides. This step crosses a trust boundary.
Step 1: Consumer to Agent platform: Authorize agent purchase. This step crosses a trust boundary.
Step 2: Stripe to Mastercard network: Provision agentic network token. This step crosses a trust boundary.
Step 3: Stripe to Agent platform: Share as SPT. This step crosses a trust boundary.
Step 4: Agent platform to Merchant: Pay with SPT. This step crosses a trust boundary.
Step 5: Merchant to Mastercard network: Authorize. This step crosses a trust boundary.
Step 6: Mastercard network to Issuer: Issuer decides. This step crosses a trust boundary.
Source of truth: Specification (external link) Generated from src/content/flows/mastercard-agent-pay-stripe-spt.json.
Play this flow step by step
Consumer
Agent platform
Stripe
Mastercard network
Merchant
Issuer
1
Crosses a trust boundary
Use the left and right arrow keys to step, space to play or pause, Home and End to jump.
Step 1 of 6: Consumer to Agent platform. Authorize agent purchase. Crosses a trust boundary.
Agent Pay failure: the keyid is not in the key directory
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
An agent sends a signed request whose keyid the verifier cannot find in the Mastercard directory, for example an unregistered or delisted agent. Mastercard's decision table says to block.
Text alternative
Sequence diagram: Agent Pay failure: the keyid is not in the key directory. 4 participants: Agent platform, CDN or edge (Cloudflare), Mastercard key directory, and Merchant. 4 steps, 3 crossing a trust boundary, 1 failure branch. Based on mastercard-agent-pay Agent Pay developer guides (unversioned, read 2026-10-11) (2026-10-11). Step 1: Agent platform to CDN or edge (Cloudflare): Signed request, unknown keyid. This step crosses a trust boundary. Step 2: CDN or edge (Cloudflare) to Mastercard key directory: Look up keyid. This step crosses a trust boundary. Step 3: CDN or edge (Cloudflare) to Agent platform: Block. This step crosses a trust boundary. If Key not found: Request blocked. Step 4: CDN or edge (Cloudflare) to Merchant: Log the attempt.
Step 1: Agent platform to CDN or edge (Cloudflare): Signed request, unknown keyid. This step crosses a trust boundary.
Step 2: CDN or edge (Cloudflare) to Mastercard key directory: Look up keyid. This step crosses a trust boundary.
Step 3: CDN or edge (Cloudflare) to Agent platform: Block. This step crosses a trust boundary. If Key not found: Request blocked.
Step 4: CDN or edge (Cloudflare) to Merchant: Log the attempt.
Source of truth: Specification (external link) Generated from src/content/flows/mastercard-agent-pay-failure-unknown-key.json.
Play this flow step by step
Agent platform
CDN or edge (Cloudflare)
Mastercard key directory
Merchant
1
Crosses a trust boundary
Use the left and right arrow keys to step, space to play or pause, Home and End to jump.
Step 1 of 4Agent platform toto CDN or edge (Cloudflare)
Signed request, unknown keyid
The request carries complete Signature-Input parameters and the Agent Pay tag, but the key was never registered or is no longer listed.
Step 1 of 4: Agent platform to CDN or edge (Cloudflare). Signed request, unknown keyid. Crosses a trust boundary.
Agent Pay failure: checkout total exceeds the registered intent
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
At Level 3 the agent submits a checkout whose total is higher than orderTotalAmount in the registered intent. Mastercard tells merchants to reject it.
Text alternative
Sequence diagram: Agent Pay failure: checkout total exceeds the registered intent. 3 participants: Agent platform, Merchant, and Mastercard network. 3 steps, 2 crossing a trust boundary, 2 failure branches. Based on mastercard-agent-pay Agent Pay developer guides (unversioned, read 2026-10-11) (2026-10-11). Step 1: Agent platform to Merchant: Checkout with intentId. This step crosses a trust boundary. Step 2: Merchant to Merchant: Compare totals. If Total greater than orderTotalAmount: Reject. If srcDpaId differs: Reject. Step 3: Merchant to Agent platform: Reject checkout. This step crosses a trust boundary.
Step 1: Agent platform to Merchant: Checkout with intentId. This step crosses a trust boundary.
Step 2: Merchant to Merchant: Compare totals. If Total greater than orderTotalAmount: Reject. If srcDpaId differs: Reject.
Step 3: Merchant to Agent platform: Reject checkout. This step crosses a trust boundary.
Source of truth: Specification (external link) Generated from src/content/flows/mastercard-agent-pay-failure-intent-mismatch.json.
Play this flow step by step
Agent platform
Merchant
Mastercard network
1
Crosses a trust boundary
Use the left and right arrow keys to step, space to play or pause, Home and End to jump.
Step 1 of 3Agent platform toto Merchant
Checkout with intentId
The agent sends the intent and credentials. The cart now costs more than the consumer approved, for example after a price change.
An Autonomous mandate carries a mandate.payment.budget cap. A new L3a would push cumulative spend over the cap, so the network rejects it. Only the network can enforce this, because it needs state across transactions.
Text alternative
Sequence diagram: Verifiable Intent failure: cumulative budget exceeded. 3 participants: Agent platform, Merchant, and Mastercard network. 4 steps, 4 crossing a trust boundary, 1 failure branch. Based on mastercard-agent-pay Verifiable Intent 0.1 (main at 356c296) (2026-04-20). Step 1: Agent platform to Merchant: Present L3b. This step crosses a trust boundary. Step 2: Merchant to Mastercard network: Present L3a. This step crosses a trust boundary. Step 3: Mastercard network to Merchant: Reject: budget exceeded. This step crosses a trust boundary. If new cumulative spend greater than max: Violation: budget exceeded. Step 4: Merchant to Agent platform: Payment declined. This step crosses a trust boundary.
Step 1: Agent platform to Merchant: Present L3b. This step crosses a trust boundary.
Step 2: Merchant to Mastercard network: Present L3a. This step crosses a trust boundary.
Step 3: Mastercard network to Merchant: Reject: budget exceeded. This step crosses a trust boundary. If new cumulative spend greater than max: Violation: budget exceeded.
Step 4: Merchant to Agent platform: Payment declined. This step crosses a trust boundary.
Source of truth: 4.5 (external link) Generated from src/content/flows/mastercard-agent-pay-failure-vi-budget-exceeded.json.
Play this flow step by step
Agent platform
Merchant
Mastercard network
1
Crosses a trust boundary
Use the left and right arrow keys to step, space to play or pause, Home and End to jump.
Step 1 of 4Agent platform toto Merchant
Present L3b
The checkout side passes: the merchant is allowed and the items match.
Spec version Verifiable Intent 0.1 (main at 356c296) (2026-04-20). Sources: [44], [46]
Step 1 of 4: Agent platform to Merchant. Present L3b. Crosses a trust boundary.
Agent Pay and Visa TAP with VIC side by side
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
Both networks use the same edge pattern (RFC 9421 signatures with a tag and a nonce, checked against a network-hosted key directory) and both issue their own agentic tokens. Tags, directories, token products and intent formats differ.
Text alternative
Flowchart with two columns. Mastercard: tag Agent-pay-auth, Mastercard key directory (location not public), Mastercard Agentic Tokens, Verifiable Intent for intent. Visa: tags agent-browser-auth and agent-payer-auth, Visa key directory, Visa Intelligent Commerce agentic network tokens, TAP consumer and payment objects. Shared in the middle: RFC 9421, nonce, edge verification at Cloudflare, Stripe Shared Payment Tokens carry both tokens.
Agent Pay is a card-network program; most links run through Verifiable Intent or through partners. Dashed links are statements by a partner or proposals without a binding.
Text alternative
Flowchart. Agent Pay connects to Verifiable Intent. Verifiable Intent shares mandate vct values with AP2 and can be carried in the UCP AP2 mandate extension. Agent Pay tokens travel inside Stripe Shared Payment Tokens, which ACP checkouts on Stripe can use. Visa TAP uses the same edge signature pattern. Agent Pay for Machines quotes Tempo on MPP compatibility. Mastercard is a premier member of the x402 Foundation. No relation to ERC-8004 is documented.
Spec-deep mode: the full explanation plus 0 field tables and wire examples.
STE mode: section B is hidden; the Simplified Technical English version (section D) is shown first.
This section uses Simplified Technical English (ASD-STE100): short sentences, one instruction per step, and one word for one meaning.
Mastercard Agent Pay is a Mastercard program for payments by AI agents. It is not an open protocol. It is not AP2. Mastercard started the program on 2025-04-29.
Only a registered agent can pay with Agent Pay. Mastercard examines each agent before it puts the agent on a list of trusted agents. The agent gives its public key to Mastercard.
The consumer gives permission to the agent. Then Mastercard gives an agentic token to the agent. The token is not the card number. The token can have limits for one merchant, one amount or one time period.
The agent signs each web request with its key. The merchant or the CDN examines the signature with the key from the Mastercard key directory. Then the agent pays with the token. The bank of the consumer makes the last decision.
Verifiable Intent is a different specification. It is open. It gives signed proof of the purchases that the user lets the agent make.
Most of the transactions that Mastercard names are tests or first transactions. Mastercard does not publish the number of transactions.
Procedure Accept a payment from an Agent Pay agent (merchant)
Register for Agent Pay through your acquirer or your payment service provider.
Find the Signature-Input header and the Signature header in the request.
If the request has no Agent Pay tag, use your usual policy for bots.
If a required parameter is not in the header, stop the request.
Get the public key for the keyid from the Mastercard key directory.
If you cannot find the key, stop the request.
Make sure that the time now is between the created value and the expires value.
Make sure that the nonce is new.
Verify the signature.
Let the agent put the token in your usual card form.
Send the payment to your acquirer as a usual card payment.
Procedure Get an agentic token for a consumer (agent platform)
Make a key pair for your agent.
Register the public key with Mastercard.
Complete the Mastercard security review and the certification.
Ask the consumer to authenticate. Use a passkey if your region supports it.
Ask the consumer for the merchants, the amount and the time period.
Request an agentic token with these limits.
Keep the token in a safe location.
Sign each request to a merchant with your key and the Agent Pay tag.
Procedure Verify a Verifiable Intent chain in autonomous mode (payment network)
Get the key of the issuer from its JWKS endpoint.
Verify the signature of L1 with the key of the issuer.
Verify the signature of L2 with the user key in L1.
Make sure that the two L2 mandates have the same agent key.
Verify the signature of L3a with the agent key in L2.
Make sure that the transaction_id in L3a is equal to the checkout_hash in L3b.
Make sure that the amount and the payee obey the constraints.
Add the amount to the total for this mandate pair.
If the total is more than the budget, stop the payment.
Send the result to the issuer.
Technical nouns and technical verbs
agentic token: A Mastercard token for payments by a registered agent. Visa uses the same words for a different product.
DTVC: A security code for one use that Mastercard gives with a virtual card token.
key directory: The list of public keys of registered agents. Mastercard keeps this list.
tag: The parameter in the signature that tells the purpose of the signature.
trusted agent list: The list of agents that passed the Mastercard certification.
issuer: The bank that gives the card to the consumer. It makes the last decision for each payment.
Verifiable Intent: An open specification for signed proof of the purchases that a user lets an agent make.
mandate: A signed statement of the purchases that a user lets an agent make.
constraint: A limit in a mandate, for example a maximum amount or a list of merchants.
checkout_hash: A hash of the checkout that connects the payment credential to the checkout credential.
STE check report
Sentences
78
Longest procedural sentence
15 words (limit 20)
Longest descriptive sentence
16 words (limit 25)
Flags
None
Written to the public ASD-STE100 Issue 9 writing rules. Vocabulary not checked against the official dictionary.
Compare with the practitioner text side by side
Practitioner text (section B)
Mastercard Agent Pay answers a card network's question: when software buys something, which agent is it, who allowed it, and within which limits? Agent Pay is a proprietary Mastercard program, not an open protocol and not Google's AP2. Only registered agents can transact: each agent passes a security review, joins a trusted agent list, and registers a public key. The consumer authorizes the agent, and the network issues an agentic token built on Mastercard tokenization, which may be single-use, merchant-specific or time-limited. At the merchant, the agent signs its web requests with HTTP Message Signatures and the tag `Agent-pay-auth`, and the edge or the merchant checks the signature against a Mastercard key directory. The agent then pays with the token through the existing checkout and card rails, and the issuer still decides. Verifiable Intent, a separate open specification, adds signed evidence of what the user approved. What Agent Pay does not give you yet: a public specification, a key directory URL that resolves, agent-specific dispute rules, or any volume data.
Mastercard announced Agent Pay on 2025-04-29 as its Agentic Payments Program, introducing Mastercard Agentic Tokens. The launch release ties those tokens to tokenization Mastercard already runs for contactless payments, card-on-file and Mastercard Payment Passkeys. It sets three goals. Agents must be registered and verified before they pay for anyone, and every party in the chain must be able to recognize an agent transaction. There must also be a process to clarify agent transactions a cardholder does not recognize.
Simplified Technical English
Mastercard Agent Pay is a Mastercard program for payments by AI agents. It is not an open protocol. It is not AP2. Mastercard started the program on 2025-04-29.
Only a registered agent can pay with Agent Pay. Mastercard examines each agent before it puts the agent on a list of trusted agents. The agent gives its public key to Mastercard.
The consumer gives permission to the agent. Then Mastercard gives an agentic token to the agent. The token is not the card number. The token can have limits for one merchant, one amount or one time period.
E. Main personas
Card issuer risk and product lead
Issues the card behind the agentic token, is enabled for Agent Pay at network level, and makes the final authorization decision. Source [8, 15, 16, 17, 44]
Goals
Approve good agent purchases without extra friction
See clearly when an agent was involved
Keep fraud and dispute rates flat as agent traffic grows
Pains
No published agent-specific reason codes or liability shift
Agent flags that are not always present, hence the 2026-09-30 probability score test
Verifiable Intent evidence that is not yet documented inside live authorizations
Implements
Network-level enablement for Agent Pay
Passkey authentication for consumer consent where offered
Authorization rules that read the additional information in the message
Must trust
Mastercard to register and certify agents
The network to detokenize and enforce token limits
The agent platform to capture the consumer intent accurately
Questions, first steps, metrics and a day in the life
Questions they ask
Which data element tells me an agent initiated this transaction?
Who carries the loss when an agent buys the wrong thing within its limits?
Can I read a Verifiable Intent chain today, or only later?
First three steps
Confirm with Mastercard that your BINs are enabled for Agent Pay
Map how agent transactions appear in your authorization and dispute systems
Read the Verifiable Intent security model and its dispute evidence section
Metrics they care about
Agent transaction approval rate
Fraud and dispute rate on agent transactions
Share of agent transactions that carry reliable agent information
A day in the life
Priya runs card authorization strategy at a mid-sized European bank. On 2026-06-02 Mastercard said all its European issuers were enabled for Agent Pay at network level, so agent transactions may already reach her systems. She wants to approve them without new friction, but her dispute team asks a hard question: when a cardholder says the agent bought the wrong hotel, which reason code applies? Nothing agent-specific is published. She asks Mastercard which message field marks agent involvement, sets a rule to review those transactions separately for a quarter, and reads the Verifiable Intent dispute evidence section to see what proof she could ask for later.
Mastercard itself: registers and certifies agents, runs the key directory and trusted agent lists, issues and detokenizes agentic tokens, and verifies Verifiable Intent chains before authorization. Source [7, 8, 16, 44, 47]
Goals
Make every agent transaction recognizable to every party
Keep raw card numbers away from agents
Set the rules other networks and EMVCo converge on
Pains
Agents that still drive human checkout forms
Stateful Verifiable Intent constraints that need new network-side state
Competing formats from Visa, Google and others
Implements
Agent registration, security review and trusted agent lists
Agentic token issuance and detokenization
The probability score for AI-initiated transactions in US testing
Must trust
Agent developers to keep signing keys safe
Acquirers to register merchants correctly
Issuers to make sensible decisions with the additional information
Questions, first steps, metrics and a day in the life
Questions they ask
How do we revoke an agent across the network?
Where do we hold budget and occurrence state for Verifiable Intent mandates?
How do our tags and directory align with the IETF Web Bot Auth draft?
First three steps
Publish a resolvable key directory location
Document a revocation path for agents and tokens
Fix the duplicate-digest issue in the Verifiable Intent L2 format
Metrics they care about
Registered and certified agents
Agentic tokens issued
Share of agent transactions verified with Verifiable Intent
A day in the life
Marco works on the network side of Agent Pay. His team certifies agents, keeps the trusted lists and issues the tokens, and since 2026-09-30 it tests a probability score for transactions that look agent-initiated. That score exists because not every agent purchase arrives with a clean flag. His backlog is long: a key directory location that developers can actually resolve, a revocation path for a misbehaving agent, network-side state for Verifiable Intent budgets, and an open issue saying the L2 format lists digests twice. He starts with the directory, because every merchant verification depends on it.
Sells online through an acquirer or PSP and wants agent orders without rebuilding checkout. Source [7, 8, 17, 35]
Goals
Accept agent purchases through the existing card form
Tell trusted agents from scrapers
Keep PCI scope unchanged
Pains
Bot defenses that block good agents
Not knowing which agents are registered
No clear dispute rules for agent orders
Implements
Registration for Agent Pay through the acquirer or PSP
Web Bot Auth verification, usually at the CDN
Normal card acceptance for tokens typed into the form
Must trust
The CDN to verify signatures correctly
Mastercard to certify agents
The acquirer to handle agent transactions like other card payments
Questions, first steps, metrics and a day in the life
Questions they ask
Do I need any code change for Level 1?
What happens to an untagged bot?
Who pays if an agent order is disputed?
First three steps
Ask your acquirer or PSP how to register for Agent Pay
Turn on signed-agent verification at your CDN if it offers it
Test a checkout where the token is typed into your card form
Metrics they care about
Agent orders accepted
False blocks of signed agents
Chargebacks on agent orders
A day in the life
Ana runs a small cinema chain website on a hosted platform with Cloudflare in front. She keeps seeing bots in her logs and blocks most of them. Her acquirer tells her that Agent Pay agents sign their requests and that her CDN can check those signatures, while the agent types a token into her normal card form, so her PCI scope stays the same. She registers through the acquirer, switches on signed-agent verification at the edge and leaves her checkout untouched. Her open question is disputes: standard chargeback rules apply, and nothing agent-specific is published yet.
Builds the agent: registers it with Mastercard, captures consent, requests tokens and signs every merchant request. Source [3, 7, 8, 23, 36, 45]
Goals
Let users buy through the agent at any Mastercard merchant
Pass certification once and reuse it
Hold tokens, never card numbers
Pains
No public SDK, API reference or sandbox for Agent Pay
Two spellings of the tag and an example directory host that does not resolve
Form filling on pages built for people
Implements
Agent key pair and registration
Consumer authentication and limit capture
RFC 9421 request signing with the Agent Pay tag
Must trust
Mastercard to keep the agent listed
Merchants and CDNs to verify signatures
The consumer passkey flow
Questions, first steps, metrics and a day in the life
Questions they ask
Which tag spelling do verifiers accept?
How do I get a token through Stripe instead of directly?
When will Verifiable Intent be required?
First three steps
Read the Rails for Agentic Commerce and Level 1 guides
Prototype signing with RFC 9421 and test against a CDN
Run the Verifiable Intent Python examples locally
Metrics they care about
Checkout completion rate
Signature verification failures
Time from consent to token
A day in the life
Sam leads payments at a startup building a shopping agent. He wants users to say "book two tickets for Friday" and have the agent finish the purchase at any merchant. Agent Pay requires a registered key, a security review and tokens instead of card numbers, which suits him, but there is no public SDK or sandbox. He signs requests with RFC 9421 and tests both spellings of the tag. For merchants on Stripe he considers Shared Payment Tokens, which carry Mastercard agentic tokens. He also runs the Verifiable Intent examples, expecting signed intent to become part of certification.
Models fraud and disputes for an issuer, acquirer or merchant, and decides how agent transactions are scored and reviewed. Source [2, 8, 16, 44]
Goals
Separate agent traffic from fraud
Use signed evidence in disputes
Avoid blanket declines of agent purchases
Pains
No public description of the agent information or the probability score fields
Verifiable Intent has no revocation protocol in 0.1
Form-filling agents look like bots
Implements
Rules keyed on agent indicators and signature verification results
Review queues for deferred orders that fail intent validation
Dispute evidence collection
Must trust
The network's agent information and score
Agent certification
Merchant intent validation
Questions, first steps, metrics and a day in the life
Questions they ask
How reliable is the agent information today?
What does a Verifiable Intent chain prove in a dispute?
Which attacks does the threat model leave open?
First three steps
List the agent signals you receive today
Read the Verifiable Intent security model
Ask the network for probability score documentation
Metrics they care about
Fraud basis points on agent transactions
Dispute win rate with evidence
Manual review rate
A day in the life
Lena runs fraud strategy for an acquirer. Agent transactions are still a small slice, but her models treat form-filling agents like bots. Mastercard's 2026-09-30 probability score tells her the network itself does not always know when an agent was involved. She reads the Verifiable Intent threat model and likes what it covers, replay, constraint stripping and split-agent attacks, but notes that version 0.1 has no revocation protocol. She sets up a separate review queue for agent orders and asks her network contact what the score looks like in the message.
Holds the Mastercard card, authorizes an agent with a passkey and sets its limits. Source [8, 12, 14]
Goals
Delegate routine purchases safely
Keep the real card number private
Get money back if the agent gets it wrong
Pains
Unclear rules when an agent buys the wrong item within its limits
Little visibility into which agents are trusted
Limits that vary by platform
Implements
Passkey authentication
Merchant, amount and time limits for the agent
Must trust
The agent platform to follow instructions
The issuer to honor dispute rights
Mastercard certification
Questions, first steps, metrics and a day in the life
Questions they ask
Can the agent see my card number?
How do I stop the agent?
Who refunds a wrong purchase?
First three steps
Check that your bank supports Agent Pay
Set tight merchant and amount limits
Review your statement for agent purchases
Metrics they care about
Purchases completed as intended
Disputes raised
Time to cancel an agent
A day in the life
Tom asks his assistant app to book a ski weekend under a set budget. The app asks him to confirm with a passkey and to choose limits: this merchant, this amount, this weekend. It never sees his card number; it gets an agentic token that works only within those limits. If the booking is wrong he can dispute it with his bank like any card purchase, because standard chargeback rights apply. What he cannot find is a simple button to stop one agent everywhere, so he plans to keep limits tight and short.
Tokenization and pilots. It names MDES for agentic tokens; Mastercard's agentic-token pages do not, and name it only for Virtual Card Tokens and Token Connect.
Defines agentic payments as transactions started and completed by AI agents, sets out how they work across retail, e-commerce and decentralized finance, and classifies their technical, legal and societal risks, including liability gaps and regulatory non-compliance.
Why it matters here: One of the few peer-reviewed legal analyses aimed at agent payments specifically, useful for the compliance and liability questions every protocol in the atlas leaves to implementers. AP2: Risks and regulation of agent payments. Mastercard Agent Pay: Survey of risks and regulation for AI agents in payments that covers card-network programs. Agentic Commerce Protocol (ACP): Risks and regulation of AI agents in payments, covering ACP.
Metadata verified 2026-10-11 through doi-negotiation.
Show BibTeX
@article{amariles2026payments,
title = {{AI Agents in Payments: Applications, Risks and Regulations}},
author = {David Restrepo Amariles and Damien Charlotin and Liyun He-Guelton},
year = {2026},
journal = {European Journal of Risk Regulation},
volume = {17},
number = {3},
pages = {884--907},
publisher = {Cambridge University Press},
doi = {10.1017/err.2026.10103},
url = {https://doi.org/10.1017/err.2026.10103}
}
Defines the agentic clearing problem, deciding whether an agent met its delegated obligation and which settlement action follows, and argues that MCP, A2A, x402, AP2 and the Visa and Mastercard network agent protocols all assume that determination without producing it. RAILS specifies seven primitives and a formal model of admissibility-graded verification yielding a soundness property that no financially material settlement rests on evidence below the obligation's admissibility floor. The abstract names Visa and Mastercard generically rather than by protocol name.
Why it matters here: Names x402, ap2 and the Visa and Mastercard agent programs as rails that lack a clearing layer; useful for the atlas comparison of where disputes and fulfillment evidence live. Visa Trusted Agent Protocol: The only paper found that names TAP; places it as the network's edge attestation layer.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{valoisfranklin2026rails,
title = {{RAILS: Verification-Native Clearing For Agentic Commerce}},
author = {Adrian de Valois-Franklin and Alex Bogdan},
year = {2026},
eprint = {2606.08790},
archivePrefix = {arXiv},
primaryClass = {cs.AI},
url = {https://arxiv.org/abs/2606.08790}
}
Argues that Know Your Agent regimes modeled on human identity verification and credit scores are incomplete because language model agents are assemblages of mutable modules (models, prompts, tool policies, memory) with fluid personas that may not internalize sanctions, so identifiability, predictability, credibility and rehabilitability lack grounding. It proposes observability-based, ex ante, protocol-level behavioral harnesses in place of ex post reputation.
Why it matters here: A direct critique of the premise behind ERC-8004's Reputation Registry and of KYA-style identity checks in TAP and Agent Pay: if the sanctioned identity can be swapped out, reputation does not discipline the agent. ERC-8004: Trustless Agents: Questions whether LLM agents have the stable identity reputation needs.
Metadata verified 2026-10-10 through doi-negotiation.
Show BibTeX
@inproceedings{hu2026dissociative,
title = {Dissociative Identity: Language Model Agents Lack Grounding for Reputation Mechanisms},
author = {Botao Amber Hu and Helena Rong and Max Van Kleek},
year = {2026},
booktitle = {Proceedings of the 2026 ACM Conference on Fairness, Accountability, and Transparency (FAccT '26)},
publisher = {ACM},
pages = {4199-4219},
doi = {10.1145/3805689.3806748},
eprint = {2605.30169},
archivePrefix = {arXiv},
url = {https://arxiv.org/abs/2605.30169}
}
Gives the first provable-security analysis of FIDO2, covering WebAuthn and the CTAP2 authenticator protocol; it proves security properties of WebAuthn, finds weaknesses in CTAP2 and proposes a stronger replacement.
Why it matters here: Passkey and FIDO-based consent is how card networks propose to confirm a cardholder before an agent pays; this paper pins down what the underlying protocol does and does not guarantee. Mastercard Agent Pay: Security analysis of FIDO2, the basis of the passkeys used for Agent Pay consent.
Metadata verified 2026-10-11 through doi-negotiation.
Show BibTeX
@inproceedings{barbosa2021fido2,
title = {{Provable Security Analysis of FIDO2}},
author = {Manuel Barbosa and Alexandra Boldyreva and Shan Chen and Bogdan Warinschi},
year = {2021},
booktitle = {Advances in Cryptology -- CRYPTO 2021},
series = {Lecture Notes in Computer Science},
pages = {125--156},
publisher = {Springer},
eprint = {2020/756},
doi = {10.1007/978-3-030-84252-9_5},
url = {https://doi.org/10.1007/978-3-030-84252-9_5}
}
Proposes Issuer-Sovereign Agentic Payments, in which the cardholder approves a spending rule once with the issuing bank's own authentication component, and at payment time the bank checks the merchant against that rule and generates the card authentication value only if allowed, so the transaction rides normal card rails with issuer validation and no extra execution-time dependency.
Why it matters here: A counterproposal to network-led designs such as visa-tap and mastercard-agent-pay, where spending controls are enforced by the network or a credential provider rather than the issuer. Mastercard Agent Pay: Closest academic work to Agent Pay: issuer control over agent payments. No paper analyzes Agent Pay or Verifiable Intent directly. Visa Trusted Agent Protocol: Argues for issuer-side controls, contrasting with network-run agent recognition.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{sharma2026issuer,
title = {{Issuer-Sovereign Agentic Payments}},
author = {Dishant Sharma and Rajneesh Kaushal and Ashu Kanaujia},
year = {2026},
eprint = {2609.27452},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2609.27452}
}
Introduces multi-step indirect prompt injection, in which an adversarial goal is split into innocuous sub-steps spread across pages along the agent's navigation path, and a benchmark of 480 cases. Across six computer-use agents, decomposition raises attack success, for one model from 41.7 percent single-step to 72.9 percent at three steps.
Why it matters here: Computer-use agents that shop across several merchant pages are the deployment TAP and Agent Pay credentials are issued to; staged injections evade per-page defenses.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{zhan2026stepjack,
title = {StepJack: Benchmarking Computer-Use Agent Safety Against Multi-Step Indirect Prompt Injection},
author = {Zhuoxin Zhan and Akbar Rafiey and Avery Ma and Leila Pishdad and Layla El Asri},
year = {2026},
eprint = {2608.06477},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2608.06477},
note = {arXiv preprint}
}
Proposes the Verifiable Action Card, which rebuilds the confirmation prompt in an agentic browser from the action that will actually execute, shows it in trusted browser chrome and binds approval to that exact action at dispatch. On a 24-scenario benchmark it cuts attack success from 68% to 100% down to 0% across the tested models.
Why it matters here: Human confirmation is the step-up that card agent programs and AP2 rely on for higher-risk purchases; this shows how that confirmation can be forged and one way to bind it to the real transaction.
Metadata verified 2026-10-11 through arxiv.
Show BibTeX
@misc{irshad2026vac,
title = {{The Verifiable Action Card: Trustworthy Human-in-the-Loop Control for Secure Autonomous Agents}},
author = {Hasnain Irshad and Anam Mughees and Neelam Mughees and Abdullah Mughees and Imtiaz Ali Soomro},
year = {2026},
eprint = {2609.18411},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2609.18411}
}
Buys traffic from 20 bot services against a honey site protected by two commercial anti-bot products and finds that about half the requests evade detection by altering browser fingerprints; inconsistencies among altered attributes then help detect them.
Why it matters here: Measures how weak fingerprint-based bot detection is, which is the problem Visa TAP and Mastercard Agent Pay address by having trusted agents sign their requests instead of hiding as browsers. Visa Trusted Agent Protocol: Why fingerprint-based bot detection fails and cryptographic agent identity appeals.
Metadata verified 2026-10-11 through doi-negotiation.
Show BibTeX
@inproceedings{venugopalan2025fpinconsistent,
title = {{FP-Inconsistent: Measurement and Analysis of Fingerprint Inconsistencies in Evasive Bot Traffic}},
author = {Hari Venugopalan and Shaoor Munir and Shuaib Ahmed and Tangbaihe Wang and Samuel T. King and Zubair Shafiq},
year = {2025},
booktitle = {Proceedings of the 2025 ACM Internet Measurement Conference},
pages = {134--149},
publisher = {ACM},
doi = {10.1145/3730567.3732919},
url = {https://doi.org/10.1145/3730567.3732919}
}
Analyzes relay attacks on contactless EMV, including a relay of Apple Pay transit transactions to locked iPhones, and proposes a relay protection protocol with a formal proof that would fit within existing EMV deployments.
Why it matters here: Relay is the card-present version of an agent acting far from the cardholder; the paper shows why binding a payment to its context, not just to valid credentials, matters. Mastercard Agent Pay: Relay protection in EMV; background for binding a token to an authorized interaction.
Metadata verified 2026-10-11 through doi-negotiation.
Show BibTeX
@inproceedings{radu2022relay,
title = {{Practical EMV Relay Protection}},
author = {Andreea-Ina Radu and Tom Chothia and Christopher J.P. Newton and Ioana Boureanu and Liqun Chen},
year = {2022},
booktitle = {2022 IEEE Symposium on Security and Privacy (SP)},
pages = {1737--1756},
publisher = {IEEE},
doi = {10.1109/SP46214.2022.9833642},
url = {https://doi.org/10.1109/SP46214.2022.9833642}
}
Shows that an attacker can make a terminal treat a Mastercard contactless card as a Visa card, routing the transaction so that the earlier Visa PIN bypass applies; the authors demonstrated it with an Android app in real transactions.
Why it matters here: A mismatch between card brand and network routing breaks assumptions on both sides; agent payment designs that span Visa and Mastercard credentials must bind the brand and network explicitly. Mastercard Agent Pay: Cross-brand confusion attacks; relevant where Mastercard and Visa agent tokens travel through the same SPT and edge.
Metadata verified 2026-10-11 through publisher.
Show BibTeX
@inproceedings{basin2021mixup,
title = {{Card Brand Mixup Attack: Bypassing the PIN in non-Visa Cards by Using Them for Visa Transactions}},
author = {David Basin and Ralf Sasse and Jorge Toro-Pozo},
year = {2021},
booktitle = {30th USENIX Security Symposium (USENIX Security 21)},
publisher = {USENIX Association},
url = {https://www.usenix.org/conference/usenixsecurity21/presentation/basin}
}
Builds a Tamarin model of the EMV contactless protocol and finds that unauthenticated card data lets an attacker bypass the PIN for high-value Visa contactless payments; the authors propose and verify fixes that terminals can deploy.
Why it matters here: The method, formal modeling of a payment network protocol that exposes a deployable attack, is what recent work applies to agent payment specs; it also shows how fragile unauthenticated fields are. Mastercard Agent Pay: Formal analysis of EMV, the card protocol family behind the tokens and cryptograms Agent Pay relies on.
Metadata verified 2026-10-11 through doi-negotiation.
Show BibTeX
@inproceedings{basin2021emv,
title = {{The EMV Standard: Break, Fix, Verify}},
author = {David Basin and Ralf Sasse and Jorge Toro-Pozo},
year = {2021},
booktitle = {2021 IEEE Symposium on Security and Privacy (SP)},
pages = {1766--1781},
publisher = {IEEE},
doi = {10.1109/SP40001.2021.00037},
url = {https://doi.org/10.1109/SP40001.2021.00037}
}
Mike Bond, Omar Choudary, Steven J. Murdoch and others. 2014. IEEE Symposium on Security and Privacy 2014. Peer reviewedDOI 10.1109/SP.2014.11 (external link)
Finds that many EMV terminals and ATMs generate weak or predictable "unpredictable numbers", which lets an attacker who briefly accesses a card harvest authorization cryptograms in advance and replay them later as if the card were present (the pre-play attack).
Why it matters here: Replay of pre-computed authorizations is the same failure class that agent payment specs try to block with nonces, timestamps and per-request signatures, as in Visa TAP signatures and network tokens. Mastercard Agent Pay: Unpredictable-number weaknesses: a reminder that cryptogram freshness matters for DSRP payloads too.
Metadata verified 2026-10-11 through doi-negotiation.
Show BibTeX
@inproceedings{bond2014chipandskim,
title = {{Chip and Skim: Cloning EMV Cards with the Pre-play Attack}},
author = {Mike Bond and Omar Choudary and Steven J. Murdoch and Sergei Skorobogatov and Ross Anderson},
year = {2014},
booktitle = {2014 IEEE Symposium on Security and Privacy},
pages = {49--64},
publisher = {IEEE},
doi = {10.1109/SP.2014.11},
url = {https://doi.org/10.1109/SP.2014.11}
}
Steven J. Murdoch, Saar Drimer, Ross Anderson and others. 2010. IEEE Symposium on Security and Privacy 2010. Peer reviewedDOI 10.1109/SP.2010.33 (external link)
Shows a man-in-the-middle attack on EMV chip cards in which a device between card and terminal makes the terminal believe the PIN was verified while the card believes signature verification was used, so a stolen card works with any PIN.
Why it matters here: A reminder that card security fails at the seams between parties that each see half the transaction; agent payment schemes add another party, the agent, between cardholder and merchant. Mastercard Agent Pay: Shows how card protocol flaws persist when issuers, networks and merchants each assume someone else checks.
Metadata verified 2026-10-11 through doi-negotiation.
Show BibTeX
@inproceedings{murdoch2010chipandpin,
title = {{Chip and PIN is Broken}},
author = {Steven J. Murdoch and Saar Drimer and Ross Anderson and Mike Bond},
year = {2010},
booktitle = {2010 IEEE Symposium on Security and Privacy},
pages = {433--446},
publisher = {IEEE},
doi = {10.1109/SP.2010.33},
url = {https://doi.org/10.1109/SP.2010.33}
}
Criticizes the original 3-D Secure schemes (Verified by Visa and MasterCard SecureCode) for training users to enter passwords into unverifiable inline frames, shifting liability onto cardholders, and weakening security in the name of convenience.
Why it matters here: 3-D Secure is the existing step-up and liability mechanism that card-based agent payments build on or bypass; this paper explains why authentication that users cannot verify fails. Mastercard Agent Pay: An earlier network-run authentication layer and how liability design shaped it; Agent Pay faces the same liability question. Visa Trusted Agent Protocol: Lessons from an earlier network-run authentication layer and its liability design.
Metadata verified 2026-10-11 through doi-negotiation.
Show BibTeX
@inproceedings{murdoch20103dsecure,
title = {{Verified by Visa and MasterCard SecureCode: Or, How Not to Design Authentication}},
author = {Steven J. Murdoch and Ross Anderson},
year = {2010},
booktitle = {Financial Cryptography and Data Security},
series = {Lecture Notes in Computer Science},
pages = {336--342},
publisher = {Springer},
doi = {10.1007/978-3-642-14577-3_27},
url = {https://doi.org/10.1007/978-3-642-14577-3_27}
}
Builds the standard model of competition between two-sided platforms that must attract both buyers and sellers, showing how price structure, not just price level, determines adoption, with payment cards as a leading example.
Why it matters here: Every agentic checkout protocol is a two-sided platform bet; this model explains the subsidy and fee choices behind merchant and agent adoption of ACP, UCP and card network programs. Agentic Commerce Protocol (ACP): Two-sided market economics behind platform fees on merchants. UCP: Two-sided platform economics behind a protocol that joins agent surfaces and merchants.
Metadata verified 2026-10-11 through doi-negotiation.
Show BibTeX
@article{rochet2003platform,
title = {{Platform Competition in Two-Sided Markets}},
author = {Jean-Charles Rochet and Jean Tirole},
year = {2003},
journal = {Journal of the European Economic Association},
volume = {1},
number = {4},
pages = {990--1029},
doi = {10.1162/154247603322493212},
url = {https://doi.org/10.1162/154247603322493212}
}
Models a payment card association in which issuers and acquirers cooperate on a network but compete for cardholders and merchants, and studies how the interchange fee balances use and acceptance of cards.
Why it matters here: Interchange is the economic engine that card-based agent payments inherit; the paper explains why networks set fees on one side to grow the other, which shapes who pays for agent checkout. Mastercard Agent Pay: Card network economics and interchange; Agent Pay leaves card economics unchanged so far.
Metadata verified 2026-10-11 through doi-negotiation.
Show BibTeX
@article{rochet2002cooperation,
title = {{Cooperation among Competitors: Some Economics of Payment Card Associations}},
author = {Jean-Charles Rochet and Jean Tirole},
year = {2002},
journal = {The RAND Journal of Economics},
volume = {33},
number = {4},
publisher = {Wiley},
doi = {10.2307/3087474},
url = {https://doi.org/10.2307/3087474}
}
Documents a national agent-identity system in China, scheduled for public launch in Q3 2026, in which an agent is bound to a verified legal principal that is not disclosed to business-layer participants and can be re-identified only by compelling two separate government agencies, a mechanism the authors call split-knowledge binding and describe as institutional rather than cryptographic. The paper is a pre-launch v1 and promises post-launch measurements.
Why it matters here: A state-run alternative to erc-8004 style permissionless identity and to network-issued agent identity in visa-tap and mastercard-agent-pay; status is announced, not yet measured.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{he2026accountable,
title = {{Accountable yet Anonymous AI Agents - Split-Knowledge Binding in National Agent-Identity Layer in China}},
author = {Yifan He and Zhiguang Shan and Le Luo and Wei Wang},
year = {2026},
eprint = {2607.23207},
archivePrefix = {arXiv},
primaryClass = {cs.CY},
url = {https://arxiv.org/abs/2607.23207}
}
Grey literature: central banks, standards drafts and white papers
Global Legal Entity Identifier Foundation (GLEIF). 2026. GLEIF Working Paper Series. Not peer reviewed
A working paper (cover dated September 2026, written by contributors from GLEIF, Curvy Protocol, zERC20, Terminal 3 and an independent expert) arguing that existing law can allocate liability for agent payments but practical proof of delegated authority is missing. It proposes Agent Mandate Credentials anchored in the verifiable LEI to show which organization stands behind an agent and what it may do.
Why it matters here: Offers an organizational-identity answer to the "who is behind this agent" question that ERC-8004 registries, Visa TAP keys and Agent Pay tokens each answer differently.
Metadata verified 2026-10-11 through publisher.
Show BibTeX
@techreport{gleif2026agenticpayments,
title = {{Agentic AI in Payments: Establishing Interoperable Trust and Control}},
author = {{Global Legal Entity Identifier Foundation (GLEIF)}},
year = {2026},
institution = {Global Legal Entity Identifier Foundation},
type = {GLEIF Working Paper Series},
month = {sep},
url = {https://www.gleif.org/organizational-identity/research-publications/2026-08-13_agentic_ai_in_payments_v1.0-1.pdf}
}
Prem Munday. 2026. Bank Underground (Bank of England staff blog). Not peer reviewed
A Bank of England staff blog post (2026-05-21) on how agentic commerce could reshape payment design, stressing that deployers stay legally responsible for their agents and asking how existing frameworks apply to card, account-to-account and tokenized rails. Views are the author's, not the Bank's.
Why it matters here: Shows how a payment system operator and overseer frames the contest between card-network agent programs and newer rails such as stablecoin-based x402.
Metadata verified 2026-10-11 through publisher.
Show BibTeX
@misc{munday2026bankunderground,
title = {{Agentic commerce and the battleground for new payments infrastructure}},
author = {Prem Munday},
year = {2026},
howpublished = {Bank Underground blog, Bank of England},
note = {Published 2026-05-21},
url = {https://bankunderground.co.uk/2026/05/21/agentic-commerce-and-the-battleground-for-new-payments-infrastructure/}
}
Reshmi Suresh. 2026. Worldpay Insights article. Not peer reviewed
An acquirer's analysis (2026-07-30) noting that Visa, Mastercard and American Express have all launched frameworks for agent transactions while the question of who bears the loss in a dispute remains largely open.
Why it matters here: Liability allocation is the unresolved commercial question behind TAP and Agent Pay; this is the merchant-acquirer view of it. Visa Trusted Agent Protocol: Acquirer view that no agent liability shift exists yet.
Metadata verified 2026-10-11 through publisher.
Show BibTeX
@misc{suresh2026worldpay,
title = {{Agentic commerce liability is still being written}},
author = {Reshmi Suresh},
year = {2026},
howpublished = {Worldpay},
note = {Article, 2026-07-30},
url = {https://worldpay.com/en/insights/articles/agentic-commerce-liability-is-still-being-written}
}
Examines how agentic AI could change authorization, liquidity, settlement, compliance and resilience in payments, using a three-layer model of intent, authorization and settlement. It stresses the tension between probabilistic AI behavior and the deterministic requirements of payment systems.
Why it matters here: The IMF view of where agent decisions should stop and rule-based payment execution should begin, a split visible in how AP2 mandates and card network tokens separate intent from settlement.
Metadata verified 2026-10-11 through doi-negotiation.
Show BibTeX
@techreport{davidovic2026imfnote,
title = {{How Agentic AI Will Reshape Payments}},
author = {Sonja Davidovic and Hervé Tourpe},
year = {2026},
institution = {International Monetary Fund},
type = {IMF Notes},
number = {2026/004},
month = {apr},
doi = {10.5089/9781513533308.068},
url = {https://doi.org/10.5089/9781513533308.068}
}
T. Meunier, S. Major. 2026. IETF Internet-Draft draft-ietf-webbotauth-httpsig-protocol-00 (Web Bot Auth working group). Not peer reviewed
The first Web Bot Auth working group draft (revision 00, 2026-09-01) for identifying automated HTTP clients with HTTP Message Signatures. It defines the Signature-Agent header for in-band key discovery, a JWKS-based key directory format and a well-known URI for serving it.
Why it matters here: The Visa TAP spec calls itself aligned with Web Bot Auth, Cloudflare says the Visa and Mastercard agent protocols build on it, and UCP offers an optional Web Bot Auth profile; this working group draft, posted almost a year after TAP launched, is the standards-track form of that request signing. Mastercard Agent Pay: The HTTP Message Signatures draft for automated traffic that Agent Pay's edge verification resembles. Visa Trusted Agent Protocol: The IETF working group draft TAP is compared against.
Metadata verified 2026-10-11 through publisher.
Show BibTeX
@misc{meunier2026webbotauth,
title = {{HTTP Message Signatures for automated traffic}},
author = {T. Meunier and S. Major},
year = {2026},
howpublished = {Internet-Draft draft-ietf-webbotauth-httpsig-protocol-00, IETF},
note = {Work in progress, 2026-09-01},
url = {https://datatracker.ietf.org/doc/draft-ietf-webbotauth-httpsig-protocol/}
}
Christopher J. Waller. 2026. Speech at Sibos 2026, Miami, Florida. Not peer reviewed
A Federal Reserve Governor speech separating agent-assisted commerce, where the buyer decides and pays, from agent-delegated commerce, where an agent shops and pays within guardrails, and naming authentication, liability and fraud as the main barriers to the delegated model. The Board speech feed dates it 2026-09-29.
Why it matters here: States in policy terms the shift every protocol in the atlas addresses: proving that an agent holds authority to pay, not only that the cardholder is genuine.
Metadata verified 2026-10-11 through publisher.
Show BibTeX
@misc{waller2026sibos,
title = {{Payments in the Age of AI Agents}},
author = {Christopher J. Waller},
year = {2026},
howpublished = {Speech, Board of Governors of the Federal Reserve System},
note = {Sibos 2026, Miami, Florida, 2026-09-29},
url = {https://www.federalreserve.gov/newsevents/speech/waller20260928a.htm}
}
Agent Pay's defenses are network controls: only registered and certified agents get tokens, tokens replace card numbers and carry limits, agent requests are signed with a nonce and a short window, and consumers authenticate with passkeys in the live pilots. Much of the program is not public, so the threats below rest on Mastercard's guides, Cloudflare's description and the open Verifiable Intent threat model. No CVE or published attack specific to Agent Pay was found as of 2026-10-11.
STRIDE threats (12)
STRIDE
Threat
Spec mitigation
Implementer notes
S Spoofing
Agent impersonation with a stolen signing keyAn attacker who steals a registered agent's private key can sign requests that verify against the Mastercard key directory. Source [8, 35]Preconditions: Key stored without hardware protection; No fast delisting.Impact: Merchants treat the attacker as a trusted agent; any token the attacker also holds can be used.
Partly
Keep agent keys in hardware; ask Mastercard how to rotate and delist keys, which is not documented publicly.
S Spoofing
Unregistered bot claiming to be an agentA scraper adds a Signature-Input header with an Agent Pay tag but its keyid is not in the directory. Source [8]Preconditions: Verifier skips the directory lookup.Impact: Bot traffic passes as agent traffic.
Mitigated by spec
Mastercard's decision table says to block when the key is not found. The Level 1 sample verifier accepts only Visa tags, so do not copy it as is.
S Spoofing
Card-on-file bypassAn agent pays with a card the consumer already stored at the merchant instead of an agentic token. Source [8]Preconditions: Merchant allows card on file for the session.Impact: The network cannot see the payment as agentic, so agent controls and flags do not apply.
Partly
Mastercard forbids it for certified agents; merchants cannot detect it from the payment alone.
T Tampering
Request replay at the edgeAn attacker resends a captured signed request. Source [8, 35]Preconditions: Verifier does not track nonces; Long created to expires window.Impact: Duplicate actions on the merchant site.
Mitigated by spec
Reject reused nonces and requests outside the window; Cloudflare lists both checks.
T Tampering
Checkout and payment mismatchAn agent or intermediary pairs a payment credential with a different checkout than the one the user approved. Source [20, 44]Preconditions: Verifiable Intent in use; Verifier skips the hash binding check.Impact: User pays for a basket it did not approve.
Mitigated by spec
Verify that L3a transaction_id equals L3b checkout_hash and recompute checkout_hash from checkout_jwt.
T Tampering
Constraint strippingAn agent removes a constraint from an open mandate before presenting it. Source [44, 46]Preconditions: Verifiable Intent in use.Impact: Agent spends outside the user limits.
Mitigated by spec
The L2 signature covers every constraint; verify it and reject open mandates with unknown constraint types.
T Tampering
Duplicate digests rejected by standard librariesThe Verifiable Intent L2 format lists each mandate digest twice, which RFC 9901 says verifiers must reject. Source [20, 39, 47]Preconditions: Verifier uses a strict SD-JWT library.Impact: Valid credentials fail, or implementers weaken checks to accept them.
Left to implementers
Track issue 29; do not disable duplicate-digest checks globally.
R Repudiation
Disputed agent purchase without evidenceA consumer says the agent bought something they did not want, within the token limits. Source [8, 17, 44]Preconditions: No Verifiable Intent chain kept; No agent-specific reason code.Impact: Dispute outcome depends on general chargeback rules; liability is unclear.
Partly
Keep intent records and signatures; Verifiable Intent provides evidence but assigns no liability.
I Information disclosure
Transaction linkability through always-visible claimsThe sub claim and last four PAN digits in L1 are always visible to verifiers. Source [44]Preconditions: Verifiable Intent in use across merchants.Impact: Merchants and networks can link a user's purchases for the life of L1, about a year.
Left to implementers
Use short-lived L1 credentials where possible; this is a stated limitation of the spec.
D Denial of service
Unreachable key directoryVerifiers cannot reach the Mastercard key directory. Source [8, 35]Preconditions: Directory outage or unknown location.Impact: Edge verification fails closed (agents blocked) or open (bots admitted).
Left to implementers
The only host in the docs does not resolve; agree on the location with Mastercard and cache keys with a short lifetime.
E Elevation of privilege
Split-agent attackTwo different agent keys are bound into the checkout and payment mandates of one pair, so one agent can complete what the other started. Source [20, 44]Preconditions: Verifiable Intent Autonomous mode.Impact: Delegation escapes the intended agent.
Mitigated by spec
Require identical cnf.jwk in both mandates of the pair.
E Elevation of privilege
Budget overrun across merchantsAn agent spends under the per-transaction limit at several merchants until the total exceeds the budget. Source [44, 46]Preconditions: Network does not keep cumulative state.Impact: Total spend above what the user approved.
Partly
The spec says this cannot be enforced cryptographically; the network must track spend per mandate pair, and no API for that state is defined.
Preconditions: Verifiable Intent Autonomous mandate with amount_range and budget; Network without cumulative tracking.
Agent buys at merchant A under amount_range
Agent buys at merchant B under amount_range
Total exceeds budget max
Impact: Spend above the user budget unless the network keeps state.
Published research findings
Issuer-Sovereign Agentic Payments: Closest academic work: argues for issuer control over agent payments; does not analyze Agent Pay itself. (paper in section G) Source [62]
A Formal Analysis of Agent Payment Protocols: Models x402, MPP, ACP and AP2 in Tamarin; Agent Pay and Verifiable Intent are not modeled. (paper (not listed in section G)) Source [63]
Verifiable Intent issue 29: duplicate digests in L2: Reports that the L2 format conflicts with RFC 9901 and that a common SD-JWT library rejects every L2 credential; open with no maintainer response as of 2026-10-11. Source [39, 47]
The EMV Standard: Break, Fix, Verify: Foundation: formal analysis of the EMV card protocol whose tokens and cryptograms Agent Pay relies on. (paper in section G) Source [64]
Verified by Visa and MasterCard SecureCode: Or, How Not to Design Authentication: Foundation: an earlier network-run authentication layer and how liability design shaped its weaknesses. (paper in section G) Source [65]
CVEs and advisories
No CVE or advisory is recorded for this protocol as of the last verification.
Agent Pay is control-heavy by design: the network decides which agents may hold tokens, and the tokens carry merchant, amount and time limits. The gaps are in what happens after something goes wrong: no public revocation path, no agent-wide kill switch and no agent-specific dispute rules.
Registered agents sign requests with RFC 9421 and the tag Agent-pay-auth; verifiers check against the Mastercard key directory at the CDN or merchant. Source [8, 35]
Agent registration (know your agent)
Native
Registration, security review, certification and trusted agent lists; Skyfire named as Know Your Agent partner on 2026-09-30. Source [7, 16]
User consent capture
Native
Consumer authorizes the agent and sets limits; passkeys in regional pilots; Verifiable Intent L2 signed by the user key. Source [8, 9, 12]
Spending caps
Native
Tokens limited by merchant, amount or time window; Verifiable Intent amount_range and budget constraints. Source [8, 46]
Merchant or payee scoping
Native
Merchant-specific tokens; Verifiable Intent allowed_merchants and allowed_payees; Intent API srcDpaId check. Source [2, 8, 46]
Time windows and expiry
Native
Time-limited tokens, signature created and expires, orderExpiry, Verifiable Intent layer lifetimes (L3 at most one hour). Source [2, 8, 20]
Revocation
Partial
No public revocation API for agents or tokens; Verifiable Intent 0.1 has no revocation protocol, only JWKS key removal and expiry. Source [44, 45]
Step-up authentication
Partial
Passkeys at consent; deferred orders escalated to the consumer; 3DS for agentic flows still in development at networks and EMVCo. Source [2, 8, 12]
Replay protection
Native
Mandatory nonce and short window on signatures; single-use tokens and one-time DTVC; Verifiable Intent nonce, aud and one L3 pair per mandate pair. Source [8, 37, 44]
Receipts and evidence
Partial
Verifiable Intent chain gives dispute evidence; intent records kept as chargeback evidence; no receipt object in the program. Source [2, 44]
Dispute support
Partial
Standard chargeback rights; no agent-specific reason codes or liability shift; Verifiable Intent leaves dispute choreography out of scope. Source [1, 8, 44]
Reputation
None
No public agent reputation score; the probability score rates transactions, not agents. Source [16]
Monitoring signals
Native
Agent transactions recognizable to issuers; probability score in US testing from 2026-09-30; Verifiable Intent risk_data at consent. Source [1, 16, 20]
Kill switch
External
Issuers keep card-level blocks and declines; no documented control to disable one agent across the network. Source [7, 44]
No public revocation. Neither the program nor Verifiable Intent 0.1 documents how to revoke an agent, a token or a mandate before expiry. Source [44, 45]
No agent-wide kill switch. Issuers can block a card, but no documented control disables one agent across all its tokens. Source [7]
Stateful limits without an API. Budgets and recurrence need the network to track spend per mandate pair; the spec defines no API for that state. Source [44]
Dispute rules unpublished. No agent-specific reason codes or liability shift as of 2026-10-11. Source [8, 17]
Where an independent controls layer can act
Before authorization
Agent registration and token scoping Certify agents and set merchant, amount and time limits when the token is provisioned. Source [7, 8]
At signing
User mandate The user signs Verifiable Intent L2 with constraints; a policy engine can review constraints before the user signs. Source [20]
At the edge
Agent request verification Verify RFC 9421 signatures, nonce and window at the CDN or merchant; block unknown keys. Source [8, 35]
At settlement
Network checks at authorization Token limits, DTVC validation, Verifiable Intent constraints and cumulative budget at the network; issuer final decision. Source [9, 38]
After the fact
Disputes and monitoring Chargebacks under standard rules, intent records and Verifiable Intent chains as evidence, probability score for monitoring. Source [2, 16]
Implementer checklist
Verify agent signatures and block unknown keys Mastercard's decision table blocks missing fields and unknown keys. Source [8]
Keep a nonce cache for the signature window Stops replay of signed requests. Source [35]
Set the shortest token and mandate lifetimes that work Expiry is the main revocation tool today. Source [44]
Check intent totals and srcDpaId at Level 3 Mastercard says to reject totals above orderTotalAmount or a different merchant id. Source [2]
Store intent records and Verifiable Intent chains They are the evidence in a dispute. Source [2, 44]
Do not let agents use cards on file The network cannot then recognize the payment as agentic. Source [8]
J. Compliance and regulation
Not legal advice. This is a study summary of public rules as of the dates cited. Ask counsel about your situation.
Agent Pay runs on card rails, so card law and network rules apply: Regulation Z and E in the US, PSD2 consent and SCA in the EU, the UK Payment Services Regulations, and Mastercard's own rules. No regulator or network has published agent-specific liability rules as of 2026-10-11, and issuers and acquirers keep existing card liability until that changes.
Rules by topic and jurisdiction
Jurisdiction
What applies
Confidence
Consumer protection and liability
United States
Regulation Z caps cardholder liability for unauthorized credit card use; whether an agent acting outside its limits has apparent authority is an open question. Source [66]
Verified
United States
Regulation E excludes transfers by someone the consumer gave the access device to, until the consumer revokes that authority; a consumer who authorizes an agent on a debit card may carry losses until notice. Source [67]
Verified
United States
Senator Warner asked Treasury on 2026-06-02 to examine how current law allocates liability when agents err; no rule followed yet. Source [68]
Reported
European Union
PSD2 ties authorization to payer consent; applying that to a standing agent mandate, such as a Verifiable Intent Autonomous mandate, is untested. Source [72]
Reported
United Kingdom
The Payment Services Regulations 2017 treat a transaction as authorized only with payer consent (regulation 67) and cap payer liability at GBP 35 with exceptions (regulation 77). Source [76, 77]
Verified
Canada
No agent-specific payment liability rule was found in Canada; the Retail Payment Activities Act applies to payment service providers since 2025-09-08. Source [80, 81]
Unverified
Singapore
The MAS E-Payments User Protection Guidelines set liability for unauthorized e-payments; agent purchases are not addressed specifically. Source [85]
Verified
Card network rules
Mastercard says standard chargeback rights apply to agentic transactions; no agent-specific reason codes or liability shift were published as of 2026-10-11. Source [8, 17, 86]
Reported
Strong customer authentication
European Union
The RTS on SCA require dynamic linking of amount and payee for remote payments. Verifiable Intent presents its constraints and checkout_hash as a cryptographic form of dynamic linking but says it does not replace SCA. Source [70, 71]
Verified
United Kingdom
HM Treasury consulted from 2026-07-14 to 2026-10-06 on how authentication, consent and liability should adapt for agentic payments; no response yet. Source [78]
Verified
Card network rules
EMVCo's draft agentic framework (2026-09-01) proposes Intent Services that would complement Verifiable Intent and lists Know Your Agent and agent transaction indicators as possible future work. Source [58, 59]
Verified
AI-specific rules
European Union
AI Act Article 50 transparency applies from 2026-08-02: people must be told when they interact with an AI system, which reaches agent platforms selling to consumers. Source [73, 74]
Verified
United Kingdom
The FCA said on 2026-03-25 it will consider with HM Treasury whether regulation must change for agentic payments. Source [79]
Verified
Singapore
MAS Guidelines on AI Risk Management (issued 2026-10-07, effective 2027-10-07) name agentic AI systems and apply to issuers in Singapore. Source [83, 84]
Verified
Data protection
United States
California CCPA rules on automated decisionmaking technology apply from 2026-01-01 and may cover agent platforms that make purchase decisions. Source [69]
Verified
European Union
GDPR applies to the consumer data in mastercardIdToken and Verifiable Intent claims; Verifiable Intent keeps sub and pan_last_four always visible. Source [44, 75]
Verified
Canada
PIPEDA governs the personal information agent platforms and merchants collect in Canada. Source [82]
Verified
Card network rules
Mastercard says merchants accepting agent tokens keep their PCI scope unchanged, because they receive tokens, not card numbers. Source [8]
Verified
K. Observability lens
1 of 5 observability score
Nothing is on a public ledger: tokens, authorizations and agent information stay inside card network and issuer systems.
No event names, webhooks or public endpoints for Agent Pay are published.
Mastercard publishes partner names and milestones but no transaction counts or values.
The only public, inspectable artifact is the Verifiable Intent repository, which earns the single point.
Publicly observable
Public signals
What
Where
How
Program milestones and partner lists
Mastercard newsroom and Investor Relations PDFs
Read releases; they name banks and partners, never volumes. Source [12, 15, 18]
Verifiable Intent repository activity
GitHub API /repos/agent-intent/verifiable-intent
Stars, forks, issues and commits; 97 stars and no commits since 2026-04-20 as of 2026-10-11. Source [10, 11]
Developer documentation index
https://developer.mastercard.com/llms.txt and the Checkout Solutions release history
Check for new Agent Pay services and documentation releases. Source [27, 45]
Key directory location
/.well-known/http-message-signatures-directory on the Signature-Agent host
Mastercard points verifiers to this path; the only Mastercard host in the docs, agentpay-key-directory.mastercard.com, did not resolve on 2026-10-11, so the live location is unknown. Source [8, 35]
Documentation tool downloads
npm registry for @mastercard/developers-mcp and @mastercard/developers-agent-toolkit
Download counts show interest in the documentation tools only, not in payments. Source [87, 88]
Private by design
Agent registry and trusted lists. Held by Mastercard; not published.
Count or value of Agent Pay transactions. Source [16, 17] Caveat: No Mastercard release reports counts or values.
European banks with completed controlled live transactions
36 banks
Banks named by Mastercard as completing controlled live agentic transactions on Priceless.com. Source [15] Caveat: Controlled transactions, not commercial volume.
Latin American issuers and processors with live transactions
17 issuers and processors
Named participants completing live agentic transactions. Source [12] Caveat: Performed in controlled environments.
AP4M named participants and supporters
32 organizations
Organizations named in the AP4M launch release. Source [18] Caveat: Includes Mastercard Merchant Cloud; announced support, not live usage.
Verifiable Intent repository stars
99 stars
GitHub stargazers of agent-intent/verifiable-intent. Source [10] Caveat: Interest signal only; no commits since 2026-04-20.
Consumers projected to use agents routinely by 2030
1 in 10 consumers
Mastercard projection of routine agent purchasing. Source [16] Caveat: Projection; the release does not give its method.
Verify a two-layer chain at the networkverifiable-intent (Python reference SDK) 0.1.0Server sidepython
network_result = verify_chain( l1, l2, l3_payment=None, issuer_public_key=issuer.public_key, l1_serialized=l1.serialize(),)if not network_result.valid: for e in network_result.errors: print(e)
Simulate the agentic token lifecycle with signed requests and revocation, and build Verifiable Intent layers L1 to L3 with a verifier that shows which binding breaks.
Simulation, no real fundsFollows spec version Agent Pay developer guides (unversioned, read 2026-10-11)
Loading the simulation.
Keys are generated in this browser for this session only, on test chain identifiers or fixture data. No wallet connects and nothing is sent to a network.
P. Compare and compose
Agent Pay is not AP2, and the difference is structural. AP2 is Google’s open protocol for mandates between agents, merchants and credential providers; Agent Pay is a card network deciding which agents may hold its tokens.Source [1, 5] The two meet through : on main it uses the same four mandate types as AP2 v0.2 (mandate.checkout.open.1, mandate.checkout.1, mandate.payment.open.1, mandate.payment.1) and aligned semantics with a mandate. prefix on each key.Source [20, 21, 46] A 2026-04 VI commit is titled field alignment per AP2 schema updates, and both specifications now sit in ’s Payments Technical Working Group.Source [4, 34] No public source documents VI running inside a live AP2 flow.Source [4, 22]
Visa TAP is the closest neighbor. Cloudflare describes both programs as with a in , a mandatory and a directory hosted by each network.Source [35] The tags differ (Agent-pay-auth for Mastercard, agent-browser-auth and agent-payer-auth for Visa), and so do the tokens: “” names a Mastercard Agent Pay product on one side and a Visa Intelligent Commerce product on the other.Source [8, 23] A CDN can verify both with the same code path and two directories.Source [35]
For checkout protocols, Agent Pay is a credential, not a competitor. Under ACP, a Mastercard agentic network token can travel inside a Stripe SPT; the ACP schema itself mentions Mastercard only as a card brand and 3DS directory server value.Source [23, 60] VI proposes ACP extensions as a carrier but defines none.Source [22] Mastercard endorses UCP, and VI maps into UCP’s AP2 mandate extension, but no Agent Pay integration with UCP is documented.Source [22, 61]
The machine-payment links are thinner. In Mastercard’s release, Tempo says it is working with Mastercard on Machine Payments Protocol compatibility; Mastercard’s own text makes no MPP claim.Source [18] Mastercard is a premier member of the x402 Foundation, and Coinbase’s AP4M quote names x402, but no Agent Pay technical document mentions x402.Source [18, 24, 25] No documented relation links Agent Pay to ERC-8004.Source [8, 18]
Relations to other protocols
Compatible withfrom AP2: Verifiable Intent shares AP2 v0.2 vct values with aligned constraint semantics and different key prefixes (payment.amount_range versus mandate.payment.amount_range); both were contributed to FIDO on 2026-04-28. Source [93, 94, 95]
Compatible withMastercard Agent Pay to Agentic Commerce Protocol (ACP): Indirect: Stripe Shared Payment Tokens can carry Mastercard agentic network tokens, so an ACP checkout processed by Stripe can use one. ACP itself names Mastercard only as a card brand. Source [23, 60]
Compatible withMastercard Agent Pay to UCP: Verifiable Intent says its credentials can travel in UCP's AP2 mandate extension (now dev.ucp.common.payment.ap2_mandate). Mastercard endorses UCP; no Agent Pay integration is documented. Source [22, 55, 61]
Competes withMastercard Agent Pay to Visa Trusted Agent Protocol: Same edge pattern (RFC 9421 signature with a tag and nonce, network-hosted key directory), different tag and directory; both networks issue their own agentic tokens, which mean different products. Source [8, 23, 35]
ComplementsMastercard Agent Pay to AP2: Agent Pay is not AP2. Through Verifiable Intent it uses the same four mandate vct values as AP2 v0.2 on main, with aligned constraint semantics and a mandate. key prefix; both were contributed to FIDO on 2026-04-28. No live VI use inside AP2 is documented. Source [4, 20, 21]
ComplementsMastercard Agent Pay to Stripe MPP (Machine Payments Protocol): Tempo, quoted in Mastercard's AP4M release, says it is working with Mastercard on Machine Payments Protocol compatibility; Mastercard makes no MPP claim itself and maintains no MPP payment method. Source [18, 96]
ComplementsMastercard Agent Pay to x402: Mastercard is a premier member of the x402 Foundation, and Coinbase's AP4M quote names x402; no Agent Pay technical document mentions x402. Source [18, 24]
Compatible withfrom Agentic Commerce Protocol (ACP): No documented protocol link. Stripe says it might use Mastercard Agent Pay tokens under SPT card payments. Source [97]
Compatible withfrom Stripe MPP (Machine Payments Protocol): Tempo's statement only: in Mastercard's 2026-06-10 AP4M release Tempo says it is working with Mastercard on MPP compatibility. Mastercard makes no MPP claim and has no MPP method spec. Source [18, 98]
Compatible withfrom UCP: The network_token credential type (number, cryptogram, eci_value, token_requestor_id) can carry network tokens in general; no Agent Pay integration is documented, and Google surfaces use Google Pay PAN_ONLY. Source [99, 100, 101]
Competes withfrom Visa Trusted Agent Protocol: Same pattern on another network: RFC 9421 signatures with a network tag and a nonce, verified at the CDN. Mastercard uses one tag, Agent-pay-auth, and its own key directory, whose location is not public. Source [8, 102]
Same stewardfrom x402: Mastercard is a Premier member of the x402 Foundation, which runs a card-acceptance working group; no technical link to Agent Pay was found. Source [103, 104]
Mastercard Agent Pay in the compare matrix (34 dimensions)
Dimension
Value
Confidence
Primary job
Let registered agents pay with scoped card tokens Network registers agents, issues agentic tokens and lets merchants recognize agent requests.Source [1, 7]
Verified
Layers covered
Payment credential, identity and trust, intent Tokens, agent registration and signatures, Verifiable Intent for intent.Source [8, 9]
Verified
Stewards
Mastercard Verifiable Intent maintained by Mastercard and contributed to FIDO.Source [1, 4]
Verified
Governance model
Proprietary network program No public spec, version or governance body; VI is open at FIDO.Source [2, 4]
Verified
License (spec and code)
Program proprietary; VI Apache-2.0 Acceptance Framework spec not public.Source [2, 3]
MisconceptionIs Mastercard Agent Pay the same as AP2?
No. AP2 is Google's open protocol; Agent Pay is Mastercard's proprietary card-network program. They connect only through Verifiable Intent, which uses the same four mandate type strings as AP2 v0.2 on its main branch. Source [1, 2, 5, 20, 21]
MisconceptionIs a Mastercard agentic token the same as a Visa agentic token?
No. The words are shared but the products are separate: Mastercard Agentic Tokens belong to Agent Pay, and Visa's agentic network tokens belong to Visa Intelligent Commerce. Source [23]
MisconceptionIs Agent Pay live at scale?
Mastercard has enabled issuers at network level in several regions, but the transactions it names are pilots, controlled trials or first transactions, and it publishes no volume data. Source [12, 13, 14, 15, 16, 17]
MisconceptionAre agentic tokens issued by MDES?
Mastercard's launch, regional and developer-guide pages say only that agentic tokens build on Mastercard tokenization and do not name MDES. Developer pages mention MDES (Mastercard Digital Enablement Service) only for Virtual Card Tokens and Token Connect enrollment, so this atlas does not call agentic tokens MDES tokens. Source [1, 8, 26, 27, 28]
MisconceptionIs DTVC a kind of agentic token?
No. A DTVC is a one-time security code issued with a Mastercard Virtual Card Token for guest checkouts. Mastercard pages expand it both as Validation Code and as Verification Code. Source [28, 37, 38]
Which tag does a Mastercard agent put in Signature-Input?
Mastercard's Level 1 guide gives Agent-pay-auth; its testing glossary writes agent-pay-auth. The browse and pay tags agent-browser-auth and agent-payer-auth are Visa's. Source [8, 36]
Where is the Mastercard key directory?
Unknown publicly. The only host in Mastercard's example, agentpay-key-directory.mastercard.com, did not resolve on 2026-10-11, and Cloudflare names no Mastercard URL. Source [8, 35]
Does a merchant need new code to accept Agent Pay?
Not at Level 1. The agent types the token into the existing card form and the token looks like a card number; signature checks can run at the CDN. PCI scope does not change. Source [8]
MisconceptionIs the Mastercard Agent Toolkit a payments SDK?
No. It is an MCP server and library that reads Mastercard documentation. It makes no payment calls, and no public Agent Pay SDK or sandbox exists. Source [27, 29, 30, 31, 45]
MisconceptionDoes Mastercard say AP4M is compatible with MPP?
Not in its own words. In Mastercard's AP4M release, Tempo says it is working with Mastercard on Machine Payments Protocol compatibility. Source [18]
What happens in a dispute over an agent purchase?
Standard chargeback rights apply. No agent-specific reason code or liability shift is published, and Verifiable Intent provides evidence but assigns no liability. Source [8, 44]
Which version of Verifiable Intent should I code against?
The 0.1 label covers two sets of names. Tag v0.1.0 (2026-03-05) uses names such as payment.amount; main after 2026-04-20 uses mandate.payment.amount_range and .1 suffixes. This atlas follows main. Source [34, 46, 51, 52]
R. Open questions and research frontier
Does any live Agent Pay authorization check a Verifiable Intent chain today?
Mastercard says it is embedding VI into the payment flow and that AP4M agents can be recognized with it, but no public record shows a VI chain checked in production. Source [10, 12, 18]
Where is the Mastercard key directory, and how are keys rotated and delisted?
The only host in the docs does not resolve; rotation and delisting are undocumented. Source [8, 35]
Who carries the loss when an agent buys the wrong thing within its limits?
No agent-specific reason codes or liability shift are published; an unattributed answer in VI issue 15 says liability work is ongoing. Source [17, 92]
Can a Verifiable Intent Autonomous mandate satisfy PSD2 SCA when the user is absent?
VI says it gives a cryptographic form of dynamic linking but does not replace SCA; no regulator has addressed it. Source [70, 71]
Will Verifiable Intent fix the duplicate-digest conflict with RFC 9901?
Issue 29 has been open since 2026-07-17 with no maintainer response, and the repository has had no commits since 2026-04-20. Source [10, 47]
How reliably do authorization messages mark agent involvement?
The 2026-09-30 probability score test implies agent involvement is not always marked; its fields and thresholds are unpublished. Source [16]
How will Mastercard's tag and directory align with the IETF Web Bot Auth draft?
Mastercard uses its own tag, while the working group draft requires web-bot-auth; no alignment plan is published. Source [8]
What does Agent Pay for Machines settle on, and at what cost?
Mastercard describes multi-rail settlement across cards, accounts and stablecoins but publishes no flow, pricing or chain addresses. Source [18]
S. Self-test
Quiz
0 of 10 answered.
Flashcards
0 of 15 marked known. Card 1 of 15.
Prompt
Agent Pay announcement date
T. Notes
Notes stay in this browser. Nothing is sent anywhere.