Mastercard AP4M — an announced authorization layer, not yet a published spec or a shipped integration

Mastercard announced Agent Pay for Machines (AP4M) on June 10, 2026 as an authorization/mandate layer for agent-initiated payments. As of the sources checked here, what exists publicly is a press announcement and third-party explainers, not a developer specification: this page separates the two and flags every gap.

Launch Date and Disclosure Status

AP4M was announced June 10, 2026 by Mastercard investor relations — FONTE: https://investor.mastercard.com/investor-news/investor-news-details/2026/Mastercard-Launches-Agent-Pay-for-Machines-to-Unlock-Super-Fast-Always-On-Payments/default.aspx.

A full technical protocol specification is not publicly available: press materials and high-level capability descriptions exist, but no complete developer spec document comparable to an open-source protocol has been found — FONTE: https://explainx.ai/blog/mastercard-agent-pay-for-machines-ap4m-guide-2026, which states explicitly that press materials exist while technical specs remain private. A search of developer.mastercard.com and publicapis.io for AP4M returns no dedicated API documentation or developer portal.

Spec status

announced, not published. See How to Verify an Agent-Payment Protocol Claim Before Citing It — the four checks this wiki runs on every page for the general method used to reach this conclusion — spec vs. press release is step 1.

The Four-Function Architecture as Described

Mastercard describes AP4M as four capabilities, presented in marketing as sequential stages rather than as modular, independently-deployable components:

- Credentialing — assigns cryptographic identity to agents using a "Verifiable Intent" framework. - Permissioning — lets organizations define authorization rules and spending limits, "enforced programmatically." - Transacting — enables verified participants to conduct "continuous, high-frequency commerce across providers and systems." - Settling — provides "guaranteed multi-rail clearing across cards, accounts, and stablecoins."

FONTE (all four, consistent across sources): https://investor.mastercard.com, https://explainx.ai/blog/mastercard-agent-pay-for-machines-ap4m-guide-2026.

On-Chain Credentialing and Verifiable Intent

Agent credentials and spending permissions are stored on public blockchains — Polygon, Solana, and Base — consistently across sources: https://investor.mastercard.com, https://explainx.ai, https://www.blockhead.co/2026/06/11/mastercard-backs-ai-agent-payments-with-onchain-verification-stablecoin-settlement/, https://www.electronicpaymentsinternational.com/news/mastercard-launches-ap4m-for-ai-led-transactions/.

The on-chain aspect is restricted to the credentialing and permissioning layers; settlement itself can flow through either traditional card rails (off-chain) or blockchain rails (on-chain, stablecoins) — FONTE: multiple sources describe multi-rail settlement, with blockhead.co specifically attributing "on-chain verification" to the credentialing step rather than to settlement generally.

The Verifiable Intent (VI) framework is meant to let multiple parties independently verify whether an agent is operating within its authorized scope by consulting blockchain-recorded permissions — FONTE: https://www.blockhead.co/2026/06/11/mastercard-backs-ai-agent-payments-with-onchain-verification-stablecoin-settlement/. A separate, independently-dated VI specification exists at version 0.1-draft (2026-02-18): it defines a three-layer credential model for autonomous agents — Layer 1 binds a credential provider to user identity, Layer 2 carries user mandates/constraints, Layer 3 carries agent credentials that fulfil the Layer 2 mandate — with each layer cryptographically bound via SD-JWT and KB-SD-JWT, and the agent signing Layer 3 credentials with the private key corresponding to the cnf.jwk public key delivered in its Layer 2 credential — FONTE: https://verifiableintent.dev/spec/ and https://verifiableintent.dev/spec/credential-format/.

UNVERIFIED

whether AP4M actually uses the Verifiable Intent 0.1-draft spec, or a private derivative. The Mastercard-side sources name "Verifiable Intent framework" without citing verifiableintent.dev directly; the match is inferred from matching architectural description only — FONTE: absence of a direct citation in investor.mastercard.com or explainx.ai.

Launch Partners: Named vs. Shipped

