PP merchant data

Matching a payment to an order is the unglamorous problem every checkout has to solve, and bitcoin makes it harder because a transaction carries no invoice number. BIP70 solved it by handing the customer's wallet a cookie and asking for it back. Merchants today solve the same problem with a one-time address per order, which is both simpler and more private.

How it works

Status: historical. Merchant data was field 7 of PaymentDetails and field 1 of the Payment message that came back, and it disappeared with the rest of BIP70 when Bitcoin Core 0.20.0 shipped on June 3, 2020.

Opacity was the point. The wallet was told to treat the bytes as meaningless and return them unaltered, which let every merchant invent its own scheme without anyone else needing to understand it.

Two schemes were common. A short lookup key, say a 16-byte order identifier, kept the request small and pushed the work onto the merchant's database. A self-contained blob held the whole cart and let the server stay stateless, at the cost of size.

The second scheme has a hole in it that the specification warned about. Those bytes come back from software the merchant does not control, so anything read out of them is attacker-supplied input. A shop that stored a price or a discount code in there and trusted the returned copy had built itself a coupon generator. The remedy is the ordinary one for round-tripped state: attach a message authentication code and check it before reading a single field.

Size mattered more than it looks. The whole signed request had to reach the customer, and rendering it as a QR code puts a hard ceiling on that: the largest symbol, version 40 at the lowest error correction level, holds 2,953 bytes of binary data. That ceiling is why BIP72 defined the r= parameter, so a short link could point at a request served over HTTPS instead of carrying it.

Where you see it

The job merchant data used to do is now done by the address itself.

Checkout software such as BTCPay Server derives a fresh address for every invoice, so an arriving payment identifies its own order with no round trip and no echoed state. That beats BIP70 twice over: there is nothing for a payer to tamper with, and it avoids the address reuse that would otherwise publish a merchant's entire revenue to anyone reading the chain. Custodial platforms work the same way, which is how a deposit lands in your account and not somebody else's.

One warning is worth carrying away from all this. Several other networks require a memo or destination tag beside a deposit, and leaving it off drops your funds into a pooled account with nothing linking them to you. Bitcoin has no such field. If a deposit page asks you to attach a tag, a memo, or a reference code to a bitcoin transaction, the form is either misconfigured or fake, and recovering a genuinely misdirected deposit is slow and frequently impossible.

PP merchant data vs PP memo

Merchant data was written for a machine; a memo was written for a person. One was never shown to the customer, the other existed only in order to be shown. Their failure modes differ to match: an unchecked memo misleads a human reading a confirmation screen, while unchecked merchant data misleads the merchant's own accounting software. Neither one was signed on the return leg, which is the reason both needed treating as untrusted.