How PayTP compares to x402 & MPP

x402 — the closest relative, and decisively ahead where it counts. x402, originated by Coinbase and hosted by the Linux Foundation, executes per-request payments carried in HTTP headers. PayTP's one-shot payment is an x402 request carrying a signed paytp extension: the merchant keeps its x402 stack — challenge, payment, facilitator relationships, settlement — and adds signed PayTP terms for the software that wants them. Plain x402 and PayTP offers coexist in the same menu. Where x402 leads, it leads decisively — standardization, production deployments, facilitator infrastructure, and an active scheme ecosystem including batch settlement. PayTP does not try to beat x402 at any of that.

MPP — a parallel standard, and a harder core. Stripe and Tempo's Machine Payments Protocol carries per-request payment through the HTTP authentication framework — a 402 with a WWW-Authenticate: Payment challenge, answered by an Authorization: Payment credential — and has been submitted to the IETF as an individual Internet-Draft (intended status: standards track). Its core is stricter than x402's minimal core: single-use is mandatory, it defines a receipt header, and its recommended EVM method binds the on-chain authorization to the challenge. But like x402 its core is fee-neutral, and like x402 it defines an extension mechanism — so PayTP relates to it the same way. (The MPP embedding is future work; the reference implementation ships the x402 embedding today.)

The meed — the primary, durable difference. This is the one a fee-neutral standard cannot carry in its own core. x402 and MPP charge no protocol fee, so the software that carries payments is paid off the wire — by sponsors and facilitators whose terms can be repriced or withdrawn (the leading hosted x402 facilitator began charging per settlement in early 2026). PayTP instead carries a small, capped, visible meed — a fixed 1%, taken from the merchant's side — inside each payment, owed to the browsers, agent runtimes, wallets, and operating systems that make paying possible. In the x402 embedding this is not an x402 protocol fee: a baseline PayTP offer quotes a split payTo address, and the signed paytp terms explain the division to aware software; two-leg quotes remain PayTP-only. It rides in the PayTP terms aware endpoints exchange, and is governed under an open, capped charter kept separate from the substrate's infrastructure. Everything else on this page is a refinement; this is the differentiator.

Running-tab channels. For recurring, high-frequency use, PayTP defines one kind of running tab between two parties: a capped exposure window, signed checkpoints that stand as evidence, and thresholds that trigger settlement — described the same way whatever rail settles beneath it. x402's batch schemes and MPP's session methods solve part of this, but each leaves the backing and redemption rules to its own network; PayTP standardizes the relationship itself.

A hardened exchange. Two properties matter: a payment should buy the exact resource it named, and one authorization should never be redeemed for more than one delivery. Both substrates can provide these — x402 through optional extensions and scheme practice, MPP with more of it in its core (single-use, a request digest, on-chain challenge-binding on EVM). PayTP makes them mandatory — and adds one check of its own, below.

The gap both leave to the endpoints. x402 and MPP bind a payment to the challenge it answers, but leave authenticating that challenge's origin to the endpoints. Left there, an agent router, an in-path proxy, or the interaction layer itself can present its own challenge, naming its own recipient, and a substrate-only wallet pays the substitute. Their omission is principled, not negligent: a direct payer-to-merchant connection is already covered by TLS, and the gap opens only in the mediated, autonomous case — an agent flow with no human to confirm the origin.

What PayTP binds. PayTP makes the quote a merchant-signed object bound to the merchant's authenticated origin, and holds delivery until the merchant itself confirms settlement — with no facilitator cast as the authority. How far that reaches depends on the wallet: a PayTP-aware wallet that can independently authenticate the intended merchant origin refuses a substituted quote before any funds move. That is the check neither substrate requires in its core for an autonomous agent with no human to confirm the origin — x402 can carry optional signed-offer evidence, but PayTP makes origin-bound quotes mandatory for PayTP-aware payments.

Honestly scoped. The protection is deliberately narrow. It works for a PayTP-aware wallet that can authenticate the intended merchant itself. Where the wallet is fully delegated to an in-path party it cannot authenticate, single-leg origin binding does not reach — closing the redirect there takes PayTP's own two-leg flow, which is a PayTP construct, not an x402 or MPP one. Two limits remain: a party that terminates TLS with the merchant's own certificate is inside the origin, not an intermediary to it; and this is the protocol design — the reference implementation is a baseline-profile artifact, not yet a proof of the full hardened exchange.

What the security record actually shows. Two independent analyses of deployed x402 stacks document cross-resource substitution and duplicate-settlement / replay within a single merchant — a malicious client against one endpoint — which PayTP's mandatory single-use and resource-binding close. The cross-origin redirect above is a separate axis PayTP names on its own; those papers do not document it, and PayTP does not attribute it to them. The "buy the exact resource you named" half is being closed across the ecosystem without origin-auth; the origin half is PayTP's own, narrow contribution.