Is auto-debit possible in Nepal?

Is auto-debit possible in Nepal?

Yes, and almost certainly not for you. A bank-rail direct debit mandate exists here and is in production: Nepal Clearing House Limited specifies it as e-Mandate Based R2P in the NPI Operating Rules, approved by Nepal Rastra Bank's payment systems department under letter PSD/Policy 04/41/078/79 dated 17 Kartik 2078. NCHL's 2024/25 annual report says the scheme "is currently being used by some of the service providers for recurring payment collection." MetLife Nepal went live on it with Standard Chartered Bank Nepal in June 2023.

What does not exist is a way for an ordinary business to get to it. There is no public developer documentation for e-Mandate, no self-serve signup, and no price list. The rules restrict origination to members, and a merchant is not a member. Consumer-side automation is real too, and equally out of reach: an eSewa customer can schedule a repeating payment for themselves, to seven listed biller categories, with no merchant API anywhere near it. That is why almost every Nepali subscription business bills some other way, and why Trile deducts from a balance the customer has already funded instead of pulling from their bank.

One thing to be exact about before the rest of this page, because it is the part people blur. Trile does not pull from a customer's eSewa or Khalti balance either. Nobody can. Trile deducts from a Trile wallet the customer pre-funded, which is a balance Trile holds. That is a different claim from having solved the missing pull rail, and it is the only one being made here.

Status, plainly: 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 is NCHL's e-Mandate, and does it really do unattended debits?

It does, by design. Section 5.2.5.2 of the NPI Operating Rules defines e-Mandate Based R2P as a request "that can be initiated as a pre-authorized debit request by Payer, corresponding to which successive transfers from Payer to Payee will be initiated on scheduled time or as and when required. Such e-Mandate will be setup and authorized by Payer as one-time activity." The rules describe it as "a tokenized digital consent authorized by Payer (debtor) allowing a Payee (creditor/beneficiary) to receive an amount from the specified Payer's debit account at predefined schedule or on request as set in the e-Mandate."

The mechanics match what a mandate rail looks like anywhere else. The payer is redirected to NCHL's tokenization gateway, authenticates through connectIPS or by linking a bank account with an OTP and a micro-deposit, picks the account, and a unique token is issued to the payee's agent. From then on, "On due date or upon request based on e-Mandate, the Payee or Payee Agent will initiate a R2P request (debit instruction) based on the authorized mandate details." Mandates expire on a validity period NCHL sets, and either side can cancel.

One caveat sits in the same section and is worth knowing before you build a plan around it. Rule 7 leaves a per-transaction step-up to the payer's bank: "Based on nature of transaction or channel used or transaction amount, Payer Agent may add controls for additional authentication (like OTP or authenticator based code or similar) that may be required to complete the financial transaction." Unattended is the intent, not a guarantee the scheme gives the payee.

Who is allowed to use e-Mandate direct debit in Nepal?

Members of the National Payments Interface, and whoever they bring with them. The rules set the boundary plainly: "Direct membership of NPI shall be open to all Banks and Financial Institutions (BFIs) operating in Nepal or any other entity at the discretion of NRB. Indirect and Technical membership shall be open to non-bank financial institutions and large institutions or corporates that are allowed to originate specific purpose based transactions."

A shop, a gym, a SaaS company, or an ISP is none of those. In the rules they are a Creditor or Service Provider, defined as "the creditors or merchants acquired by the members." So the path runs through a bank or a licensed payment service provider that has already built e-Mandate into its own channel, and NCHL's own instruction for getting started is a contact address rather than a portal. That is the difference between a scheme existing and a capability being available: the MetLife deployment took an insurer, a bank, and a bespoke NPI integration, and was reported as a first for its sector.

It is also why the products built on mandate rails elsewhere do not port. Stripe Billing assumes a card it can charge again. GoCardless assumes a bank mandate the merchant itself holds. Neither assumption survives here, and no aggregator, APINepal included, can add a capability the rail beneath it does not have.

What is the difference between auto-debit and deducting a pre-funded balance?

The difference is when the money moves, not how automatic the billing feels. A mandate defers the movement: the customer grants authority today so a payee can reach into their account on a future date. That is why it needs a rail, why it needs a token, why it expires, and why it can be cancelled from either side.

A pre-funded balance moves the money first. The customer pays once through eSewa, Khalti, IME Pay, or a bank transfer, and that payment settles like any other single payment on those rails. What happens on the renewal date is bookkeeping against funds already held. Nothing is re-authorized, nothing leaves the system, and nothing can decline. The failure mode moves too: a short balance is visible before the renewal, where a failed debit is only visible after.

Which Nepali payment rails can schedule an unattended charge?

One scheme can, and it is not open to merchants. None of the consumer rails can, on a merchant's instruction. Each row below was checked against that rail's own public pages in August 2026, or against the regulator's own directives where the rail publishes nothing.

eSewa has scheduled payments. Is that not auto-debit?

It really does deduct without anyone tapping, and it still cannot bill your customers. eSewa's own walkthrough is unambiguous about the automation: choose MONTHLY and "your bills shall be paid automatically for the Payment Count you have set. For example: If you set the Payment Count as 7, your bills shall be paid automatically for the upcoming 7 months." The terms have the customer agreeing "to provide debit authority of their eSewa account for the scheduled payment lists," and to their linked bank account as a fallback if the wallet is short.

