Skip to main content
eSewa Intent is a newer payment flow from eSewa that lets buyers pay inside the eSewa mobile app instead of the eSewa web page. PayBridgeNP handles both the deeplink (mobile) and the cross-device QR (desktop) automatically - same POST /v1/checkout call, eSewa just feels faster and more native.
Intent is live. In sandbox it is open to every plan so you can prove the integration first. In live it is a Pro feature and each merchant supplies their own eSewa production Intent Access Key (see Going live).

​
Why Intent matters

Compared to the existing eSewa v2 ePay (web) flow, Intent gives you: Most NP commerce is mobile-heavy. Intent removes the web detour for the majority of your buyers, which usually shows up as a measurable conversion lift.

​
How it works

You don’t change anything about how you create checkout sessions. PayBridgeNP picks Intent automatically when:
  1. The merchant has eSewa configured (existing merchantCode + secretKey), AND
  2. The merchant has flipped the eSewa Intent toggle on at Dashboard → Providers → eSewa (off by default), AND
  3. The merchant’s plan allows Intent - any plan in sandbox, Pro in live, AND
  4. In live only: the merchant has supplied their own eSewa production Intent Access Key (sandbox auto-uses eSewa’s public test key, so no key setup is needed there).
If any of these fail, the existing v2 ePay flow runs instead - buyer sees no difference.

​
What the buyer sees

1

Buyer picks eSewa on the checkout page

Same picker tile as before. No “Intent vs Web” choice - we route automatically.
2

On mobile: deeplink opens the eSewa app

The page fires the eSewa deeplink. The eSewa app launches with the payment pre-filled. Buyer authenticates with biometric / PIN and pays. If the app does not open within 3 seconds (e.g. the buyer does not have the eSewa app installed), the page silently submits the v2 ePay web form so the buyer never gets stuck.
3

On desktop: QR with sonar rings + scan-line animation

The page renders a QR encoding the same deeplink. Buyer scans it with the eSewa app on their phone, pays, and the desktop page polls our /status endpoint and flips to “Payment received” within seconds. There is also a “Pay on the web instead” link for buyers who do not have the eSewa app on their phone.
4

Server-to-server callback + polling worker

eSewa POSTs the result to our callback URL. As a safety net, we also poll eSewa’s /status API every 3-30 seconds (with backoff) in case the callback drops. Whichever lands first wins; the other is deduplicated.

​
What changes on your side

Nothing in the API. Your existing POST /v1/checkout request shape is unchanged. Your existing webhooks fire with the same payment.succeeded event and the same payload - provider is still "esewa". The only outward signal that Intent was used is metadata.esewa_intent.bookingId in the checkout session’s metadata, which is internal-only.

​
Testing in sandbox

In sandbox mode, any merchant on any plan can test Intent. You do not need to upgrade. The dashboard auto-fills eSewa’s public sandbox merchant code, secret key, and Intent access key for you - no setup beyond flipping the toggle. To test the full flow you will need:
  1. A sandbox merchant account on PayBridgeNP (any plan).
  2. eSewa Intent toggled on at Dashboard → Providers → eSewa (off by default - flip it to enable Intent for your sandbox).
  3. eSewa’s sandbox test app (UAT APK). Direct download from eSewa: esewa_rc_release.apk (~58 MB). Install it on an Android device alongside your real eSewa app - the UAT app is a separate package and points at eSewa’s sandbox backend, so live payments cannot leak through it.
  4. A phone on the same WiFi as your dev server (for the desktop QR scan flow). Or just open the deeplink URL on the phone directly.
Then create a session normally:
Open the returned checkout_url and pick eSewa. Mobile gets the deeplink; desktop gets the QR.

​
What lives in metadata.esewa_intent

When Intent is dispatched, PayBridgeNP writes to checkout_sessions.metadata:
These are eSewa’s internal references. You can use bookingId to look up the payment in eSewa’s merchant dashboard. They are visible to merchants on the dashboard’s payment detail page but are not part of the public API surface today.

​
Refunds

Refunds for Intent payments behave the same as v2 ePay: PayBridgeNP records the refund as requires_action and returns a message asking you to process it manually through the eSewa merchant dashboard. eSewa has not yet exposed an automated refund API for Intent (or for v2 ePay). When they do, refunds will become automatic for both flows in the same release.

​
Going live

Live Intent is open. To turn it on for real payments, a merchant needs all of:
  1. A Pro (or Enterprise) plan - esewa.intent is a Pro entitlement in live.
  2. Their own eSewa production Intent Access Key, requested from eSewa and pasted into Dashboard → Providers → eSewa (the sandbox public test key is rejected in live).
  3. The eSewa Intent toggle on for eSewa.
With all three in place, live buyers get the Intent deeplink and QR. A live merchant who has not configured their Intent Access Key (or is not on Pro) keeps getting the v2 ePay flow automatically, so nothing breaks.

​
Frequently asked

Will my existing eSewa integration keep working? Yes. Intent is additive - v2 ePay remains the automatic fallback whenever Intent does not apply (a merchant not configured for live Intent, or a buyer without the eSewa app installed). Do I need to change my SDK / webhook code? No. The provider is still reported as "esewa", the payload shape is unchanged, and the only new field is internal metadata. What happens if the buyer does not have the eSewa app installed? On mobile, the page detects the deeplink did not open the app (3-second timeout via visibilitychange) and auto-submits the v2 ePay web form so the buyer continues without friction. On desktop, the QR is the primary call to action and there is a “Pay on the web instead” link beside it. Can buyers refund themselves? No. Refunds are merchant-initiated, same as today. Why is there a 30-minute session expiry? Buyers may background the eSewa app (phone call, app switch) and come back later. 30 minutes matches the picker’s expiry and gives buyers cushion. eSewa’s own session window is shorter; if they expire on eSewa’s side first the buyer gets a clear “session expired” message and can restart from your store.