26 standards
The exchange between payer and payee: what is being asked for, what is being sent, and how both sides know it finished. Standards here define those conversations and the transports they run over.
Also searched as payment protocol, payment protocols, DPP, Direct Payment Protocol, invoice, settlement, remittance.
The string fed into key derivation that makes each derived key unique. It is open-ended by design, so a protocol can number its keys however suits it.
Open in the glossary26 standards, spread across 7 of the 12 topics.
Sending an ordinary Bitcoin payment leaves the recipient unsure whether it is real without checking the whole chain. This defines a straightforward payment between two parties that the recipient can verify independently, and that any compliant wallet can take part in.
Filed under Payments
Payment handshakes is the main subject of these 7.
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.
Sending an ordinary Bitcoin payment leaves the recipient unsure whether it is real without checking the whole chain. This defines a straightforward payment between two parties that the recipient can verify independently, and that any compliant wallet can take part in.
A payment protocol with no actual payment method defined does nothing. This adds a flexible mode to the direct payment protocol, covering ordinary Bitcoin as well as other kinds of token.
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.
Paying someone with a digital token normally means checking in with an online service at the exact moment of payment, which fails in a shop with bad signal, on a train, or at a market stall. Cash does not have this problem. This describes a way for a payment to be handed over and trusted on the spot, with the online check happening later instead of during the handoff.
Right now, if an app relies on a single server to hold and deliver messages or lookup results, that one server becomes the weak point: if it goes down, delays, or drops something, there is no backup and no way to reward anyone else for stepping in. This approach lets several independent hosts race to answer the same request, with the fastest honest ones getting paid automatically, so no single operator can quietly become a bottleneck or single point of failure.
Moving coins between two different blockchains usually means trusting an exchange or bridge to hold your funds while the swap happens, and that middleman can freeze, lose, or steal them. This describes a way for two wallets to trade coins across chains directly, so that either the trade completes for both sides or each party simply gets its own coins back, with nobody ever holding the other's funds and neither side needing to be online at the same moment.
These are about something else, and deal with payment handshakes on the way.
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.
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.
An application that has received a payment on someone's behalf has no standard way to hand it over. This defines how a transaction and its proofs are submitted into a wallet, so the wallet recognises the funds as the user's own.
Developers building on Bitcoin keep designing the same flows from scratch. This collects the user experiences worth getting right, as a reference to work from rather than a specification to implement.
The readable-name payment scheme was built before there was a good way to send verifiable transactions. This updates it to carry the newer self-verifying bundle instead of bare transaction bytes.
Swapping a token for payment with a stranger requires one of you to go first, which neither party wants to do. This describes an exchange between two parties where neither has to trust the other to complete their side.
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.
Two people who want to pay each other directly still tend to route the payment through a service. This describes a wallet flow where the two devices negotiate between themselves and settle as several independent transactions.
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.
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.
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.
Imagine paying for a digital item, like a song, over a payment network: the network can confirm the payment landed, but has no built-in way to also hand over the thing you paid for only once that payment is genuinely and exclusively yours. Without a clear process, a seller could claim a payment is accepted but never deliver, deliver to the wrong person, or leave a buyer stranded if something fails partway through. This gives buyers and sellers a dependable, replayable sequence for locking in terms, submitting payment, and releasing the purchased secret only to its rightful recipient.
Buying access to licensed digital content on Bitcoin SV normally means every app invents its own payment flow and licensing format, so content bought through one app's purchase method cannot be unlocked or re-issued through another. This makes it hard to build a marketplace where sellers set a price once and many different apps can sell and deliver the same protected content correctly.
Every chat-style client invents its own commands, so what you learn in one is useless in the next. This fixes a common set of verbs that behave the same way everywhere.
Sending someone a bit of digital cash normally means telling them who you are, because the payment format includes your long-term identity key. That's fine for a friend or a business you trust, but it means every coffee tip or casual peer payment lets the recipient permanently tag it to your identity and link it to every other payment you've ever made them. There was no easy way to pay someone spendable coins for a one-off transaction while keeping your long-term identity out of the record.
Sending someone bitcoin, a token, or a digital asset usually means they have to be online and ask for it first, or you need some separate side channel to tell them a payment is coming and how to claim it. This makes it hard to just drop an asset into someone's account the way you'd send an email, especially when the asset involves extra rules about colors, authority, or expiry that both sides need to agree on and check independently.
Right now, if you want to let someone sell a digital item or token from their wallet without being online when it sells, you either trust a central listing service to enforce the price and fee, or you risk a buyer taking the item for free by reusing a badly-signed listing. This describes a way to make an offer that can only ever be completed by paying exactly what the seller asked, with no index holding any keys and no way to skip the agreed fee.
When a wallet request fails, today's wallets each write their own error sentence and hand it straight to the app, which has no choice but to show it to the user unchanged. That sentence rarely says whose fault the failure was, whether trying again is safe, or whether the payment might actually have gone through anyway. The result is users double-spending after a timeout, support tickets full of mismatched wording, and apps that cannot translate or shorten a message they did not write.
Concepts that keep appearing on the same standards as this one.
Search standards by number, title, author or topic