CSC385 Project: Building a Secure Payment Point-of-Sale System

Table of Contents

I recently completed the class project for CSC385 (Microprocessors) at the University of Toronto. Our team built a secure payment point-of-sale (POS) system. In this post, I’ll share the challenges we encountered, the solutions we developed, and what I learned through the process.

Background and Use Case #

Small businesses often rely on outdated loyalty methods like paper gift cards, stamps, or coupons. These get lost easily and provide no insights into customer behavior.

Our idea was to modernize this process using low-cost NFC tags (under 5 cents each). These can be programmed with customer information, visit dates, or gift card balances. By distributing them, businesses could track return visits, create loyalty deals, and issue digital gift cards.

We also explored the use of encryption for securing stored balances. While a Trusted Platform Module (TPM) would have been ideal, our STM32 board lacked the component we initially expected. This became one of our key technical challenges.


This is what we took inspiration from STMicroelectronics

My Contributions #

My main responsibilities included:

Designing the overall system architecture and finite-state machine (FSM) controller
Implementing UART communication between STM32 (STM32L745) and ESP32 (ESP32 WROOM)
Setting up MQTT messaging and experimenting with telemetry through ThingsBoard
Building a lightweight HTTPS server for product listing and UID handling

System Design #

I spent a large portion of the time on this project working on the system design. I designed the integrations between the STM32 and ESP32 and deliberated with the TAs about the best state-machine to solve our project’s technical challenges and ensure proper system operation.

One of the major issues with the STM32 is that it has limited modern networking abilities (e.g. TLS)
Deciding to add an ESP32 to add an additional thread and ensure that networking was more stable for the STM32. Also for adding an e-paper display.
Hardware selection and component organization


I worked on the system design and hardware selection

Communication Between STM32 and ESP32 #

I developed a custom UART protocol to ensure atomicity of transactions between the STM32 and ESP32. Key steps included:

Flushing UART data at initialization
Building a robust message format for requests/responses
Designing power management so the STM32 could drive the ESP32

This reliable communication layer became the backbone of the system.

NFC Integration #

NFC functionality was central to our project. While reading tags was relatively straightforward, writing data to tags posed significant challenges.

The RFID reader often failed to write consistently.
We added a 100µF capacitor to stabilize the 3.3V power line, improving reliability.
Even with this fix, we discovered first-hand how critical hardware choice is to project success. There were many issues with the off-the-shelf NFC reader which we faced.

Networking and Telemetry #

For connectivity, I worked on both HTTP(S) and MQTT:

MQTT & ThingsBoard: I implemented telemetry to send a “heartbeat” message every minute. While ThingsBoard provided visualization, it felt more suited for hobbyist projects. In hindsight, I would have used Mosquitto on our own server for more reliable control.
HTTPS Server: I set up a simple API on the domain csc385.ca. It listed products and logged NFC tag UIDs. Since TLS support in Mbed OS was limited, the STM32 sent data to my server via direct IP. This worked, but highlighted Mbed’s networking limitations.
WiFi Handler Sharing: Managing a shared WiFi connection between HTTP and MQTT was one of the trickiest parts. Frequent re-connections and driver limitations consumed a lot of time.


Thingsboard allowed us to view MQTT telemetry out of the box

Hardware Design and Soldering #

Hardware assembly was a major part of our work:

I soldered headers and wiring onto a protoboard, creating a modular stack with the STM32 at the base and ESP32 mounted above it.
We optimized wire routing with some reverse mounting techniques.
The result was a compact, robust, and modular prototype that could be easily debugged.

Limitations and Missing Features #

Two areas stood out as limiting factors:

Mbed OS: While documentation exists, networking and TLS support lag behind alternatives. Libraries also are outdated as the OS is deprecated. This slowed down integration and really made our team spend unreasonable amounts of time digging through Mbed documentation.
Trusted Platform Module: Our board lacked the expected TPM. An earlier I²C hardware test could have revealed this, saving us time. We spent a good 40+ hours collectively debugging to find out that the module itself isn’t mounted! This was a key lesson in verifying hardware assumptions early. A TPM would have been ideal because we would have been able to implement a fully working AES encryption which would be the industry standard. We also were hoping to do this and compete full on biometric encryption.

Presentation and Engagement #

We structured our final demo as follows:

2 min – Business problem and motivation
2 min – Components and system design
2 min – Live demo
2 min – Reflections and next steps

To prepare for this one, I watched the late Bob Lee’s demo for Square which I thought was a really great demo discussing embedded technologies and Square’s POS which I tried to model. Our product-style presentation was well-received. Unlike some groups that only screenshared software, our working hardware demo kept the audience engaged. The feedback was overwhelmingly positive, with our instructor noting the strength of our delivery which I believe is a big reason why we scored the highest grade in the project. I think our delivery worked out because of the many practice runs we did and the focus on building a working-demo.

For more, please check out the slides which we published.


This was the end product that we created.

Reflections and Lessons Learned #

This project taught me lessons beyond the technical details:

Encryption mindset: Secure payments require more than usernames/passwords. Validating gift card balances or transactions involves cryptographic guarantees, which connects directly to real-world systems like blockchain.
Hardware matters: A missing TPM or underpowered RFID reader can derail plans. Careful hardware selection is as critical as the software.
Prototyping affordability: For under $70 (ESP32, STM32, e-paper display, NFC modules, and HTTP server), we built a functional POS system — showing that accessible hardware can support ambitious projects.
Engagement: Product-focused demos resonate more strongly than slides alone. A tangible prototype elevates the project experience for both the team and the audience.

Final Thoughts #

CSC385 was a great course and I highly recommend anyone in computer science to take it. I believe embedded systems will become even more ubiquitous in the years ahead. I believe we can teach embedded systems to anyone regardless of background. To me, it’s the combination of many areas of computer science applied into real-world problems. By combining hardware integration, networking, and security principles, my team demonstrated how to tackle a technical project from the ground up utilizing our diverse backgrounds.


I spent a ton of time soldering and teaching my team how to solder (many thanks to CSC490)


Whiteboard planning prior to implementation which I’ve found extremely helpful for projects