What we build
Agent and distributor networks
Multi-level hierarchies with server-checked creation rules, relationship managers, staff roles and network reports.
Wallet ledgers
Wallets on a ledger with unique references and row locks, reconciliation tools, fund requests and settlement to bank accounts.
Commission and charges engines
Slab-based charges and commission with GST and TDS, upline shares, reversals and statements.
Provider integrations
Bill payment, recharge, AEPS, Micro ATM, UPI cash withdrawal and payout providers behind common interfaces, with routing and failover rules.
Partner APIs
Keys with permissions, HMAC request signing, IP whitelists, rate limits, idempotent references, reference docs and an audit trail.
Android apps
Native apps with RD device and card-reader SDK bridges, server-driven menus, receipt sharing and in-app updates.
Operations consoles
Dispute handling, stuck transactions, manual re-hit with locks, single-user 360 views and provider health.
Collection flows
Dynamic QR and loan repayment collection, built on your own bank, payment aggregator or lender.
Much of this already exists in the Payonclick platform, so a custom project often starts from proven modules rather than from a blank page.
Engineering rules we build by
These rules come from running live money flows on the Payonclick platform, and they go into every project.
- Pending stays pending. A transaction without a final answer is settled by a callback or a status check, never guessed.
- Refunds follow a confirmed failure. Money goes back only when the provider confirms the failure, and only once, under its own reference.
- One reference, one ledger entry. Every wallet movement has a unique reference, so a retry or a race can't post it twice.
- No second provider for a pending request. A request moves to another provider only after a clear failure, never while its result is unknown.
- Callbacks are checked. An incoming callback is verified, or re-checked with the provider, before it changes money.
- Secrets stay out of logs. Provider credentials and API keys are masked in logs and audit trails.
- One decision in one place. Access rules, limits and service switches each live in one module, so the web portal, the app and the API agree.
Our guide to idempotency and reconciliation in payment APIs explains several of these rules with examples.
How an engagement runs
Discovery call
We learn your business model, your regulated partners and the problem to solve.
Written scope
You receive the scope, the delivery milestones and a commercial proposal.
Build in milestones
We build in stages, and your team runs acceptance testing at each milestone.
Go-live
We deploy, train your team and watch the first days of live traffic with you.
Support and change
Bug fixes after go-live run under a support plan, and new features are quoted separately.
Changes after the scope is signed off are handled as change requests, so the cost and the timeline stay visible to you.
Technology
| Layer | What we use |
|---|---|
| Backend | Python and Flask, served by Gunicorn behind Nginx |
| Data | MySQL, with Redis for sessions, caching and short-lived locks |
| Web | Server-rendered pages, installable as a PWA |
| Mobile | Native Android in Kotlin and Java |
| Operations | Scheduled jobs for status checks and reconciliation, and a Prometheus metrics endpoint |
What we don't do
- We don't hold licences or funds for you. Your regulated partners hold the licences, and money flows through their accounts or yours.
- We don't make your compliance decisions. RBI's framework for outsourcing of payment and settlement-related activities by payment system operators (RBI/2021-22/76) doesn't let operators outsource core management functions or compliance decisions, such as decisions on KYC. We build the tools, and your team makes those calls.
- We don't promise what your providers control. Limits, approvals and settlement timings come from your banks and providers, and the software follows them.