A dashboard for checkout, payment links, invoices, receipts and the reports your accountant asks for. It works the same for a one-person shop and a team of twenty.
The page your customer lands on. It shows your business, the amount and the methods you have switched on, then hands the customer to eSewa, Khalti or Fonepay to pay.
| Methods shown | Only connections that are ready and enabled, per test or live |
|---|---|
| Branding | Your display name, logo and accent colour |
| Language | English or Nepali, switched by the customer |
| Opening it | Full-page redirect, or a popup over your site with checkout.js |
| Your own domain | Serve checkout on a domain you verify with a DNS record |
| Expiry | A checkout link lasts one hour; a new one is a click away |
For the shop without a website, or the customer who just needs to pay a balance. Make a link, send it on Viber or by SMS, and see it paid in the dashboard.
| Amount | Fixed (say Rs 2,450) or typed in by the customer |
|---|---|
| Expiry | Anywhere from 1 to 365 days, or switch it off by hand |
| Receipt contact | Customers can leave a phone or email for their receipt |
| Methods | Khalti is left out on amounts under Rs 10, its minimum |
Write a proper invoice, send it, and let the customer pay it online. Every checkout payment also gets its own numbered receipt automatically.
| Line items | Up to 100 lines with quantity and price, in rupees and paisa |
|---|---|
| Tax | 13% VAT per line, shown as a tax invoice when VAT is on |
| Numbering | INV-2026-0001 style, counted separately for each workspace |
| Sending | Email with the PDF and a pay button, plus a short SMS notice if you want one |
| Reminders | Up to three: before the due date, on it, then weekly while overdue |
| Paid in cash? | Mark it paid with a note; the PDF says so |
Gentle nudges for unpaid orders, and the occasional offer to your customers. Anyone who unsubscribes is never messaged again.
| Order reminders | Up to two per unpaid order: an email with a fresh checkout link, and a short SMS |
|---|---|
| Daily digest | A morning summary of unpaid orders for owners and administrators |
| Who can get offers | Your customers who have not opted out; consent is tracked per channel |
| Unsubscribing | A one-click unsubscribe link in every email; it covers that contact for good |
| Limits | Daily sending caps per workspace; SMS campaigns are switched on by request |
The numbers are verified payments only. Nothing in the dashboard is a balance, because we never hold one. Finance can export what they need and check it against what actually reached the bank.
| Overview | Volume, conversion and failed attempts for any Nepal-time date range |
|---|---|
| Exports | CSV of payments, checkouts and customers, opens cleanly in Excel |
| Settlement upload | Your provider or bank CSV, with BS dates, lakh commas and Nepali digits understood |
| Matching | Each settlement row comes back matched, missing or a different amount |
| Stuck payments | A list of checkouts still waiting on a provider, with a re-check button |
Give each person the access their job needs. Every change to keys, credentials and settings is written to an audit log with who did it and when.
| Owner | Everything, including team members and archiving the workspace |
|---|---|
| Administrator | Gateway credentials, API keys, webhooks, branding and settings |
| Developer | Sees API keys and webhook deliveries, sends test webhooks, re-checks stuck payments |
| Finance | Payments, invoices, exports and reconciliation |
Paymentsnp handles the payment step. Your cart, stock, bookings and delivery stay in the system you already use.
Your store owns the cart and shipping. We take care of the payment and send your server a verified result for that order. If the customer closes the browser after paying, the payment is still checked and recorded.
Install the WooCommerce plugin, or call the API from your own code. Use the order number as the idempotency key so nothing is fulfilled twice.
Your backend creates the checkout and your app opens the link. The amount is set on your server, so nobody can change it in the browser.
The same webhook arrives whether the customer paid with eSewa, Khalti or Fonepay, so your app needs one handler, not three.
Tie each payment to an invoice. The WHMCS module pays hosting invoices; schools and agencies can send invoices or payment links straight from the dashboard.
Recurring billing and automatic wallet debits are not supported. Each payment is made by the customer.
A few limits, so nothing surprises you later.
No. Each method needs approved merchant access and credentials from that provider. Signing up with Paymentsnp and onboarding with a provider are separate steps.
No. It shows verified payments. Bank settlement, fees and available balances stay with your provider. Upload their settlement file in Reconciliation to compare.
Only ready, enabled connections appear at checkout. If a provider call fails or times out, the attempt is marked unknown, not failed, and it is never reported as paid until the provider confirms it.
Yes. One login can belong to several workspaces, each with its own gateways, keys, branding and records. Switch between them from the sidebar.