Skip to content
All work
Full-stackGoReactMicroservices

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

Admin
User
Merchant

API layer

APIGo · Gin

Services

Payment Service
Callback Service
Email Service

Data & messaging

PostgreSQL
Kafka

Cache

Redis

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.

© 2026 Yernazar KarabayevBuilt with Gatsby, TypeScript, and Tailwind CSS.