Nothing is half-saved
A payment and the event that announces it are written in the same database transaction. Either both exist or neither does, so a crash cannot lose a webhook.
How we handle money, keys and data
Plain answers to the questions a careful business owner should ask before letting anyone near their payments. Everything here describes how the software works today; we do not claim certifications or audits we have not done.
The money goes from your customer to you
We are not in the middle of the money. We are in the middle of the information about it.
When a customer pays Rs 1,500 with eSewa, that Rs 1,500 lands in your eSewa merchant account. eSewa settles it to your bank on whatever schedule and fees you agreed with them. We receive the proof of payment so we can tell your system the order is paid.
That is why the dashboard shows verified payments, not a balance. To check what actually reached your bank, upload the provider's settlement file under Reconciliation.
- CustomerPays in the eSewa, Khalti or banking app they already use
- eSewa, Khalti or FonepayTakes the payment on your merchant account
- Your merchant accountReceives the money and settles it to your bank
- PaymentsnpGets the proof, never the funds
What we protect, and how
| Area | What it covers | How it is protected |
|---|---|---|
| Gateway credentials | Your eSewa, Khalti and Fonepay secret keys | Encrypted with AES-256-GCM and tied to your workspace and the exact connection. The key lives outside the database. They are never sent back to a browser, written to logs or shown to Paymentsnp staff. Every save creates a new version, and a payment in progress keeps the version it started with. |
| API keys | The np_test_ and np_live_ keys your server uses | Shown once, then stored only as a hash. Each key has its own scopes, and can have an expiry date, an IP allowlist and a rate limit. Rolling a key gives the old one a grace period of an hour, a day or a week. Test keys can never see live data. |
| Dashboard sign-in | Your team's sessions | httpOnly cookies with CSRF protection, email verification before first sign-in, and a list of signed-in devices you can sign out remotely. Roles are checked again on every request. |
| Your business data | Orders, customers, payments | Each workspace is isolated in the database itself with row-level security, not only in application code. Test and live records are kept apart. |
| Webhooks | Events we send to your server | Signed with HMAC-SHA256 over a timestamp and the raw body. We only deliver to public HTTPS addresses on ports 443 or 8443, check the address again before every attempt, and never follow redirects. |
| Changes | Who did what | Credential saves, API key changes, team changes and settings changes go to an audit log with the person, the action and the time. |
A screenshot is not a payment
Neither is a customer landing on your thank-you page. Return links can be opened by anyone. We only mark an order paid when the provider itself confirms the payment for the right merchant, the right order and the exact amount.
When a payment is unclear
Networks drop and providers time out. Each payment attempt is in one of these states, and we never guess our way to ‘paid’.
- Succeeded
- The provider confirmed the payment for the exact amount. The order is paid and your webhook is sent.
- Pending
- The customer is on the provider's page, or the provider says it is still processing. We keep checking.
- Unknown
- The provider did not answer clearly, for example a timeout. Treated as possibly paid: no second payment can start until it is resolved.
- Failed
- The provider clearly said no. The customer can try again.
- Expired
- Nobody finished the payment within 30 minutes. If eSewa or Khalti later report it was paid after all, we still record it.
If something goes wrong on our side
Webhooks retry
If your server is down, we retry with growing gaps for up to 8 attempts and you can replay any event from the dashboard. A failed webhook never changes the payment itself.
Late payments still count
A background job re-checks unfinished eSewa and Khalti payments. If one succeeds after the checkout expired, it is recorded and your webhook is sent.
One honest limit: Fonepay has no status lookup, so a Fonepay payment where the customer never returns to the checkout cannot be confirmed by us. Check your Fonepay merchant panel for those. More about Fonepay
Trust questions
Does Paymentsnp collect customer wallet passwords or OTPs?
No. Customers sign in and approve payments on the provider's own pages. Paymentsnp never asks for wallet credentials.
Is Paymentsnp certified or independently audited?
No certification or audit is claimed on this site. The controls described here are implemented in the platform; provider approval and UAT are completed per merchant before live payments.
Can Paymentsnp staff see my gateway secrets?
No. Platform administrators can see operational data such as payment records to help with support, but secrets are never returned to any screen, including ours.
What happens if a payment succeeds after expiry?
Expiry stops new attempts but is not proof that no money moved. If the provider later confirms the payment, it is still recorded and your webhook is sent.