Payment providers in Nepal: from checkout to usable NPR

Nine records provide questions, not a ready-made shortlist

The collection/payout split matters because the two directions solve different jobs. A merchant needs evidence that a sale can be accepted for its business model; a payout operation also needs an authorised funding account, eligible recipients and a way to resolve individual failures.

We do not publish actual fee averages or settlement-speed statistics for this small Nepal sample. The recorded settlement models need further qualification, and an average would conceal that unresolved question. A numeric field in a catalogue is not evidence of a lawful, currently available arrangement. Individual rates and private provider details stay out of this material.

Use the records as a research starting point. Before comparing price, establish the contracting entity, authorised product, merchant requirements, settlement account and permitted flow of funds. A collection record does not prove that a matching payout operation exists; separate country, currency and method associations do not verify every combination.

Price the basket your customers actually buy

A smaller percentage can cost more on a small payment when a fixed charge is added. Consider two invented tariffs used only to explain the arithmetic: model A charges 2%; model B charges 1.5% plus NPR 10 per successful payment. Neither is a PayStar quote, a Nepal market benchmark or a term from the private records.

The break-even value is NPR 2,000: 10 ÷ (0.02 − 0.015). Below it, model A has the lower transaction charge; above it, model B does. This comparison holds only for the invented components shown. Refund fees, failed-attempt charges, minimum billing, tax, currency conversion and settlement charges could change the result.

Build a comparison with your own ticket distribution, not just one average basket. Ask each provider to price the same successful-payment volume and the same assumed refund and failure volumes. Record which event is billable. A charge per attempt is not directly comparable with a charge only after a successful payment.

A debit notification is not your complete order record

The official connectIPS FAQ distinguishes a successful debit followed by failed credit from a successful debit followed by a credit timeout. Its guidance describes bank reconciliation followed by a refund or beneficiary credit, depending on the state. That distinction is why a debit screenshot alone cannot resolve every merchant exception. See the connectIPS transaction FAQ.

For a merchant implementation, define what evidence closes the order: the selected provider's authoritative result, the transaction reference, amount, currency and your own order identifier. This is an operational recommendation, not a claim that every local product exposes the same API fields.

Agree a pending-state policy before launch. It should say who investigates an unresolved payment, how long an order is reserved, what the customer sees, and how the final outcome is matched to the original order. A customer retry and a delayed success can otherwise look like two unrelated events. Avoid both premature fulfilment and automatically charging again while the first result remains unknown.

Conversion measurement should follow the same discipline. The catalogue contains no comparable measured conversion rate. Define the denominator, observation window and handling of pending, duplicate and reversed transactions before comparing providers. A shorter checkout and a higher recorded success rate are different claims; neither can be inferred from a list of methods.

Choose QR around enrolment and reconciliation

NCHL describes static and dynamic NEPALPAY QR, including integration with billing and acquiring systems. Its product page directs merchants to their bank for enrolment; dynamic integration also requires a specific enquiry. These are product capabilities and onboarding steps, not confirmation that your company or any catalogue record is eligible. See NCHL's NEPALPAY QR overview.

The commercial question is what your operation needs to reconcile. For an online order, ask whether the integration associates an amount and order reference with the payment request and what evidence returns after payment. For an attended sale, establish how staff confirm receipt and how the day's transactions reconcile to the business account.

NCHL's FAQ also describes merchant transaction access through a portal or app after enrolment. Ask for a demonstration using your actual workflow: finding an unmatched order, exporting an end-of-day report and tracing a correction. See the NEPALPAY QR section of the NCHL FAQ. The recommendation to test these tasks is ours; a portal alone does not prove that every report or automation you need is included.

Separate available funds from the payout promise

Fast customer payment does not by itself establish when proceeds become available to your business or whether they can fund a payout. Write down the account receiving settlement, the release schedule, reserves, deductions and reconciliation process. Treat any timing label as a contractual condition to confirm, not measured speed.

