Equipment retained
The project worked with the existing bicycles and docking locks rather than replacing the whole installed system.
Sports & Recreation · Self-service bike rental
Reconnecting legacy bike-rental kiosks with locks and payments
A self-service bike-rental operator replaced unsupported terminal and backend software while retaining existing docking equipment. The deployed retrofit reconnected locks, payments, and rental records, with unresolved limits in the legacy protocol.
The business context
The bicycles still had value after the original supplier stopped supporting the system.
Riders paid at a kiosk, took a bicycle, and returned it to a docking lock. The rental charge depended on time, so physical equipment, payment, and the operating record belonged to the same service. The business could not keep that service usable through a payment screen alone.
The original supplier had stopped providing support. The operator also needed to replace an aging cellular POS terminal. Shinetech's scope connected a replacement terminal and payment integration with the existing locks and a new backend for kiosks, bicycles, orders, and reconciliation.
System view
A payment response does not prove that a lock responded
Conceptual rental-terminal interface with a fictional station, bike, and transaction. Separate payment and lock-response states illustrate the integration boundary; the exact screen and status controls are reconstructed, not evidence of an implemented fault-resolution feature. View full-size interface (new tab)
The operating challenge
The lock protocol had no documentation to work from.
The team had to investigate the CAN communication used by the docking locks through direct probing. Selecting and programming a replacement POS device was only part of the task: the terminal still needed to communicate with old physical equipment and with the backend.
Protocol discovery remained incomplete. Some behavior was still unknown and communication was not fully stable. The available budget limited further investigation, making this a bounded retrofit with residual technical risk rather than a complete recovery of the original system's design.
The delivery decisions
Restore the service path around the equipment that remained.
Investigate the existing lock interface
The team probed the undocumented CAN protocol to understand the operations needed to control the docking locks. This allowed the retrofit to work with existing equipment while leaving an explicit boundary around behavior that had not been fully understood.
Replace the terminal and payment connection
A new POS device was selected and programmed, with payment-gateway integration included in the scope. The terminal connected the rider-facing transaction to the retained docking hardware.
Rebuild the operating backend
Backend work covered kiosks, bicycles, rental orders, and reconciliation. The team also improved terminal-to-server communication, brought the solution into operation, and provided support.
The working detail
Operating use and complete protocol knowledge are different outcomes.
The remaining reliability boundary
The deployment could support rental activity without every aspect of the old CAN protocol being known. That operating result does not remove the unresolved communication behavior. Both facts belong in the case: the equipment returned to a supported transaction path, and further protocol work remained limited by budget.
The business value lay in extending the use of existing rental equipment and restoring terminal and backend software that the team could support. Further investigation would still be needed to resolve the unknown protocol behavior and remaining communication instability.
The delivered result
The retrofit supported rental operations, with a documented limitation.
Rental use reported
The team reported operation across about 100 bicycles, with roughly 100 orders on peak days.
Limits retained
Unknown protocol behavior and incomplete communication stability remained within the documented delivery.
The operating figures are project-team reports. The CAN protocol was not fully understood, stability issues remained, and budget constrained further probing. This is a delivered retrofit with residual limitations, not a claim of fault-free operation.
Case taxonomy
Searchable by industry, technology, product, and business need.
Industry and product
- Sports & Recreation
- Self-service bike rental
Technology and delivery
- TypeScript
- Android
- CAN
- Payment integration
Business need
- Legacy hardware
- Protocol discovery
- Rental operations
- POS integration
- Lock control
- Reconciliation
- Communication reliability
Discuss your project
Does valuable equipment depend on software its supplier no longer supports?
Tell us how your business works and where your software needs to change.
Get in touch
Ready to build software that fits your business?
Tell us what you need to build, modernize, automate, or augment with AI. We can start with a focused discussion or a no-risk 1-week trial.
“A fantastic company to work with.” After the initial rapid development project, American Shipping Co. kept two Shinetech developers embedded for nearly four years, supporting internal and external tools and new AI initiatives.
CEO, American Shipping Co. - 5-star Google Review