A Mastercard Virtual Card Token in an existing checkout form

The situation

A consumer asks an agent to buy one item from a small merchant that has changed nothing for agents: it has an ordinary guest checkout form and a CDN in front of its site. The consumer approves the purchase up front and lets the agent finish it.

Three pieces meet here, and they are not equally deployed. Agent Pay is a proprietary Mastercard program with no public specification or version of its own.^{Source [1, 2]} Mastercard says all its issuers in Europe are enabled at a network level, yet most transactions it has named ran in controlled environments or pilots.^{Source [3, 4, 5, 6]} Verifiable Intent is a Draft at v0.1.^{Source [7]} Mastercard said on 2026-03-24 that it is embedding Verifiable Intent into the payment flow.^{Source [4]} No public source shows it in a live purchase, so its steps below are marked “specified; live use not shown publicly”.

Actors

• Consumer, who holds an L1 credential and signs the L2 mandate.
• Agent platform, registered and certified; only registered agents can transact through the network.^{Source [8]}
• CDN or edge, which verifies agent signatures; merchants can also do this in their own backend.^{Source [9]}
• Mastercard key directory, hosted by Mastercard for its registered agents.^{Source [10]}
• Merchant, registered through its acquirer or PSP.^{Source [8]}
• Mastercard network and token service, acquirer and issuer.

Step by step

1. Delegate (Verifiable Intent, specified; live use not shown publicly). Verifiable Intent chains SD-JWT credentials from credential provider to user to agent.^{Source [7, 11]} In Autonomous mode the consumer signs L2 mandates that bind the agent’s key, with a lifetime of 24 hours to 30 days.^{Source [12]}
2. Sign the request (Agent Pay). Mastercard documents keyid, alg, created, expires, nonce and tag in Signature-Input.^{Source [9]} Its Level 1 guide gives one tag, Agent-pay-auth, while the testing glossary writes it in lower case.^{Source [9, 13]} Cloudflare says Agent Pay uses Web Bot Auth as its agent authentication layer.^{Source [10]}
3. Fetch the key (Agent Pay). The guide’s example sends Signature-Agent pointing at agentpay-key-directory.mastercard.com.^{Source [9]} That host did not resolve on 2026-10-11, and Cloudflare names no Mastercard directory URL.^{Source [9, 10]} The directory’s public location is unknown.
4. Verify and forward (Agent Pay). The edge checks the window, nonce, tag and signature.^{Source [10]} Mastercard’s own sample verification code accepts only the two Visa tag values, so a verifier copied from it would reject this agent.^{Source [9]}
5. Checkout page. The merchant serves its ordinary form. Verifiable Intent needs a checkout_jwt, whose schema and signing are implementation-defined in v0.1.^{Source [12]}
6. Request a token (Agent Pay). Mastercard directs integrators to Virtual Card Tokens for web guest checkouts with a simple form.^{Source [14]} A one-time DTVC may be requested after user validation and consent.^{Source [14]}
7. Receive token and DTVC (Agent Pay). A DTVC is a one-time security code issued with a virtual card token, not an agentic token itself.^{Source [14, 15]} Mastercard expands it both as Dynamic Token Validation Code and as Dynamic Token Verification Code.^{Source [14, 16]}
8. Sign L3a and L3b (Verifiable Intent, specified; live use not shown publicly). L3a carries the final payment mandate to the network and L3b the final checkout mandate to the merchant.^{Source [11]} checkout_hash is the base64url SHA-256 of checkout_jwt, and L3a transaction_id must equal L3b checkout_hash.^{Source [12]} Both expire after 5 minutes by recommendation and one hour at most.^{Source [12]}
9. Fill the form (Agent Pay). The agent types the token into the standard card fields, where it looks like a card number.^{Source [9]} The merchant’s PCI scope stays unchanged.^{Source [9]}
10. Merchant checks L3b (Verifiable Intent, specified; live use not shown publicly). The merchant recomputes checkout_hash. Transport is out of scope for Verifiable Intent, so how a form-based checkout receives L3b is not defined.^{Source [7]}
11. Authorize (card rails). The merchant submits through its usual acquirer.
12. Network checks (Agent Pay; Verifiable Intent per spec). Mastercard validates the DTVC at authorization.^{Source [15]} Per spec the network validates the chain before authorization and enforces one L3 pair per L2 pair.^{Source [11, 17]}
13. Issuer decides. The issuer is told whether DTVC validation was performed and makes the final decision.^{Source [11, 15]}
14. After the sale. Standard chargeback rights and dispute processes apply.^{Source [9]}

