Can eSewa do recurring payments?

Can eSewa charge a customer every month without the customer being there?

No. Nothing in eSewa's public developer documentation lets a merchant start a charge on its own. Every documented payment product ends the same way: the customer authenticates inside eSewa and confirms one specific amount. eSewa's own ePay overview states the scope plainly, that the system "enables partner merchants to perform a transaction and receive money from the customer having an eSewa account in a secure environment." Receive, on confirmation. There is no stored instrument to charge, no mandate object, and no scheduler a merchant can write to.

That is a product-scope gap, not an engineering one. eSewa announced PCI DSS v4.0.1 certification on 20 August 2026. It is simply built around a customer who is present and consenting each time.

Trile is in beta and runs in sandbox mode platform-wide. You can integrate and test end to end today. No real money moves until Trile completes Nepal Rastra Bank verification.

What does the eSewa API actually let a merchant do?

Three things, all of them one-off collections. ePay v2 takes a form POST to https://epay.esewa.com.np/api/epay/main/v2/form carrying amount, total_amount, transaction_uuid, product_code and an HMAC-SHA256 signature, then redirects the customer to eSewa to log in and confirm. Intent creates a booking through an API call, then deeplinks into the eSewa app where, in eSewa's words, the "user will enter MPIN for confirming payment." Token hands the customer a code they type into eSewa. The verbs available to you are create a payment request, verify a result, and check a status. There is no verb for charge this customer again.

What is eSewa's Scheduled Payment feature?

Scheduled Payment is a feature the customer sets up in the eSewa app to pay their own bills on a date they choose. eSewa's terms, dated 21 September 2022, define it as "an individual payment instruction that defines the date and time for a specific payment." The customer supplies the payment details, sets the date, time and frequency, and agrees "to provide debit authority of their eSewa account." They can tick a box to fall back to a linked bank account when the wallet balance is short. eSewa sends a notification one hour before it runs, and another after it succeeds or fails. The whole instruction lives on the customer's side of the relationship, protected by their MPIN.

Why is Scheduled Payment not merchant recurring billing?

Because the merchant is the payee, never the party that starts it. eSewa's terms define "Merchants" as "any party that receives payment through eSewa," and the customer grants debit authority over their own account, not to you. Two limits follow. First, eligibility: the terms state the feature "is only available in limited services which have been listed in recommended products," and that list is a fixed catalogue of utility and telecom billers. A SaaS product, a gym, or a media subscription has no documented route onto it. Second, control: you cannot create, read, amend or cancel a schedule, and you get no event when one is set up or torn off. Your revenue would depend on a setting you cannot see.

It is genuinely automatic deduction, and it is worth saying so plainly rather than pretending eSewa has nothing here. It is just automatic deduction that a consumer arranged for a bill they already owe, aimed at Nepal Electricity Authority and Worldlink, not at your billing engine. Whether any Nepali rail supports the unattended merchant-side version is the subject of is auto-debit possible in Nepal.

Is eSewa "My Payments" a merchant subscription tool?

No. My Payments is the older consumer feature that Scheduled Payment now sits inside. eSewa introduced it on 18 December 2019 as a way for a user to "manage your routine expenses by scheduling all regular payments" such as electricity, water and internet bills, with a reminder on a chosen day each month. It is a saved-biller list plus reminders. The 2024 setup flow still routes through it: the customer opens My Payment, taps Add Payment, and can choose "Set Reminder Only" instead of scheduling an actual debit. Nothing in it is addressable by a merchant, and it appears nowhere in eSewa's developer documentation.

Does the eSewa Token API store a payment method for later charges?

No. The name is misleading if you arrive from Stripe, where a token is a saved instrument you charge later. eSewa's Token payment runs the other way. Your server generates a token, the customer types it into eSewa, and then eSewa calls your server: a GET to your inquiry endpoint with the token, and you answer with the amount owed and a free-form properties map. eSewa then POSTs to your payment endpoint with a transaction_code once the customer has paid. You authenticate eSewa's calls with basic auth or a bearer token from an /access-token exchange.

eSewa's own inquiry example even returns a package list, "One Month Package. [ 1 Month at 499 ]" through a three year option, alongside an expiry_date. So eSewa clearly anticipates subscription products. It still needs the customer to walk into the app and enter a token to start each renewal.

Does eSewa Intent's linked bank account debit count as auto-debit?

