Payment protocol (BIP70)

Ambition, then abandonment. Gavin Andresen and Mike Hearn published BIP70 on July 29, 2013, Bitcoin Core shipped it in 0.9.0 in March 2014, deprecated it in 0.19 in November 2019, and deleted it in 0.20.0 on June 3, 2020. If a checkout still asks your wallet to speak it, treat that as a sign the integration has not been touched in years.

How it works

Status: deprecated in Bitcoin Core 0.19 and removed outright in 0.20.0 on June 3, 2020. No maintained wallet implements it. What people use instead is a plain BIP21 URI for on-chain payments, BOLT11 or BOLT12 invoices on Lightning, and BIP352 silent payments where a reusable destination is wanted.

The design was a four-BIP family. BIP70 defined the messages, BIP71 registered a MIME type for each of the three that crossed the wire, BIP72 added the r= parameter so a URI could point at a request, and BIP73 handled content negotiation for wallets that could not parse the protocol.

The flow ran like a card terminal. A merchant served a signed PaymentRequest over HTTPS. The customer's wallet fetched it, walked the attached X.509 certificate chain up to a root it already trusted, and displayed a company name instead of a string of characters. The customer approved, the wallet broadcast the transaction and also posted a Payment message back to the merchant containing the raw transaction bytes and a refund address. The merchant replied with a PaymentACK, which served as a receipt.

Four reasons it collapsed, and they are worth understanding because each one recurs whenever somebody proposes identity on top of bitcoin.

It borrowed its trust from certificate authorities. Any one of hundreds of CAs in a typical root store can issue a certificate for any name, which is the failure mode bitcoin was built to sidestep. BIP70 also permitted a x509+sha1 signature type, and a practical SHA-1 collision was published on February 23, 2017.

It needed the merchant online. A payment could not be constructed unless the merchant's HTTPS endpoint answered, so an outage stopped payments that would otherwise have worked from an address alone.

It leaked. The wallet made an outbound request to the merchant's server, exposing the customer's IP address, and the refund field handed over a fresh address belonging to the payer.

It bought very little. The certificate proved that someone controlled a domain name, not that the invoice was legitimate or the goods real.

Where you see it

The main reason BIP70 still circulates as a term is that the bitcoin.org developer reference describes the protocol in the present tense, and that reference has not tracked Bitcoin Core for years.

Beyond that, you meet BIP70 in archived wallet source, in old integration guides written when large processors pushed it, and occasionally in a .bitcoinpaymentrequest file attached to a decade-old invoice. Nothing you buy today will require it. Merchants who want a checkout use software such as BTCPay Server, which issues BIP21 URIs and Lightning invoices, and asks nothing unusual of the customer's wallet.

Payment protocol (BIP70) vs PaymentRequest

The payment protocol is the whole exchange; PaymentRequest is one message inside it. Three messages travelled between wallet and merchant, and PaymentRequest was the first of them, the signed envelope the merchant served. Using the two names interchangeably makes old documentation harder to read than it needs to be. Note also that PaymentRequest is the name of an unrelated browser standard for card and wallet checkout, so a developer using the word today is unlikely to mean bitcoin at all.