A primary-source review of MPP, Payment Auth, Tempo and HTTP 402 for the week ending September 13, 2026.
Last week was the flattest one yet — four changes, all inside the build pipeline or the docs, zero verified new development. This week breaks that streak with something that actually touches what the specification covers: the IETF Payment Auth suite adds a payment method for the XRP Ledger. Everything else sitting alongside it is the same kind of hygiene work that’s shown up in every recent brief, plus one real Tempo-ecosystem announcement and a run of self-reported x402 side projects that don’t clear the bar for a verified development.
The spec picks up an XRP Ledger payment method
mpp-specs PR #346 adds the xrpl payment method to the core specification, with a matching documentation update in mpp PR #963 and the underlying merged commit. The method supports two intents: a charge intent for a single payment, and a session intent for an off-ledger channel — the kind of construct that lets a payer and payee settle a running balance without posting every individual transaction to the ledger.
This is the first substantive expansion of the spec’s method catalog I’ve covered in a few weeks, and it’s worth being precise about what it does and doesn’t establish. Adding xrpl to the specification means implementers now have a documented way to express XRP Ledger payments and payment channels through Payment Auth. It doesn’t mean anyone has shipped that yet — the report’s own “what to verify next” asks directly whether an xrpl-mpp-sdk correctly implements both intents as specified, which tells me the SDK side isn’t confirmed working (or possibly doesn’t exist yet) as of this report. Spec support and working implementation are two different milestones, and only the first one happened this week.
Error handling gets a name: problem URIs land in the core spec
mpp-specs PR #353 derives the specification’s problem pages directly from the core spec, formalizing four problem URIs: bad-request (400), invalid-payload (402), internal-payment-error (500), and payment-action-required (402). Two of those map to the same 402 status code but mean different things — a malformed payload versus a challenge that still needs a payment action — which is exactly the kind of distinction that matters once an agent, not a person, is deciding how to react to an error.
This is the same category of change as August’s payment-expired status: small, and precisely the sort of precision that lets client code branch on what actually went wrong instead of pattern-matching a status code and hoping.
The recurring hardening thread continues
The rest of the mpp-specs activity this week is the same maintenance pattern that’s run through every recent brief. PR #350 moves the Stripe and Tempo charge intent titles to consistent Title Case. PR #349 cites TEMPO-TX-SPEC directly in the Tempo charge method documentation. PR #351 renews the core IETF draft ahead of its Datatracker expiry, bumping it to revision -01. PR #352 sets author countries to US across the core draft’s author list. And PR #347 pins the GitHub STS action to a POST-based token exchange, continuing the same vendoring-and-pinning campaign against third-party CI actions that’s shown up in each of the last several weeks.
None of these change what the protocol does. The draft renewal is the one with a hard deadline attached — an expired IETF draft stops being a citable, current reference — so confirming that revision -01 is correctly picked up by anything pointing at the spec is worth a look.
Docs catch up to mppx’s own main branch
mpp PR #966 syncs documentation to mppx’s main branch, covering deferred EVM signing, MCP multi-offer composition, and subscription documentation bound to Challenge IDs. PR #968 updates recipient allowlist examples for both primary and split recipients. PR #964 stabilizes documentation fonts and trims initial JavaScript. This is the recurring “docs catching up to what the SDK already does” pattern from prior weeks, not new capability — worth noting only because “subscription documentation bound to Challenge IDs” is a detail that’s easy to skim past and actually describes how recurring payments get tied to a specific auth challenge, which is a real piece of subscription plumbing even if the code behind it shipped earlier.
A real Tempo-ecosystem move, outside the spec
One item this week is a genuine company announcement rather than a repository change: Wirex is now live on Tempo for enterprise stablecoin card programs. Like BlackRock’s BUIDL integration a few weeks back, this is Tempo-the-company signing up an institutional partner on its own rail, not an MPP protocol change — but it’s a first-party announcement with a named counterparty, which puts it a step above the self-reported community posts below. I’m flagging it separately rather than folding it into “MPP developments,” for the same reason I’ve drawn that line before: the spec and the company running its primary payment rail are related but distinct things to track.
A handful of self-reported x402 projects, named and left there
This week’s source ledger carries more outside links than usual, and none of them get treated as verified developments: a Show HN for a SOCKS proxy billed to AI agents over x402, a project describing agent payments routed by social handle rather than Stripe or bank rails, a described headless payment backend for gaming economies, a serverless x402 gateway for FastAPI on Vercel, a newsletter writeup of x402, a second x402-trinity project aimed at local AI and robotics, and a blog post claiming an AI agent bought a physical t-shirt over HTTP 402 with USDC, no human involved. All seven are self-reported, none come with an independently checkable transaction record, and none of them are MPP, Tempo, or the IETF spec — they’re evidence that people are building against x402 in the wild, which is worth naming as community signal without counting it as this week’s news.
What I’m taking from this week
The one thing that happened to the specification itself this week was real: xrpl is now a documented payment method with charge and session intents, expanding Payment Auth’s coverage into XRP Ledger payment channels. Everything else — problem URIs, title case, a draft renewal, author metadata, pinned CI actions, a docs sync — is the same hygiene work that’s carried the last several briefs, and Wirex’s Tempo integration is a real but separate layer of news about the rail rather than the protocol. The honest open question is whether the xrpl method gets an implementation to match it: does an SDK show up handling both intents correctly, or does this stay a spec-only addition for another few weeks the way some past method additions have.
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.