Protocol Version and Date Log — the version/date table every other page in this wiki must match

This is the single reference table for which version of which agent-payment authorization protocol is current, as of the last-checked date below, plus the change history that got each one there. Every other page in this wiki that cites a version number should match this page; if it doesn't, this page is the one to trust and the other page needs a refresh.

Current Protocol Versions Table

| Protocol | Current Version | Version Date | Spec URL | Last Checked | Spec Public | |----------|-----------------|--------------|----------|--------------|-------------| | AP2 (Agent Payments Protocol) | v0.2.0 | 2026-04-28 | https://github.com/google-agentic-commerce/AP2 | 2026-08-24 | Yes | | ACP (Agentic Commerce Protocol) | 2026-04-17 | 2026-04-17 | https://github.com/agentic-commerce-protocol/agentic-commerce-protocol | 2026-08-24 | Yes | | x402 (HTTP Payment Protocol) | v2 | 2026-01-21 | https://x402.org (first recorded; the living source at the 2026-08-26 check is https://github.com/x402-foundation/x402 — see the changelog note below) | 2026-08-24 | Yes | | Visa Intelligent Commerce | no version tag | 2026-04 | https://developer.visa.com/capabilities/visa-intelligent-commerce | 2026-08-24 | Yes | | Visa Trusted Agent Protocol (TAP) | no version tag | 2025-10-14 | https://developer.visa.com/capabilities/trusted-agent-protocol | 2026-08-24 | Yes | | Mastercard AP4M | no public version | 2026-06-10 | not publicly available | 2026-08-24 | Partial | | Coinbase Agentic Wallets | no version tag | 2026-02-11 | https://docs.cdp.coinbase.com/agentic-wallet/welcome | 2026-08-24 | Yes | | RFC 9421 (HTTP Message Signatures) | IETF Proposed Standard | 2024-02 | https://datatracker.ietf.org/doc/html/rfc9421 | 2026-08-24 | Yes | | Web Bot Auth | no adopted document | WG chartered 2025-10-23 | https://blog.cloudflare.com/web-bot-auth/ | 2026-08-24 | Drafts only |

Note the two distinct versioning styles in play: AP2 and x402 use semantic version tags (v0.2.0, v2); ACP uses date-based versioning (YYYY-MM-DD) rather than semver — its "version" IS a date, so the Version and Version Date columns collapse into one for that row. Visa's two protocols (Intelligent Commerce, TAP) and Mastercard's AP4M publish no version tag or changelog at all; for those rows "Version Date" is the best-attested date found (launch, or latest documented update), not a spec release.

AP4M is the only row where "Spec Public" is Partial, not Yes

Mastercard's press materials describe a four-function architecture (credentialing, permissioning, transacting, settling) but no public GitHub repo or open technical spec has been found — see Mastercard AP4M — an announced authorization layer, not yet a published spec or a shipped integration for what is and isn't disclosed.

Two identity-layer standards the payment protocols build on

The rows above cover payment protocols. Two IETF items belong in the same log because Agent Identity and Credentialing — Why the Authorization Layer Needs to Know Who's Asking shows that Visa TAP and Web Bot Auth both sit on top of them, and because together they are this wiki's clearest case of deployment running ahead of standardisation — the opposite of the pattern in Announced and Not Shipped — the graveyard list that keeps the rest of this wiki honest.

RFC 9421 (HTTP Message Signatures) is a published IETF Proposed Standard, February 2024, authored by A. Backman, J. Richer and M. Sporny. It is the mechanism both TAP and Web Bot Auth use: the agent operator publishes a public key, the agent signs each request.

Web Bot Auth has no adopted document at all. Its working group was chartered on 23 October 2025 after a Birds-of-a-Feather request, and as of 12 August 2026 had adopted zero documents — every draft remains an individual submission, and the group's own April and August 2026 milestones were missed. Yet Cloudflare, AWS WAF, Akamai, HUMAN and Vercel verify Web Bot Auth signatures in production, and Vercel shipped verification ten weeks before the working group was chartered.

That inversion carries a concrete cost, and it is the reason this row says "Drafts only" rather than "No": the Signature-Agent header moved from a bare-string to a dictionary format in October 2025 and the dictionary form is now required, but vendor documentation still references the old bare-string format. A protocol that ships before it standardises accumulates exactly this kind of divergence, and there is no adopted document to point at when resolving it.

*Provenance note*: the facts in this section are carried over from Agent Identity and Credentialing — Why the Authorization Layer Needs to Know Who's Asking, where they were checked in that page's own verification pass (38 claims checked, 3 removed). They were not independently re-fetched for this table, and are cited here at that confidence.

AP2 (Agent Payments Protocol)

Announcement date (September 16, 2025) and spec publication date are distinct events, not the same thing.

