How it works
How it works
How a PayTP payment happens, end to end. A merchant advertises support in ordinary HTTP headers; the payer's wallet answers; the payment is negotiated inside the same TLS connection as the request it pays for, then settles on a rail the two sides choose. There are two tiers — a single payment (Tier 0), and a channel for paying often (Tier 1) — each carrying a fixed meed. The common shape is the same either way: advertise support, quote signed terms, prove payment, then serve with a receipt. The Primer and whitepaper go deeper.
Tier 0 · one-shot · settles before delivery
A single payment
For buying something once. No prior relationship is needed, because the payment settles before the merchant delivers. The whole exchange is an ordinary x402 request carrying a signed PayTP extension, so a merchant keeps its existing x402 setup.
The wallet asks GET
The payer's software requests the resource and signals that it speaks PayTP.
The merchant quotes 402
It answers 402 Payment Required with a signed quote — amount, asset, destination, expiry, and the meed terms. This is an ordinary x402 challenge carrying PayTP's extension.
The wallet pays retry + proof
The wallet settles on a rail — dividing the merchant's net from the meed — then retries the request with proof. (How the split executes on each rail is the whitepaper's job.)
The merchant delivers 200 + receipt
It verifies the payment (meed included), serves the resource, and returns a signed receipt. Each proof is single-use, so a lost response can never double-charge.
Tier 1 · for paying the same counterparty often
A payment channel
For a reader and their regular sites, or a software agent calling a paid API thousands of times an hour. Each payment is a tiny authenticated entry — a Value-Slice, about 35 bytes, essentially a meter tick — and the settlement rail is touched only at agreed thresholds, so a hundred thousand tiny payments cost a handful of transfers.
Open
The wallet signs the channel's terms — the currency, a spending limit, the settlement thresholds, and how the meed is split — and the merchant countersigns.
Stream
Value-Slices flow one way, payer to merchant, one per payment. The spending limit caps each side's exposure and pauses payment once it is reached — much like a TCP receive window.
Checkpoint
Now and then both sides co-sign the running total — at once the payer's receipt and the merchant's claim — so the amount riding on unsigned trust never exceeds the agreed limit.
Settle
At each threshold the balance settles on the chosen rail, covering the payout and that round's meed. A settlement that leaves out the meed counts as incomplete: the channel closes, and the shortfall stands in signed evidence.
Close
Any unused deposit returns — unless a successor channel carries the balance forward from the last checkpoint, so a tab can outlive a single connection.
Where the meed goes
Figure 1. Each payment carries a fixed meed schedule. The merchant keeps 99%; the meed — a flat 1% — is divided among the enabling software involved. Adjust the amount, or the roles present, to see how the meed is divided.
With no operating-system role present, its 0.10% goes to an independent open-source fund that a planned PayTP Foundation would not control — so approving or denying an operating system would change its income by zero.
This figure illustrates the fixed meed schedule. The demonstration computes the same division from the reference implementation. When a role is absent, its share goes to a fixed fallback address, so the merchant's cost does not change and no party gains from omitting a role.
What it does, and does not, require
The rail is chosen, not fixed. The protocol specifies no currency and no settlement rail. Stablecoins, on-chain crypto, Lightning, and instant bank rails all qualify. Every implementation also supports one common baseline rail, so any two endpoints always share a settlement path. Which rail becomes that baseline is an open charter decision; today the reference implementation runs the exchange against a simulated in-process rail, and its settlement contracts target Solana as a build choice — no live chain adapter is wired in yet.
No token or chain of its own. PayTP defines no coin and no blockchain. Value-Slices are accounting entries; the actual funds move over whatever rail the two parties accept. There is nothing to buy in order to use it.
It uses the connection that is already there. Support is announced in standard HTTP headers, and payments travel in the existing TLS connection. No new ports, and no changes to routers or middleboxes. A site that does not speak PayTP simply falls back to its normal checkout.