Insights / Deep Tech / Cashless Payments in Public Transport: A Success Story (part 2)


3 mins read

Cashless Payments in Public Transport: A Success Story (part 2)

This article is the sequel to Cashless Payments in Public Transport: A Success Story (part ).


Working on projects can be challenging in numerous ways. For a developer, many aspects can be unknown and tricky to deal with in the beginning. Challenges occur in all phases of software development, such as in technology, domain, and operational tasks. Communication in a foreign language or with clients in different time zones has its trials as well. When two of our HTEC teams started working on cashless payment solutions, they encountered challenges that do not necessarily occur often. Our colleagues decided to tell an inside story about what they faced and learned from it.

The TSU project was one of the rare occasions our HTEC teams were able to influence the selection of hardware. There was a tricky situation when we received the printers without any USB port, so we needed to adjust on the go and do additional work to make the integration possible. 

Coding was an integral part of the project, of course, but the most interesting part is the integration of all the hardware (touch screen + computer = all-in-one machine, printers, card readers, Payplaza PIN terminals, modem, antenna, etc.).

One time, there was an issue with the card readers. When we received the specification, we realized it was not in accordance with the actual devices. Communication with the manufacturer’s support did not get us far. Finally, the manufacturer sent amplifiers to improve the performance. In the end, everything was connected and set in boxes, amplifiers arrived on Friday, and buses were scheduled to start on Sunday. All hands on deck from Telexis were available to complete the project in time.

We’ve had the opportunity to see how the buses were put together and how everything was being installed and set. We experienced the entire process and even took part in it: the cables were cut, boxes put together and screwed on. The boxes had to be in compliance with the anti-vandal standard and they arrived connected to monitors and printers. All other devices were on us to connect and make them functional. 

Of course, our teams are usually not in charge of the installation. However, our colleagues wanted to use this opportunity to see the hardware and experience the entire flow in person. This was particularly beneficial for them since they were able to get a clear image of how everything works in real-life situations.

Opposed to these challenges, working on OBSU was different. We knew in advance which hardware was going to be used since it was already used for the existing software. In addition, all hardware components were already installed, so our task was to create software for them. We did not have to take security measures into account since the software in question is used by the bus driver.

The fact that we were developing a system that would be used in a huge number of vehicles brought its own set of challenges. Auto Updater service was one of the solutions which helped us manage many of them. This service enabled us to update the system and fix any bug at once, without having to manually do this on every vehicle. The challenge was the integration with the transaction management part, which is a separate system.

Working on demanding tasks can have an impact on our motivation and incite self-doubt, especially for less experienced software engineers. However, if we approach challenges from a learning perspective, it will be less hard to face them. Our team members have come out of this stage of the project with a broadened perspective and battle-hardened expertise that not only builds confidence but also better prepares us for the unpredictable nature of dealing with technically and operationally complex and demanding projects.

Gain new knowledge on tech industries, here.