eSewa runs a sandbox so you can make test payments before you have a live merchant agreement. These are the shared test values eSewa publishes for its ePay v2 checkout, and what to do with them.
Last checked: 22 October 2026, against eSewa's test credentials page and the sandbox PayBridgeNP runs test payments against every day. If eSewa changes a value, its page is the one to trust.
eSewa test login (for paying in the sandbox)
Use these on eSewa's test payment page, the one your checkout redirects to:
| Field | Value |
|---|---|
| eSewa ID | 9806800001, 9806800002, 9806800003, 9806800004 or 9806800005 |
| Password | Nepal@123 |
| MPIN | 1122 (in the eSewa app only, not on the web test page) |
| Token / OTP | 123456 |
These accounts are shared by every developer in Nepal, so treat them as test only and never as a place to keep anything.
eSewa test merchant values (for your server)
| Value | Sandbox |
|---|---|
| Product code (merchant code) | EPAYTEST |
| Secret key (for the HMAC signature) | 8gBm/:&EnhH.1/q |
| Payment form URL | https://rc-epay.esewa.com.np/api/epay/main/v2/form |
| Status check URL | https://rc-epay.esewa.com.np/api/epay/transaction/status/ |
The secret key signs the total_amount, transaction_uuid and product_code fields with HMAC-SHA256, in that order. Your live product code and secret key come from eSewa with your merchant agreement and are different. The live URLs drop the rc- prefix.
Running a test payment
- Post a signed payment form to the sandbox form URL with
product_codeset toEPAYTEST. - On eSewa's test page, sign in with one of the test IDs and the password above, then enter the OTP.
- eSewa sends the customer back to your
success_urlwith a signeddataparameter. - Confirm the payment with the sandbox status check before you mark the order paid. Never treat the redirect alone as proof.
Then try the unhappy paths: cancel on eSewa's page, and run a status check with a deliberately wrong amount so you have seen NOT_FOUND before a customer shows it to you. The whole flow, field by field, is in the eSewa API integration guide.
Why eSewa test payments fail
- Mixing test and live.
EPAYTESTwith a live URL, or your live product code with therc-URLs, fails every time. Switch all three values together. - A signature eSewa rejects. The signed fields must be listed in
signed_field_namesin the same order you signed them, and the amount must be written exactly as you sent it, for example100.00. - The status check says
NOT_FOUND. Ask about the sametransaction_uuid, product code and amount format you put in the form. A rupee amount sent as100and checked as100.00, or an amount in paisa, is the usual cause. - Reusing a
transaction_uuid. Each attempt needs a new one, even when the customer retries the same order. - The sandbox is slow or down. It happens. If the test page does not load, try again later before changing your code.
Testing eSewa without any keys
In PayBridgeNP test mode, eSewa and Khalti test payments work without you entering any eSewa keys: a test API key (sk_test_) uses the sandbox credentials above for you. Create a test checkout, choose eSewa, and pay with a test ID from the table. The sandbox testing guide has the Khalti test logins too. When you go live, you connect your own eSewa merchant account and payments settle straight into it.
Next Steps
- Build it yourself: the eSewa API integration guide.
- Need the live merchant account? Read the eSewa merchant login and registration guide.
- Testing Khalti too? See the Khalti API integration guide.
- Get free test keys in the PayBridgeNP dashboard.