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, hosted checkout can recognize the trusted device and fill the saved profile after matching it to the checkout. The buyer sees a welcome message, chooses a payment method, and pays without another sign-in. 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 fresh verification with an SMS code 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. Autofilled name, email, phone, and address use the same checkout and webhook customer fields as a guest payment. The payment.succeeded event is unchanged. 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 and email, encrypted at rest
  • Name and default shipping address, encrypted at rest
  • Preferred wallet, which is not a payment credential
  • Passkey public keys + counter (private half stays on the buyer’s device)
  • Buyer-merchant links and account activity
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 their PayBridgeNP ID data from id.paybridgenp.com: profile, merchant links, payments and refunds, checkout sessions, devices, passkeys, Shop orders, imported Insights data, Wrapped, and the full audit log. Passkey entries are metadata only, never the credential id or public key, and a duplicate charge recovered directly from a provider carries no checkout link so it is not listed. 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. Shop orders are anonymised rather than destroyed: recipient details, gift messages and voucher codes are erased, while the amount, status and dates survive as a financial record. Payments the buyer made to merchants are also retained, unlinked from the deleted identity, because those are the merchant’s own transaction records.

​
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.
  • Protected sessions and fresh verification for sensitive actions.
  • 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.