VSCGames
[Client]
VSCGames
[Year]
2025
[Project Focus]
- Automate voucher and top-up fulfillment from supplier to customer.
- Give merchants a secure, real-time path to sell digital products.
Scroll to explore
[Overview]
VSCGames needed a single fulfillment layer that could scale with new suppliers and merchants without rewriting the purchase path each time.
[What I did]
- Designed and implemented GraphQL backend services for digital product workflows
- Integrated supplier APIs to automate voucher and top-up fulfillment
- Built merchant integration pipelines with secure authentication and access controls
- Enabled Telegram-based commerce with real-time purchase and delivery processing
[The role]
Backend Engineer
Njay
Project Info
VSCGames is a digital marketplace for game top-ups, gift cards, and vouchers. Customers expect a purchase to reach the correct account within seconds. Merchants expect the same catalog and fulfillment through their own storefronts. The product requires one backend that can serve both channels from a single source of truth.
I owned the GraphQL services behind that commerce core: product queries, orders, supplier fulfillment, merchant authentication, and Telegram purchase flows. The requirement was a single path from request to delivery that could accept a new supplier or merchant without rewriting checkout.
Overview
2025
VSCGames is a digital marketplace for game top-ups, gift cards, and vouchers. Customers expect a purchase to reach the correct account within seconds. Merchants expect the same catalog and fulfillment through their own storefronts. The product requires one backend that can serve both channels from a single source of truth.
I owned the GraphQL services behind that commerce core: product queries, orders, supplier fulfillment, merchant authentication, and Telegram purchase flows. The requirement was a single path from request to delivery that could accept a new supplier or merchant without rewriting checkout.
The Process
Work started with the order model. A top-up moves through defined states — requested, paid, submitted to a supplier, confirmed, and delivered — and each state has a failure mode. I modeled those workflows in GraphQL so the web store and the Telegram bot called the same mutations, then persisted payment and delivery status in MongoDB so neither channel could diverge.
Supplier APIs were implemented as adapters, not as the product. Each integration mapped into a shared fulfillment contract: product lookup, player verification where required, order submission, and status polling. Catalog growth did not require a rewrite of checkout.
Merchant access used the same services with a separate key and permission model. A merchant can query products, place orders, and read their own transactions without access to another merchant’s data. Telegram commerce reused that path so chat purchases did not require a second backend.
The Outcome
The platform operates as a production fulfillment layer: real-time purchases on web and Telegram, automated supplier delivery, and a merchant API that can sell the same catalog under a separate brand.
New suppliers and merchants attach to the existing order path. Payment state, delivery state, and merchant history remain consistent across channels.