A primary-source review of MPP, Payment Auth, Tempo and HTTP 402 for the week ending August 23, 2026.
Last week was the quietest one I’d tracked: zero spec changes, zero integrations, all documentation and cleanup. This week isn’t quite that thin — there’s one real spec hardening and one real bug fix — but the catalog still didn’t move. No new services, no new provider integrations, no new pricing terms. What changed was how strictly the protocol enforces its own rules, and how accurately one endpoint charges money.
Failed verification now means nothing gets through, not just nothing important
mpp-specs PR #321 changes the charge intent specification to require MUST NOT for any partial access after a verification failure — response bytes, streamed output, tool or API calls, and async task initiation are all explicitly blocked, not just the “main” payload. That synchronizes the charge-intent language with the core idempotency rules already in place elsewhere in the spec.
This is a narrower change than it might sound, but it closes a specific and real gap: a protocol that says “don’t grant access on failed verification” without naming every channel access can leak through is a protocol that implementers will interpret inconsistently. Streamed tokens and async task kickoffs are exactly the kind of side channel where an early, irreversible effect could happen before the failure is fully processed. Naming them explicitly is what turns “should not” into something an auditor can actually check an implementation against.
A seven-pull-request documentation sync, mostly closing gaps that already existed in behavior
The bulk of this week’s repository activity was documentation catching up to what the SDK already does: a sync of mppx docs through upstream commit 7568194c, a new service submission guide for the registry, hosted fee-payer support for Tempo sessions, a description of standard x402 v2 payments without mppx extensions, documentation of dynamic stream amounts over SSE and WebSocket, and a streamlined Tempo agent quickstart.
None of these changes what the protocol does. What they do is lower the odds that a new integrator gets the mainnet/testnet split wrong, misreads the fee-payer model, or assumes mppx extensions are required when they aren’t. The service submission guide is the one I’d flag as structural rather than clarifying — it’s aimed at the people trying to get into the catalog, not the ones already integrated, and that’s a different kind of accessibility than a docs fix.
The real fix this week was a decimal, not a paragraph
mpp PR #909 corrects the Stripe charge amount in the photo endpoint, moving it from "100" to "1" and removing a non-standard decimals: 0 override that had been left on the integration. The endpoint was priced to display and charge $0.01, but with the old settings it would have charged $1.00 — a tenfold overcharge — on every transaction. The merged fix aligns the endpoint with the STRIPE_PAYMENT standard of decimals: 2 used elsewhere.
I’m not going to pretend this is a small item just because it’s one line of config. A payment integration that silently charges 100x its stated price because of a decimals mismatch is precisely the kind of bug that erodes trust in machine-initiated payments faster than any spec gap does — a human might notice a $1.00 charge for a $0.01 photo; an agent paying on a loop might not, for a while. That it was caught and fixed before this brief is the good outcome here. Whether it shipped to production before the fix, and for how long, isn’t something I have visibility into from the PR record alone — that’s worth verifying directly rather than assuming it was caught in time.
Two more self-reported x402 experiments, no more verified than usual
Two Hacker News posts surfaced this week describing new x402-based payment flows: an agentic-payment auction concept riding on x402, and a project describing an agent-to-agent payment loop where agents pay each other for data via x402. Both are self-reported, neither comes with transaction records or independent verification, and I have no way to confirm either is processing real payments rather than demonstrating a wiring diagram. I’m naming them the same way I named similar posts in past weeks — as community signal to watch, not developments to report — because the gap between “someone built a demo using x402” and “x402 is settling real machine-to-machine commerce” is exactly the distinction this brief exists to hold onto.
What I’m taking from a hardening-and-correction week
Zero new services, zero new integrations, zero new pricing terms — the catalog held still for a second straight week. What moved was precision: the charge-intent spec now names every channel that must stay closed after a failed verification, and a real overcharge bug in a live Stripe integration got caught and fixed. Neither is an adoption signal, and I’m not going to call it one. What’s worth verifying next is concrete rather than speculative: confirm the atomicity behavior actually holds in an environment with an irreversible first effect like a streamed token, confirm the photo endpoint now charges and displays $0.01 correctly, and keep watching whether either of this week’s self-reported x402 demos resurfaces with anything closer to real transaction evidence behind it.
I built MPP Pulse to keep those layers separated instead of blurring them into one undifferentiated “things happened” feed. It’s an open-source AWS agent that collects primary evidence and drafts a cited weekly brief for human review.