AI agents now hold payment credentials, browse merchant catalogs, and submit checkout requests on behalf of human principals. The acquirer at the other end of the transaction has a problem no card network was designed to solve: how do you tell a legitimately delegated agent from a scripted attacker reusing a stolen token? Agent identity verification is the layer that answers that question. This article maps the four production approaches shipping in 2026, the consent flow that ties them to a human, and the threat model each is built to defeat.
​

Agent identity verification is the cryptographic process of proving that a software agent submitting a payment is (a) a known agent registered with a network or issuer, (b) currently authorized by a specific human principal, and (c) acting within a scoped mandate. It binds agent, user, and intent into a single signed credential the merchant or acquirer can verify before settlement.
​

The 2026 landscape splits into four implementation models: tokenized agent identities (Mastercard Agent Pay), attestation headers (Visa Trusted Agent Protocol), Verifiable Credentials with signed mandates (Google's AP2), and decentralized identifiers (DIDs, used by crypto-native agents settling onchain). Each maps to a different trust anchor: card network, acquirer, issuer-signed VC, or self-sovereign DID document.
​

Existing 3-D Secure flows assume a human cardholder is present at checkout to complete a challenge. An AI agent cannot solve a CAPTCHA, receive an SMS OTP on the user's phone, or pass a biometric prompt. Networks classify agent traffic as card-not-present with no liability shift, which spikes decline rates and shifts chargeback exposure onto merchants. A purpose-built identity layer was required.
​

Mastercard's own April 2025 announcement framed the gap explicitly: "today's payment systems weren't built for AI agents to transact." Visa's Intelligent Commerce program described a parallel finding, that agent transactions were being blocked by issuer fraud rules trained on human session patterns. Both networks now layer agent-specific identity on top of EMV tokenization rather than replacing it.
​

Mastercard Agent Pay issues an Agentic Token through the Mastercard Digital Enablement Service that binds three identities into one credential: the cardholder, the registered AI agent, and the scope of the mandate. When the agent presents the token at checkout, the network verifies the agent's certificate, decrypts the cardholder PAN, and enforces the mandate's spending limits before authorization.
​

Agents must be enrolled by their developer through Mastercard's program (announced with Microsoft, OpenAI, IBM, and PayPal as launch partners). Enrollment produces a cryptographic agent ID that the network associates with the developer's KYC'd entity. At checkout, the token carries the agent ID alongside the cardholder token, letting the issuer score risk per agent rather than per session. See our full Mastercard Agent Pay explainer for the token lifecycle.
​

Visa's Trusted Agent Protocol takes a different architectural choice. Rather than embedding agent identity in the payment token, it adds signed HTTP headers to the merchant request that attest the agent's identity, the user's consent, and the transaction intent. Merchants verify the signature against Visa's registry before routing the authorization, preserving the existing card rails.
​

The attestation header carries the agent operator's identifier, a user-consent reference, and a payload hash binding the attestation to the specific cart. Visa published the protocol in late 2025 as an open standard with Adyen, Cloudflare, and Stripe in the early signatory cohort. Because the protocol lives at the HTTP layer, it works with any underlying card brand. Compare the architecture side-by-side in our Agent Pay vs Trusted Agent breakdown.
​

Google's Agent Payments Protocol (AP2) uses W3C Verifiable Credentials to make user consent cryptographically auditable. The protocol defines two mandate types: an Intent Mandate, which the user signs to authorize an agent to shop within a scope (e.g., "buy size-9 running shoes under $200"), and a Cart Mandate, signed when the agent presents the final cart for explicit human approval.
​

Each mandate is a VC issued by a wallet the user controls, signed with the user's key, and presented by the agent to the merchant or payment processor. The merchant verifies the signature and checks the mandate scope before charging. Google open-sourced the AP2 specification with more than 60 launch partners including Mastercard, American Express, PayPal, Coinbase, and Salesforce. For protocol depth see our AP2 protocol explainer.
​

Decentralized Identifiers (DIDs), standardized by the W3C in 2022, give an agent a self-sovereign identifier resolvable to a DID document containing public keys and service endpoints. A crypto-native agent settling in stablecoins on Base or Solana can sign a transaction with the key referenced in its DID document, and a counterparty can verify the agent by resolving the DID without consulting a central registry.
​

DIDs pair naturally with VC mandates: the user's wallet issues a VC delegating spending authority to the agent's DID, and the agent attaches the VC to onchain payments. AP2 explicitly supports DID-anchored issuers and holders, which is why protocols like Coinbase's x402 micropayment standard and Skyfire's agent-payment network use DIDs as the primary identity primitive for autonomous-agent commerce.
​

The four models differ in trust anchor, transport, and how user consent is captured. The table summarizes the production characteristics relevant for merchants and developers choosing an integration path in 2026.

Across all four models the consent flow follows the same three-leg pattern. A human principal authorizes an agent with a scoped mandate. The agent shops within scope and presents a cart. The merchant verifies the agent's identity and the mandate's binding to the cart before settling. The verification step is what each protocol implements differently.
​

In a typical AP2 + Agent Pay hybrid flow, a user opens a wallet app, signs an Intent Mandate ("$500 monthly grocery budget, only at approved retailers"), and delegates to a registered agent. The agent fills a cart at an enrolled merchant. Before authorization, the merchant requests a Cart Mandate, which the user signs after reviewing the line items. The agent submits the Agentic Token plus the Cart Mandate VC. The issuer validates both before approving.
​

The threat model agent identity verification addresses includes rogue agents (unauthorized agents impersonating a registered one), replay attacks (reusing a captured mandate or token for a second transaction), scope escalation (an agent transacting outside its mandate), and merchant collusion (a merchant fabricating a mandate the user never signed). Each protocol layers defenses against this set.
​

Agentic Tokens defeat replay by binding each token to a single authorization window and a specific agent certificate. Trusted Agent headers prevent merchant collusion through user-consent references that are independently verifiable. AP2 Cart Mandates defeat scope escalation because the merchant must obtain a freshly signed mandate for each transaction. DIDs defeat impersonation by anchoring the agent's public key in a tamper-evident document the user can revoke. The remaining residual risk is principally key compromise, which falls back on wallet-level protections such as hardware-bound keys, biometric re-prompts, and revocation lists.
​

Eco's orchestration layer settles agent payments in stablecoins across 15 chains, which means agents using AP2 or DID-based identity can route a verified mandate to the cheapest execution venue without human intervention. The Eco Routes API accepts a DID-signed payload, validates the attached mandate, and dispatches the transaction through Hyperlane or CCTP rails depending on destination chain.
​

For builders integrating agent commerce, the practical pattern is: use AP2 mandates for human-to-agent consent, use DIDs for agent-to-agent identity, and use Eco for the stablecoin settlement leg. See the Agent Pay implementation guide for the integration checklist.
​

This article synthesizes primary documentation from the four protocol families plus the W3C identity standards underpinning them. All claims about partner cohorts, mandate types, and protocol mechanics trace to the original announcements and specifications listed below. Dated stats use Q1 2026 qualifiers where supply or partner counts change weekly.