The limits are who owns it and what it can pay. The customer sets it up in their own eSewa app, sets the date, time and frequency, and confirms with their MPIN. The terms say the feature "is only available in limited services which have been listed in recommended products," and eSewa lists seven: electricity, KUKL water, community water, mobile top-up, Worldlink and Vianet, Dish Home and Mero TV, and credit cards. A merchant cannot create one, read one, cancel one, or join that list by asking, and no API touches any part of it.

Two eSewa features are easy to misread here. The one named direct debit lets a customer pay from a linked bank account in one step at checkout instead of loading the wallet first, which is a shortcut through the top-up rather than a mandate. And eSewa's Token is not card-on-file tokenization: the merchant generates the token and the customer types it into eSewa, so it runs the opposite way to a stored credential. Rail-level detail lives on eSewa recurring payments and Khalti recurring payments.

Why does deducting a pre-funded balance need no mandate rail?

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. The wallet is Trile's, not eSewa's or Khalti's, and that is the whole reason the model works. A mandate exists to let money cross an institutional boundary later. A wallet deduction crosses no boundary, because the crossing already happened at top-up and Trile verified it against the provider's own status check before crediting the ledger.

What is left on the renewal date is arithmetic that has to be exact. Amounts are integer paisa held as strings, so NPR 499.00 is 49900 and no float ever touches it. The wallet ledger is append-only, the balance is the sum of its entries, and the two are reconciled daily. Every write carries an Idempotency-Key, so a retried debit returns the stored response instead of charging twice. The Trile docs put the renewal itself in one line: "Each renewal, the billing engine deducts the next cycle from the wallet and generates an invoice."

Is SUQO right that auto-debit is not available in Nepal?

Right about the practical situation, imprecise about the reason. On their recurring payments page SUQO writes "Auto-debit isn't available in Nepal yet. Banking infrastructure hasn't opened that up," and adds that "When auto-debit arrives in Nepal, SUQO will have it first." The first sentence describes what a business shopping for auto-debit actually finds. The second half of it is where the record differs: the infrastructure was specified in 2021, approved by Nepal Rastra Bank, and is carrying live recurring collections. It opened to members, not to merchants.

Their collection model follows from the same constraint either way. An SMS reminder goes out before the renewal date carrying a payment link, and the customer taps it and pays through eSewa, Khalti, or connectIPS. Their own FAQ defines the thing they lack as pulling "the payment from the customer's wallet automatically without any action from them."

Read that definition closely, because the difference is one word: whose. SUQO means pulling from the customer's own eSewa or Khalti balance, and Trile cannot do that any more than SUQO can. Nobody can. What Trile debits is a Trile-held wallet the customer pre-funded. The missing pull rail is not solved here, it is stepped around, by holding the balance rather than reaching for someone else's.

Once you accept that, the argument stops being about banks. Nothing is pulled from anywhere on the renewal date, so no rail has to open first. The question is whether a mandate is the only way to bill without a person acting every cycle, and it is not, if the money is already on your side of the line. The caveat is real and applies to every prepaid model: this moves the customer's action from every cycle to every top-up. It does not delete it.

What does the customer actually have to do, and how often?

Nothing on the renewal date, if the balance covers the invoice. The customer's work is funding the wallet, and they choose when. One top-up can carry several cycles, which is the part a reminder-and-link model cannot offer, because there the action is once per cycle and it lands on the biller's schedule rather than the customer's.

That is the real trade. A mandate asks for one action ever and then nothing. A reminder asks for one action per cycle. A pre-funded wallet sits between them: fewer actions than a reminder, more than a mandate, and unlike a mandate it is available to a business that is not a bank. The full cycle, top-up through invoice, is on how recurring payments work in Nepal.

What happens if the balance is short on the renewal date?

The invoice stays open, the subscription moves to past_due, and an invoice.payment_failed webhook fires. When the customer tops up, Trile retries and the subscription returns to active. The docs are direct about treating this as ordinary: customers in a prepaid model routinely let balances run low, so past_due is a recoverable state to design around rather than an error to alarm on. The first cycle behaves differently, because it charges at subscription creation and fails outright if the wallet cannot cover it.

Is deducting from a wallet allowed under Nepal Rastra Bank rules?

Trile is built to operate within Nepal Rastra Bank rules. KYC-tiered wallet caps, and data localized in Nepal. Each customer's wallet has a maximum balance tied to their KYC tier, and the cap is read from the API as cap_paisa rather than hard-coded into your integration, because the policy behind it is set by NRB and can change. A customer raises their ceiling by completing a higher tier. One consequence worth planning for is that a customer on a low tier may not be able to hold enough to cover an expensive plan's first cycle, so route them through KYC before the subscribe step rather than after.

What changes if e-Mandate opens up to ordinary merchants?

Less than the anticipation around it suggests. The instrument is already written down and already running, so the missing piece is a member bank or payment service provider exposing it with documentation and a signup. If that lands, an e-Mandate becomes another way to fund a wallet, sitting beside eSewa, Khalti, IME Pay, and bank transfer, and the customer stops having to remember. It does not replace the ledger.

Everything above the funding step stays where it is. Invoices still have to be generated on the right cycle boundary, proration still has to be right to the paisa, retries still have to be idempotent, and past_due still has to recover cleanly. A mandate makes funding more reliable. It does not do billing for you, and the rules leave the payer's bank free to ask for an OTP anyway. What the billing layer has to get right is set out in the subscription billing API for Nepal.