Skip to main content
PayBridgeNP ID (PB ID) is the buyer-identity layer that ships inside hosted checkout. Once a buyer has saved their info at one PayBridgeNP merchant, every other PayBridgeNP merchant gets the same buyer recognized, autofilled, and converted. You don’t integrate anything. PB ID surfaces on the checkout page you already use the moment a returning buyer lands on it.

​
The buyer’s first save

After their first paid checkout, the buyer sees a “Save with PayBridgeNP ID” prompt on the success page. One SMS code stores their name, email, address, and preferred wallet. Tapping “No thanks” sets a 90-day cookie so we don’t ask again from that browser. That’s the entire signup. There is no separate registration page, no password, no app to install.

​
Recognizing returning buyers

PB ID has three recognition paths, all on the same hosted checkout page:

​
Trusted device (silent autofill)

When a buyer is signed in on id.paybridgenp.com (their __pbid_session cookie is in the browser), the hosted checkout page reads it during HTML render. If the cookie identity is consistent with the session’s pre-filled phone, we splice a “Welcome back, NAME” banner inline at first paint. No SMS, no passkey tap, no flicker. The buyer just picks a wallet and pays. This is the lowest-friction path and it is the default for anyone who has signed in once on the buyer site.

​
Phone match (State A)

If the merchant pre-filled customer.phone on the checkout session (or the buyer types it in the cold form), we look up an existing PB ID by hashed phone. If we find one, the page shows:
Welcome back to PayBridgeNP Send a code to 98XXXXX001 to fill in your details [Send code] [Use a passkey] [Use a different account]
The buyer either gets an SMS, taps Touch ID for an instant passkey, or chooses to type fresh details.

​
Cold (State C)

For buyers we have no signal on (no cookie, no matching phone), the form shows as normal with a small “Already on PayBridgeNP? Sign in with a passkey” pill above the inputs. The buyer can ignore it and type, or tap to sign in via discoverable passkey.

​
Sign-in methods

​
Sensitive-action protection

Deleting an account or downloading a data export prompts the buyer for a fresh verification (SMS, email, or passkey). The verification is single-use: each gated action requires its own step-up, so one OTP cannot unlock multiple destructive actions in a row.

​
What the merchant sees

Nothing changes on the merchant side. PB ID writes the autofilled name, email, phone, and address to the same customer_* fields you already read from checkoutSessions and webhook payloads. The merchant’s webhook on payment.succeeded fires identically whether the buyer was a first-time guest, an autofilled returning buyer, or a trusted-cookie recognition. The only new field is pbid_identity_id on the checkout session, populated when a returning buyer was matched to an existing identity. You don’t need to use it. The buyer’s merchants tab on id.paybridgenp.com lists every PayBridgeNP merchant they’ve paid, with a per-merchant “remove” button. Revoking a merchant removes that merchant link without affecting the historical payments.

​
What gets stored, what does not

Stored:
  • Phone number (HMAC-SHA-256 lookup hash + AES-256-GCM ciphertext)
  • Email (HMAC-SHA-256 lookup hash + AES-256-GCM ciphertext)
  • Name, default shipping address (AES-256-GCM ciphertext)
  • Preferred wallet (plaintext routing label, not a credential)
  • Passkey public keys + counter (private half stays on the buyer’s device)
  • Buyer-merchant link table + audit log (plaintext, buyer-controlled)
Not stored:
  • eSewa, Khalti, or Fonepay passwords. The buyer always logs in with the wallet on the wallet’s own page.
  • Card numbers (PayBridgeNP doesn’t accept cards).
  • IP-derived location.
  • Any merchant’s order details beyond what that merchant already sees.

​
Data export and deletion

Buyers can export a JSON copy of every field above plus the full audit log from id.paybridgenp.com. Account deletion is gated by a fresh OTP, soft-deletes immediately (revoking all sessions and identity lookup), and hard-deletes after 30 days. Hard-delete removes the encrypted ciphertexts and breaks every merchant link.

​
Languages

The buyer site (id.paybridgenp.com) runs in नेपाली and English. Login detects the buyer’s preference automatically. The hosted checkout banners (Welcome back..., Send code, etc.) inherit the merchant’s checkout theme strings; merchant-side localisation will arrive in a future release.

​
Privacy and security posture

  • Per-merchant data isolation: each merchant only sees the buyers who’ve paid them.
  • Buyer-revocable links: a single tap on id.paybridgenp.com removes a merchant from the buyer’s history.
  • Cross-site CSRF defense: cookie is SameSite=Lax, HttpOnly, Secure in production.
  • WebAuthn ceremonies use discoverable credentials with userVerification=preferred. Counter-rollback is enforced where the authenticator supports monotonic counters.
  • Sub-processor list and retention timeline live in the privacy policy.

​
FAQ

Do I need to call any new API to enable PB ID? No. PB ID is on by default, and the hosted checkout surfaces it automatically. There is no SDK call and nothing to integrate. If you want it off, flip the per-project toggle described below. Why don’t I see PB ID on my sandbox checkout? By design, not a bug. PB ID is live-mode only: a sandbox checkout session renders the plain customer form, with no “Welcome back” banner, no save-after-pay prompt, and no passkey pill, and nothing is written to a buyer’s real PayBridgeNP ID from a sandbox payment. PB ID lives entirely inside hosted checkout with zero merchant integration, so there is nothing for you to test against it in sandbox, and keeping sandbox out of it keeps test traffic from touching real buyer identities. To see the PB ID experience yourself, create a live-mode session in a test project, or sign in directly at id.paybridgenp.com. Can I disable PB ID on my checkout? Yes, per project. In the dashboard, open your project’s settings, go to Branding, and turn off “PayBridgeNP ID on checkout”. Disabling it suppresses the “Welcome back” banner, the save-after-pay prompt, and trusted-cookie autofill on that project’s checkouts, so buyers see a normal cold checkout form. Identities buyers have already saved stay valid and keep working at other merchants and projects. What happens if the buyer’s cookie identity has a different phone than the one I pre-filled? The trusted-cookie path refuses to autofill, the page falls back to normal State A or State C, and the buyer can sign in with the matching account or pick “Use a different account” to type fresh details. Does PB ID work on my mobile SDK or my Shopify app? PB ID is currently a hosted-checkout feature. Mobile SDK and Shopify pay-by-link checkouts go through the same hosted page, so they benefit automatically when the buyer arrives in a browser. Native popup or in-app modal flows do not yet surface PB ID.