Skip to main content
PayBridgeNP records the provider fee on every successful payment so you can see exactly how much each provider charges, broken down by provider, on your dashboard. Each provider exposes fee information differently - here’s how each one works.

​
At a glance

​
Khalti

Khalti returns the per-transaction fee in its lookup response. We read it on every successful payment and persist it to the payment row. No merchant configuration needed.

​
eSewa

eSewa does not expose per-transaction fees on its API. To track fees for eSewa, you tell PayBridgeNP what rate you have negotiated with eSewa, and we compute the fee at payment time.

​
Set your rate

  1. Go to Providers in the dashboard
  2. Find the eSewa card
  3. Type your negotiated rate (in percent) into the Provider fee input
  4. Click Save
The default is 1.5% - a reasonable public-rate fallback. If your real rate is different, set it before relying on the fee numbers.

​
How it’s computed

For each successful eSewa payment:
Where fee_bps is your saved rate in basis points (150 = 1.50%), saved with your eSewa provider settings. The rate at the time of payment is snapshotted into payment.metadata.esewa_fee_bps so historical totals stay correct even after you change the rate later.

​
Fonepay

Fonepay’s published schedule is Rs 0 per transaction on merchant QR, and the overwhelming majority of Fonepay payments really are free. Not all of them. Two things we have measured do carry a charge:
  • Instant settlement. If you switch settlement from the free multi-session schedule to instant, Fonepay charges Rs 5 per settlement - their published price, which we have also confirmed in our own settlement data. It arrives as a network fee on the settlement report.
  • Card-funded QR payments. Some banks let a card sit behind a Fonepay QR scan, and those carry a percentage. We have seen 0.60% on one.
Either way the figure reaches us on the settlement report after the payment, not at checkout, which is why the dashboard reports it per payment instead of assuming a rate. In our own production data a small number of live Fonepay payments carry a real charge, the largest being NPR 49.20 on a single NPR 8,200.00 payment, which is 0.60%. The fee is not known when the payment succeeds. It comes from Fonepay’s settlement report, which lands afterwards, so the dashboard shows a Fonepay fee as unknown until that report arrives rather than showing it as zero. An unreported fee and a reported zero look different on purpose.

​
Where you see it

  • Dashboard home - a “Provider fees” KPI card next to Volume, Payments, and Success rate, plus the period’s effective rate.
  • Provider breakdown - fee total and effective rate per provider on the dashboard home.
  • Payments list - a Fee column on every payment row.
  • Payment detail - a Provider fee line, with your eSewa rate shown as a tooltip.
  • CSV export - a Provider Fee (NPR) column on the Payments export.

​
API access

If you consume payment data via the API (or webhooks), the fee surfaces on payment.metadata with stable keys: Refunded payments DO contribute to fee totals. When a payment is fully refunded its status flips to refunded, but the provider took its fee at capture and a refund does not give it back, so the charge stays in your totals. For Fonepay this is directly observable: the fee was already deducted from the bank deposit recorded on the settlement report, and refunding the buyer does not rewrite that report. This changed on 2026-08-12. The dashboard home previously excluded refunded payments from its fee total while the reconciliation statement included them, so the two pages reported different fees for the same period whenever a refund fell inside it.

​
Caveats

  • Fee tracking started on 2026-04-29. Payments before that contribute 0 to fee totals - they were not captured at write time.
  • The eSewa fee is only as accurate as the rate you save. If you renegotiate with eSewa, update the rate on the Providers page so your dashboard reflects reality going forward.
  • Partial refunds are not counted against fees in aggregate (PayBridgeNP does not track partial refunds in its payment status enum). If you issue many partial refunds, your dashboard fee total will slightly overstate what the provider actually kept.
  • Periods run on UTC days, which start at 05:45 Nepal time. “Last 30 days” on the dashboard home and on Reconciliation both mean 30 whole UTC days, and the two agree with each other exactly. But if you are checking a calendar month against a provider statement kept in Nepal time, the window is shifted at both ends: it begins 05:45 on your first day and runs to 05:44 on the day after your last. For a month that is usually a handful of early-morning payments moving between periods. If the totals must tie out to the rupee, compare against the payment timestamps in the CSV export rather than the period totals.