Not in the sense that matters for billing. eSewa Intent lets the customer pick, in the eSewa app, between paying from the wallet or from a "Direct Link Account (DLA) via Direct Debit (DD)." The phrase direct debit reads like a mandate, but the documented flow puts a human in it: eSewa creates a booking, deeplinks the customer into the app, shows them the payment details, and step three is that the "user will enter MPIN for confirming payment." The bank link changes where the money comes from, not who authorises the movement. Your merchant server still cannot fire a charge at a sleeping customer on the first of the month.

How do eSewa's payment products compare on who starts the charge?

Sort them by that one column and the picture resolves. Everything eSewa offers a merchant is customer-started. The one thing that runs unattended is customer-owned and restricted to a fixed biller list. The last row shows where Trile sits, for contrast.

What breaks if you build a subscription on eSewa ePay v2?

The integration works. The business model is what fails. Each cycle is a brand new checkout: a fresh transaction_uuid, alphanumeric and hyphens only, and a fresh HMAC-SHA256 signature computed over total_amount, transaction_uuid and product_code in exactly that order, base64 encoded. eSewa returns the result to your success_url as a base64 blob you decode and re-sign to verify. If no response arrives within five minutes you poll the status endpoint, which can answer PENDING, COMPLETE, FULL_REFUND, PARTIAL_REFUND, AMBIGUOUS, NOT_FOUND or CANCELED.

Now put that on a monthly loop. Every renewal needs the customer at a screen, so churn is no longer a product problem, it is a reminder-open-rate problem. This is exactly the model SUQO runs, and they describe the constraint honestly: "Auto-debit isn't available in Nepal yet. Banking infrastructure hasn't opened that up." They are right about the bank rails. A pre-funded balance sidesteps the question rather than answering it.

What could not be verified from eSewa's public documentation?

Four things, listed here rather than guessed at:

• Whether eSewa operates any private or partner-only recurring, mandate, or standing-instruction API. Nothing at developer.esewa.com.np references one.
• How a merchant joins the Scheduled Payment "recommended products" list. eSewa says more services are coming but names no criteria, process or contact.
• The Instant Payment Notification payload and signature scheme. ePay v2's transaction flow mentions IPN at step six, but the ePay section publishes only Transaction Flow, Integration, Status Check and Credentials pages.
• Any merchant fee, settlement timing, or transaction limit relevant to subscription billing. Not stated in the developer documentation.

If eSewa ships a merchant-initiated recurring product, this page is wrong and we will update it. As of August 2026 it is not documented.

How does eSewa work as a top-up source for Trile?

Trile is subscription-billing infrastructure for Nepal. Because no card-on-file rail exists here, the customer pre-funds a wallet and Trile deducts each cycle from that balance. eSewa's job in that model is one payment, at the start, in the flow it is actually good at. The customer confirms a top-up through eSewa, Trile credits the wallet, and every renewal after that is a ledger movement inside Trile: the subscription draws an invoice against the balance and the invoice moves to paid. Nothing returns to eSewa, so nothing needs re-authenticating and nothing can decline. Amounts are integer paisa serialized as strings, so NPR 499.00 is 49900, never a float.

ग्राहकले इसेवाबाट एक पटक वालेट भर्छन्, त्यसपछि हरेक चक्रको रकम त्यही ब्यालेन्सबाट कट्छ।

What changes in your code when eSewa becomes the top-up instead of the biller?

The eSewa integration stops being on your renewal path. You send the customer to a Trile checkout session, which handles phone verification, the top-up, KYC and the subscribe step in one flow, and your server receives a subscription.created webhook. From then on you read invoices, not payment redirects. Writes carry an Idempotency-Key, so a retried renewal never double-charges, and responses arrive in a success, data and meta envelope. When a balance runs short the subscription moves to past_due, an invoice.payment_failed event fires, and it recovers on the next top-up. The object model behind that is covered in is there a subscription billing API for Nepal.

Are Khalti, ConnectIPS, Fonepay or IME Pay any different?

Not on the question that matters. None of them publishes a merchant-initiated recurring charge for domestic NPR billing, so what you find when you go looking is the same one-off checkout integration under four different names. Khalti has its own wrinkle worth reading separately, because its Stripe partnership is about receiving cross-border money rather than billing Nepali customers on a cycle: see can Khalti do recurring payments. Fonepay and ConnectIPS sit on bank rails and are covered in is auto-debit possible in Nepal. All four work well as top-up sources into a pre-funded wallet, which is how Trile uses them.