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 → Settings → Payment 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 eSewa app opens with the payment filled in, and the buyer pays with biometrics or PIN. On a full-page mobile checkout, if the app does not open within 3 seconds (for example, it is not installed), the page tries eSewa’s web checkout; in embedded checkout the buyer chooses it. The switch goes ahead only after eSewa confirms the app payment is cancelled.
3

On desktop: a QR to scan

The buyer scans the QR with the eSewa app and pays; the page shows “Payment received” within seconds. A “Pay on the web instead” link covers buyers without the app.
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 → Settings → Payment providers → eSewa (off by default - flip it to enable Intent for your sandbox).
  3. eSewa’s sandbox test app (UAT APK, ~58 MB): esewa_rc_release.apk. It installs on Android next to your real eSewa app and only talks to eSewa’s sandbox.
  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 → Settings → Payment 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, if the eSewa app does not open, the page continues with eSewa’s web checkout automatically, so the buyer can still pay. 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.