Which protocol does what

Verifiable Intent’s main branch has had no commits since 2026-04-20.^{Source [18, 19]}

Where controls apply

• Before authorization. For the agentic-token path, Mastercard says agentic tokens may be single-use, merchant-specific or time-limited; the DTVC path in this scenario uses a Virtual Card Token, which is a different product.^{Source [9]} Agents may not use a card already on file at the merchant, because the network could not see the purchase as agentic.^{Source [9]}
• At signing. A controls layer can review L2 constraints before the consumer signs. Verifiable Intent registers eight constraint types, among them allowed merchants, amount range and budget.^{Source [20]}
• At the edge. Mastercard’s decision table sends requests without a scheme tag to the non-agent bot policy and blocks unknown keys.^{Source [9]} With no public directory, only partners that Mastercard supplies with keys can verify.
• At settlement. Budget enforcement cannot be done cryptographically and needs stateful tracking by the network.^{Source [17]} Networks and EMVCo are still developing 3DS support for agentic flows.^{Source [9]}
• After the fact. Verifiable Intent gives evidence for disputes but assigns no liability.^{Source [17]} It defines no revocation protocol beyond short lifetimes and key removal.^{Source [17]}

What is observable from outside

Program milestones appear in Mastercard releases, and the Verifiable Intent repository is public.^{Source [18]} Everything per transaction is private: signature headers, tokens, DTVCs, mandates and authorization messages. No public Agent Pay SDK, API reference or sandbox was found.^{Source [21, 22]} Mastercard has published no Agent Pay volume or value figures.^{Source [23, 24]} It began US testing of a score for the likelihood that an AI agent started a transaction, which implies agent involvement is not always marked reliably.^{Source [23]}

What can go wrong

• Unknown key. The edge blocks the request.^{Source [9]} Because the directory location is not public, a merchant’s own verifier may have no key to check at all.
• Wrong tag spelling or Visa-only code. A verifier that matches case exactly or copies the sample code rejects a valid agent.^{Source [9, 13]}
• Checkout and payment disagree. Checkout-payment mismatch is in the threat model; the transaction_id and checkout_hash link exists to catch it.^{Source [17]}
• Library rejects L2. An open issue reports that L2 lists each digest twice, which RFC 9901 says verifiers must reject (reported).^{Source [25, 26]}
• Who bears the loss. No agent-specific liability rule or chargeback reason code for Agent Pay was published.^{Source [24, 27]} Standard chargeback rules apply.^{Source [9]}

Variants

• Immediate mode. With the consumer present at the end, L2 Immediate carries the final mandates, about 15 minutes long, and no L3 is needed.^{Source [11, 12]}
• Agentic token instead of a virtual card token. At Levels 1 and 2 an agentic token goes into the same card fields.^{Source [9]} For form-fill checkouts a signed Payment Data object can hold a hash of the tokenized payment data for the merchant to compare.^{Source [28]}

// Illustrative example, Verifiable Intent 0.1 on main (356c296). Specified; live use not shown publicly.
{
  "vct": "mandate.payment.open.1",
  "cnf": { "jwk": { "kty": "EC", "crv": "P-256", "x": "<agent-key-x>", "y": "<agent-key-y>", "kid": "agent-key-1" } },
  "payment_instrument": { "type": "mastercard.srcDigitalCard", "id": "<token-uuid>" },
  "constraints": [
    { "type": "mandate.payment.amount_range", "currency": "USD", "max": 20000 },
    { "type": "mandate.payment.reference", "conditional_transaction_id": "<B64U(SHA-256(checkout_disclosure))>" }
  ]
}