- v0.1.0 — 2025-09-16 — initial release with the core AP2 framework and "Pull" payment method support, signed by Google's agentic-commerce team. Source: https://github.com/google-agentic-commerce/AP2/releases - AP2 announced 2025-09-16 with 60+ launch partners — PayPal, Mastercard, American Express, Adyen, Coinbase, Salesforce, ServiceNow, Worldpay, JCB, UnionPay International named. Source: https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol. Being a named launch partner is not the same as a shipped integration — see Outside Implementations Tracker — separating shipped code from launch-partner press releases across the five agent-payment protocols for that distinction. - v0.2.0 — 2026-04-28 — added "Human Not Present" flows, letting agents execute pre-authorized payments when the user is not present. On the same date, Google donated AP2 governance to the FIDO Alliance, "to ensure platform-agnostic, community-led standardization." Sources: https://github.com/google-agentic-commerce/AP2/releases + https://blog.google/products-and-platforms/platforms/google-pay/agent-payments-protocol-fido-alliance/

Detailed mandate fields (Intent/Cart/Payment Mandate) belong to Google AP2 — the one agent-payment authorization spec that shipped code, not just a press release, not here — this page tracks only the version/date facts.

Agentic Commerce Protocol (ACP)

ACP uses date-based versioning (YYYY-MM-DD) rather than semantic versioning — treat the date itself as the version identifier.

- 2025-09-29 — Initial Release — core checkout functionality; co-developed by OpenAI and Stripe, released under Apache 2.0. - 2025-12-12 — Fulfillment Enhancements — added fulfillment-related capability negotiation. - 2026-01-16 — Capability Negotiation — protocol versioning and agent-merchant negotiation layer. - 2026-01-30 — Extensions, Discounts, Payment Handlers — added discount codes and payment method options. - 2026-04-17 — Cart, Feed, Orders, Authentication, MCP — major capability expansion; added Model Context Protocol support. This is the current version in the table above.

All five ACP entries source to: https://github.com/agentic-commerce-protocol/agentic-commerce-protocol

- ACP remains in beta status as of April 2026 — Stripe and OpenAI maintain joint governance; an unreleased/ directory in the repo tracks active development ahead of the next tagged date. Source: https://stripe.com/blog/developing-an-open-standard-for-agentic-commerce. A jump in unreleased/ activity is itself a staleness signal for this page — see the checklist below.

x402 (HTTP 402 Payment Protocol)

No v1 launch date was found in primary sources for this log; v2 is the first documented major version bump with a public changelog.

- v2 — 2026-01-21 — major upgrade after roughly six months of v1 production usage. Adds wallet-based identity, automatic API discovery, dynamic payment recipients, modular SDK architecture, and CAIP standards for multi-chain/fiat support. Sources: https://x402.org/x402-v2-launch/ + https://x402.report/x402-v2-specification-release-enhanced-modularity-x402scan-v2-launch-and-ronin-integration-for-gaming-payments-01-21-26/ - x402 Foundation established April 2026 — Coinbase contributed x402 to the Linux Foundation for neutral governance. Source: https://www.coinbase.com/developer-platform/discover/launches/agentic-wallets - 2026-08-08 and 2026-08-17 — two MUST-level amendments to `specs/x402-specification-v2.md`, with no version bump (commits db5da2e65952, payment flow handlers; 6dba93edc0b8, settlement pending state). The document still reads **Protocol Version**: 2, so the table row above stays at v2: what changed is the spec text under an unchanged version. Checked 2026-08-26 — Refundable x402 Was Specified in May. On 24 August, Zero of 15,317 Listings Offered It.. - 2026-05-13 — `auth-capture` scheme v1.0, v1.1 dated 2026-08-18 and merged to main 2026-08-25. A separate scheme document, not a core-version bump. Same check date and source. - `coinbase/x402` is a development fork by its own README (note added 2026-04-09; last commit to main 2026-04-21). Watching that repository's main for x402 movement watches the wrong tree. Same check date and source.

x402.org's own tracker shows 75.41M transactions and $24.24M in volume for the trailing 30 days, last updated 2026-07-14, with no per-chain (Base vs. Solana) breakdown published; a separate tracker (agenteconomy.to) counted 157.4M cumulative transactions as of 2026-07-19. The two figures use different windows and definitions and do not reconcile against each other — see x402 'Tens of Millions of Transactions': Reconciling the Claim — a number without a base is not a fact for the full breakdown and do not treat either as a settled, annualizable run rate.

Visa Intelligent Commerce / Trusted Agent Protocol

Visa runs two separate but related protocols: Intelligent Commerce (merchant checkout) and Trusted Agent Protocol (agent identity).

