Working draft v0.29 · reference implementation available · not deployed

PayTP: An Open HTTP Payment Protocol with Channels and a Capped Software Incentive

PayTP carries a payment inside the ordinary HTTPS connection that already serves the page or API response it pays for. A merchant advertises it in normal HTTP headers; the payer's software answers with a signed payment proof, negotiated end to end and settled on a rail the two sides choose — no separate checkout gateway, and no token of PayTP's own. It is a compatible superset of x402: the one-shot flow is an x402 request carrying a signed extension. It also carries a capped software incentive — the meed: a fixed one percent of each payment, taken from the merchant's side so the buyer still pays the listed price, that rewards the software which makes paying possible. A reference implementation runs the whole exchange today; nothing is deployed to production.

The idea

PayTP rests on three commitments. They are the spine of the design — everything technical follows from them.

Masterless, end-to-end. No company owns the protocol, and the draft proposes governance intended to prevent any party from unilaterally pricing, repricing, or revoking it; its terms live in an open, capped charter. No mandatory gateway sits in the payment's path — the decisions belong to the payer, the merchant, and the software each of them chose.

Enabler incentives. A fixed 1% of each payment — the meed — rewards the software that makes paying possible: browsers, agent frameworks, wallets, operating systems. It is carved from the merchant's side, so the buyer pays the listed price and nothing more, and no single participant can change it.

Bounded, negotiated trust. Exposure is explicit and capped rather than vouched away. A one-off purchase settles before delivery; an ongoing relationship runs as a tab with a spending limit both sides set. Each side's worst case is a figure it agreed to in advance.

Compatible with x402. PayTP's one-shot flow is an x402 request carrying a signed extension — it adds the meed, payment channels, and a stricter exchange, and coexists with plain x402. How it compares.

Whether the meed works — a fixed, on-wire fee aligning the web's software without a central enforcer, and merchants accepting it — is an economic hypothesis no deployment has yet tested. The Primer makes the case on both sides.

More: the meed · governance · related work · FAQ · status · for implementers · license · formal spec.