Almost every business that comes to us wanting to add online payment thinks it is a checkbox. It is not. It is a merchant account, a gateway integration, a server endpoint that has to be reachable and correct, a reconciliation habit, and a plan for the payments that land in the gap between your customer paying and your system knowing about it. Skip any one of those and you will eventually take money you cannot match to an order.

Step One Has Nothing to Do With Code

Before a developer writes a line, you need a merchant account with the provider, and that is a business process: company registration documents, PAN or VAT details, a bank account in the business name, and a signed agreement. Timelines vary and are outside your developer control. Start this first, in parallel with the build, because it is the single most common reason a launch date slips. A perfectly integrated checkout is useless while your merchant application is still under review.

Test Credentials Are Not Optional

Every serious provider gives you a sandbox: separate credentials, a separate endpoint, and fake money. Build and test entirely there. The mistake we see is a team wiring straight into live credentials because sandbox access takes too long to request, then discovering their callback handling is wrong only after real customers are involved. Sandbox first is not caution, it is the only way to test the failure paths, because you cannot deliberately fail a real payment over and over.

The Callback Is the Whole Integration

Here is the part that separates a working integration from a fragile one. When a customer pays, they are sent to the provider, and the provider tells your server what happened. That message, the callback or webhook, is what your system must treat as the source of truth. Not the customer landing back on your success page. The two are different events and they can disconnect: a customer can pay and then close the browser before being redirected. If your order only gets marked paid when the browser comes back, that customer paid and has nothing to show for it.

Verify Server-Side, Every Time

Never trust the amount, the status or the reference that arrives in a URL the customer browser passed through. Anything the browser touches can be edited. The correct pattern is: receive the callback, then make your own server-to-server call back to the provider asking what it actually received for that transaction, and compare that answer to the order in your database. Amount matches, currency matches, reference matches, status is successful. Only then mark it paid. Providers publish a verification or lookup endpoint precisely for this, and skipping it is how stores get charged nothing for real goods.

Idempotency: The Bug That Bites Six Months Later

Providers retry callbacks. If your endpoint is slow or returns an error, the same successful payment may be delivered to you two or three times. If your handler simply adds a payment record each time it is called, you will ship three orders for one payment, or credit a wallet three times. Every callback handler needs to check whether that transaction reference has already been processed and do nothing if it has. Write it in on day one. It is ten lines, and retrofitting it after a live incident is far more expensive.

Reconciliation Is a Habit, Not a Feature

At the end of every day, the total your system says it collected and the total your provider says it collected should match. When they do not, you want to find out that evening, not at month end. Build a simple report that lists the day successful orders against the provider settlement, and make checking it someone job. The mismatches are almost always instructive: an abandoned callback, a duplicate, a refund nobody recorded.

Which Gateway to Choose

The honest answer is that it depends on where your customers already are, not on which has the nicest documentation. eSewa and Khalti are wallets your customers likely already hold. Fonepay reaches customers through their own bank apps and mobile banking, which matters for older and less wallet-inclined buyers. Connect-IPS suits higher-value or business-to-business transfers. Most serious Nepali storefronts end up offering more than one, because the cost of a customer reaching checkout and not finding their preferred method is the entire sale. Budget for two from the start rather than adding the second under pressure later.

What This Should Cost You in Time

For a single gateway, on a codebase that is already well structured, integration is a matter of days, not weeks, once merchant credentials are in hand. The time goes into the edge cases: the failed payment, the double callback, the customer who closes the tab, the refund. If a quote treats payment integration as an afternoon, that quote has priced the happy path only. Ask specifically how the failure paths will be handled, and you will learn a great deal about who you are hiring.

The Short Version

Start merchant onboarding before development. Build in sandbox. Treat the server callback as truth, not the browser redirect. Verify every transaction server-side before marking it paid. Make the handler idempotent. Reconcile daily. Do those six things and online payments become boring, which is exactly what you want from the part of your business that handles money.