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.
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
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.
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