How do recurring payments work in Nepal?

Why can a Nepali business not save a card and charge it every month?

There is no card-on-file rail for domestic recurring charges in Nepal. Nepali banks do not offer Variable Recurring Payments, and the public developer documentation for eSewa and Khalti, read in August 2026, covers one-time checkout, mobile SDKs, refunds, and status lookups, with no merchant-initiated scheduled charge anywhere in it. Trile's documentation says the same of Fonepay. So the pattern Stripe made ordinary elsewhere, store a card once and pull from it on a schedule, has nothing to attach to here.

Trile is subscription-billing infrastructure for Nepal, and it inverts the direction of the money instead of waiting for that rail to arrive. The customer pre-funds a wallet and Trile deducts each cycle from that balance.

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.

Whether any Nepali rail can pull without the customer acting is a separate question, answered on is auto-debit possible in Nepal.

What are the ways to collect a recurring payment in Nepal?

Five, and only three of them are practical for a software business today. You can send a reminder with a payment link every cycle and wait for the customer to tap it. You can hold a prepaid balance and deduct from it. You can arrange a bank mandate through a member bank. You can collect manually in cash or by bank transfer. Or you can store a card, which no Nepali rail supports. The differences that matter are who has to act on billing day and what happens when the money is not there.

How does a reminder and payment link subscription work?

The biller sends the customer a payment link at each renewal date, and the customer taps it and pays through their own eSewa or Khalti account. SUQO, which currently holds the featured snippet for this query, runs exactly this model and is candid about why: "Auto-debit isn't available in Nepal yet. Banking infrastructure hasn't opened that up." Its page calls the result "Reminder-driven collection. Fully structured." and adds, "When auto-debit arrives in Nepal, SUQO will have it first."

That is a fair description of what an SMS-and-link layer can automate on top of eSewa, Khalti, and ConnectIPS. The billing calendar, the reminder schedule, the overdue list, and the dashboard all run themselves. One step does not: the payment. Collection rate becomes a function of how many customers open a message and finish a checkout, every cycle, forever.

How does a wallet deduction subscription work?

The customer funds a balance once, and each cycle Trile moves money from that balance to an invoice inside its own ledger. No provider is contacted on billing day, so there is no checkout to abandon and nothing that can decline. The authorization happened earlier, at top-up and subscribe time.

The object model is small. A Product has one or more Prices, each a recurring amount and interval. A Customer owns a Wallet. A Subscription binds a Customer to a Price and generates an Invoice every cycle, paid from the Wallet. Balances and amounts are integer paisa held as strings, never floats, so NPR 499.00 is the string 49900 in every request and every ledger row.

नवीकरणको दिन ग्राहकले केही गर्नु पर्दैन। पैसा पहिले नै वालेटमा हुन्छ, र त्यहीँबाट कटौती हुन्छ।

How does a customer put money into the wallet?

Through eSewa, Khalti, IME Pay, or a bank transfer. A top-up creates a pending record and hands the customer off to the provider. The customer pays there. When the provider redirects back, Trile verifies the result server-side against the provider's own status API and only then credits the wallet ledger and clears the pending amount. The redirect alone is never trusted, because a redirect is a browser event and a browser event is not a settlement. On the eSewa side this is an ordinary one-time payment, which is covered on can eSewa do recurring payments.

Wallet caps come from Nepal Rastra Bank rules and attach to the customer's KYC tier, so the ceiling is per customer rather than per merchant. A top-up that would push the balance past the cap is rejected with wallet_cap_exceeded. Read the cap from the balance response instead of hard-coding a number, since the tiers are policy, not product.

What happens on the renewal date?

A scheduled billing tick fires, a worker generates an open invoice for the cycle amount, and it attempts to debit the wallet for that amount. If the balance covers it, the invoice becomes paid, the ledger records the debit, and an invoice.paid event and webhook fire. Nobody is contacted. Nobody taps anything.

The first cycle is the exception: it charges synchronously when the subscription is created, which is why creating a subscription against an underfunded wallet returns insufficient_funds rather than creating a subscription that is immediately behind. Trials shift that first charge to the end of the trial and the subscription starts in trialing. Everything after the first cycle runs asynchronously in the worker, so your integration should react to events rather than poll.

