The Proposed 402-Receipts Standard

The Client

Because the 402-Receipts system is designed to be used passively by the human user, we mostly speak in terms of the Client (the web-browser).



The Client is an HTTPS client requesting a resource for which a receipt is required. Typically the Client will be a web browser being used by a human to view websites.

It needs to detect 402 Responses and parse the attached Receipt Definitions so that it can obtain the necessary receipts.

It needs to compose the Receipt and communicate with the Notary to get it signed. Finally, it will include the Receipt in the Header of the HTTPS request.

Existing web browsers don’t have the behavior defined in this standard, so the user will need to install a browser plugin.

Javascript included on pages served may be able to act as the Client; this would be good because it would be easier for some users. We need a clear idea of how that can work, and how it can support the same privacy and trustworthiness guarantees before we can promise that it will be an option.



A wallet is a (presumably encrypted, etc) storage location separate from the Client where receipts owned by a user can be stored for reuse. This is necessary specifically because users will want to reuse receipts across devices.

It’s desirable to include the communication between the Wallet and the Client in this standard, firstly because independently created Clients (for example a Firefox plugin and an Android app) should be able to use a common Wallet, and secondly because a safe standard for Wallet communication will be critical to an in-page javascript Client implementation.

The Host

The Host is the computer (the server) which provides the web pages to the Client. The Host is not exactly just “the website”, although this is an OK layperson’s approximation.



The Host is, by definition, the server receiving the HTTPS request with the Receipts-Receipt header. This standard specifies further responsibilities for the Host leading up to such a request and in how such requests should be handled.

It is the Host’s responsibility to validate incoming receipts; they must accept any receipt satisfying the Receipt Definition published for the given resource. If appropriate Receipts are provided, then the Host will respond like any other HTTPS host. If the Receipt is missing, inappropriate, or invalid, then the the Host will give an informative 402 Response.

We assume that the Host’s address will match the domain (and often item) of the Bare Receipt, and this may be enforced by the Client or Notary.

A fully static host will not be suitable for this standard because validating receipts and saving them for future reimbursement is critical to the process. At absolute minimum the host will need to be able to strip the identifying key and signature and forward the receipt and Notary signature to the Notary; otherwise the Notary would never know to pay the Host.
In practice, the Host should also be obliged to validate the receipt as part of request handling, and the Host should not forward the receipt until handling of the HTTPS request in question has finished. Submitting receipts to the Notary in batches (for example, every hour) can (in conjunction with some defensive behavior on the part of the Clients) prevent deanonymization of Receipts by timing analysis.

The Notary

The Notary is a third party, analogous to a traditional monetization platform but fundamentally less powerful. The Notary sells Receipts to Clients; the Receipts are used to access websites.



The Notary signs the receipt.
It is up to the parties involved to agree in advance what is promised when a receipt is signed; here we assume that the Notary has collected the money in question from the Client and will forward those funds to the Host by some outside channel. In this sense the “Notary” is properly thought of as a “Broker”.

Of course it’s the Notary’s responsibility to make themselves valuable to the other parties, but it’s illuminating to explain here some of the ways they might do that.

  • The Notary will generally relieve the Host of payment processing complexity, and account-management more generally.
  • When a Host joins a Notary’s network, they hope to receive payments from a wide audience of consumers; the Host can focus on traffic and audience retention instead of a sales funnel.
  • The Notary can protect the Client from abusive Hosts in various ways, including proactive monitoring of member Hosts and post-hoc remediation. (Point-of-sale protections are generally not feasible for the Notary, as receipt signatures are issued blindly. Such protections can be built into the Wallet.)
  • For a Client to set up an account with a given Notary generally constitutes pre-authorization of certain kinds of payments for certain kinds of resources. In this sense Notaries act like “channels” to which a user can subscribe.

In practice, we only anticipate two kinds of Notaries.

  • A Host could be their own Notary. This could accomplish any of the same functionalities as existing paywalls offer, although the standardized machine interface would enable smoother user-experiences.
  • A Notary can act as a network, channel, buyer’s club, or federation. Many Hosts and many Clients are assumed to have prior arrangements (accounts) with a given Notary; this is the Notary’s network. As long as a Host and Client have a network in common, payment for resources can typically proceed automatically.

Notaries with larger networks will obviously have an advantage toward attracting new members of both kinds.
On the one hand, the variety of use-cases this standard can accommodate, and the variety of legal, technical, and business paradigms people operate in, will likely ensure a plurality of Notaries. On the other hand, it is still desirable to include protections against the Notaries. Consumers are presumed to have given their payment processing information (a debit card, for example) directly to the Notary, but privacy of their data can still be protected by insisting on a blind-signature scheme, and by proper design of Wallets and Clients. Producers (Hosts) can best be protected by making sure self-Notarization is a viable option (although this does put the onus of payment processing back in their lap).


Cannonical URL

A Notary is required to expose a canonical URL endpoint by which they can be identified, and which is sufficient to interact with that Notary.

  • A GET request to the canonical URL should return an HTML page which a human could use to complete a purchase and obtain a receipt. In practice this page would probably also prompt the user to open an account with the Notary. TODO: specify how a receipt could be passed into this page from the URL hash for blind-signing and how the Notary's signature would be communicated back to the Client.
  • A POST request to the canonical URL is used to obtain a Notary Signature; a signature with a pre-approved Client’s private key should be sufficient authentication for this. TODO: the details of this process will be filled in as the cryptographic details of receipt signing are determined.
  • A PUT request to the canonical URL is used by the Host to redeem receipts, in batches.