Building a QR payment platform from scratch.
Unified QR payment infrastructure for vending and merchant businesses.
- Role
- Founder / Full-stack Engineer
- Status
- Built from concept to MVP
The Idea
PayQR was an attempt to build a unified QR payment solution together with a payment-system partner, targeting approximately 1,000 vending machines.
Instead of requiring dedicated payment hardware on every vending machine, the idea was to replace the physical payment terminal with a QR code that customers could scan to pay directly.
The Challenge
Vending payment terminals are expensive to purchase, install, and maintain across a large fleet of machines. For a partner operating at scale, that infrastructure cost was a significant, recurring expense.
The core engineering challenge was replacing that hardware-dependent flow with a QR-based payment flow that stayed reliable, auditable, and fast enough for a real point-of-sale interaction — without introducing a single point of failure across payment creation, confirmation, and merchant callbacks.
My Role
As founder and sole engineer on the project, I independently designed and implemented the entire MVP — both the backend platform and the three frontend applications built on top of it.
This covered service architecture, API design, database schema, asynchronous processing, and the full UI layer for admins, users, and merchants.
Architecture
A conceptual representation of the PayQR platform. It illustrates the shape of the system, not an exact production topology.
Frontend applications
API layer
Services
Data & messaging
Cache
Conceptual diagram — not an exact production architecture.
Async Processing
Go microservices communicated over gRPC for synchronous, low-latency calls between the API layer and internal services.
Kafka handled asynchronous communication between worker services, decoupling payment-status changes from downstream effects such as callback delivery and email notifications, so a slow or failing downstream integration could not block a payment.
The callback service was responsible for delivering payment-status callbacks to partner systems, and the email service handled asynchronous transactional email delivery.
Caching
Redis was used to cache frequently accessed information, including user activation status, reducing repeated round-trips to PostgreSQL for data that changes infrequently but is read on nearly every request.
Multiple Frontends
The frontend was split into three separate applications, each scoped to a distinct audience: an Admin interface for platform operators, a User Cabinet for end customers, and a Merchant Cabinet for merchant-side management.
All three were built with React, TypeScript, Vite, and shadcn/ui, sharing conventions and tooling while remaining independently deployable.
Technical Decisions
Backend
- Go
- Gin
- gRPC
- Microservices
- PostgreSQL
- Redis
- Kafka
Frontend
- React
- TypeScript
- Vite
- shadcn/ui
Status
MVP completed. PayQR was built from concept through a working MVP.