Protocol Breakdown Report
Agent Payments: Versions, Authorization and Merchant Readiness
Compare current AP2, Visa and Mastercard roles. Verify user authorization, provider support and operating responsibilities before planning an agent-payment pilot.
v1.1 · October 2026 · Tenten GEO Research
CH.01
Read Announcements as Announcements
A published protocol or pilot does not establish universal merchant availability, adoption or friction-free payment.
Google released AP2 v0.2 and announced its donation to FIDO on April 28, 2026. FIDO describes ongoing work on agent authentication and payment frameworks. These are versioned technical and standards efforts, not a requirement that every merchant adopt all networks.
| Official publication | Date | What it establishes |
|---|---|---|
| Google/FIDO AP2 v0.2 and standards work | 2026-04-28 | Current release and ongoing collaborative work |
| Visa Trusted Agent Protocol | 2025-10-14 | Agent recognition and signed information exchange |
| Mastercard Agent Pay Acceptance Framework | 2025-10-14 | Agent verification, tokens and data exchange |
Publication dates, not a common rollout deadline or availability list.
Confirm actual provider, market, user and merchant support separately. A transaction demonstration or partnership cannot prove that every Visa merchant accepts ChatGPT purchases.
Next step
Begin with a supported customer task and written provider requirements.
CH.02
Separate the Roles of the Frameworks
Authorization, agent identity and card acceptance can complement each other without being the same function.
AP2 secures authorization within a commerce protocol; catalog APIs and general checkout updates are outside its scope. Visa and Mastercard publish recognition and network frameworks. Identity checks do not by themselves authorize a user’s purchase or guarantee issuer approval.
| Framework | Published role | Verification focus | Merchant question |
|---|---|---|---|
| AP2 v0.2 | Checkout and Payment authorization evidence | Mandates, constraints and linked checkout | Which role verifies each object? |
| Mastercard Acceptance Framework | Registered agents and agentic tokens | Agent recognition and supported payment flow | Does our provider support this market and task? |
| Visa Trusted Agent Protocol | Signed exchange with recognized agents | Agent identity, intent and optional information | How is purchase authorization separately checked? |
Role comparison, not equivalent products or a universal interoperability test.
Next step
Choose only integrations supported by your commerce and payment providers.
CH.03
AP2 v0.2: Two Mandates, Three Checks
The three checks below are work steps, not three mandate types. The current specification defines Checkout and Payment Mandates, each with open and closed forms.
Human Present approves the closed checkout and payment. Human Not Present uses prior user-authorized constraints to permit an agent to form a closed transaction. Verifiers receive closed mandates and evaluate applicable authorization and constraints using deterministic code.
CHECK 1
Check the Checkout Mandate
Verify the authorized checkout and its binding to the merchant-signed checkout object under the current specification.
CHECK 2
Check the Payment Mandate
The credential provider, network and processor follow their distinct verification responsibilities for the linked payment.
CHECK 3
Check Constraints and Versions
In autonomous mode, verify relevant open-to-closed constraints and signatures; match exact schema versions. Do not delegate approval to an LLM’s judgment.
Next step
Read and implement the actual version’s verification rules. An older Intent/Cart/Payment description is not the current v0.2 mandate list.
CH.04
Identity Is One Check, Not the Whole Payment
Keep agent authenticity, user consent, payment credentials and financial authorization distinct.
Visa’s Trusted Agent Protocol helps identify recognized agents and exchange signed information. Mastercard’s framework describes registration and agentic tokens. Neither lets a merchant infer that every request is authorized merely because it came from a recognized agent.
| Check | Existing commerce responsibility | Agent-related addition |
|---|---|---|
| Identity | Authenticate relevant parties | Verify the agent under the supported framework |
| Consent | Confirm the user’s approved transaction | Check delegated scope and constraints |
| Payment | Validate credentials and issuer decisions | Use the supported token or payment path |
| Operations | Handle cancellation, fraud and disputes | Keep role-specific evidence and incident handling |
Additional checks complement existing payment controls rather than replace them.
Next step
Ask the provider who verifies each step and what happens when verification fails.
CH.05
Evidence, Privacy and Operational Limits
Signed evidence has a defined technical role; it does not automatically settle disputes, certify compliance or prove brand trust.
Keep customer-facing prices, returns and consent understandable alongside protocol objects. Current AP2 requires deterministic validation. A signature is not evidence that all claims are true, nor an authorization for unrelated future actions.
AP2 defines evidence objects but leaves detailed dispute resolution, retention and retrieval outside this specification. Share only required disclosures, minimize personal data and follow applicable provider and legal requirements. The unmeasured readiness chart is retired.
Next step
Define evidence access, failure handling and data responsibilities with the relevant specialists.
CH.06
Decide from Provider Support and a Real Task
A business model alone does not determine which protocol must be adopted.
| Business model | Task to confirm | Provider evidence | Review point |
|---|---|---|---|
| Retail | One supported customer purchase | Actual merchant/market support and authorization flow | Price, stock, returns and failed checkout |
| Subscription | Recurring or changed charge | Explicit supported consent and renewal conditions | No assumption one-time consent covers renewals |
| Cross-border/high-value | Eligible market and payment instrument | Provider support, limits and required checks | Fees, security, fraud and dispute responsibilities |
Questions for procurement, not a mandatory network ranking.
STEP 1
Define the supported task
Identify customer, product, market and provider; confirm current availability rather than infer it from an announcement.
STEP 2
Assign verification roles
Document agent identity, user consent, mandate/credential validation and financial authorization separately.
STEP 3
Confirm versions and failure rules
Follow the relevant current specification and provider requirements; record rejection and retry behavior.
STEP 4
Plan privacy and operating support
Set data access, revocation where supported, incident and dispute processes with responsible teams.
STEP 5
Test within a bounded scope
Use the provider’s permitted test environment, acceptance criteria and stop conditions before considering a rollout.
Next step
A well-defined pilot can also lead to waiting or stopping. Adopt only where the customer task, support and operating evidence justify it.
Sources & methodology
Revised October 5, 2026. Google and FIDO April 28, 2026 publications identify AP2 v0.2 release/donation and standards work in progress. Current AP2 specification defines two Checkout/Payment Mandate types, open/closed forms, Human Present/Not Present modes and deterministic verification; catalog APIs and detailed dispute/retention arrangements are outside its scope. Visa and Mastercard October 14, 2025 publications describe identity/information and acceptance frameworks, not universal ChatGPT checkout availability. Sources: https://ap2-protocol.org/ap2/specification/; https://blog.google/products-and-platforms/platforms/google-pay/agent-payments-protocol-fido-alliance/; https://fidoalliance.org/fido-alliance-to-develop-standards-for-trusted-ai-agent-interactions/; https://investor.visa.com/news/news-details/2025/Visa-Introduces-Trusted-Agent-Protocol-An-Ecosystem-Led-Framework-for-AI-Commerce/; https://www.mastercard.com/us/en/news-and-trends/stories/2025/agentic-commerce-framework.html. Retired unmeasured 30/55/70 bars and fixed three-mandate/current-all-merchant claims; historical descriptions may concern earlier versions. This is a source-based planning guide, not a performed payment test, legal certification or adoption/return guarantee.
© 2026 Tenten GEO · Feel free to cite this whitepaper; please attribute the source.
Discuss your AI search priorities
Request a 30-minute benchmark interpretationSend a booking request. We’ll email you to confirm a time within 24 hours.