There’s Apple Pay, Samsung Pay, Google Wallet, and a host of other ways to pay for stuff with your phone. What about receipts, though? Do you really need to carry around little bits of paper to prove to incredulous friends you have, indeed, bought a donut? The proof is back home, in the file. Under D, for donut.
[Hisham] is working on a very interesting system for the Hackaday Prize. It’s effectively the the opposite side of every point of sale transaction that Apple Pay, Samsung Pay, and Google Wallet are working on. Instead of handling payment, [Hisham]’s Aelph handles receipts.
[Hisham]’s project is hardware, with a small device that plugs into a point of sale terminal. This device transmits a receipt to the Aleph app (or a third party app), and uploads a PDF copy of the receipt to a server. Other than a small hardware box, there’s no additional software required for a POS terminal. For retailers, it’s as easy as plugging in a box, and for consumers, it’s as easy as downloading an app.
The hardware was prototyped on a TI LaunchPad featuring a TIVA C microcontroller. This, along with the NFC eval kit give Aleph more than enough power to connect to a company LAN and spit out a few PDFs. You can check out one of [Hisham]’s demo videos below.
There are a lot of benefits to a electronic receipts; if you ever need a receipt, odds are you’ll scan it anyway – a dead tree receipt is just inefficient. There’s also some nasty chemicals in thermal receipt paper. You only need to Google ‘BPA receipt’ for that evidence. Either way, it’s a great idea, and we long for the day that our wallets aren’t stuffed to Costanzaesque proportions, and a time where we won’t need a scanner to complete an expense report.
There’s a start-up in Melbourne, Australia working on a commercial version of this, although as I understand it they’re using mobile phones and a combination of both NFC and OCR. Might be worth looking at the local educational institutions (RMIT etc) to see if any of them did the preliminary research work.
Really nice idea! I really like that this solves different problems altogether:
-Reduce BPA contamination
-Reduce thermal paper costs to business on the long run (buy Aleph once, never print a receipt anymore)
-Reduce paper storage
Good stuff nonetheless.
Thanks for the great post
This is a great idea IMHO.
As a business owner this would save me a lot of time , bring it on!
Yeah, nah.
http://www.stuff.co.nz/business/68161778/xero-and-paymark-team-up-for-paperless-receipt-service
lol yeah someone somewhere is thinking about something somehow similar, what a great finding thanks.
Mitch! “There is no need to bring ink and paper into this”
I shall add a video of this to the project
Bravo
Ironically last week I bought a lawnmower from a small engine repair place, and they had the most technically advanced POS I’ve experienced. It worked like a regular terminal, except it pairs with a smartphone and sends the receipt directly to your email (as well as theirs). This is what they had: https://www.tdcanadatrust.com/products-services/small-business/merchant-services/accept-payments-at-point-of-sale/td-mobile-pos.jsp?click=tdct:p:pos-hp-mobilepos:en
I wish everyone had this…
The problem I have with these is, that they don’t look trustworthy enough..
The Phone could be modified however you want.
Probably a bit to scared though..
Why not email? I have to use someone’s Square card reader at places like food trucks or when I get a haircut. I prefer getting an email receipt than having to use a specific app to get a receipt. That way you’re never depending on the app being up to date, not compatible with your phone, etc.
That is the purpose of uploading to the server, just to demonstrate that the receipt will be available to access on the internet (of course with security) let it be email, web app or anything else.
Misses several of the reasons for having a receipt in the first place, instead of just listing advantages, writeup should list some of the problems.
In some stores they check your receipt on the way out, and mark it some way (presumably so you can’t walk in, pick up another of the item and walk out with it.) Or you may buy something at a counter within the store (e.g. a pharmacy counter, etc.) You need some way to show that you paid (e.g. if the anti-theft system beeps at you) How will you handle this sort of transaction? (i.e. you have to have some token so they can identify which electronic receipt to mark saying the person has left the building with the goods). Given that you may not have your cell phone with you, and monkeying with cell phones would slow down the process of getting out of the store.
In the case of a dispute, this would put you even more at the mercy of the merchant. (whoever controls the receipt repository could change what you bought, when you bought it, how much you paid, etc.) You wind up with no paper trail, no evidence of what happened within your control
(Sure, you could get a PDF, but how do you authenticate that.) e.g. need a whole layer of public key cryptography, have the merchant publish a key and electronically sign the document sent to you, and have user controlled devices/software to verify the validity of the document.
So one could probably do it in a way that protected the user from manipulation by the receipt server, but would require careful design (especially to make it give protection and make it easy to use).
There might also be security issues with how do you validate the printers. (i.e. how do you prevent injection of bogus receipts into the system).
Current printers might not be highly secured devices (anyone can buy a thermal printer, and print out a receipt that looks like it comes from some store). But if the “printer” is now transmitting the receipt to a server, how do you handle bogus receipts injected into the server? (Both the printer and the connection to the printer may need to be secured like the rest of the POS system?) By centralizing the receipt repository and making it virtual you may have changed the nature of the problem for receipt fraud.
If you don’t have your cell phone with you(i.e you didn’t tap to get the receipt withing some number of seconds), a normal paper receipt will be printed with an extra code at the end (QR, NUMBER …) that connects your receipt to the electronic one on the server so that no one else can see it or claim it. That way when leaving you can show the paper as you normally do (or if you have your smartphone maybe tap on another device to authenticate your receipt ?!!!)
The server should be centralized, the merchant will not have any access on editing or changing whatsoever in the receipt once it is generated.
Security is a very big issue with this system you are right. But if we manage to implement it right, I think we will end up with a much more secure system than the current piece of paper system. Security on M2M devices already exist, we will handle bogus injected receipts the same way any other platform handles injected fraud data. Surely there will be encryption and unique keys for each merchant and more layers as I move on in the development.
I have no control on minimizing the size of the receipt, but the long goal is to integrate vouchers and loyalty cards inside Aleph.
Thanks for comment
Attempting to minimize the size of receipts would be a simpler first step towards reducing resource waste and toxics exposure in this area.
Currently many businesses bury the customer with mile-long receipts, with dozens of coupons, rebate forms, lots of white space, etc. (Think grocery stores, electronics stores, etc.) On black Friday one feels as if they are printing you all the garlands for decorating the tree (or trying to wrap you up like a mummy).
Although we’ve known since Apple’s Worldwide Developer Conference that Apple Pay, the company’s own mobile payment solution, would arrive in the U.K. in July, a British bank accidentally revealed by way of a tweet that the service is, in fact, launching tomorrow.
RIP Mitch Hedberg.