What happens when the balance does not cover the cycle?

The invoice stays open, the subscription moves to past_due, and invoice.payment_failed fires. Notice what does not happen: nothing is declined, because no external party was asked for anything. There is no issuer response, no gateway error, and no soft-decline taxonomy to interpret. The cycle is unfunded, which is a much simpler fact to act on than a card decline code.

On your side the webhook is the whole integration. You receive invoice.payment_failed, you decide whether an account in past_due keeps access, and you prompt the customer to top up. Trile keeps the invoice open and retries against the balance, so scheduling the next attempt is not your problem.

How does a past_due subscription recover?

The customer tops up, Trile retries the debit, and the subscription returns to active with the invoice marked paid. That is the whole recovery path. The Trile docs are explicit that past_due should be treated as normal rather than as an error, because in a prepaid model customers let balances run low the same way they let a phone balance run low.

This is the practical reason the model is worth the extra concept. A reminder-driven cycle needs the customer to complete a full checkout on the renewal date or the month is lost. A wallet-driven cycle needs the customer to have money in an account, at some point, in any amount, from any of four funding routes. The recovery window is the whole month rather than the hours after a message lands.

What record does each billing cycle leave?

One invoice, one pair of ledger entries, and an append-only event. Every invoice carries its own timeline you can read back, and the account-wide event log records what happened to every object with a permanent identifier such as evt_01ARZ3NDEKTSV4RRFFQ69G5FAW. Wallet balances are reconciled against the sum of the ledger daily, so a drift between the two is caught rather than discovered.

That matters more in a prepaid model than in a card model. When you hold customer money, the balance is a liability you have to be able to prove at any moment, so the ledger is append-only and corrections are new entries rather than edits. The mechanics of idempotency keys, signed webhooks, and replay are covered on is there a subscription billing API for Nepal.

Is there a bank mandate that could pull the money instead?

On paper, yes. Nepal Clearing House Limited describes NEPALPAY Request, part of its Retail Payment Switch, as supporting "recurring e-Mandate payments for a specified frequency and time period, whereby on due date the standing instruction amount will be debited from the payer and credited to payee." NCHL-IPS separately supports mandate-based direct debit collection for purposes like insurance premiums and loan installments.

What that does not yet give a software business is a self-serve merchant API. The NEPALPAY Request flow NCHL documents for end users today runs through the ConnectIPS web interface, with the payer logging in and approving each request, capped at NPR 1,00,000 per transaction and NPR 2,00,000 per day. Reaching the mandate side means an arrangement with a member bank or payment service provider. The detail sits on is auto-debit possible in Nepal.

Which collection model fits which business?

Reminder-driven collection fits a business whose customers already expect a monthly nudge and whose ticket sizes are large enough that a few hours of follow-up per cycle is cheap. Gyms, coaching centers, and insurance agents sit here comfortably, which is why SUQO aims at them. If your billing volume is a few hundred customers and somebody already owns the collections job, a link in an SMS is a reasonable answer.

Wallet deduction fits software. If you are billing NPR 499 a month across thousands of accounts, per-cycle human involvement is the cost that kills you, and access has to be granted or revoked by a webhook rather than by someone reading a dashboard. The trade is honest: you are asking customers to hold a balance, which is a real ask and needs a good top-up experience. In exchange, billing day stops being an event.

What does recurring billing in Nepal actually cost?

Trile has not published pricing, and no figure appears on this page for that reason. The costs worth modeling before you choose anything are the ones that scale with your customer count. Under a reminder model those are the SMS per cycle, the wallet or gateway fee on each collection, and the staff hours spent on customers who did not tap. Under a wallet model they are the top-up fee and whatever you spend making top-ups painless.

The number nobody quotes is the one that decides it: what share of cycles collect without a person. Trile is subscription-billing infrastructure for Nepal, and because no card-on-file rail exists here, the customer pre-funds a wallet and Trile deducts each cycle from that balance. That design exists to push the unattended share as close to all of them as a country without a pull rail allows. Stripe and Chargebee solve the same problem elsewhere by holding a card; here the balance is the card.