A primary-source review of MPP, Payment Auth, Tempo and HTTP 402 for the week ending September 27, 2026.
The last brief in this series covered the week ending September 13, when the IETF Payment Auth suite picked up an xrpl payment method. This week’s pulse signal is flatter than that one: no verified new development. No new services, no new payment terms, no catalog changes. The one thing that touches how the protocol actually behaves is a fix to how HMAC challenge binding gets computed — everything else sitting around it is documentation, CI hygiene, and dependency housekeeping.
HMAC challenge binding gets vectors instead of vibes
mpp-specs PR #362 defines deterministic HMAC-SHA256 challenge-binding layouts, with explicit test vectors for three cases: legacy inputs, header-only inputs, and header-plus-opaque inputs. The merged commit keeps backward compatibility with existing challenge IDs rather than breaking them.
This is a spec fix aimed at removing ambiguity, not adding capability. Before this, two conforming implementations could plausibly compute a challenge binding differently for the same header-plus-opaque case, because the spec described what to bind without pinning the exact byte layout. Vectors close that gap the way a test suite closes a spec’s own loopholes: now there’s something concrete to check an implementation against instead of a prose description open to two readings. Worth verifying next is whether existing MPP integrators’ HMAC implementations actually match the new vectors, especially around legacy challenge IDs minted before this PR — a spec correction doesn’t do anything until the running code catches up to it.
Documentation lines up with the current IETF draft
mpp PR #1000 and its merged commit correct protocol examples in the docs to match draft-httpauth-payment-01 — fixing Tempo Challenge formats and Receipt references that had drifted from what the current IETF draft actually specifies.
Docs drifting from the spec they’re supposed to describe is a familiar failure mode for any protocol with more than one home for its canonical text — a draft moves at the IETF, the implementation guide doesn’t, and eventually an implementer copies an example that no longer matches. This closes that gap for one draft revision. It doesn’t tell me anything about whether draft-httpauth-payment-01 is itself the officially published version at the IETF Datatracker right now, which is the more basic thing worth confirming before treating this as settled.
The pin-and-upgrade campaign keeps going
The CI hardening thread that’s run through most of the last several briefs continues on both repositories. In mpp-specs: PR #364 pins shared gh-actions workflows, followed by PR #367, PR #368, and PR #369 updating those pins to fresh commits (d39baa2b, bd66336e, ee2960a6). In mpp: the same pattern repeats across PR #1003, PR #1008, PR #1016, and PR #1018, and PR #1011 upgrades dependencies outright rather than just re-pinning them.
None of this changes what either repository does. It’s the same supply-chain instinct that’s shown up for weeks — fewer third-party actions with standing repository permissions, dependency versions that don’t move without someone choosing to move them. Worth a look, per the report itself: whether the dependency bump in PR #1011 carries any breaking changes or license terms nobody signed up for, since “upgrade dependencies” is a commit message that can hide a lot.
Session recording and memos sync with how Tempo and Stripe actually settle
mpp PR #998 syncs MPPx session recording and memo handling with Tempo and Stripe settlement practices, alongside a smaller pair of documentation fixes — PR #999 enforcing code-fence conventions and PR #1001 preserving semantic tab labels in MCP setup examples.
The memo-handling piece is the one with actual settlement consequences even though it’s filed as documentation: it describes how a memo attached to a payment should map onto a Tempo Session or a Stripe PaymentIntent when the two systems reconcile. Get that mapping wrong in the docs and an integrator can build a mismatch that only shows up when a memo doesn’t survive settlement. The other two are formatting fixes to how examples render — real, but not consequential the same way.
Two side projects named in the source ledger, not verified
This week’s source ledger also carries a handful of Hacker News posts describing independent x402 work: tkeeper, pitched as threshold cryptography for AI agents handling payments and digital assets, Tenjin, a Jev-based x402 tool router for Claude Code, and a0flow, described as paid micro-APIs for AI agents over x402/USDC with no signup. None of these touch MPP, Tempo, or the IETF spec, and none come with a transaction record I can check independently — they’re the same kind of self-reported community signal that’s shown up in past briefs, named here rather than folded into “developments.”
What I’m taking from a hygiene-only week
Nothing shipped this week that changes what a payment looks like, who can take one, or what it costs. What did happen is precise in a way that’s easy to undervalue: a challenge-binding fix that turns an underspecified byte layout into something with test vectors, documentation that stopped drifting from the current IETF draft, a CI pipeline that keeps closing off third-party dependencies one pin at a time, and a memo-handling sync that matters the moment a Tempo Session and a Stripe PaymentIntent need to agree on the same payment. None of it is adoption news. All of it is the kind of maintenance that makes the next adoption story less likely to break on a spec ambiguity nobody caught.
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.