Agentic commerce needs an identity layer: Visa TAP, Google AP2, and Mastercard Agent Pay

Key takeaways

• Visa Trusted Agent Protocol (TAP), Google Agent Payments Protocol (AP2), and Mastercard Agent Pay all make agent-led purchases safer, but they solve different parts of the trust problem.
• TAP helps merchants recognize approved agents and verify signed commerce intent. AP2 creates evidence of what a user authorized. Agent Pay combines registered agents, tokenized payment credentials, consent, and network visibility.
• None of these mechanisms eliminates the need to prove who the human or business is, screen risk, enforce jurisdiction-specific controls, and preserve an audit trail.
• Didit is neutral infrastructure for identity and fraud, not a card network or payments company. Its hosted Model Context Protocol (MCP) server exposes 115 tools across 11 categories, while the Representational State Transfer (REST) Application Programming Interface (API) supports embedded production flows.
• A full Know Your Customer (KYC) bundle costs $0.33, every account includes 500 free verifications per month, and the MCP server itself is free.

Agentic commerce begins when an artificial intelligence (AI) agent does more than recommend a product. It compares offers, assembles a cart, chooses a payment method, and may complete a purchase within limits set by a person or business. That shift creates several trust questions at once: Which agent made the request? Who authorized it? Who is the human or legal entity behind it? Is the transaction permitted? And what evidence will exist if the purchase is disputed?

The emerging payment standards answer important parts of that sequence. They do not all answer the same part, and they should not be treated as interchangeable. For developers, the useful question is not which brand will “win.” It is which controls remain necessary under every credible architecture.

Three standards, three trust boundaries

Visa TAP: can the merchant recognize and trust this agent?

Visa Trusted Agent Protocol is merchant-facing. Its core job is to help a merchant distinguish an approved commerce agent from an ordinary crawler, abusive bot, or unknown automation. An agent signs a request with time-bound, purpose-specific credentials. The merchant or its protection provider verifies the signature and can decide whether to permit browsing, checkout, or a narrower action.

TAP describes three related signals: an agent-recognition signature, a linked and signed consumer or device identity, and a linked and signed payment container. This is useful separation. Agent recognition establishes which approved agent is present; signed intent establishes what kind of interaction is requested; the consumer signal can help a merchant recognize an existing customer.

That consumer signal is not automatically equivalent to fresh identity proofing. Visa’s model includes an identity-provider role upstream, but a merchant still needs policy for a new or high-risk customer: what evidence was checked, how strong the assurance is, whether KYC is required, and when reverification is necessary. TAP can carry trusted identity information without prescribing every jurisdictional onboarding decision.

Google AP2: what did the user authorize the agent to buy?

Google Agent Payments Protocol focuses on authorization and evidence. It uses signed mandates to connect user intent, checkout contents, and payment. An open mandate can give an agent bounded discretion, such as merchant constraints or spending limits. A closed mandate binds approval to a specific cart and amount. Receipts complete the evidence chain.

AP2 distinguishes human-present and human-not-present flows. When the person is present, they can approve a closed checkout and payment mandate directly. When absent, the agent operates inside previously approved constraints and signs the final closed mandates. A merchant or credential provider can still bring the person back into the loop when a constraint cannot be resolved.

This design answers “Did this person authorize this action under these conditions?” more directly than “How was this person originally verified?” The AP2 authorization framework assumes the relevant enrollment and user credentials exist. A developer therefore still needs an identity-proofing and credential-lifecycle process before those mandates can carry meaningful assurance.

Mastercard Agent Pay: can the network recognize and govern an agentic payment?

Mastercard Agent Pay builds on payment tokenization. Mastercard’s acceptance framework registers and verifies agents, assigns unique agent identity, and uses Agentic Tokens so transactions are traceable and payment credentials remain protected. Merchant-facing recognition can work with existing checkout infrastructure, while deeper integrations support richer data exchange.

The model also emphasizes consumer consent, authentication, and the ability for issuers, acquirers, and merchants to recognize that an agent participated. This makes agent activity visible inside a familiar card-network risk model instead of making automation indistinguishable from an ordinary card-not-present request.

Agent Pay is strongest at payment credential security, agent visibility, and network controls. It does not remove a merchant’s obligation to decide when identity verification, Know Your Business (KYB), Anti-Money Laundering (AML) screening, age checks, or enhanced review applies. Those decisions depend on the product, customer, transaction, and jurisdiction—not only on the payment rail.

Where the standards overlap—and where identity still fits

