Payment integration
eSewa, Khalti, Fonepay and bank QR — done so the books balance.
Taking payments in Nepal is not one integration. It is a wallet, another wallet, a bank QR, and a customer who sends a screenshot at 11pm — and then the question of whether what you were paid matches what you recorded.
We have built this for our own products, which is why we know where it goes wrong.
What we handle
- eSewa and Khalti — the full flow, including the part everyone gets wrong: never trusting the browser's return URL, and confirming against the provider
- Fonepay and bank QR — dynamic QR where the bank supports it, manual proof with an approval queue where it does not
- Reconciliation — provider statements against your records, with the mismatches surfaced rather than quietly absorbed
- Refunds that reverse correctly in the books, not just in the wallet
Why this is more than an API call
A payment that is confirmed twice must not be recorded twice. A payment for the wrong amount must stop and ask rather than proceed. A payment that fails silently must be found by a job rather than by a customer's phone call. Those three rules are most of the work, and they are the difference between a gateway that works in a demo and one you can run a business on.
Scoped in writing first
Every engagement starts with a written scope: what gets built, what it costs, and when it lands.