- TAP launched 2025-10-14 — open specification published to GitHub; uses HTTP Message Signatures (RFC 9421) plus Ed25519 signatures. 12 merchant/processor launch partners: Adyen, Ant International, Checkout.com, Coinbase, CyberSource, Elavon, Fiserv, Microsoft, Nuvei, Shopify, Stripe, Worldpay. Source: https://investor.visa.com/news/news-details/2025/Visa-Introduces-Trusted-Agent-Protocol-An-Ecosystem-Led-Framework-for-AI-Commerce/default.aspx - Visa Intelligent Commerce API updated March 2026 — Visa Intelligent Authorization launched on the Visa Acceptance Platform, for acquirers to support emerging payment methods and agentic flows. Source: https://www.pymnts.com/visa/2026/new-visa-api-tool-updates-payment-infrastructure/ - Visa Intelligent Commerce Connect announced April 2026 — enables AI-driven shopping for businesses, integrating Visa Intelligent Commerce APIs with non-Visa networks. Source: https://corporate.visa.com/en/sites/visa-perspectives/newsroom/visa-intelligent-commerce-connect-ai-shopping-for-businesses.html - Visa MCP (Model Context Protocol) Server published February 2026 — secure integration layer for AI agents/LLMs; Node.js/TypeScript implementations provided; bridges to Visa core services. Source: https://github.com/visa/mcp - Production API migration scheduled 2026-02-05 to 2026-02-12 — changes to api.visa.com required client system updates. Source: https://developer.visa.com/ - No formal versioning tags found for TAP or Intelligent Commerce — the TAP repository shows 6 commits on main and no releases/tags published, implying rolling updates rather than tagged releases. Source: https://github.com/visa/trusted-agent-protocol

Mastercard AP4M (Agent Pay for Machines)

Mastercard published a launch announcement, but the full technical specification has not been released publicly — this is the pattern flagged in the table's "Spec Public: Partial" column.

- Launched 2026-06-10 — 31 launch partners announced, including Coinbase, Adyen, Stripe, Cloudflare and others. Source: https://www.mastercard.com/us/en/news-and-trends/press/2026/june/mastercard-launches-agent-pay-for-machines.html - Technical specification not publicly available — press materials describe a four-function architecture (credentialing, permissioning, transacting, settling); no public GitHub repo or open spec was found. Same source as above. - Credentials and spending permissions stored on Polygon, Solana, Base — on-chain component; both card-rail and stablecoin settlement paths are described, but implementation details are not published. Source: https://www.biometricupdate.com/202606/mastercards-ap4m-enables-small-agentic-payments-at-machine-speed-and-scale - No version tag or changelog published for AP4M — this differs from AP2, ACP, x402 and Visa's practice of open versioning, and is treated in these notes as a proprietary launch rather than an open spec. Source: https://www.mastercard.com/

Coinbase Agentic Wallets

Coinbase wraps the x402 protocol in a developer-friendly wallet interface and has no independent version system of its own.

- Launched 2026-02-11 — MPC-secured wallet with session caps, per-transaction limits, gasless Base settlement, and native x402 support. Source: https://www.coinbase.com/developer-platform/discover/launches/agentic-wallets - Distributed via CLI (`npx skills add coinbase/agentic-wallet-skills`) or MCP server — compatible with Claude, Codex, Gemini. Source: https://github.com/coinbase/agentic-wallet-skills - No independent version tags — versioning follows Coinbase's agentkit SDK releases rather than a separate Agentic Wallet version number; depends on x402 v2 as of February 2026. Source: https://github.com/coinbase/agentkit - Spend limits enforced at smart-contract and policy level — on-chain policy enforcement, with KYT compliance screening included. Same source as launch date above.

Re-check schedule

