Challenge
A payment institution does not start with a website. It starts with what the regulator will ask for, and three answers have to exist before the first line of code: how the system reports, who is allowed near the money, and what happens when a transfer leaves but the confirmation never comes back.
The brief covered all of it: a company that would take a licence from the Central Bank of Uzbekistan, move money across the CIS, accept four card schemes, and run through its own apps.
Solution
We built from the inside out. The settlement core came first: accounts, entries, fees, balances. Roles and permissions came second, because an operator, an accountant, an agent and a merchant need different access to money, and that difference belongs in the data rather than in which buttons are visible.
One part of the work is rarely written into a brief: reconciliation. Every payment system survives until its first disagreement with a partner, and nobody settles that by reading an export.
Architecture and implementation
The billing core keeps entries and balances, and a balance only ever moves inside an atomic operation. Above it sit an admin panel with role-based permissions and an action log, a merchant back office with API onboarding and payouts, and an agent back office with top-ups, commission and rewards. Three client applications shipped, one of them inside a messenger.
Sending the same payment twice does not create a second operation.
Result
The institution received its licence in May 2021 and ran as a full payment company: transfers, card acceptance, merchants, agents, apps in both stores. The owner of DigiCore founded it, served as its chief executive, designed the system himself, and sold the company recently.
For a client the useful part is simpler: the person responsible for payment architecture here has taken a system of this kind through a regulator, and all the way to a sale.
