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. Payment success and ticking a save checkbox alone do not verify phone ownership. Automatic saving and profile updates require phone verification in that checkout; otherwise they are skipped without affecting payment.

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

If the merchant pre-filled customer.phone on the checkout session (or the buyer types it in the cold form), and that number already has a PB ID, 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.

New or unrecognised buyers

For buyers we don’t recognise, 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 or at the same time. Retrying a failed action requires fresh verification.

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 the merchants that can currently reuse their saved details, with a per-merchant “remove” button. Revoking a merchant blocks reuse of saved details at that merchant without affecting historical payments. Paying again does not restore permission. Explicitly saving with a fresh phone verification grants permission again.

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

Export. Buyers can download a JSON copy of their data from id.paybridgenp.com: profile, merchant links, payments and refunds, checkout sessions, devices, passkeys, Shop orders, imported Insights data, Wrapped and the audit log.
  • Most lists are capped at 10,000 entries, and imported Insights transactions at 50,000. The audit log, payments, refunds, Shop orders and checkout sessions keep the newest. truncated_sections and insights.transactions_truncated say which lists hit the cap.
  • Passkeys are listed as metadata only, never the credential id or public key.
  • A duplicate charge on one of the buyer’s checkouts is included, marked duplicate_of_session_id, with any refund of it.
Deletion. Deleting the account needs a fresh one-time code.
  • It stops working at once: every session is signed out and it can no longer be looked up.
  • After 30 days, stored personal data is erased for good and every merchant link is removed.
  • Shop orders are anonymised: recipient details, gift messages and voucher codes are erased; amount, status and dates stay as a financial record.
  • Payments to merchants are kept, unlinked from the identity, because they are the merchant’s own 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: on id.paybridgenp.com the buyer can remove a merchant, after one confirmation, and that merchant can no longer reuse saved details.
  • Protected sessions and fresh verification for sensitive actions.
  • Passkey sign-in requires device verification, such as Face ID, Touch ID or a PIN, and checks for signs of a copied passkey where the device supports it.
  • 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. PB ID is live mode only, so sandbox checkouts show the plain customer form and never write to a real buyer’s PB ID. It needs no integration from you, so there is nothing to test in sandbox. To see it, create a live session in a test project, or sign in at id.paybridgenp.com. Can I disable PB ID on my checkout? Yes, per project: project settings, Branding, turn off “PayBridgeNP ID on checkout”. That project’s checkouts then show the plain form, with no “Welcome back”, save prompt or autofill. Buyers’ saved identities keep working everywhere else. 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 the phone-match or normal form, 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.