Explaining the Payment Protocol (BIP70) vs Plain Address Invoicing

03 October 2026

The Short Answer

BIP70 is a machine-readable payment request that carries invoice details directly to the customer's wallet, while plain address invoicing is simply a static or per-invoice cryptocurrency address presented with an amount. BIP70 automates the exchange of payment information and can return a signed, cryptographically verifiable receipt. Plain address invoicing is the older, simpler method: you show an address, the customer sends funds, and you reconcile manually. For most businesses today, plain address invoicing is the practical default, but BIP70 still matters because it solves specific problems that address-only workflows do not.

What plain address invoicing actually does

When you invoice with a plain address, the process looks like this:

1. Your system generates a fresh address for the customer (or you reuse one, which is not recommended).
2. You present that address alongside the requested amount, usually as a QR code or text.
3. The customer copies the address, enters the amount in their wallet, and sends the transaction.
4. Your system watches the blockchain for a transaction that matches the address and amount.
5. You reconcile when the transaction confirms.

The critical thing to understand is that the address and the amount are not cryptographically bound together. The address is just a destination. The amount is just a number the customer typed in. If the customer sends the wrong amount, or sends from a different wallet, or the QR code gets corrupted, nothing in the protocol itself catches the error. Your own software has to notice the mismatch and flag it.

That is why the site's existing pages on reconciliation and wrong-amount handling exist. Plain address invoicing shifts the burden of accuracy onto your backend. It works, but it is manual and error-prone at the edges.

What BIP70 Adds

BIP70, the Payment Protocol, changes the flow in a few important ways. Instead of showing a raw address, you serve a signed payment request. That request is a small file containing:

• The destination address(es).
• The exact amount requested.
• A human-readable memo describing the purchase.
• A merchant identifier and signature.
• A payment URL where the customer's wallet can send a confirmation.

When the customer's wallet receives this request, it can display the memo, verify the signature, and present the payment details as a proper invoice rather than a bare address. After the customer approves, the wallet sends the transaction and then contacts the payment URL to report what it did.

The signature is the key difference. A plain address has no identity attached. A BIP70 request is signed by a certificate, which means the customer's wallet can verify that the request actually came from you and was not tampered with in transit. That is a genuine security improvement over copying an address from a webpage that may have been modified by a man-in-the-middle attack.

BIP70 also gives you a structured receipt. The customer's wallet can store the signed payment request and the confirmation of payment together, forming an auditable record. For businesses that need to prove a payment occurred, that is useful.

Where BIP70 falls down

The protocol never achieved the adoption its designers hoped for. The main reasons are practical:

• Wallet support is thin. Most major wallets dropped BIP70 support years ago. The ones that still support it tend to be Bitcoin-specific and technically oriented. A customer using a mainstream wallet may simply see an unrecognized payment format.
• Certificates cost money and expire. To sign requests, you need a valid certificate, usually an X.509 one from a commercial certificate authority. That means recurring cost and renewal maintenance. Self-signed certificates work but trigger warnings in wallets, which defeats the purpose.
• It is Bitcoin-centric. BIP70 was designed for Bitcoin's model. It does not map cleanly onto other chains with different address formats, smart contract logic, or fee structures.
• It adds infrastructure. You need a server that can generate, sign, and serve payment requests, plus handle the payment callback. That is more moving parts than a simple address generator.

For these reasons, BIP70 is not the default choice for new businesses. The "plain address" model, often implemented with per-invoice address generation and a monitoring daemon, is what most payment processors and self-hosted tools like BTCPay Server use as their baseline.

How they interact in practice

One misconception is that you must choose one or the other. In reality, many payment systems support both. BTCPay Server, for example, can generate a plain address invoice for a standard wallet, but it can also produce a BIP70-style payment request for wallets that understand it. The fallback is the address. The customer's wallet decides which path to take.

That means you can offer BIP70 without forcing everyone to use it. The cost is the certificate and the extra code path. The benefit is a more robust experience for the subset of customers who can use it.

Which one should you care about

If you are setting up a business today, plain address invoicing with fresh addresses per invoice is the workable baseline. It is what your payment processor likely uses under the hood. BIP70 is worth understanding because it explains why some wallets show an "invoice" screen with a merchant name and a description, while others just show an address and a number. But you should not build your entire acceptance flow around BIP70 unless you have a specific reason, such as a customer base that explicitly uses supporting wallets and values the signed receipt.

The practical advice is to use a processor or self-hosted tool that handles both formats and defaults gracefully. That way you get the security of per-invoice addresses, the convenience of a familiar flow for customers, and the optional upgrade path for the few who can use it. Your accounting and reconciliation processes do not change much between the two: you still match transactions by hash and amount, and you still need to handle confirmations and errors the same way. The protocol is a transport detail. The business logic around it is what actually matters.

Back to crypto payments