8 standards
Paying for an API call rather than a subscription. These standards use HTTP status 402 to say that a request needs payment, and define what the client sends back to satisfy it.
Also searched as 402, x402, monetization, micropayment, paywall, PacketPay, metering.
8 standards, spread across 2 of the 12 topics.
Charging a small amount for a single web request has no standard shape, so every service invents one and no client can be written once. This defines how a server states its price and how a client pays it in the same exchange.
Filed under Payments
HTTP payments is the main subject of these 6.
Charging a small amount for a single web request is impractical with cards, where the fee can exceed the payment. This describes paying per request with Bitcoin, so an interface can be metered by use rather than sold by subscription.
Charging a small amount for a single web request has no standard shape, so every service invents one and no client can be written once. This defines how a server states its price and how a client pays it in the same exchange.
A payment large enough to need several transactions will not fit in a web request header, where the payment scheme puts it. This moves the payment into the request body when it grows too big.
A payment-gated web protocol developed elsewhere had no stable identifier here, so implementations could not cite a fixed version of it. This registers it and states what compliance means.
The full micropayment framework is more than a small service needs to charge for a single endpoint. This is the short version: a price and an identity key in the refusal, a payment in the retry.
Software that wants to pay ten cents for an API call, like a script, a CI job, or an automated agent, usually doesn't have and doesn't want a full crypto wallet setup with identity keys and special serialization formats. Before this, a BSV payment for a paywalled web request required adopting that whole wallet ecosystem just to send a small amount of money, so the payment often simply didn't happen. This makes it possible for anything that can sign a basic transaction to pay for an HTTP request and have that payment checked by anyone, not just the seller.
These are about something else, and deal with http payments on the way.
An abstract payment protocol still has to travel over something real. This specifies how it runs over ordinary secure web requests, including the practical size limits that implies.
Some data on the blockchain world needs to stay private until someone pays for it, like a song's decryption key, but the usual way overlay servers share and index information assumes everything is public and copied everywhere. Without a clear contract, a seller has no safe way to accept payment, hold a secret key in reserve, and reliably hand it over, especially if a network hiccup happens between "paid" and "delivered". This makes it possible to run a paid catalogue where buyers always eventually get what they paid for, even after crashes or lost responses.
Concepts that keep appearing on the same standards as this one.
Search standards by number, title, author or topic