Building

Plug-and-play e-commerce for game servers

A store for GTA:RP and Minecraft servers with direct in-game integration, a config panel and automated tax-invoice issuing.

Period
May 2026 ongoing
Role
Solo
2
target platforms
1-click
install
Auto
invoicing

#Context

GTA:RP and Minecraft servers sell items, access and perks to their players, but setting up that store today is painful: each owner improvises their own in-game integration, handles the gateway by hand, and issues (or forgets to issue) tax invoices on the side. It's repeated, fragile, easy-to-get-wrong work — exactly the part that shouldn't eat up the time of whoever runs the community.

#What the product does

  1. Integrates the store into the game artifacts/build in a plug-and-play way — the purchased item reaches the player without manual hacks.
  2. Keeps all configuration in a panel, no code needed to operate.
  3. Automates tax-invoice issuing on every sale.
  4. Controls the payment gateway, with selection by payment method and amount.
  5. Delivers metric-backed tracking of sales, with external plugins to help management.

#Architecture

A purchase flowThe purchase goes through the store, is routed to the chosen gateway by payment method, triggers invoice issuing and delivery of the artifact inside the game.Store (panel + checkout)Gateway routerPayment gatewayInvoice issuingIn-game delivery (build)
A purchase flow

#Technical decisions

Why plug-and-play integration instead of letting each owner configure it?

Because manual integration is where everything breaks. The more infra decisions I take out of the admin's hands, the less support I give later. The cost is having to support each platform's artifact formats — the complexity sits with me, not the customer.

Why choose the gateway by payment method and amount instead of fixing one?

Fees and gateway availability vary by method and by ticket size. Routing dynamically lets each sale land on the most advantageous gateway. The trade-off is one more routing layer to maintain instead of a single simple path.

Why bake in invoice issuing instead of leaving it outside?

Manual issuing is the step everyone forgets and pays for later. Putting the invoice inside the sale flow makes the correct thing the default path. I traded initial simplicity to remove a whole class of operational error.

#What went wrong

The biggest lesson so far is about scope: the temptation to support every game platform from day one is strong, and it stalls delivery. I re-centered the project on two platforms done well (GTA:RP and Minecraft) before generalizing — breadth only after depth proves the value.

#Outcome

  • Under construction. The goal is to turn a fragile, manual integration into a plug-and-play install with invoicing and gateway solved by default.
  • Sales metrics in the panel from day one, so the owner decides on data, not guesswork.

Stack

  • Next.js
  • TypeScript
  • PostgreSQL
  • Node.js

Want a result like this in your product?

Talk to me