Refundable x402 Was Specified in May. On 24 August, Zero of 15,317 Listings Offered It.

x402 has carried a specified, contract-backed mechanism for holding, partially capturing, voiding, refunding and reclaiming a payment since 13 May 2026. As of the last full enumeration of the discovery index (24 August 2026), no listing out of 15,317 declares it. The reference implementation ships the buyer's half only, and its own README says the server half is not built.

The date in the headline is the date of the fact. Everything below is dated the same way: the fetch date for every source is 2026-08-26 and is never the date of a fact.

What this page does not claim. It does not claim the reversal layer "shipped". A specification, a network binding and a client library exist; a facilitator and a server do not. Keeping those apart is the whole point.

The claim this page tests

What Is Actually Priced: The One-Cent Ceiling, and the Market That Escaped It argues the one-cent ceiling is caused by three absences: no inspection before payment, no reversal after it, no memory of who was right. Its wording on the second is flat — *"in x402 the money moves first and the content arrives afterwards, with nothing in between"*, and *"x402 has no such state. Once settled, settled."* What None of These Protocols Currently Solve — the gaps common to AP2, AP4M, Visa, ACP and stablecoin rails says the same at protocol level, noting that non-custodial refund machinery exists (Circle's Refund Protocol) but that *"standardization across merchants, wallets, and protocols remains lacking."*

Those sentences are now wrong about the protocol and still right about the market. Separating the two is what follows.

FATTO — the `auth-capture` scheme, and its dates

Regime: citazionale. Document: specs/schemes/auth-capture/scheme_auth_capture.md in github.com/x402-foundation/x402 (canonical raw URL in provenance). Its own version history, quoted verbatim:

| Version | Date | Changes | Authors | |---|---|---|---| | v1.1 | 2026-08-18 | Payment flow lifecycles and operator types | @phdargen | | v1.0 | 2026-05-13 | Initial draft | @A1igator |

The two dates are different facts. 2026-05-13 is when the mechanism first existed as a specification — that is the date the market has had to respond to. 2026-08-18 is the version stamp v1.1 carries. The commit that put v1.1 on main is f8a3682de3e6, "Auth-capture spec update: v1.1 (#3197)", 2026-08-25. The EVM binding (scheme_auth_capture_evm.md) carries the identical version table and moved in the same commit.

Scheme summary, verbatim

*"Where exact moves a fixed amount once and offers no way to give it back, auth-capture is for payments whose final amount is not known when the client authorizes, or which may later need to be undone."*

Lifecycle table, verbatim:

| Operation | Effect | Repeatable | |---|---|---| | authorize | Reserves the client's funds, where they are held. | No — once per payment. | | charge | Collects and distributes the funds in one step, with no hold. | No — once per payment. | | capture | Pays held funds out to the receiver. | Yes — up to the held total. | | void | Releases the remaining hold back to the client. | No — only while a hold remains. | | refund | Returns captured funds to the client. | Yes — up to the amount captured and not yet refunded. | | reclaim | Client recovers its own hold after the capture deadline passes. | No. |

The buyer's unilateral exit, verbatim: *"reclaim is the client's unilateral escape hatch and is never relayed through the facilitator."* Two absolute deadlines govern it — extra.captureDeadline and extra.refundDeadline — so *"a resource server that abandons a payment cannot strand it forever."*

Both of the scheme's flows are reversible, which matters for how it is counted below. The scheme defines escrow (default: hold, then capture or void, then refund, with reclaim as backstop) and authorization (*"charge after the resource runs, and refund later. No hold, therefore no capture, void, or reclaim."*). Refundability does not require the hold.

The EVM binding names its substrate rather than describing it: *"The binding builds on the [base/commerce-payments](https://github.com/base/commerce-payments) contract stack"*, whose AuthCaptureEscrow singleton *"holds funds, enforces the expiry ordering, moves value on every operation, and gates each of them on msg.sender == paymentInfo.operator."* That repository exists (github.com/base/commerce-payments, created 2025-03-06, last push to default branch 2026-07-27, description *"Onchain authorization and capture for trust-minimized commerce"*).

FATTO — the core spec grew two new orderings, without a version bump

Regime: citazionale. specs/x402-specification-v2.md took two normative amendments inside the 5–26 August window: commit db5da2e65952, "feat(ts): payment flow handlers (#3053)", 2026-08-08, and commit 6dba93edc0b8, "feat: add settlement pending state (#3083)", 2026-08-17. Section 6.1 ("Asset Transfer Methods and Payment Flow Models") now defines three orderings. Flow and Ordering columns are verbatim; the Description column is truncated by us at the ellipsis:

| Flow | Ordering | Description (truncated) | |---|---|---| | authorization (default) | verify → resource → settle → respond | "Read-only verify before the resource executes; funds move only after it completes successfully." | | upfront | settle → resource → respond | "Payment is durably committed before the resource executes, giving the server finality first. Facilitator /verify is not part of this ordering…" | | escrow | settle → resource → settle → respond | "A first settle commits a deposit or ceiling, the resource executes, and a second settle records the final charge. Facilitator /verify is not part of this ordering…" |

extra.paymentFlow is now a protocol-reserved key: *"clients and servers MUST interpret them as defined here rather than as opaque scheme-private fields."* The 17 August addition makes settlement admit an unresolved state — settlement_pending is *"the settlement transaction was broadcast but its confirmation could not be established… Facilitators MAY return this non-terminal code."*

The spec itself warns against reading `escrow` as the buyer-friendly option. Verbatim: *"When a resource offers both authorization (post-handler settlement) and a pre-handler-settlement flow (upfront or escrow) for the same request, clients SHOULD prefer authorization."* upfront and escrow are grouped as pre-handler fund commitment. So an escrow count is a proxy for one specific shape of buyer recourse, not for buyer protection in general — a correction to how the counts below could be misread.

**A staleness signal Protocol Version and Date Log — the version/date table every other page in this wiki must match does not currently catch. That page's x402 row reads "v2, version date 2026-01-21, last checked 2026-08-24" (verified in that file). The document still reads `Protocol Version**: 2` at its head, yet took two MUST-level amendments on 8 and 17 August. Its checklist watches for a version announced but not in the repo; the shape here is the inverse. That is a correction owed to that page.

FATTO — the server half does not exist yet

Regime: citazionale, on two independent artifacts.

The package typescript/packages/mechanisms/evm/src/auth-capture/ has exactly two commits: 10e59e125a "auth-capture client scheme (TypeScript) (#2486)", 2026-05-29, and 4f587236e9 "feat(TS): spend controls (#3124)", 2026-08-13. Its README, verbatim:

> This package currently ships the client only: detecting auth-capture payment > requirements and signing the payment payload. Server and facilitator support follow in a > later change.

The repository tree corroborates the README rather than merely repeating it: a full recursive listing of main returns 26 paths matching auth-capture, and the only implementation subdirectory under the package is client/ (client/index.ts, client/scheme.ts). There is no server/, no facilitator/, and no Go or Python port at all — the paths are confined to specs/, the TypeScript EVM package, its unit tests, and one TypeScript client example.

So a buyer's agent can sign an auth-capture payment and no seller can accept one through the reference stack. This is the cleanest instance in this wiki of the distinction Outside Implementations Tracker — separating shipped code from launch-partner press releases across the five agent-payment protocols exists to keep: shipped code on one side is not shipped code.

Regime: attestato. Who

Salesmart S.r.l., which publishes Sinapsi. Method: re-reading the accepts[].scheme field of three complete enumerations of the x402 discovery index already on file (The x402 Market, Counted: 14,766 Listings, 12,741 Calls a Day, One Winner) — bazaar-2026-08-03.json (14,766 records), bazaar-2026-08-05.json (14,620), bazaar-2026-08-24.json (15,317). Base: every record in each file, not a sample; counts are listing-level (a listing counts once per distinct scheme it offers). No fourth census was taken; this is a new question put to existing files, and anyone holding them can rerun it. Every figure in this section and the next two was recomputed from the files during verification and reproduced exactly.

| Scheme | 3 Aug | 5 Aug | 24 Aug | |---|---|---|---| | exact | 14,756 | 14,609 | 15,215 | | upto | 86 | 89 | 230 | | batch-settlement | 50 | 50 | 195 | | exact_cosmos_authz | 126 | 126 | 89 | | onchain | 23 | 23 | 14 | | aggr_deferred | 18 | 18 | 13 | | agent-pay | 2 | 2 | 2 | | nvm:erc4337 | 0 | 1 | 2 | | alipay:a2m | 0 | 0 | 1 | | `auth-capture` | 0 | 0 | 0 |

The string does not appear at all: it is absent, not rare.

Window the zero is measured over. Against v1.0's availability, not v1.1's: specified since 2026-05-13, i.e. 103 days before the 24 August enumeration; client code since 2026-05-29, 87 days before. The 24 August file predates the v1.1 merge (2026-08-25) by one day, so nothing here is a verdict on v1.1.

The index is not what is stopping it. The Bazaar extension spec (specs/extensions/bazaar.md) lists scheme as an optional free-string query filter — *"Filter by payment scheme (for example, exact)"* — with no allowed-value list anywhere in the document. The index in fact carries nine distinct scheme strings on 24 August, several non-standard vendor names (alipay:a2m, nvm:erc4337, aggr_deferred). A seller who wanted to advertise a refundable payment could. The obstacle is the one the README states.

ATTESTATO — offered the buyer's ordering and the seller's, the index took the seller's

Same files, same method, offer-level this time. extra.paymentFlow — the key made protocol-reserved on 8 August — appears in the index for the first time on 24 August:

| | 5 Aug | 24 Aug | |---|---|---| | Offers declaring extra.paymentFlow | 0 | 318 | | of which upfront | 0 | 318 | | of which escrow | 0 | 0 |

Base and its limits

318 of 36,473 offers on 24 August, 0.87%. All 318 sit on one host, api.magentlab.com, behind one recipient address, 0x33236133BecE789D551d0B5c4f9A50095d4b57d3. One operator is not a market, and nothing about buyer preference follows from it — buyers are not visible in this field at all. What does follow is narrower: of the two orderings the spec published together, the one that hands the server finality before delivery reached the index within sixteen days and the one that leaves the buyer holding a claim on the funds had not, at n=1 operator.

ATTESTATO — the supply growth in this window is a handful of wallets, not a market

Listings by host, 5 → 24 August (host taken from the listing's resource URL):

| Host | 5 Aug | 24 Aug | Gain | |---|---|---|---| | api.m2mcent.com | 0 | 937 | +937 | | api.delx.ai | 121 | 942 | +821 | | x402.orthogonal.com | 11 | 432 | +421 | | api.magentlab.com | 0 | 318 | +318 |

Base and window

all listings in the two files, 19 days apart. Gross listing gains across all hosts total 6,233 against a net index change of +697, so roughly 5,536 listings also disappeared. Those four hosts supply 40.1% of gross gains.

The two scheme counts that moved materially both move with one host each. On 24 August, 159 of the 195 batch-settlement listings sit on api.magentlab.com, which had none on 5 August — the *net* rise was only 145 because other hosts shed listings (api.vaults.fyi 20 → 5). Likewise 85 of the 230 upto listings sit on fittings.sh, absent on 5 August, with agent402.tools supplying another +59 (35 → 94); net rise 141. The claim is limited to those two counts: nvm:erc4337 (1 → 2) and alipay:a2m (0 → 1) also rose and are not bulk-listing, they are noise at n≤2. This is the supply-bubble shape already recorded in The x402 Market, Counted: 14,766 Listings, 12,741 Calls a Day, One Winner, not new demand.

Offers grew far faster than listings — 28,665 → 36,473 (+27.2%) against 14,620 → 15,317 (+4.8%), so mean offers per listing rose from 1.96 to 2.38. Sellers are attaching more payment options to the same endpoint. None of the added options is refundable.

One recorded observation with no weight attached: the alipay:a2m scheme string appears once, on token4u.ai, on 24 August and not before. n=1. Logged only so a later reading of China Shipped Agent Payments First. The 1,000x Volume Gap Does Not Survive the Numbers. has the date, not because anything follows from one listing.

FATTO — the other protocol repositories did not move in this window

Regime: attestato (our fetch, 2026-08-26) over citazionale primary artifacts (the repositories). Method: GitHub REST commit and release listings; window opens 2026-08-05. "Last commit" means last commit to the default branch.

| Protocol | Repository | Last commit to default branch | Commits since 5 Aug | |---|---|---|---| | AP2 | google-agentic-commerce/AP2 | 2026-04-29 (e1ea56db72) | 0 | | ACP | agentic-commerce-protocol/agentic-commerce-protocol | 2026-07-18 (7fdd78df67, #281) | 0 | | Visa TAP | visa/trusted-agent-protocol | 2025-10-28 (16d59bdf3f) | 0 | | Visa MCP server | visa/ai — `visa/mcp` now 301-redirects here (api.github.com/repositories/1090553246) | 2026-06-08 (4df7e39af8) | 0 | | Coinbase agentic wallets | coinbase/agentic-wallet-skills | 2026-08-04 (70cb79c85f) | 0 | | x402 | x402-foundation/x402 | 2026-08-25 | 10 to specs/ alone |

The identifier correction is load-bearing. visa/mcp no longer resolves as a name; the GitHub API returns 301 to repository id 1090553246, whose current name is visa/ai. Any row in this wiki that tracks visa/mcp by name is tracking a redirect.

AP2's newest release is still v0.2.0, published 2026-04-28; there is no v0.3. Mastercard AP4M still has no public repository or open specification, so its row in Protocol Version and Date Log — the version/date table every other page in this wiki must match stays at "Spec Public: Partial" (Mastercard AP4M — an announced authorization layer, not yet a published spec or a shipped integration).

coinbase/x402 declares itself superseded — README verbatim: *"Our repo ([coinbase/x402](https://github.com/coinbase/x402)) is now a development fork."* Two dates, neither of which the README states: the move note landed in commit 0e07cd437f, 2026-04-09; the last commit to main is dd927a26cf, 2026-04-21. Its pushed_at is 2026-08-24, so non-default branches still move — main is what is frozen. Anyone watching that repository's main for x402 movement is watching the wrong one; the Protocol Version and Date Log — the version/date table every other page in this wiki must match x402 row points at x402.org, not at x402-foundation/x402, and should point at the foundation repo.

Scope of this section, stated so it is not over-read

it covers six named repositories, not "every agent-payment protocol". Protocols with no public repository (AP4M), work happening on non-default branches, and anything outside these six are invisible to it. AP2's repository, for instance, has a pushed_at of 2026-06-17 — later than its last main commit, still before the window opens, but proof the branch-level view differs from the main-level view.

Recorded absence — regulation

Regime: attestato, and weak. One search pass on 2026-08-26 for a dated normative act on agent-initiated payments issued between 5 and 26 August 2026 returned nothing new; everything returned re-dated to instruments already in this wiki (Regulation E's unresolved authorized/unauthorized line, Visa Core Rules 4.1.24.8, ID# 0031174, April 2026 — Regulatory Response to Agent Payments So Far — What's Actually on the Books vs Assumed, US and Canada: The Rails Shipped First, and the Rulebook Named the Payer).

A correction to an earlier draft of this page, kept visible. That draft listed "the CFPB's January 2026 Regulation Z advisory" among the existing instruments. It is not one. US and Canada: The Rails Shipped First, and the Rulebook Named the Payer already records that exact item under claims it could not stand up: *"We searched consumerfinance.gov and the Federal Register and found nothing matching. Treat it as unsourced until someone produces the document."* Repeating it here would have laundered a refuted claim back into the wiki through a new page. It is removed.

Absence of a finding is not a finding of absence: one search pass, English-language sources, no register enumerated exhaustively.

Our reading

This section is interpretation, not measurement.

What Is Actually Priced: The One-Cent Ceiling, and the Market That Escaped It argued the one-cent ceiling follows from missing information, not from adoption stage. Its weakest form was always the risk that the machinery simply had not been built — that x402 was young, not structurally limited. That excuse is weaker now: for 103 days the reversal machinery has had a specification and a named contract stack, and for 87 a signing client. The index's answer is zero.

But the honest reading has to say which zero this is. The README says the facilitator side is not built, and the repository tree confirms no server code exists in any language. Sellers therefore cannot offer the scheme through the reference stack even if they want to. That makes the zero primarily a measure of the *implementers'* priorities, not the sellers' preferences — a materially weaker claim than "the market rejected refunds".

What survives that discount is narrower and harder. Given a fully specified, contract-backed reversal scheme sitting in the same repository, the people writing the code shipped the buyer's signing half in May (2026-05-29), spend controls in August (2026-08-13), and upfront settlement handlers — the ordering that gives the server finality first — within the same window (db5da2e65952, 2026-08-08; bb46ffc6eeed, "upfront paymentflow for exact mechanism", 2026-08-25), while leaving the escrow-and-refund server half for "a later change." Effort followed the seller's risk before the buyer's. That is the same asymmetry A Spending Limit Is Not a Conduct Limit finds in mandates: what gets built is the constraint on quantity, not the constraint on conduct.

The prediction that follows is cheap to check and we are on the record for it: the facilitator half will ship before a meaningful number of sellers offer the scheme, and the gap between the two is the interesting number.

Falsifier

On the market. We are wrong, and this page should be superseded, if by 2027-04-30 a full enumeration of the discovery index finds either more than 200 listings declaring scheme: "auth-capture", or more than 500 offers declaring extra.paymentFlow: "escrow" from at least 5 distinct `payTo` addresses. The distinct-seller floor is deliberate: without it one operator with a script clears any threshold we could write, exactly as api.m2mcent.com and api.magentlab.com did in this window.

Known weakness of the second arm

the scheme's authorization flow is also refundable, so an escrow count under-detects refundable supply; a listing declaring auth-capture with paymentFlow: "authorization" trips the first arm and should.

On the protocol. We are wrong if auth-capture is withdrawn, or if its version history stops advancing while exact continues — that would make v1.1 an abandoned branch rather than a direction.

Both are one command against a fresh dated snapshot with the script in agent-economy/dati/, plus one fetch of the spec's version table.

Honest limits

One facilitator's index. The zero is a count inside one discovery index. A refundable x402 payment negotiated privately, or listed elsewhere, is invisible to us — the standing scope caveat of The x402 Market, Counted: 14,766 Listings, 12,741 Calls a Day, One Winner.

Point-in-time versus trailing-window. Listing, offer and scheme counts are point-in-time and compare cleanly across the files. Any *call* figure is not: the index's l30DaysTotalCalls is a trailing 30-day window, so the 5 and 24 August readings share roughly 12 of 30 days and no traffic delta may be quoted as a period-on-period change. This page rests on point-in-time fields only.

The scheme string is self-declared. We count what sellers write in accepts[].scheme. A seller offering refundable payment under a private scheme name would not be matched. Nothing in the three files resembles one, but we cannot exclude it.

Host attribution is by URL. Listings are grouped by the netloc of the resource URL. One operator behind several hostnames would be counted as several, which makes the concentration figures a *lower* bound on concentration.

We did not run the code. Spec, binding, README, tree and commit dates were read; no auth-capture payment was signed, settled, or refunded by us. Every claim about what the scheme *does* is citazionale on the specification, never attested by execution.

We did not audit the contracts. base/commerce-payments was confirmed to exist with its dates and description. Whether AuthCaptureEscrow behaves as the binding says is outside what we checked, and the binding itself warns that its appendix Solidity *"illustrates a future addition rather than audited or deployed code."*

Related

- What Is Actually Priced: The One-Cent Ceiling, and the Market That Escaped It — the thesis this page tests; its "Once settled, settled" needs the protocol/market split made here. - The x402 Market, Counted: 14,766 Listings, 12,741 Calls a Day, One Winner — the enumerations re-read here, and the source of the supply-bubble shape the mass-listers reproduce. - x402: HTTP 402 Finally Gets a Job, at 32 Cents a Transaction — the protocol page these scheme and payment-flow additions belong under. - Protocol Version and Date Log — the version/date table every other page in this wiki must match — four corrections owed: the v2 document amended without a version bump, the coinbase/x402 fork, the visa/mcp → visa/ai redirect, and an x402 row that points at x402.org rather than the foundation repo. - What None of These Protocols Currently Solve — the gaps common to AP2, AP4M, Visa, ACP and stablecoin rails — its "standardization remains lacking" on reversal is now dated: a standard exists since 2026-05-13, deployment does not. - Outside Implementations Tracker — separating shipped code from launch-partner press releases across the five agent-payment protocols — where "client shipped, server not shipped" belongs as a category. - US and Canada: The Rails Shipped First, and the Rulebook Named the Payer — the source of the refuted CFPB advisory item this page had to remove from itself.

What does NOT work

Reading the scheme table as adoption does not work: the two counts that grew materially grew because one host each bulk-listed, and four hosts supply 40% of all gross listing gains.

Treating the 318 upfront offers as evidence of what buyers prefer does not work: they are one wallet, and the field records what the *seller* advertises.

Treating escrow as the buyer-protection flow and upfront as the seller-protection flow does not work as a clean dichotomy: the core spec groups both as pre-handler fund commitment and tells clients to prefer authorization over either, and auth-capture's authorization flow is refundable without any hold.

Citing "x402 now supports refunds" as a market fact does not work in either direction: the specification is real and dated 2026-05-13, the facilitator is not built in any language, and the sellers number zero.

Titling this "x402 shipped the reversal layer" does not work, and an earlier draft of this page did exactly that. A spec plus a client is not a shipped layer, and 2026-08-18 is a version stamp, not a release date.