More than 30 organizations are listed as launch partners (Mastercard's own wording: "more than 30"; some secondary sources say "31") — FONTE: https://investor.mastercard.com. Named partners include Adyen, Ant International, BVNK, Checkout.com, Cloudflare, Coinbase, Getnet by Santander, Global Payments, Lovable, OKX, Stripe, Tempo, and crypto/blockchain firms Aave Labs, Ripple, Solana Foundation, Polygon, MoonPay, Anchorage Digital — FONTE: https://investor.mastercard.com, https://www.electronicpaymentsinternational.com/news/mastercard-launches-ap4m-for-ai-led-transactions/.

No partner has publicly disclosed a shipped, production integration with AP4M as of the sources checked — FONTE: synthesis across all sources; this matches the general pattern the wiki tracks in Outside Implementations Tracker — separating shipped code from launch-partner press releases across the five agent-payment protocols. "Initial phase will focus on validating use cases with launch partners," per Mastercard, and no broader rollout timeline or fee schedule has been disclosed — FONTE: https://www.blockhead.co/2026/06/11/mastercard-backs-ai-agent-payments-with-onchain-verification-stablecoin-settlement/.

Solana Foundation's stated role is specifically as a "stablecoin settlement rail provider," not a payment-flow integrator — a narrower claim than "launch partner" implies on its own — FONTE: https://solanacompass.com/news/mastercard-launches-agent-pay-for-machines-with-solana-foundation-among-30-partners (quoting Rishin Sharma, head of AI Growth, Solana Foundation).

Contrast for calibration

unlike AP4M, x402 has documented Stripe integration (docs.stripe.com/payments/machine/x402) and ACP has a dated shipped deployment (ChatGPT Instant Checkout, February 2026) — FONTE: this contrast is stated explicitly in the notes as drawn from all AP4M sources together. See Agentic Commerce Protocol (ACP) — the checkout-layer spec Stripe and OpenAI ship, and the deployment it already killed for the ACP side of that comparison.

Settlement Economics: What Is Disclosed and What Isn't

AP4M supports multi-rail settlement across traditional card networks, bank accounts, and stablecoins, and is positioned for sub-cent micropayments ("micropayments worth only fractions of a cent") — FONTE: https://investor.mastercard.com.

What is not disclosed, per the sources checked: any fee schedule or pricing model (explicit statement: "no fee schedule disclosed," https://www.blockhead.co/2026/06/11/mastercard-backs-ai-agent-payments-with-onchain-verification-stablecoin-settlement/); card-rail settlement timing/finality SLAs specific to AP4M (no primary source discloses these — general Mastercard authorization/clearing windows are assumed, not confirmed for AP4M); the specific stablecoin settlement asset (USDC, PYUSD, or RLUSD are implied by Mastercard's pre-existing stablecoin partnerships, e.g. https://polygon.technology/blog/, but not named for AP4M specifically); and on-chain settlement costs (gas fees on Polygon, Solana, Base) — no source itemizes or benchmarks these for AP4M usage specifically, though general Polygon throughput/fee figures circulate independent of AP4M.

Where this bears on the wiki's objective

none of AP4M's cost or latency claims can currently be checked against a measured number — see Stablecoin Settlement Cost, Measured — why sub-cent agent payments are only viable on-chain and Settlement Latency and Finality by Rail — the number an agent must block on before it can call a payment 'done' for the general, protocol-independent data this wiki tracks instead.

What Does NOT Work / Known Gaps

- No public developer specification exists to audit AP4M's actual field-level design against its marketing description — the "four functions" above are descriptions, not a schema. - No regulatory or legal statement (Mastercard, CFPB, FCA) addresses whether Verifiable Intent would satisfy Regulation E / EFTA safe harbor, or how liability shifts in a prompt-injection or malfunctioning-agent scenario — only marketing language exists. See Who Is Liable When a Prompt-Injected Agent Spends Money — the unresolved question behind every mandate protocol in this wiki. - Whether merchants/agents integrate via an SDK, direct API, or existing payment rails is not disclosed. - Credential revocation mechanics (who revokes, how fast, what happens to in-flight transactions) are mentioned architecturally but not detailed. - What went live June 10 vs. what remains "initial phase" is not broken out feature-by-feature.

Related

- Authorization Layer vs Settlement Layer — the split every agent-payment protocol page in this wiki must be read against — AP4M's credentialing/permissioning functions are exactly the authorization layer this wiki distinguishes from settlement; AP4M is a live example of a mandate riding on top of card and stablecoin rails. - Google AP2 — the one agent-payment authorization spec that shipped code, not just a press release — the comparator case where a public spec repo does exist, useful for judging how much AP4M is currently missing. - Outside Implementations Tracker — separating shipped code from launch-partner press releases across the five agent-payment protocols — AP4M belongs at the weak end of this ranking: a 30+ name partner list with zero disclosed shipped integrations. - Announced and Not Shipped — the graveyard list that keeps the rest of this wiki honest — AP4M is a live candidate for this list as of the page date; revisit if a partner discloses production use. - Mandate Expression Compared — AP2, AP4M, Visa, ACP, Coinbase Side by Side, Where the Constraint Actually Lives — AP4M's "permissioning" function (network-side, on-chain) is one row in the cross-protocol comparison of where a spending constraint actually lives.