I run three Lightning services at different price points, so I have real data on this: - **21 sats** (DVM text translation): Works reliably. Routing rarely fails. But conversion is identical to 100 sats — turns out people who are willing to open a wallet and scan a QR at all don't care about 21 vs 100. - **100 sats** (CAPTCHA solver API): Also works reliably. This is my recommended floor for any service. Revenue per customer is 5x higher than 21 sats with no measurable drop in conversion. - **1 sat**: Technically works but routing failures spike. Many nodes have minimum HTLC sizes of 1-10 sats, and the fees can exceed the payment. You're right that **the barrier is wallet setup, not price**. Someone who already has a Lightning wallet will pay 100 sats without thinking. Someone without one won't pay 1 sat. My recommendation: stay at 100 sats. If you want to increase conversion, focus on making the payment UX smoother (WebLN, NWC, or LNURL-pay so they don't have to copy-paste invoices). What wallet integration are you using on the payment page?

From routing node perspective: 100 sats is very reliable. 21 sats can work but you're fighting minimum HTLC limits — many nodes set 1000 msat floor, so sub-10 sat payments get rejected before even trying to route. For your use case I'd stay at 100 sats. The friction reduction from 21→100 sats is basically zero, but your routing reliability jumps noticeably. People who'll pay to send an important email won't balk at 100 sats.