The Browser-Extension Wallet: Pay by Alias, Scan QR
Wallets that live in your browser have a superpower: they are right there when you need to pay, without an app switch. KibiPay's browser-extension wallet takes that convenience and adds two things people actually want — pay by alias and scan a QR — while keeping keys self-custodial on the user's device.
Self-custody, briefly
Self-custodial means the private keys never leave the user's control. The extension stores them locally, encrypted, and signs transactions on the device. No server holds the keys, so no server can move funds on the user's behalf. That is a strong security posture, and it puts the user firmly in charge — with the corresponding responsibility to protect their credentials.
- Keys are generated and stored locally, encrypted at rest.
- Signing happens in the extension, not on a backend.
- The user approves every transaction explicitly.
Pay by alias from the extension
Typing a raw wallet address into a browser is exactly the error-prone act self-custody wallets are notorious for. Pay-by-alias fixes that: the user enters a handle, the extension resolves it through the directory, shows the recipient name, and only then prompts to sign. The address complexity disappears behind a name the user recognises.
| Action | Where it happens |
|---|---|
| Resolve alias | Directory lookup |
| Show recipient | Extension UI |
| Sign transaction | Locally, in the extension |
Scanning a QR from the browser
The extension can read a request-to-pay QR — from a webcam or an on-screen code — and open a pre-filled payment. Because the QR encodes an alias, the wallet resolves it fresh and displays who is being paid before anything is signed. Scan, verify the name, approve: the same safe pattern as the rest of KibiPay's receive flows, covered in our piece on confirmation of payee.
Bridging on-chain and off-chain
A self-custodial wallet is naturally at home on-chain, but paying an alias may resolve to a non-crypto destination. The interesting design question is how a wallet that holds keys for a Solana address participates when the recipient's best rail is mobile money or a bank. The directory answers the "who", and the payment experience surfaces the rail the routing engine chose, so the wallet stays a clean signing surface rather than a rail decider.
Security expectations
Extension wallets face browser-specific risks: malicious pages, clipboard hijacking, and phishing. Displaying the resolved recipient name defeats a whole class of address-swap attacks, since the user is confirming a person, not a string. Clear signing prompts and origin checks round out the defenses.
Where it fits in KibiPay
The extension wallet is the self-custodial front end to the same directory everything else uses. Pay-by-alias and scan-to-pay make it feel like the rest of KibiPay, while keys stay local. For the broader rail picture behind each resolved payment, see the rails overview.
Recovery without a custodian
Self-custody's greatest strength — nobody else holds your keys — is also its sharpest edge. If a user loses their device, no support team can reset a password to get their funds back. That makes recovery design essential: seed-phrase backups, optional encrypted exports, and clear, repeated warnings that the keys are the money. A browser extension has to make backing up feel like part of setup, not an afterthought a user skips on the way to their first payment. The wallet can smooth the addressing experience with aliases and QR scanning, but it cannot smooth away the responsibility of custody. Being honest about that tradeoff, rather than hiding it behind a slick interface, is what separates a trustworthy self-custodial wallet from a dangerous one.
Keep the keys with the user, keep the addresses behind a name, and a browser wallet becomes something people can actually use without fear.