Five payment providers behind one interface.
One Python library that connects your app to all of Uzbekistan's payment providers through a single, consistent API.
Every Uzbek product re-builds the same five fragile payment integrations from scratch — the exact code most likely to leak money.
Every product that takes money in Uzbekistan re-implements the same five integrations: different request shapes, different webhook contracts, different verification rules, the same bugs. The cost is paid again by every team, and the surface most likely to leak money is the one most often hand-rolled. I rewrote the webhook layer three times before the state machine felt honest. Money code that 'mostly works' is just a slower bug.
One gateway class per provider behind a shared interface, with built-in webhook handlers that speak each provider's dialect — including JSON-RPC 2.0 — and normalise them into a single transaction lifecycle. Integrity and verification checks are part of the library, not an exercise left to the integrator. The seam for adding a sixth provider is deliberately small. Naming things across five providers was harder than the integrations. One vocabulary, or it isn't unified.
The library owns the boring, dangerous parts — signature checks, state transitions, callback parsing — and hands back a clean transaction object. It does not own your database or your money logic. The goal was not to abstract payments away, but to make the correct integration the path of least resistance. Shipped it so the next team in Tashkent doesn't lose the same week I did.
Teams drop in one library instead of losing a week per provider, and the dangerous parts — signatures, webhooks, state transitions — are handled correctly by default.
5 providers · 1 API