Security

• Email-verified merchant accounts. New signups must confirm their address before issuing live API keys.
• Multiple sign-in methods on the merchant dashboard: email + password, Continue with Google (OAuth 2.0 + PKCE), or device-bound passkey (WebAuthn). Merchants can register a passkey from the dashboard settings.
• Optional TOTP-based two-factor authentication for password sign-in.
• Step-up authentication on sensitive operations (API key creation, passkey deletion, team-member changes, data exports). The dashboard re-prompts for a fresh credential (password, TOTP, or passkey) shortly before the action is honoured.
• Active sessions in the dashboard settings - every signed-in browser is enumerated with user-agent, IP, last-seen, and sign-in method. Revoke any session or sign out everywhere with one click.
• Separate JWT signing secrets for merchant authentication and internal staff authentication. A leaked merchant token cannot be used to access internal surfaces.
• Short-lived access tokens held in browser memory only. A separate HttpOnly refresh cookie (pb_refresh, SameSite=Strict) rotates them and is revoked immediately on sign-out.
• API key + publishable key separation. Secret keys (sk_live_, sk_test_) authenticate server-side calls; publishable keys (pk_live_, pk_test_) are safe to expose in client-side code.
• Scoped MCP tokens with explicit read / write permissions; revocation is immediate from the dashboard.

PayBridgeNP is a multi-tenant platform. Merchant data isolation is enforced at the database layer, not just at the application layer.

• Postgres row-level security (RLS) on the multi-tenant tables that hold merchant data. Every database transaction sets a tenant context (the merchant ID) before queries run, so rows belonging to other merchants are not returned from those tables.
• Project-level separation between live and sandbox environments within a single merchant account. Sandbox API keys cannot read live data and vice versa.
• Internal staff actions run on a separate authentication track with their own audit log and explicit reason capture for sensitive operations.

• In transit - TLS 1.2+ on all public endpoints (api.paybridgenp.com, dashboard.paybridgenp.com, paybridgenp.com, cdn.paybridgenp.com, docs.paybridgenp.com).
• At rest - provider credentials - eSewa, Khalti, and Fonepay credentials stored in the database are encrypted with AES-GCM using a key held only in the application's runtime environment, not in source control.
• At rest - passwords - Argon2id with per-password salt. Plaintext is never stored.
• At rest - webhook signing secrets - generated server-side, returned to merchants once at creation, then encrypted at rest with AES-256-GCM and decrypted only at delivery time.

PayBridgeNP does not rely on client-side redirects or browser-visible state to mark a payment as successful. Payment status is based on provider callback and verification flows, then surfaced to merchants through the dashboard, APIs, and signed webhooks.

• Webhook signing - every webhook delivery includes an HMAC-SHA256 signature header. Merchants must validate this signature before mutating order state.
• Idempotent reconciliation - replayed callbacks and out-of-order events are deduplicated server-side. Refund requests are safe to retry with the same Idempotency-Key.
• Webhook delivery logs - merchants can see whether each delivery was accepted, failed, or pending retry, with full headers and bodies for debugging.
• Public payment tracking - customer-facing tracking pages show the limited information needed to recognise and follow a payment, never dashboard-only or merchant-internal data.
• Suspension enforcement - when a merchant is suspended, API keys return 403, hosted checkout and payment links are blocked, and the dashboard is locked, with the suspension reason shown at sign-in.

• Sliding-window rate limits backed by Upstash Redis on all public API endpoints, with per-IP and per-API-key tiers.
• Per-merchant SMS burst limits with a per-recipient cooldown. Suppressed messages are still logged to the SMS history.
• Free-plan caps enforced server-side: monthly volume, active webhook endpoints, active API keys.

Sandbox and live are separate modes that cannot cross. There is one exception you must know about before you test: Fonepay.

• Sandbox keys can only initiate sandbox checkout sessions; live keys can only initiate live ones. The two cannot cross.
• Sandbox SMS dispatches are logged but never reach the SMS provider - no real messages, no real cost.
• Fonepay has no test environment. Sandbox eSewa and Khalti use each provider's official test environment, so no real money moves. If you add your own Fonepay credentials to a sandbox project, sandbox Fonepay payments run on the real Fonepay network and move real money, hard-capped at NPR 1,000 per payment and NPR 5,000 per merchant per calendar month. Treat a sandbox Fonepay QR like a live one.
• Webhooks fire as normal in sandbox so integrators can develop end-to-end before going live.

Pro-plan and Enterprise merchants can serve hosted checkout on their own subdomain (e.g. pay.theirstore.com). PayBridgeNP provisions and renews TLS for the hostname; the underlying checkout origin and payment-state handling are unchanged. PayBridgeNP can revoke a merchant's custom hostname at any time (downgrade, suspension, abuse), at which point the merchant's URLs revert to checkout.paybridgenp.com.

We run regular security reviews of authentication, tenant isolation, payment integrity, dependencies, and infrastructure, and fix what they find in order of risk.

If we ever confirm a personal-data breach that affects you, we will notify affected merchants without undue delay, describe what happened and what data was involved, and tell you the steps we are taking in response.

Security is shared. Merchants are responsible for protecting their own dashboard accounts, API keys, MCP tokens, webhook endpoints, return URLs, and internal systems that consume PayBridgeNP events.

• Use strong passwords and enable two-factor authentication for operational accounts.
• Rotate API keys, MCP tokens, or webhook secrets if you suspect exposure.
• Verify webhook signatures before updating order state on your side.
• Keep your integration endpoints, servers, and admin tooling patched and access-controlled.
• Treat AI-agent MCP tokens as sensitive - don't share between humans, don't paste into untrusted environments.

If you believe you have found a vulnerability, exposed credential, or account compromise, contact support@paybridgenp.com as soon as possible. Use the subject line "Security Issue". Include a clear description of the issue, affected URL or project, steps to reproduce, and any relevant request IDs or screenshots.

Please avoid public disclosure before we have had a reasonable chance to investigate and remediate the issue. Good-faith reports are appreciated, and we credit reporters on this page, with their permission, once a fix has shipped.

Good-faith research means: do not access, change, or keep data that is not yours; do not disrupt the service or use social engineering; and stop and report as soon as you can see personal data. We will not pursue legal action against researchers who follow these rules.