I saw in China's bus system, that there are devices inside the bus which can handle e-payments. The process is something like this:

  1. Passengers come in the bus.
  2. Passengers use a QR-code in their smartphone app to wipe on the device's screen (the QR code scanner)
  3. If passengers charge successfully, they are allowed a seat on the bus. If not, the device sounds some alerts.

I'm trying to implement this system for my project in my university. At first, I used a Raspberry Pi and a QR code scanner module to recognize the QR-code and push the data via Wi-Fi to the API on the remote server. My way of doing is that every time the device receives a QR code, it immediately sends that data to the API. Then the API handles all things and sends a response back to the device.

Everything works well. However, a problem occurs is that it seems taking a lot of time between each sendings and I'm not really handling some unexpected cases such as a lost connection in sending data to API.

For example, when the first passenger comes and put the QR-code of his phone's app on the device but it takes around 4-6 seconds for completing the whole process (included sending the passenger's data to server's API, API handling charging, balance processing, then sending a response back to the device for checking whether that passenger is allowed to come or not). Sometimes, the device loses connection, so the passengers can't use the device.

So, I came up with the idea that:

  1. I will synchronize the passenger's key data (Id, name, balance) on the database with the device's storage.
  2. Now, processing payments will be directly implemented on the device. For instance, the device will check the passenger's QR code and then compare with the data in its storage to handle whether that passenger can come in or not.
  3. After all passengers finished their check-in (it means when the bus moving), the device's storage will again synchronize with the server's database.

I think if the system runs in this way, it will be smooth as all things will be done locally until they synchronize.

So that is the brief summary of my system as well as my idea. However, I'm not in China and my country also has not implemented a similar system so far so I do not have any references sources.

I would very appreciate it if you guys can suggest me some directions or any related references about this new idea.

  • Is it possible or not?
  • Are there some hidden dangerous logics inside?
  • If yes, can you help me with some hints? For example, what is the most suitable time for synchronizing data between server's database and device's database?
  • On server side, I use ASP.net to write APIs, and working with passenger data is not hard (find, edit, update) by using the Entity Framework. But how can I do the similar thing in Raspberry Pi for local processing?

1 Answer 1


I have a similar idea for you still with local processing. I won’t deal with the security breaches of this idea as it is a school project.

Make your QR code also have the data of the balance of the user. You RPi reads the code, deducts the fee from the balance it sees on the QR code. If it can, perfect, if not, you are declined to use the bus. If you want , you can encrypt this balance data with some secret so that people can’t generate QR codes with infinite amount of balance. When the bus comes to a station, you just upload your local storage to the server.

Some drawbacks:

  • For every ride, your users have to open their mobile data to update their balances. You can put a time limit on the QR to make sure that it is only for one ride.

  • Generating illegal but valid QR codes.

For the technical part independent from the idea above:

You are using .Net for the backend. If you want to bring the same stack to RPi , you can install windows 10 IoT edition to your RPi. It is free and only requires a Windows 10 computer to do the installation. Nevertheless I would prefer using python and Linux on RPi.

For the payment idea above, it is perfectly fine if you just ignore it, it is there just to give you a perspective and was a nice brainstorming for me.

  • 1
    First, thank you your suggestion.So it means that the device's storage now just keeps data (id, balance) of passengers who successfully come in the bus. Hence, it will upload these data to the server for synchronizing, after that it will delete all these data. Is that your idea? So, the device's storage now is no longer need to hold all the database in this case? FYI, my device is integrated with wifi/3G module, so that it does need to come station for uploading data :D May 7, 2018 at 9:28
  • 1
    Yes, like that, your device only keeps local data. A personal QR code can't be used several times when your customer is in the bus, so you don't need to keep the whole database. I wouldn't delete the data so frequently for logging and accounting purposes. You mentioned connectivity losses, that's why a wifi on the station seemed like a good idea. May 7, 2018 at 9:33
  • 1
    Yes, it 's a great idea. As in this way, the workload is less heavy on the hardware side. And imagined that in my idea, if the system has 1000 users, so every time a passenger comes, it needs to search in those 1000 users and process some logics which will cost a lot of time, I think. May 7, 2018 at 9:49
  • 1
    Rpi is fairly strong to do a 1000 user search. Mine has the mentioned drawbacks and maybe more, but now that you have the core idea , you can improve on it. May 7, 2018 at 9:58
  • 1
    And would you mind to clarify me about your hint "You can put a time limit on the QR to make sure that it is only for one ride." What's the issue here and why we need to make sure the QRcode is only for one ride May 7, 2018 at 10:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.