- Monthly (every 4 weeks from the last-checked date): query each protocol's primary GitHub repo (AP2, ACP, x402, TAP, agentkit) for new release tags or commits to main; check official blog/press channels (Google, Stripe, Coinbase, Visa, Mastercard) for new-version or deprecation announcements; scan for breaking changes merged into spec repos. - Quarterly (every 12 weeks): re-fetch every spec URL in the table to confirm it still resolves to the same location; review each protocol's changelog for a summary of accumulated minor versions; check for governance changes (a protocol being donated to a standards body, as AP2 was to FIDO and x402 to the Linux Foundation). - As-needed (urgent triggers): a major version bump (AP2 v0.3, x402 v3, an ACP date jump reflecting unreleased/ activity going live); a deprecation notice; a spec-availability change (e.g. Mastercard publishing the AP4M spec, moving the table's Partial to Yes); a governance change affecting maintenance authority or licensing.

Checklist for updating this page

1. For each row, visit the Spec URL and note whether the version tag or "last update" date has changed. 2. If there is a GitHub repo, check the Releases page for new tags since the last-checked date. 3. If there is no GitHub repo, check official docs for a changelog or "latest update" timestamp. 4. Update the Version Date column if a new version exists. 5. Update the Last Checked column to today's date, in YYYY-MM-DD format. 6. Add a new bullet to that protocol's changelog section with the new version, date, and key features, sourced from the official channel. 7. Update Spec Public if it has changed (e.g. Partial → Yes). 8. Do not add claims from press releases, announcements, or third-party blogs unless they cite a primary source (official repo, spec, or a blog post by the protocol's own maintainer). This is the same discipline as How to Verify an Agent-Payment Protocol Claim Before Citing It — the four checks this wiki runs on every page — this page is where that discipline gets applied to versions specifically.

Signals that a version entry is outdated

- This page's last-checked date is more than 4 weeks old and no recent commits/releases appear in the spec repo. - The spec URL returns a 404 or sits behind an authentication wall — note it as "Access restricted" in Spec Public rather than silently updating the row. - A maintainer blog post or press release describes a new version that has not yet appeared in the GitHub releases — mark it "in press, not yet in repo" rather than promoting it to the table. - The inverse shape, added 2026-08-26: the repo changes and the version does not. The signal above watches for a version announced but not in the repo; x402 took two MUST-level amendments to its spec file on 2026-08-08 and 2026-08-17 while the header stayed at Protocol Version 2. A version bump is not a sufficient trigger — watch commits to each spec document itself, not only release tags (Refundable x402 Was Specified in May. On 24 August, Zero of 15,317 Listings Offered It.). - Another page in this wiki cites a version newer than the one shown here — that is a direct signal this page needs a refresh, not that the other page is wrong.

Version Tag

a semantic (v0.1.0, v2) or date-based (2026-04-17) identifier published by the maintainer in a release, tag, or official changelog. A commit hash or branch name does not count.

Publication Date

the date the version was formally released or tagged — not the date this page was read, and not the date a commit was authored. For a specification, this is when the version became available for use or implementation.

Spec URL

the primary, stable URL where the specification document or code repository lives. It should remain valid and point to current version information; redirects should be followed and noted if they occur.

Last Checked

the date this page was last updated with a re-verification pass — not merely the date it was cited or read elsewhere. This is the field the staleness signals above key off.

Spec Public

- Yes — the full technical specification is publicly available at the Spec URL, in a repository with no authentication barrier, or in published docs. - Partial — some parts are public (press materials, API docs, a launch-partner list) but the full technical specification is not disclosed, or is under NDA. AP4M is currently the only Partial row. - No — the technical specification is proprietary and not publicly available; only marketing materials or press releases exist. No row in the current table is at No.

What this page is for, in this wiki's terms

the objective of this wiki is telling a shipped, dated, sourced spec apart from an announcement — the first of the three-way test in Authorization Layer vs Settlement Layer — the split every agent-payment protocol page in this wiki must be read against (spec vs press release, outside implementation vs none, figure with a base vs figure without one). This page IS that first test, made concrete and datable, for all seven protocol rows at once; every reference page for an individual protocol should defer to this table for its version and date rather than restating one that may drift out of sync.

What does NOT work

Treating a launch-partner announcement or a press release as a version bump does not work: AP4M has a launch date (2026-06-10) and a partner list but no version tag at all, and Visa's two protocols have never published one — collapsing "announced" into "versioned" would hide that gap rather than expose it. Annualizing or projecting from any single figure in this log (e.g. x402's on-chain transaction counts) is also out of scope for this page by design; that arithmetic, with its caveats, lives in x402 'Tens of Millions of Transactions': Reconciling the Claim — a number without a base is not a fact, not here.

Related

- Google AP2 — the one agent-payment authorization spec that shipped code, not just a press release — the full mandate-field detail (Intent/Cart/Payment Mandate) that this page's AP2 version-log entries link forward to; use this page for AP2's dates, that page for AP2's mechanics. - Mastercard AP4M — an announced authorization layer, not yet a published spec or a shipped integration — expands on why AP4M is the sole "Spec Public: Partial" row and what the four-function architecture actually discloses versus withholds. - x402 'Tens of Millions of Transactions': Reconciling the Claim — a number without a base is not a fact — takes the transaction-count figures noted here under x402's changelog and works through what counts as a "transaction" and whether the different trackers reconcile against each other and against the Bazaar enumeration already on record in agent-economy. - How to Verify an Agent-Payment Protocol Claim Before Citing It — the four checks this wiki runs on every page — the general method (find the primary spec, check for outside implementation, find the base of every number) that this page's re-check checklist applies specifically to version and date claims. - Outside Implementations Tracker — separating shipped code from launch-partner press releases across the five agent-payment protocols — where "named launch partner" (recorded here for AP2, TAP, and AP4M) gets separated from "has shipped code using this protocol."