Here is a second hypothetical example, in NPR throughout. Start with NPR 100,000 in gross collections. Deduct NPR 2,000 in fees, NPR 5,000 reserved and NPR 20,000 not yet released. The available amount is NPR 73,000. If NPR 80,000 in payouts is due, the funding gap is NPR 7,000. The example is not a Nepal reserve requirement, actual tariff or observed settlement performance.

A daily balance view should separate gross receipts, available cash and committed payouts. Ask whether collections and payouts share a balance or require separately funded accounts, when top-ups become usable, and how a failed payout changes the available amount. Do not assume the answer from a collection method's brand name.

For local context, NCHL describes CORPORATEPAY as a business platform for individual and bulk payments from linked bank accounts, using different payment systems. Enrolment is completed with the bank under its document requirements. See NCHL's CORPORATEPAY overview. This is a separate business-payment use case, not evidence that a checkout agreement includes bulk payouts.

When reviewing an actual payout proposal, require a result for each recipient. An accepted file or batch is not sufficient evidence that every recipient received funds. Agree beneficiary checks, rejection handling, duplicate protection and the evidence needed before retrying a failed or unresolved item.

Qualify the entity, activity and money flow

Nepal Rastra Bank's Payment Systems Department licenses and supervises payment system operators and payment service providers. Start with the department's official information and the licensed-institutions section linked there. The directory was checked on 14 October 2026; its July 2026 list entry was visible, but the individual list page returned an access error, so this review does not reverify any provider's licence. Presence on a list is not blanket authorisation for every merchant activity or settlement arrangement.

The NRB's cryptocurrency FAQ states that cryptocurrency transactions are illegal in Nepal. This article does not offer a cryptocurrency or stablecoin settlement route. Historical catalogue descriptions do not override local restrictions; a proposed funding or settlement model must be qualified before commercial discussion proceeds.

For a real proposal, obtain written confirmation of the merchant entity and business activity accepted, the authorised product, recipient types, accounts and settlement currency. If the company, customer, beneficiary or money flow crosses borders, ask the selected institution and qualified advisers to confirm the applicable permissions, foreign-exchange requirements and documents. A domestic NPR payment capability is not proof of unrestricted cross-border settlement.

PayStar works on lawful business use cases with appropriately authorised providers. Product restrictions, licensing and party checks are part of qualification. This is a practical comparison guide, not a legal conclusion that your specific activity is permitted; material unresolved questions must be settled before launch.

PayStar's role

PayStar provides informational and technical services. It is not a bank or payment service provider, does not arrange payment acceptance or settlement in its own name, and does not receive, hold or settle customer or business funds.

The merchant chooses the payment service provider and contracts with it directly. That provider is responsible for its payment services and settlement under its own agreement. PayStar Discovery can help organise the requirements and comparison; any API integration, routing or monitoring support is a separately agreed technical scope. PayStar does not guarantee provider approval, availability, conversion or settlement outcomes.

Get details on payment options in Nepal

Send your business activity, country of incorporation, expected NPR ticket sizes and monthly volume, collection and payout needs, and intended settlement account and currency. Include how you fulfil orders and investigate payments that remain unresolved. These details make the comparison more useful than a request for the lowest percentage alone.

Anastasia can provide free information about options to investigate for lawful activity through Telegram or email. PayStar Discovery helps structure the next questions. Current availability, eligibility and full pricing require separate confirmation with the selected provider. Free information does not make integration or payment processing free.

About the data and sources

The commercial snapshot is dated 14 September 2026. Gateway statements have not been independently verified by PayStar; terms can change weekly or more often. Counts refer to unique Nepal-only catalogue records and do not establish live methods, independent providers or approved routes. Actual fee and settlement statistics are withheld; both economic examples are hypothetical. No measured conversion average is available. Official local sources were checked on 14 October 2026; mutable rules and product conditions must be checked again before publication or onboarding. Private identities and individual terms are not included.