Skip to main content
Wire-format encoder and decoder for the Machine Payments Protocol (MPP), the IETF draft draft-ryan-httpauth-payment co-authored by Brendan Ryan (Tempo) and Jeff Weinstein (Stripe). The adapter handles the three-header round-trip: WWW-Authenticate: Payment (challenge), Authorization: Payment (credential), and Payment-Receipt (receipt). Pure functions, no IO — HTTP transport and on-chain settlement live in the MCP gateway. This package is a wire-format adapter, not the source of truth for the MPP spec. When the IETF draft advances to a new revision or breaks compatibility at the quoted-string escaping or JCS layers, a new minor is shipped and the MPP_VERSION constant is bumped in the same PR.

Install

npmjs.com/package/@glideco/mpp-adapter

Why MPP alongside x402?

MPP and x402 are not wire-compatible. x402 uses custom headers (X-PAYMENT-REQUIRED, X-PAYMENT, X-PAYMENT-RESPONSE); MPP uses standard RFC 7235 (WWW-Authenticate: Payment, Authorization: Payment, Payment-Receipt). The two can coexist on the same endpoint via separate header sets — Glide’s MCP gateway dispatches both. Use MPP when your buyer agents prefer standards-track HTTP auth scheme machinery; use x402 when you want the broader existing agent ecosystem that already speaks it. The method= parameter selects the settlement rail. The server can issue one WWW-Authenticate: Payment header per supported method in the same 402; the buyer agent picks one. Glide supports tempo and solana today; lightning and stripe land in a later release.

Spec version

Pinned to MPP draft-mpp-v1-2026-04 (IETF draft draft-ryan-httpauth-payment). Exported as MPP_VERSION = '1.0'. When the IETF draft becomes an RFC or breaks compat at a draft revision, bump the version literal and re-verify serializeWwwAuthenticatePayment quoted-string escape behavior — RFC 7230 §3.2.6 changes around obs-text affect the backslash + CR/LF handling.

API surface

Challenge + credential round-trip

Multi-rail 402

Serve multiple payment methods in a single 402 — the buyer agent picks one:

Receipt serialization

After F1 server-side RPC verification confirms settlement, emit the receipt:

Security notes

serializeWwwAuthenticatePayment throws if any field contains CR (\r) or LF (\n) — those bytes enable HTTP response-splitting and indicate untrusted data reaching the challenge builder without sanitization. The function escapes backslash before double-quote (in that order) to comply with RFC 7235 quoted-string escaping. The F1 money-safety rule (server-side RPC verify before recording settlement) lives in the MCP gateway, not here. This package is intentionally scope-limited to encoding and decoding headers.

Reading list