Security measures built around how the product actually works.

• Email-verified merchant accounts. New signups must confirm their address before issuing live API keys.
• Optional two-factor authentication for the merchant dashboard.
• Separate JWT signing secrets for merchant authentication and internal staff authentication. A leaked merchant token cannot be used to access internal surfaces.
• Short-lived dashboard JWTs (15-minute access window) issued from the API and held in browser memory only — never written to localStorage, sessionStorage, or IndexedDB.
• 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 multi-tenant tables. Every database session sets a tenant context (the merchant ID) before queries run; rows belonging to other merchants are not visible regardless of any application-layer mistake.
• 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, Fonepay, ConnectIPS, and HamroPay 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 stored hashed.

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. Refunds, voids, and capture flows are safe to retry.
• 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 payment-tracking pages expose only the payment status, not account or merchant-internal data.
• Suspension enforcement — when a merchant is suspended, API keys return 403, hosted checkout is blocked, and the dashboard becomes read-only with the suspension reason surfaced.

• 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 (50 messages/minute, 500/hour) with a layered per-recipient cooldown (1 message every 30 seconds to the same phone). Suppressed messages are still logged to the SMS audit table.
• Free-plan caps enforced server-side: monthly volume, active webhook endpoints, active API keys.
• Staff-only kill switches for platform maintenance mode and per-provider enforcement.

Sandbox mode is a hard guarantee, not a label.

• 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.
• Sandbox payments use each provider's official test credentials and never touch real settlement.
• Webhooks fire as normal in sandbox so integrators can develop end-to-end without real money moving.

PayBridgeNP runs security audits periodically. Recent rounds:

• 2026-03-26 — initial round; covered authentication, JWT handling, and provider-credential storage.
• 2026-04-04 — second round; expanded to webhook signing, rate limits, and staff-vs-merchant authentication separation.
• 2026-04-17 — third round; 11 fixes deployed across CSP, suspension flows, and tenant-context propagation.

External penetration testing by an independent third party is on the roadmap. We will publish the report (or a summary) once complete.

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; PayBridgeNP currently does not run a paid bug bounty programme but will credit reporters in a public hall-of-fame on this page (with permission) once a fix has shipped.