đBest Practices
Inform & ask before you prompt
Most of WebLN's methods will prompt the user to make payments or have them provide information. Before running window.webln.enable()
or other methods, make sure the user knows what your app does, and why they should allow your calls to run. Popping up a window as soon as they load a page will cause users to reject WebLN requests, or worse yet, bounce from your page. Explicit buttons (e.g. to login) are helpful, but alternatives could be hiding pages behind loaders while requesting the user's provider, or keeping it to sub-pages and having your homepage not require WebLN.
Prioritize WebLN, offer fallback options
WebLN offers a very convenient way for users to interact with their lightning wallets. Therefore you should always check for WebLN support before showing some fallback options (QR codes, copy invoice, etc).
Code Example
If a user does not have a compatible client, inform them (e.g. with Error messages) and let them know how to get started with a WebLN client. This is also a good time to promote your favorite WebLN provider projects!
For simple use cases such as making payments, you can always just use BOLT-11 links instead of webln.sendPayment
to have maximum compatibility with all types of Lightning clients.
Don't Assume a Particular Client
Anyone can make a WebLN provider, so don't assume the user is using a particular one, such as Alby or Joule. Try to stay agnostic in your language about the user's client, e.g. instead of saying Pay
with Alby
, just say Pay
.
Last updated