Payment Gateway & API Integration

Any developer can get a payment button working in a demo. The real work is everything around it: the customer who closes the tab after paying, the webhook that arrives twice, the wallet that times out, the refund requested a week later. Each of those, handled badly, becomes a support ticket or a lost order.

We design for those cases from the start. Payments are verified on the server, webhook events are checked for authenticity and processed once even if they arrive twice, and every state change is logged. When something odd happens, you can see exactly what and when.

The right gateway depends on who's paying, not on what's easiest to integrate. In Nepal that usually means eSewa and Khalti, as on Giftkdiu. In India it means UPI first, with cards, net banking and cash on delivery behind it, as on Oryizon. For international customers and subscriptions, Stripe is usually the cleanest choice.

Plenty of businesses need more than one. A Nepali brand selling to diaspora customers might want wallets for local buyers and cards for everyone else. We plan for that up front so adding a second provider later doesn't mean rewriting checkout.

Every provider has its own API, its own webhook format and its own idea of what a failed payment looks like. Integrate them one at a time and you end up with the same checkout logic written twice, tied to whichever provider came first.

Our open-source UniPay project came out of exactly this problem: a type-safe layer that puts Stripe and Razorpay behind one interface and normalises their webhooks into a single event shape. We bring the same thinking to client work, so your order logic talks to one interface and providers can be added or swapped without touching it.