Own productPayments platform
Rezana
grey-market top-upsa payment with a receipt
Payments and subscriptions for Russian games, with a receipt and the money in your own account.
In short
Payments and subscriptions infrastructure for Russian mobile games plus a top-up storefront for players: 5% instead of the stores’ 30%, a legal receipt, and a refund if the item never arrives.
- Problem: Russian cards do not work in Google Play or the App Store, studios have no way to take payments, and players top up through grey-market Telegram bots.
- Two sides: a developer cabinet (set up “in an evening”, payouts reconciled to the kopeck, webhooks) and a player storefront (you see who gets the money, a receipt and a refund).
- Double-entry money ledger, amounts in kopecks, row-level security on 41 tables, 116 operations in the OpenAPI contract, 1,289 tests.
- Naming checked against 160+ domains: “Rezana” is an Old Russian coin, literally a cut piece of silver.
30%5%
platform fee versus the stores
1,289
automated tests: backend, frontend, contract
116
operations in the OpenAPI contract
Problem
Russian cards do not work in Google Play or the App Store. Studios have no legal way to take in-game payments, and players top up through grey-market Telegram bots: no receipt, no refund, no guarantee the money arrives. The real competitor is not Codashop but the grey market.
Solution
| For whom | What they get |
|---|---|
| Developer | Set up in 4 steps “in an evening”, a dashboard, transactions with a timeline, refunds, payouts broken down to the kopeck, zero-downtime API key rotation, webhooks with a delivery log, a sandbox, team roles |
| Player | “Top up games in roubles. With a receipt, with refunds, without bots”: a catalogue with typo-tolerant search, the recipient’s in-game name shown before paying, fast bank transfers, one-click subscription cancel |
The model is a flat 5% of each payment, with the bank’s acquiring fee as a separate line. Try it: the calculator below uses the same algorithm as the backend, rounding fees down to the kopeck and sending the remainder to the partner.
Try it
Decisions
- ADR-0001
The product is a full B2C marketplace
Why. The analysis recommended a middle option, a storefront without paid traffic. I chose the full marketplace and rebuilt the plan around its main risk, the cold start: public launch is the second-to-last stage, after the first partners.
Rejected: B2B infrastructure only, with no storefront of our own.
- ADR-0006
Money is kept in a double-entry ledger
Why. Every movement is two entries that sum to zero. A partner payout reconciles to the kopeck not because a report says so but because the balance would not close otherwise.
- ADR-0004
Money is stored as integer minor units
Why. No floats: 99 roubles is 9,900 kopecks. Rounding is an explicit rule, not a property of the CPU.
- ADR-0010
A flat 5%, acquiring passed through
Why. No pricing matrix in the MVP: one number is easier to sell and to verify. The answer to “why more than RevenueCat?” is ready: we process payments, it only tracks them.
How it is built
A modular monolith in C# on .NET 10 with PostgreSQL as the source of truth: double entry, row-level security on 41 tables, 157 check constraints. The API contract comes first: 116 operations in OpenAPI. The web is Next.js 16 and React 19. T-Bank acquiring with one terminal for the whole platform: fast bank transfers, Mir cards, SberPay, T-Pay; fiscal receipts under law 54-FZ; signed webhooks; OpenTelemetry and Prometheus.
Before development I reviewed my own plan like a hostile reviewer: 17 pages and 140 tasks, with findings ranked by how expensive they get to fix late.
Status
The prototype runs on staging. Everything that depended on code is done; what remains depends on people and the bank: the acquiring sandbox, the first partner, the contract text. Launch targets: one hour from partner sign-up to the first test payment, and zero reconciliation mismatches.
Want more? Switch the reading depth to 30 min.