A primary-source review of MPP, Payment Auth, Tempo and HTTP 402 for the week ending August 16, 2026.
Last week gave us three chains changing settlement semantics in the same seven days. This week gives none of that. No new payment terms, no new provider integrations, and — for the first time in the weeks I’ve tracked this brief — no spec changes at all. What moved was documentation, one removed fallback, a dependency bump, and a UI pass. That’s a legitimate week’s work for a maturing project, and I’m not going to dress it up as anything more than it is.
The SDK documentation caught up to the implementation
mpp PR #889 synced the mppx documentation with upstream behavior, covering Stripe metadata handling, stablecoin minimums, and PaymentIntent idempotency keys. mpp PR #881 resolved a batch of audited documentation issues, including receipt formatting, charge request structures, and challenge binding mechanics. mpp PR #875 updated the Stripe integration pages to clarify the preferred stripe.create() approach for MPP-on-Stripe implementations. mpp PR #886 revised the quickstart examples to explicitly separate mainnet and testnet configuration and to demonstrate proper MPP_SECRET_KEY generation.
None of these change what MPP does. They change whether a new integrator can find out what MPP does without guessing or filing a support ticket. Documentation accuracy is unglamorous, but it’s the difference between an integration that ships in a day and one that ships in a week of back-and-forth — and the mainnet/testnet split in particular closes a real path to an accidental production mistake, not just a clarity gap.
One fallback removed, on purpose
mpp PR #885 removed an internal Stripe profile fallback, stated purpose: reduce integration confusion. That’s a different kind of change than the documentation passes above — removing behavior, not just explaining it. I don’t have evidence either way on whether any existing integration was quietly depending on that fallback path. That’s the kind of thing that shows up later as a regression report, not in a PR diff, so I’m naming it as the one item this week actually worth re-checking rather than filing away as routine.
The rest of this week’s repository activity, correctly not treated as news
A dependency bump advanced pnpm/action-setup to v6.0.10, and a UI fix aligned the home page with a reference design, adjusting animation timing and terminal presentation. Real work, correctly held to the same line every week here: a busy commit history isn’t a busy adoption story.
A new post on request attestation, worth flagging on its own
mpp PR #884 published a new mppx identity blog post covering Web Bot Auth, the Trusted Agent Protocol, and signed request attestations. That’s the Payment Auth layer this brief tracks separately from the settlement rail — proving a request came from a legitimate, identifiable agent before payment logic runs. A blog post isn’t a spec change or a new implementation; it’s the project explaining a surface it apparently considers ready to be understood by integrators. Whether that surface gets cited or built against in the coming weeks is worth watching rather than assuming.
A skeptical data point from outside the ecosystem
The most concrete outside signal this week wasn’t about MPP at all. A Hacker News post, “I put an API behind an x402 paywall for nine days”, reports 1,835 callers and zero payments over the run. That’s a real, checkable number, not a vibe — and it cuts directly against the more optimistic framing in three other posts surfacing this week: a Show HN on using Mu’s agent tools with x402 payments, an executable SOAR playbook dataset billed per record over HTTP 402, and a post describing an API monetized with x402 in 30 minutes, no accounts or API keys. None of these four posts comes with independent verification — they’re all self-reported, and I have no transaction records for any of them. But “zero payments across 1,835 calls” is worth sitting with precisely because it’s the one number in the batch that argues against the ecosystem’s own enthusiasm rather than for it.
What I’m taking from the quietest week yet
Zero specs, zero integrations, zero payment terms — the thinnest verified week in this brief’s run so far. What did happen was documentation catching up to implementation, one confusion-reducing removal that deserves a second look, and an attestation-layer blog post landing in the same week an outside data point suggests x402 paywalls aren’t yet converting callers into payers. None of that is a spec or adoption signal I can act on, and I’m not going to inflate it into one. Next week’s honest question is the same as it’s been: does any already-listed service show a second week of real usage, and does anyone corroborate — or refute — the conversion skepticism the community raised this week.
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.