| Provider / approach | Documented starting point | Confirm for your merchant account |
|---|---|---|
| eSewa ePay | Hosted redirect flow, response signature and transaction verification | ePay versus Intent or another approved integration |
| Khalti KPG-2 | Server-side initiation, pidx and payment lookup | Account credentials, amount units and supported states |
| connectIPS | Bank-account checkout for merchant portals | Onboarding pack, credentials and verification contract |
| Fonepay | Merchant QR and dynamic-QR options | Acquirer/POS arrangement, API access and notifications |
Payment integration design checklist
Choose a payment journey before choosing an API
Decide whether customers need a hosted online checkout, a bank-account payment or a QR experience at a counter. A static QR image is not the same integration as an order-specific dynamic QR. Ask which product your merchant agreement enables; do not mix request fields from unrelated versions.
Get the account-specific onboarding requirements
Request the current business/KYC document checklist, supported channels, test access, production approval process and settlement agreement from the provider or acquiring bank. Keep test and production credentials separate and store secrets on the server. The same onboarding list or signature algorithm should not be assumed for every provider.
Treat eSewa and Khalti returns as different contracts
eSewa ePay documents browser redirects, a signed response and a transaction-status check. Khalti KPG-2 uses a server-side initiation request and pidx for lookup; its documented amount unit is paisa and its completed status is Completed. Neither should be described generically as an identical webhook posting PAID. Use each current official document for exact fields and status semantics.
Confirm connectIPS and Fonepay integration access
connectIPS describes checkout using a linked bank account. Fonepay describes merchant QR and dynamic-QR arrangements. Obtain the integration pack approved for your merchant or acquiring-bank setup. Public product information alone is not enough to invent API endpoints, signature rules or a universal server-notification format.
Verify before fulfilling an order
Persist an expected order amount, currency/unit convention, merchant identity and unique attempt reference before redirecting. Validate incoming data according to the provider contract, obtain authoritative payment status, and match it to the stored attempt. Handle mismatches and unknown states as reviewable exceptions. Never fulfil solely because a browser URL says success or a customer shows a screenshot.
Make retries and delayed results safe
Maintain an order separately from its payment attempts. Use a database uniqueness rule and an atomic state transition so repeated notifications or lookups cannot ship an order twice. Keep timeouts pending or under review until resolved. Test failed payments, delayed returns, duplicate events, wrong amounts, refunds and interrupted connections in the provider’s approved test environment.
Read the fee and settlement agreement
Collect a written quote covering setup/integration costs, transaction charges, minimums, refunds, reversals, settlement schedules and applicable taxes. A QR acceptance offer does not establish the cost of every API or acquiring arrangement. This guide deliberately gives no universal merchant fee percentage or next-day settlement promise.
Reconcile payments and bank settlements separately
Keep the order reference, payment-attempt reference, provider reference, verified amount and status, fee entries, refunds and bank settlement reference. A customer payment and its later bank payout are separate events. Compare provider reports with your ledger and bank statement, and review unmatched records rather than overwriting the original evidence.
Official references
Reviewed October 18, 2026. Follow the documentation for the product approved for your account.
Frequently Asked Questions (Nepal Context)
Q: Does every provider send a webhook?
No universal callback format is assumed here. The reviewed ePay and KPG-2 documents describe browser-return and verification/lookup flows. Other products or merchant arrangements may provide different notifications. Follow the integration contract supplied for your account.
Q: Are merchant fees and settlement times the same for every integration?
No. Obtain current written commercial and settlement terms for your provider, product and merchant arrangement; check any exceptions, fees and refund conditions.
Q: Are these code examples tested against a live merchant account?
This overview contains no production-ready payment code and does not claim a live or sandbox payment test. Use the official test environment and complete the provider’s required verification before going live.