What None of These Protocols Currently Solve — the gaps common to AP2, AP4M, Visa, ACP and stablecoin rails

Across every authorization protocol this wiki tracks (AP2, AP4M, Visa Intelligent Commerce, ACP, Coinbase Agentic Wallets), four problems remain unsolved as of the sources checked here: a mandate/token issued under one protocol does not carry to another; on-chain settlement has no chargeback-equivalent; mid-transaction human override is described mostly as pre-authorization plus escalation, not a live stop-and-ask at the moment of spend; and no protocol yet produces a standardized, cross-system audit trail a user could hand to a regulator. Use this page as the checklist for grading any protocol's marketing claim about "solving" one of these.

Cross-protocol portability of a mandate/token

An AP2 mandate is encoded as a W3C Verifiable Credential and is described as "theoretically portable" (Google's own framing) — https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol. But portability today runs one direction only: Mastercard joined AP2 as a launch partner in September 2025 specifically so "an AP2-compliant agent can pay via Mastercard rails with the AP2 mandate envelope wrapping a Mastercard Agentic Token" — https://www.cobo.com/post/ap2-protocol-complete-guide-to-agent-payments-for-web3-developers-2026. That is AP2 riding on top of a card-network token, not a mandate moving freely between independent protocols. See Authorization Layer vs Settlement Layer — the split every agent-payment protocol page in this wiki must be read against for why that composition (mandate-on-top-of-rail) is the general pattern, not an exception.

Cross-protocol bridges: roadmap, not shipped. AP2's own roadmap lists "Cross-Protocol Bridges: Interoperability with other agent payment standards" as a "medium-term (2027) initiative" — https://www.cobo.com/post/ap2-protocol-complete-guide-to-agent-payments-for-web3-developers-2026. That is a direct admission the capability does not exist yet.

No established cross-protocol standard. Commentary from payments law notes "multiple options exist [AP2, x402, Stripe/Tempo MPP] but there is no established standard" and flags "lack of a clear framework for handling disputes" as a direct consequence — https://www.fenwick.com/insights/publications/is-2026-the-year-of-agentic-payments.

(unverified) A merchant or agent-builder that wants to accept payment from an AP2 agent, an ACP agent, and an x402 client is implied by multiple sources to need a separate integration for each — this specific claim is not stated directly by any single source read here, only implied by the absence of a unified standard. Treat as a working hypothesis, not a confirmed fact. See Interoperability or Walled Gardens? Cross-Protocol Compatibility — what a builder actually integrates when an AP2, ACP, x402 and UCP agent all show up for the fuller merchant-integration-count question.

Dispute resolution for on-chain/stablecoin agent payments: no chargeback-equivalent

Stablecoin transfers are final and irreversible by blockchain design: "once recorded, it cannot be undone or reversed by any central authority" — https://www.plasma.org/learn/stablecoin-chargebacks. The structural reason is the settlement model itself: stablecoins use a "push model where the sender (customer) initiates and authorizes the transfer of funds," in contrast to the card "pull model" where merchants can trigger a reversal — https://www.plasma.org/learn/stablecoin-chargebacks. Traditional card chargebacks have no equivalent here: "no chargeback in the card-network sense, no 60-180 day dispute window, and no scheme to file a claim with" — https://eco.com/support/en/articles/14839404-stablecoin-payments-for-ai-agents. Consumer protection follows directly from this: "a consumer who buys a defective product through an agent cannot file a card-style chargeback" — https://www.fenwick.com/insights/publications/is-2026-the-year-of-agentic-payments.

What exists instead, and its limits

Circle's Refund Protocol is the most mature non-custodial dispute mechanism on record. It requires "upfront refund addresses specified during payment initiation" and "fixed lockup timelines" before funds can be withdrawn, via three functions — specify a lockup period, approve refunds, permit early withdrawal with fees — https://www.circle.com/blog/refund-protocol-non-custodial-dispute-resolution-for-stablecoin-payments. Its own stated limitations: it "lacks audited security guarantees, cannot prevent a malicious arbiter from issuing unwarranted refunds, and incurs higher gas costs than standard transfers" — same source. Smart-contract escrow and arbiter-mediated refunds are described as emerging alternatives, but "standardization across merchants, wallets, and protocols remains lacking" — https://www.spark.money/research/payment-reversal-stablecoin-chargeback-gap. Dated, and superseded for x402 only. That sentence held when spark.money wrote it; as of 2026-08-26 a standard exists for one protocol on this page: the auth-capture scheme, v1.0 2026-05-13, v1.1 2026-08-18, bound to EVM on existing contracts (Refundable x402 Was Specified in May. On 24 August, Zero of 15,317 Listings Offered It.). What is missing there has moved from standardisation to deployment — no server half, no facilitator, and 0 of 15,317 listings declaring it on 2026-08-24. Nothing here says the other protocols acquired one.

Why this is hard to solve without recreating the fraud problem it avoids

friendly fraud (illegitimate chargeback claims) already costs merchants an estimated $103 billion annually under the card system; building consumer protection into stablecoin rails without reintroducing that cost is the unresolved tension — https://www.spark.money/research/payment-reversal-stablecoin-chargeback-gap.

Agent-to-agent disputes add a layer human transactions don't have. Timing and state divergence: "network latency, message queue delays, and distributed ledger propagation windows can all produce divergent records of the same event" — https://www.tfsfventures.com/blog/resolving-payment-disputes-between-autonomous-agents-1719. And a judgment vacuum: agents "cannot negotiate in natural language the way humans do, and they cannot exercise discretionary judgment about whether a disputed amount is worth pursuing" — same source, which also names cross-border jurisdiction conflicts and vertical-specific dispute patterns (supply chain vs. healthcare revenue cycles) as unresolved.

When it applies

any protocol here that settles in stablecoin (AP4M's on-chain path, Coinbase Agentic Wallets, x402) inherits this gap wholesale; card-rail paths (Visa Intelligent Commerce, AP2-over-Mastercard) inherit the card network's existing — if imperfect — chargeback machinery instead. See Settlement Latency and Finality by Rail — the number an agent must block on before it can call a payment 'done' for how the two rails otherwise compare.

Real-time, mid-transaction human override

What exists is threshold-based escalation, not a live pause at the moment of purchase. Vouched describes the pattern: "if a task is high-risk or over a limit, the system asks the person to sign off," and separately, a kill-switch: "stop access if you see a threat or a mistake... once you revoke its access, it cannot spend your money" — https://www.vouched.id/learn/blog/ai-agent-transaction-authorization. The IMF's report on this describes the same shape at the institutional level: for transactions over a threshold, systems create a "pending" transaction and notify a human for real-time approval, with agent execution contingent on that approval — https://www.elibrary.imf.org/view/journals/068/2026/004/article-A001-en.xml.

The trade-off is explicit in the sources, not implied. Friction-free execution below the threshold is the whole point — "humans do not need to click 'yes' for every single small buy" — but that same design "may obscure patterns" the human never sees — https://www.vouched.id/learn/blog/ai-agent-transaction-authorization. And the approval loop has a real cost when it does trigger: payment delays from human approval can "unintentionally increase liquidity risks and make risk-hedging strategies less effective" — https://www.elibrary.imf.org/view/journals/068/2026/004/article-A001-en.xml. The same IMF source notes a regulatory consequence of keeping override/pause capability at all: platforms that maintain it "may be subject to heightened regulatory scrutiny, including licensing requirements."

UNVERIFIED / negative finding

none of the sources read for this page cite an actual deployed system that checks for mid-transaction approval at the moment of purchase execution itself, as opposed to pre-authorization boundaries plus escalation for out-of-scope transactions. If a protocol page in this wiki claims true real-time mid-transaction override, that claim needs its own primary source — it is not backed by anything found here.

Auditability: can a user reconstruct what an agent was authorized to do vs. what it did?

Regulatory expectation is already stated plainly: "every agent transaction must be traceable to a verifiable human principal, must operate within a pre-authorised mandate, and must produce a tamper-evident audit trail" — https://www.trustsphere.ai/post/authenticating-the-autonomous-buyer-identity-mandate-and-audit-trail-for-agentic-payments. The same source names three capabilities leaders are actually implementing toward that: verifiable agent identity via cryptographic credentials, mandate-aware authorization that declines out-of-scope transactions, and tamper-evident audit trails.

Where it breaks down in practice, by party

- Consumers: "consumers granting open-ended mandates underestimate transaction volume, creating disputes when bills arrive" — https://www.trustsphere.ai/post/authenticating-the-autonomous-buyer-identity-mandate-and-audit-trail-for-agentic-payments. - Merchants: they "struggle differentiating legitimate agent traffic from bot abuse" — same source. - Banks: they "face significant operational lift in disputes where the agent identity is not cryptographically verifiable end to end" — same source.

Missing logs cannot be recovered after the fact. "Organizations can often add logging, monitoring, and observability layers to capture future AI interactions," but "information that was never recorded cannot usually be reconstructed after the fact" — https://www.miniorange.com/blog/ai-agent-audit-trail/. That source specifies what a complete audit trail needs to capture: trigger/intent, chain of thought, tool & API calls, context window payload, and output & action — five components, and gaps in any one break reconstruction.

Retrofitting is failing; purpose-built stacks aren't universal yet. "Institutions attempting to retrofit agentic commerce onto existing infrastructure are failing, while purpose-built stacks succeed" — https://www.trustsphere.ai/post/authenticating-the-autonomous-buyer-identity-mandate-and-audit-trail-for-agentic-payments. Practically this means centralizing logs across diverse SIEM platforms remains a major integration barrier — https://www.miniorange.com/blog/ai-agent-audit-trail/ — compounded by fragmentation at the business-system level: "fintechs typically operate with multiple systems: payment gateways, KYC providers, CRM tools, and internal databases, each producing its own log files in different formats" — https://www.tfsfventures.com/blog/agent-payment-infrastructure-2026-overview.

No standard schema yet. "The audit trail format must be standardized" for cross-platform forensic tools and regulatory reporting, but "a common event schema, perhaps based on the OpenTelemetry model," is not yet adopted — https://www.compelframework.org/articles/audit-trails-and-decision-provenance-in-multi-agent-systems?nav=stage.

(unverified, follows from the interoperability gap above, not independently sourced) cross-protocol audit trails are fragmented — each of AP2, ACP, x402, AP4M and Visa Intelligent Commerce is understood to maintain its own logging format, preventing unified reconstruction of an agent's spending history across multiple payment systems. This is an inference from the absence of cross-protocol bridges (see above), not a claim any source states directly.

A determinism problem, not just a format problem. Even within a single audit trail, when two agents submit conflicting claims about a transaction's status, "nondeterministic arbitration creates audit trail inconsistencies that financial-services regulators will not accept" — https://www.compelframework.org/articles/audit-trails-and-decision-provenance-in-multi-agent-systems?nav=stage. That is a harder problem than logging format: it says the underlying event record itself can be genuinely ambiguous between two honest agents, which no schema alone fixes.

Why this page matters for the wiki's objective

The objective of this wiki is separating what has shipped and is measurable from what is announced. This page is where that discipline is applied negatively: instead of grading one protocol's claims, it fixes the four problems that recur across *all* of them, so a reader evaluating any single protocol page (Google AP2 — the one agent-payment authorization spec that shipped code, not just a press release, Mastercard AP4M — an announced authorization layer, not yet a published spec or a shipped integration, Visa Intelligent Commerce: Tokenized Agent Credentials — the spec-vs-announcement test applied to Visa's own numbers, Agentic Commerce Protocol (ACP) — the checkout-layer spec Stripe and OpenAI ship, and the deployment it already killed, Coinbase Agentic Wallets — spend limits enforced server-side, native x402, and how thin the outside-usage evidence still is) can check its marketing against a fixed checklist rather than accepting "solves disputes" or "full audit trail" at face value. Use Mandate Expression Compared — AP2, AP4M, Visa, ACP, Coinbase Side by Side, Where the Constraint Actually Lives for the side-by-side of how each protocol expresses (or fails to express) revocation and constraints, and Who Is Liable When a Prompt-Injected Agent Spends Money — the unresolved question behind every mandate protocol in this wiki for what these same gaps mean legally when a prompt-injected agent actually spends money.

Related

- Authorization Layer vs Settlement Layer — the split every agent-payment protocol page in this wiki must be read against — the mandate-riding-a-rail composition pattern (AP2 over Mastercard) is the concrete example of the portability gap described here. - Interoperability or Walled Gardens? Cross-Protocol Compatibility — what a builder actually integrates when an AP2, ACP, x402 and UCP agent all show up — the merchant-side integration-count question this page's portability section only gestures at (unverified) is worked in full there. - Who Is Liable When a Prompt-Injected Agent Spends Money — the unresolved question behind every mandate protocol in this wiki — when dispute resolution and audit trails fail, this is the page that asks who actually eats the loss. - Settlement Latency and Finality by Rail — the number an agent must block on before it can call a payment 'done' — the stablecoin finality property that makes chargebacks structurally impossible is explained mechanically there. - Outside Implementations Tracker — separating shipped code from launch-partner press releases across the five agent-payment protocols — a protocol claiming to solve one of these four gaps should be checked against that page's shipped-vs-announced evidence bar before the claim is trusted.