Why PayTP?

Every payment system has to answer one question: who is paid for making the payment possible? Cards answer it with interchange, collected by networks and banks. App stores answer it with commission. Most open payment standards do not answer it at all, which is why the underlying software that would have to support them rarely does. Or the question is answered quietly: the standard is free to use, but its sponsor earns somewhere else — on the rail it runs, or the processing it sells — an agenda the protocol itself never states.

PayTP's answer is the meed: a transparent, flat 1% taken from the merchant's side and paid on the wire to the software that makes paying possible.

Apart from this novel on-wire incentive structure, PayTP does not invent new capabilities — nearly everything below exists somewhere already. However, no one offers them together, on an open protocol, without an owner whose interests may eventually diverge from the parties using it.

PrivatePay — no account, no signup, no stored credential. Paying does not require creating a relationship with the merchant. The wallet uses a separate unique payment identity for every merchant, so there is no reusable credential to steal in a breach, and no payment identity that links a buyer's purchases from one site to the next.

SubscriptionControl — subscriptions that can be easily stopped, unilaterally by the buyer. With PayTP, each subscription payment is pushed by the payer, not pulled by the merchant — so cancelling is a single action in the payer's wallet.

InstantRefund and DisputeResolve — buyer-focused protection that merchants can offer as an additional service. The protocol has room for instant no-questions refunds, and for neutral third-party adjudication when a sale genuinely goes wrong.

WarrantyControl — receipts and warranties the buyer keeps. A payment can carry a merchant-signed record of what was bought and what was promised (services, warranties, etc.), held by the buyer's wallet rather than in a third-party app.

MicroPayments — pay in amounts a card can't handle: a couple of cents for an article, a fraction of a cent per API call, a few pennies to tip, per-second billing for a service. A whole layer of transactions too small to be worth processing before becomes possible.

Protocols like PayTP also let wallets offer controls that belong to no single merchant — for example, spending limits, sub-accounts for family members, or proof of age that reveals nothing else about you. These are wallet features rather than PayTP inventions. What an open payment protocol adds is that they can work the same way everywhere, instead of only inside one company's app.

Taken one at a time, every capability above exists somewhere already. Taken together, and provided by software that is not also selling something else, the combination may give buyers more control than any other existing payment system.

For a merchant, PayTP changes four things: who can reach you, what payment costs you, what you can charge for, and what risks you no longer have to carry.

ReadyCustomers — buyers who arrive able to pay. The meed pays browsers, wallets and agent frameworks on every payment, so they have their own reasons to support PayTP and to ship it where buyers already are. And because that software earns only when a payment completes, it has a standing incentive to make paying quicker and simpler.

This is what gave us the frictionless tap of Apple Pay: a share of roughly 0.15% per transaction, on top of the existing card fees, was enough for Apple to build the smoothest checkout on the phone. The meed is a customer acquisition cost for merchants.

FixedFee — capped at one percent, forever. That is PayTP's entire fee: published, governed, and not repriceable by any participant. Optional services the merchant chooses to offer can add up to 0.5% more. Outside of PayTP, rail fees and gas can add another few basis points, but it is up to the merchant to find the cheapest rails and fee structures.

MicroPricing and MeteredBilling — transactions today's card rails are not built to support. Sub-cent amounts, per-request billing and per-article sales. Metered billing allows for a running tab to settle in periodic batches, touching the rail a few times a day to minimise settlement costs.

NoChargebacks — no card-style chargebacks to fight. Payments are signed by the buyer and final, so there is no unilateral chargeback to reverse a settled sale — and the friendly fraud that shelters behind "it wasn't me" disappears with it. That is the category driving most disputes on today's card rails.

NoGatekeeper — PayTP puts no one in the middle of the sale. No mandatory gateway, no card network judging a business the wrong kind, and no acquirer holding settlement back as a reserve: money moves as fast as the rail, minus only a refund window the merchant sets. The only parties who can decide whether the sale proceeds are the two endpoints and the rail and software they each chose.

NoPCI — no card numbers, so no card-data burden. Taking cards today means complying with PCI DSS — the Payment Card Industry Data Security Standard — which brings an annual assessment, security scans and breach liability, even for a merchant that never stores a card number. PayTP payments carry none of it.

This is the side existing standards forget. A browser, an agent framework, a wallet, an operating system — the software that turns an intent into a payment a merchant can trust — does substantial work with no way to bill for it. PayTP's answer is to pay it on the wire.

MeedShare — a published share of every payment. Of the 1% base: 50 bp to the interaction layer, 30 bp to the wallet, 10 bp to the operating system, and 10 bp to a Protocol Development Fund for ongoing development, audits and upkeep. No affiliate contract to negotiate merchant by merchant, and no rail of its own to operate. The share is set by the protocol and can only be changed by governance and broad consensus.

NoToken — no PayTP coin to buy or hold. PayTP issues no token of its own: nothing to acquire as a condition of taking part, no token sale, and nothing whose price your revenue depends on. You are paid in the ordinary settlement asset, received on the shared baseline rail — so a recipient needs an account there, or a provider that receives and converts on its behalf.

MerchantNeutral — the same rate for every merchant. No merchant can pay to be favoured over another, so payment revenue never becomes a question about whether the software is biasing which shop it shows you. There is nothing for a merchant to bid for, and no wall to maintain between a commerce team and the people who control ranking.

EasyIntegration — an extension, not a new stack. For software that already speaks x402 over HTTP, the one-shot flow (Tier 0) is that same exchange plus signed PayTP terms: advertise, quote, verify, deliver. No new transport and no proprietary rail. Supporting running tabs (Tier 1) takes more integration work.

The 1% is flat. It pays the roles inherently involved in completing a payment — and, because the protocol is itself part of every payment, a Protocol Development Fund to keep it maintained. Nothing else. Everyone else stays out of the way — unless they provide a service that both the buyer and the merchant opt into. Those are paid from a separate tier of up to 0.5%, declared in the same signed payment and earned only where the merchant offers the service and the buyer accepts it.

The specification reserves one such future role: dispute resolution. Adding others would take a governance decision rather than a commercial deal.

None of it is running. PayTP is a specification and a reference implementation, published for review. There are no live payments, no users, and no adoption to cite. Everything above describes what it would be worth if it works and if others build on it — both open questions.

Almost nothing here is individually novel. Card issuers, Apple, Google and open-banking rules already give buyers comparable control over recurring payments; other machine-payment stacks already price below a cent; refunds, dispute resolution and receipts all exist elsewhere, in some good products. The argument is about the combination, the openness, and who controls it.

The meed is a design, not a track record. No one has yet earned a share of a PayTP payment. Whether it draws in the software it needs — much of which has no way to earn from payments today — is the open question the whole idea rests on.

The hard part is untested. The whole design rests on software supporting a protocol because it is paid to. The incentive is real and the mechanism is specified, but whether that produces adoption at scale is the open question, and no amount of design settles it.

Nobody is compelled. Plain x402, cards, and direct transfers remain available and meed-free. A large platform can simply decline to support PayTP, and the protocol has no answer to that beyond the incentive itself.