All three approaches are trying to make delegated commerce legible. A merchant should be able to tell that automation is involved, verify that the agent is trusted, connect the action to user intent, constrain the purchase, and retain evidence. Their emphasis differs:

• TAP: agent recognition and signed intent at the merchant boundary, with optional linked consumer and payment signals.
• AP2: cryptographic authorization artifacts that bind user intent to checkout and payment outcomes.
• Agent Pay: registered agents, tokenized payment credentials, consent, authentication, and visibility across the card network.

Identity proofing sits before and beside these controls. A signed authorization is valuable only if the credential belongs to the right person. An approved agent can still be instructed by a synthetic, stolen, sanctioned, underage, or otherwise ineligible account. A token can protect payment credentials without establishing that a marketplace seller or business beneficiary passed required due diligence.

Agent identity answers “which software acted?” Authorization answers “what was it allowed to do?” Identity verification answers “who is behind it?” Fraud and compliance controls answer “should this action proceed?”

What developers have to build regardless of which approach wins

• Enrollment and proofing. Verify the person or business before granting a reusable credential or delegated spending authority. Apply KYC, KYB, liveness, document, database, or biometric checks according to risk.
• Credential binding. Bind the verified subject to an account, device, passkey, wallet, or other credential that can participate in the agentic flow.
• Scoped authorization. Capture limits such as merchant, category, amount, frequency, expiry, and whether a human must return for approval.
• Runtime risk decisions. Screen the person, business, wallet, and transaction at the moment of action. Know Your Transaction (KYT) controls and AML checks remain relevant even when intent is signed.
• Revocation and recovery. Stop delegated authority when a credential is compromised, the user withdraws consent, or risk changes.
• Auditability. Preserve the verification result, authorization artifact, agent identity, transaction decision, timestamps, and later review actions as separate evidence.

This layered design is deliberately standards-neutral. A team can adopt TAP at the merchant edge, AP2 mandates in an agent workflow, Agent Pay for card settlement, or a combination. The identity and fraud decision remains portable because it is not embedded in one payment network.

How Didit covers the identity half today

Didit provides infrastructure for identity and fraud used by 2,000+ companies in production. The same capabilities are available through a hosted MCP server for agent-driven operations and a REST API for application-controlled flows. For a broader architecture overview, see how an MCP server handles identity verification and how MCP connects identity and fraud checks for AI agents.

The hosted MCP endpoint is https://mcp.didit.me/mcp. It uses Streamable Hypertext Transfer Protocol (HTTP), with Open Authorization (OAuth) 2.1, Proof Key for Code Exchange (PKCE), and Dynamic Client Registration. A user signs in through the Didit Business Console and grants scoped access; the hosted MCP endpoint does not use API-key authentication.

After authorization, an agent can call 115 tools across 11 categories. A practical verification sequence can use:

didit_context_get
didit_session_create
didit_verify_id
didit_verify_passive_liveness
didit_verify_face_match
didit_session_get_decision

Those tools can create a verification session, run the selected checks, and retrieve a structured decision. Other real tools include didit_verify_aml, didit_verify_kyb_search, didit_verify_kyb_select, and didit_transaction_screen_wallet. High-consequence writes remain subject to the connected user’s permissions and confirmation behavior.

The REST API covers the application path: create sessions from your backend, send users through hosted or embedded verification, consume webhooks, and store decisions in your own system. REST server-to-server requests use an x-api-key header; this is separate from the OAuth-authenticated hosted MCP connection. Read the MCP overview, authentication guide, and tool reference for implementation details.

Pricing is independent of the agentic-payment standard. The MCP server is free. A full KYC bundle—ID Verification, Passive Liveness, Face Match, and IP Analysis—costs $0.33, and every account includes 500 free verifications per month.

A standards-neutral implementation path

Start by defining the assurance required for each action, not by choosing a network logo. Low-risk browsing may need agent recognition only. Account creation may require verified identity. A regulated purchase may require KYC or KYB plus AML screening. A crypto transfer may add wallet screening. Higher amounts or changed risk can return the human to the loop.

Then connect the payment artifact to the identity decision with stable internal identifiers. Keep the agent signature, user authorization, verification evidence, and payment result distinct so each can be independently revoked, reviewed, and upgraded as standards evolve.

Explore the Didit MCP developer page or inspect the public, permissively licensed GitHub repository. Claude users can add the Didit connector and complete the OAuth login.

The durable architecture is layered: payment standards prove agent participation and authorization; identity and fraud infrastructure proves who is involved and whether the action is acceptable. That division lets developers support today’s standards without hard-coding trust to a single one.