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

PayBridgeNP confirms the result

PayBridgeNP verifies the payment with eSewa and sends your existing signed payment webhook.

​
What changes on your side

Nothing in the API. Your existing POST /v1/checkout request and payment.succeeded webhook stay the same. The provider remains "esewa".

​
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.

​
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.

​
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", and the public payload shape is unchanged. 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.