Khalti for Business: A Complete Guide

Khalti is the wallet many Nepali merchants reach for second, after eSewa - and in one important respect it is the friendlier rail to reconcile. It exposes a clean transaction lookup, a documented refund API, and per-transaction fee data. If you care about proving where every rupee went, that transparency matters. This guide covers onboarding, the payment and lookup flow, refunds, and fees.

Getting a Khalti merchant account

Like eSewa, a Khalti merchant account is distinct from the personal wallet. You apply as a business and receive keys tied to a merchant profile that settles to a business bank account.

You will typically need:

• Business registration (PAN or VAT, firm or company documents).
• A settlement bank account in the business name.
• Owner identification.
• Details of the website, app, or storefront accepting payments.

After verification you are issued API keys. The developer documentation lives at docs.khalti.com and is worth reading end to end before integrating - it is one of the clearer payment docs in the market.

The pidx and lookup flow

Khalti's current server-side flow is built around a value called the pidx (payment identifier). The shape is simple and reliable:

• Your server calls the initiate endpoint with the amount, a purchase order id, and a return URL. Khalti responds with a pidx and a payment URL.
• You redirect the customer to that payment URL to authorise the payment.
• After payment, Khalti redirects back to your return URL with the pidx and a status.
• Your server calls the lookup endpoint with the pidx to get the authoritative status - Completed, Pending, Refunded, Expired, or User canceled.

The golden rule: the lookup is the source of truth, not the redirect. Only mark an order paid when lookup returns Completed. This one habit eliminates a whole class of disputes where a customer closes the tab mid-payment.

The transaction list and reconciliation

Where Khalti earns its reputation is data access. Beyond the per-payment lookup, the merchant dashboard and APIs let you pull a transaction list for a period - every payment with its reference, amount, status, and fee. That list is your gross ledger.

Reconciliation then becomes: a set of completed transactions in the list, minus fees, minus any netted refunds, should equal the settlement credits on your bank statement. Because Khalti gives you both the transaction reference and the fee per transaction, the match is far less guesswork than a rail that reports only a lump settlement. For the settlement mechanics themselves, see how Khalti settlement and payouts work.

Refunds and the netting behaviour

Khalti documents a refund API keyed to the original payment, supporting both full and partial refunds. This is a genuine advantage - you can issue and track refunds programmatically instead of emailing support.

But there is a behaviour to model. On the merchant side, a refund often nets against a future settlement rather than appearing as its own reversal. The customer is made whole immediately; on your side the amount is carried forward and quietly subtracted from a later payout. If your books expect every refund as a standalone debit, that settlement will look mysteriously short. We unpack this fully in why a Khalti refund reduces your next settlement.

The clean way to handle it:

• When you issue a refund, open an expected-netting record for that amount, tied to the original payment.
• Watch subsequent settlement batches for a matching deduction.
• Close the record against the batch that absorbs it - now the refund has a home and the settlement is correctly reduced, not short.

Per-transaction fees

Khalti reports a fee per transaction. That sounds small but it is powerful: you can compute your effective rate - what you were actually charged - rather than assuming the headline percentage. Over a month of thousands of transactions, the gap between assumed and actual fees is exactly the kind of leak reconciliation is supposed to catch. If you want to see how the rails stack up on cost, we compare them in payment gateway fees in Nepal, compared.

A sensible go-live checklist

• Test the full initiate then lookup loop in the sandbox before switching to live keys.
• Store the pidx, purchase order id, and lookup status against every order.
• Persist the per-transaction fee at the moment of payment so your effective rate is auditable later.
• Model refunds as netting from day one, even before your first refund.
• Reconcile the transaction list against the bank statement on a regular cadence, not once a quarter.

Khalti operates under Nepal Rastra Bank's payments framework, which you can read at nrb.org.np if you want the regulatory context behind settlement timing.

Where RakamHQ fits

RakamHQ ingests your Khalti transaction list and your bank statement, matches every completed payment to the settlement that paid it out, tracks refunds through netting, and surfaces your true effective fee rate. The result is a proven daily close - every rupee traced to a source row, without a spreadsheet.

Frequently asked

What is the pidx in Khalti's payment flow?

The pidx is the payment identifier returned when your server initiates a payment. You use it to call the lookup endpoint and get the authoritative status of that transaction.

Should I trust Khalti's browser redirect or the lookup call?

Always trust the lookup call. Only mark an order paid when lookup returns Completed, since a closed tab or network issue can leave the redirect ambiguous.

Why did a Khalti refund make my settlement smaller?

Khalti often nets refunds against a future settlement rather than reversing them as a standalone debit, so the refund amount is quietly subtracted from a later payout.

Does Khalti show fees per transaction?

Yes. Khalti reports a fee per transaction, which lets you compute your true effective rate rather than assuming the headline percentage.

Keep reading

How Khalti Settlement and Payouts Work

Read

Why Your Khalti Refund Reduced Next Week's Settlement

Read

eSewa vs Khalti vs Fonepay for Merchants

Read