Web Vouchers: A Simple and Secure Way to Handle One-Time Payments on the Web..

Web Vouchers introduce a simple, standardized way to use vouchers, codes, or tokens for one-time payments and services on the web. By using Uniform Resource Names (URNs), Web Vouchers easily integrate into existing web systems, offering a secure and interoperable solution that improves upon current methods.

Designed as urn:voucher:namespace:123456789abcdefghi, these vouchers can be used for everything from e-commerce discounts to secure access for web services. This spec explains how to format and use Web Vouchers, provides examples, and addresses important aspects like security, making sure transactions are safe, and extensible, ensuring everyone can use them easily.

We've included guidelines for developers on how to implement Web Vouchers, along with tools to check if they're set up correctly. Plus, there's information on how to give feedback and help improve future versions of the spec.

In short, Web Vouchers aim to make web payments and services simpler and safer for everyone, everywhere.

This document in an informal draft originally discussed in the w3c web payments community group.


One time codes are a popular way of solving one off problems on the web. And example might be sending someone a code to log in to a system, or one to reset a password or one to creating a private address for a calendar. However there exists no generic URN on the web to encode such a one time code such that it can be used for redeeming a payment, good or service.

This document specifies a format, and operations that Web Vouchers may support.


This spec is a work in progress. This document in an informal draft originally discussed in the w3c web payments community group, now inactive. It has been updated to take into account new innovations such as electronic coins such as bitcoin, the lightning network, and Cashu.

Design Goals

Web Vouchers are a component of larger systems, such as the Linked Data ecosystem [[LINKED-DATA]], which have driven the design goals for this specification. This section summarizes the primary design goals for this specification.

Goal Description
Decentralization The voucher should not be server specific, though it may be.
Control Only the entities that know the voucher URN can use it.
Privacy The Voucher URN is kept private between those that honor it.
Security Transmission of a URN will be over encrypted formats.
Discoverability It may be possible to discover more information about a URN in a proof based network, or using an authoritative server.
Interoperability URIs and URNs are used to provide wide interoperability with existing systems on the web.
Portability Be system and network-independent and enable entities to use their digital identifiers with any system that supports Web Vouchers.
Simplicity Favor a reduced set of simple features in order to make the technology easier to understand, implement, and deploy.
Extensibility When possible, enable extensibility provided it does not greatly hinder interoperability, portability, or simplicity.

Understanding Namespaces in Web Vouchers

In the context of Web Vouchers, namespaces play a crucial role in organizing and identifying vouchers across various domains and applications. A namespace is a part of the voucher's URN that specifies its category or issuer, enabling a structured and hierarchical approach to voucher management. This system facilitates the differentiation between vouchers, even when they originate from different entities or serve distinct purposes.

For example, the URN urn:voucher:cashu:123456789abcdefghi uses "cashu" as its namespace, indicating a voucher associated with the Cashu project. Similarly, a voucher intended for general web use might employ a namespace like "web", as in urn:voucher:web:123456789abcdefghi. The Web namespace is generic web based voucher issuance, JSON will safely encode small JSON objects, txo will be used by selectronic coins, and so on. By utilizing namespaces, the Web Vouchers system ensures interoperability and clarity, allowing vouchers to be easily categorized, discovered, and validated.

The design of Web Vouchers supports a wide range of namespaces, accommodating everything from corporate issuers to cryptocurrencies, and from loyalty points to fiat currencies. This flexibility ensures that Web Vouchers can adapt to various use cases and evolve alongside the web's ever-changing landscape.

URN Format

Each namespace will have its own format and a link to the documentation. Current namespaces are `txo` (transaction object), `cashu` cashu nuts, and `web` generic web vouchers The basic idea is to create a capability URN (like a capability URI but with an URN) and allow it to be used as a voucher for spending. The proposed format is :


Cashu is a free and open-source Chaumian ecash system for Bitcoin which allows building privacy-preserving custodial payment and voucher systems. The latest Cashu V3 token serialization format is: `cashu` then `A` which is the version followed by URL safe base64 encoded JSON.

Transaction Objects

Transaction options are spendable token in electrionic coins such as bitcoin. Typically it will have, for a given chain, a public components, the txid plus output (vout), plus a public key or script showing who can spend the token. A transaction object web voucher, can be made spendable by appending the private key K, to the end of the voucher. Web vouchers including private keys should be kept or transmitted in a secure environment, as anyone with access to the string can spend all coins from that address.

JSON format

The json format is a simple extension to the cashu system, which allows arbitrary json to be transmitted in an object. This is a work in progress, and has not currently been implmented.


There are two things that are useful to discover. Firstly, more information about a voucher. The discovered document SHOULD return Linked Data. This can be done on a well known url, for example :
The other convenient thing that can be discovered is a server or servers that accept the voucher. This could be done over a gossip network with an initial bootstrap. A discovery node accepts the URN and points to a document with relevant servers.


This spec is a team effort. Thanks to Michiel De Jong, Andrew Bansford Brown, Stuart Rashford, Adrian Hope-Bailie, Calle and many others for making this possible.