The application goes something like this:Users download app and upon downloading, a unique barcode will be presented to them.The barcode (via phone) is scanned at the checkout (so it eliminates paper receipts).The receipt will then be send to there phone because of there unique barcode.I am wondering two things:Will I require users to register for this application AND only then, present their barcode to them? I am wondering this because how will the store, i.e. how will the supermarket know that this barcode belongs to Alice's phone? Which also brings me onto question two...How will supermarket scanners know this barcode is not a product? From my understanding, items in a supermarket are scanned, and stored on a database, so how will my external barcode be recognized?Is this an effective way to go about this? I am still in the idea phase, so I am open to alternative approaches.
Should registration be required for an application which relies on success based on unique barcode?
mobile;application design
Is registration required?When the app is launched, it connects to the server and tells it an unique identifier. The server generates a barcode and binds it to that identifier. The network connection stays open while the app is running.When the server receives a receipt with a barcode from a point-of-sale, it can look up the identifier for that barcode, look up the active network connection for that identifier, and push the receipt data.No registration required. Neither for the consumer nor for the point-of-sale.When you plan to monetize your app by logging all purchases of each user, data-mine it to generate a comprehensive consumer profile and then sell that profile to market research, then the identifier sent from the app to the server should be a constant identifier of the device, like its IMEI number.When you plan to respect your users privacy and find a more ethical method of monetization, then the identifier should be randomly-generated each time the app is launched and be long enough to make collisions impossible (like a GUID).How does the barcode scanner tell your codes apart from product codes?This is a tricky one, because you will have to dive into the technical details of point-of-sale barcode scanners and see what their soft- and hardware can and can't do (this is not my area of expertise, but I could imagine that there are scanners which decode the barcodes completely in hardware). And there are quite a lot of different POS systems on the market. Dealing with all the different POS systems will be the hardest part of your project anyway. Maybe you can get the scanners to read a new barcode format which is completely different than the EAN format usually used for retail products. Maybe you could register your own EAN company number so you get a range of EAN codes for exclusive use by your applicationMaybe you can use EAN encoding but with values which are invalid. Your codes could for example turn the check-digit into its binary compliment. That way the POS terminal could check if the check-digit is correct according to EAN or correct according to yours and process the code accordingly.Maybe you can use arbitrary EAN codes which might also be used by actual products, but have the POS terminal handle them differently depending on its current state.