Mastercard Agent Pay and Verifiable Intent
Mastercard Agent Pay acceptance framework and Verifiable Intent open-source authorization — LCP as the merchant-side complement.
This section is advisory.
This page covers two related Mastercard initiatives: Agent Pay (the acceptance framework) and Verifiable Intent (the open-source authorization standard).
Mastercard Agent Pay
Mastercard Agent Pay is the acceptance framework for agent-initiated transactions on the Mastercard network. It includes:
- Know Your Agent (KYA) registration — agent identity and authorization credentials established during onboarding
- Agentic tokens — dynamic, cryptographically secure payment credentials via network-level tokenization
- Dynamic Token Verification Code (DTVC) — enables no-code merchant integration through standard card payment fields
- Cloudflare Web Bot Auth — CDN-layer verification of agent credentials
Verifiable Intent
Mastercard's Verifiable Intent is an open-source cryptographic framework (Apache 2.0, verifiableintent.dev) co-developed with Google. It creates a tamper-resistant record of consumer authorization using a three-layer SD-JWT credential format:
- Layer 1 (Identity): Issuer-signed credential binding consumer identity to a payment instrument (~1 year lifetime)
- Layer 2 (Intent): User-signed authorization with constraints — amount bounds, merchant categories, validity windows, geographic scope (~15 minutes lifetime in immediate mode; 24 hours to 30 days in autonomous mode)
- Layer 3 (Action, autonomous mode only): Agent-signed execution record showing what the agent actually did (~5 minutes lifetime)
Verifiable Intent uses Selective Disclosure to share only the minimum information each party needs: merchants see authorization validity, issuers see full transaction history, dispute systems see whether the transaction fell within or outside the mandate parameters.
LCP as the Merchant-Side Complement
Verifiable Intent captures the consumer's authorization chain — what the consumer authorized and whether the agent stayed within scope. LCP captures the merchant's terms — what was offered, under what conditions, with what obligations. Together they form a complete picture:
| What | Protocol |
|---|---|
| Consumer authorized this agent | Verifiable Intent Layer 1-2 |
| Agent stayed within constraints | Verifiable Intent Layer 2-3 |
| Merchant offered these terms | LCP (contentHash) |
| Both parties agreed | Agreement Identity record |
| Dispute resolution is available | LCP Level 4 (disputeResolution) + AAA |
Integration Point — Verifiable Intent Layer 2
The consumer's Intent credential (Layer 2) defines financial constraints. LCP can extend this with legal constraints — acceptable terms of service, required dispute resolution, jurisdiction preferences. These legal constraints would be included in the Layer 2 credential alongside the existing financial constraints, signed by the user's device key, and carried through the mandate chain.
Dispute Resolution Pipeline
Verifiable Intent explicitly designs for dispute evidence but explicitly excludes the dispute mechanism itself. LCP Level 4 provides the mechanism: the disputeResolution field specifies the process (e.g., AAA Commercial Arbitration Rules), and the api field provides the entry point for filing.
The combined evidence package:
- Verifiable Intent credential chain — consumer authorization
- LCP terms record — merchant offer
- Agreement Identity — mutual acceptance
This provides a complete evidentiary foundation for arbitration.