API Integrations Every Custom Nepali Web App Needs: Payments, SMS, and Government IDs

A custom web application almost never operates in isolation. It needs to send a text message when an order ships, verify a customer's identity before approving a loan, calculate a delivery route, or reconcile a payment that happened somewhere else entirely. These connections, API integrations, are often treated as an afterthought bolted on near launch. That's backwards. The integrations a system needs should shape the architecture from day one, not get squeezed in once the core is already built.

Why Integrations Make or Break a Custom App

We've seen projects where a payment or SMS integration was assumed to be simple and left until the final sprint, only to discover the chosen provider's API doesn't support a required feature, or requires a business verification process that takes two weeks. By then, the core system is built around an assumption that no longer holds. Scoping the actual integrations honestly during discovery, not development, avoids this entirely.

Payment Gateways Beyond Checkout

Most businesses think of Fonepay, eSewa and Khalti purely as a checkout button. For a custom web application, payments often need to go further: automatic reconciliation of which invoice a payment matched, handling partial payments and refunds programmatically, and reacting to delayed webhook confirmations gracefully rather than leaving an order stuck in limbo when a callback arrives late over a shaky connection. This is meaningfully more work than a simple website checkout button, and it should be scoped as such.

SMS and Notification Gateways

Order confirmations, appointment reminders, OTP verification, low-stock alerts to a manager, these all typically run through an SMS gateway or, increasingly, Viber Business messages for lower cost per message. The practical questions to settle early: which gateway has reliable delivery to Nepali telecom numbers, what's the cost per message at your expected volume (this adds up fast for high-transaction apps), and what happens when a message fails to send, does the system retry, alert someone, or silently drop it? We've inherited systems where the answer to that last question was "nobody knew", which meant customers weren't getting confirmations for weeks before anyone noticed.

National ID and KYC Verification

Apps handling loans, larger transactions, or any regulated service increasingly need identity verification, checking a citizenship number or national ID against a government or verified database, rather than trusting a self-reported form. This is one of the more sensitive integrations to build: it needs careful handling of personal data, clear consent flows, and awareness that verification services and their requirements can change as government digital ID systems evolve. Building this flexibly, rather than hard-coded to one provider's exact format, saves a rebuild later if the verification landscape shifts.

Google Maps and Delivery Logistics

Delivery apps, service-area businesses and anything needing "how far is this customer from us" logic typically integrate mapping APIs for address lookup, distance calculation and route display. The catch in Nepal: address data is often informal, ward numbers and landmarks rather than standardised streets, so a good implementation supports landmark-based address entry alongside map pins, rather than assuming every customer can drop a precise pin on a first try.

Planning Integrations Before You Build, Not After

Every integration above adds real scope: API costs, provider account setup (some require business verification that takes days), error handling for when the third-party service is slow or down, and testing that goes beyond "did it work once." We map every required integration during discovery, before quoting, precisely because guessing at this stage is how fixed-price projects blow their budget. If your project needs payments, SMS, ID verification or maps woven in, tell us upfront and we'll scope it properly the first time, with a fixed-price quote within 24 hours that already accounts for the integration work, not a surprise change order three weeks in.