Paymail Payment Destinations
A Bitcoin address is a long unreadable string, and asking someone to type one is a good way to lose money. This documents the widely-used scheme that lets people be paid at a readable name like john@example.com instead.
8 standards
How a payer finds out where to pay. Standards here cover resolving a human readable handle into a fresh destination, and the link schemes that let a URL start a payment.
Also searched as paymail, address, URI scheme, PeerPay, destination.
An addressing scheme that uses a human-readable name at a domain in place of a Bitcoin address, resolving to a payment destination over HTTPS.
Open in the glossary8 standards, spread across 4 of the 12 topics.
A Bitcoin address is a long unreadable string, and asking someone to type one is a good way to lose money. This documents the widely-used scheme that lets people be paid at a readable name like john@example.com instead.
Filed under Payments
Payment destinations is the main subject of these 2.
A Bitcoin address is a long unreadable string, and asking someone to type one is a good way to lose money. This documents the widely-used scheme that lets people be paid at a readable name like john@example.com instead.
Sharing where to send a payment usually means copying a long key and hoping it survived the paste. This packs the recipient and an optional amount into a single link that can be sent, tapped or turned into a QR code.
These are about something else, and deal with payment destinations on the way.
Paying an invoice online usually means handing your card details to a merchant and trusting them to look after it. This consolidates a decade of earlier attempts at paying someone directly into one standard covering how an invoice is presented, paid and acknowledged.
An output on its own says nothing about which application it belongs to or what it is for. This adds a way to tag one with the group it belongs to, and with instructions whose meaning that group defines.
Bitcoin addresses were meant to be temporary scaffolding and instead became the thing users are asked to handle. This argues that showing an address to a person is a failure of design, and looks at what ought to replace it.
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.
Reaching someone online means knowing which service they are on, which stops being true the moment they move. This gives each person a readable handle that resolves wherever they actually are.
A wallet that wants to pay someone usually has just a long string of random-looking characters, a public key, with no way to know if it really belongs to the person named by an email-like address such as alice@example.com. Flipping it around is just as broken: a wallet that just received a payment has no name to show for the sender, only that string of characters. There was no safe way to look a name up and get back a key you could trust, or to look up a key and get back a name.
Concepts that keep appearing on the same standards as this one.
Search standards by number, title, author or topic