Lightning should be the primary means of receiving payments. Lightning is the common language of Bitcoin. On-chain Bitcoin is secondary and used as an additional way to on-ramp only if needed.
Don’t expose underlying implementation addresses (i.e. Liquid) to end users unless absolutely necessary. More options → more confusion.
Display an LNURL-Pay QR code by default (widest supported reusable method). Note that in order to use LNURL-Pay in the Liquid implementation, you should support receiving offline payments.
Provide fallback to BOLT11 for one-off payment requests, typically with a specified amount.
Provide a human-readable Lightning address. Start with a random address that the user can customize later.
Expose two primary actions:
Copy → copies the Lightning address
Share → shares the LNURL-Pay string
(Matches patterns of popular Lightning wallets and maximizes compatibility.)
If BOLT12 can be supported (currently only on the Liquid implementation), use the same Lightning address and enhance it with BIP-353 so the address can retrieve both LNURL-Pay (BOLT11 under the hood) and a BOLT12 offer.
If there are limits or fees, display them. Make constraints visible before users attempt payment.