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 recognised, 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.Documentation Index
Fetch the complete documentation index at: https://docs.paybridgenp.com/llms.txt
Use this file to discover all available pages before exploring further.
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.Recognising 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 onid.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-filledcustomer.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 98XXXXX833 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
| Method | Where it works | Notes |
|---|---|---|
| SMS one-time code | Login, checkout, step-up | 6 digits, valid 15 minutes |
| Passkey (Face ID / Touch ID / device PIN) | Login, checkout, step-up, account dashboard | Buyer registers once at id.paybridgenp.com, then signs in everywhere with a tap |
| Email one-time code | Login, step-up | Sent to the saved email address. Anti-enumeration: response is identical whether the address is registered or not |
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 samecustomer_* 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 clears the pbid_merchant_links row for that pair 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)
- eSewa, Khalti, FonePay, or ConnectIPS 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 fromid.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.comremoves a merchant from the buyer’s history. - Cross-site CSRF defense: cookie is
SameSite=Lax,HttpOnly,Securein production. - WebAuthn ceremonies use discoverable credentials with
userVerification=preferred. Counter-rollback is enforced where the authenticator supports monotonic counters (skipped for Apple authenticators that always return 0). - Sub-processor list and retention timeline live in the privacy policy.