Recurring payments in Nepal when almost nobody has a card on file

Subscription billing in most markets rests on a card stored on file and charged every month. In Nepal that foundation is thin: domestic cards are rarely used online, and international “dollar cards” are prepaid and capped — NPR cards for individuals carry a USD 500-per-year limit set by Nepal Rastra Bank (raised in April 2026 only for IT businesses, to USD 3,000–5,000). You cannot build a SaaS on that.

Pattern 1 — invoice link + reminders

On the renewal date, issue the invoice and email a payment link that opens the hosted checkout with every rail. Send reminders before and after the due date. Most Nepali B2B subscriptions already run this way informally; the difference is doing it from the billing system so the payment reconciles to the invoice automatically and `invoice.paid` tells your app to keep the lights on.

Pattern 2 — prepaid wallets

Let the customer top up a balance and draw renewals and usage from it. It turns a collection problem into a top-up problem, works for every rail, and gives you low-balance alerts and hard spend limits for free. It suits usage-heavy products — AI, APIs, infrastructure — especially well.

Pattern 3 — e-mandates on connectIPS

NCHL's Retail Payment Switch supports recurring e-mandates under NEPALPAY Request: a payer authorises a standing debit for a frequency and period, and the amount moves on the due date. Mutual-fund SIPs already use it. Merchant tooling is still maturing, so treat it as the direction of travel rather than today's default.

Cards, where they fit

Foreign customers, and the growing number of Nepali IT firms with higher card limits, can be auto-charged through Stripe. Offer it; don't depend on it.

How Tola Pay models this

Each subscription has a collection method — `auto_charge` where the rail allows it, `invoice_link`, or `wallet` — so one plan can renew three different ways for three different customers, and every path ends in the same paid invoice and webhook.