The largest QR code in the standard, "version 40" - can only store 3 kilobytes at the lowest level of error correction and 1.2 kilobytes at the highest level [1]. And that's a pretty huge QR code [2]

My back-of-the-envelope calculations say you'd need 61 bits per line on a receipt just to encode UPC, quantity and price. So the largest QR code would only allow 19-50 lines. And that's without including data like the store name, special offers, means of payment and so on. Believe me, plenty of people buy more than 50 items in their supermarket christmas shop :)

Standardised digital receipts would be neat but, QR codes encoding the data ain't the way to go about it.

[1] https://www.qrcode.com/en/about/version.html [2] https://commons.wikimedia.org/wiki/File:Qr-code-ver-40.svg

Seems like the obvious thing would be to have the QR code contain a "receipt ID" (UUID?) in a URL.

When the QR code is scanned, the browser opens to the URL, the remote side takes your "receipt ID", and presents you with a list of all the items you purchased.

I can't imagine any decent-sized retailer isn't already maintaining records like this.

See, one of the useful properties of a paper receipt is that, once you receive it, you can be fairly confident about the ~one way you're going to lose it

Two ways. Receipts fade, sometimes very quickly.

1.2 kilobytes = 9.6 kilobits. If you need 61 bits per line, you’ve got enough bits for 157 lines. 393 lines if we go with 3 kilobytes. I think you may have used 61 bytes per line in your calculation rather than 61 bits.

I (not OP) would say bytes would be closer. The product name could be 20 characters long (20 bytes minimum)

OP was assuming the receipt would list the product UPC code rather than product name. A UPC code is 12 digits, which can be encoded in 40 bits.

it could just contain a url linking to a page with to content.