Inililipat ang pahina.
Inihahanda ang susunod na kabanata…
Psst… magbasa sa paraang gusto mo.
Nasa Hitsura ang mga font at tema. May boses din ang iyong mga mata.
Inihahanda ang susunod na kabanata…
A protocol for requesting a Lightning payment invoice from a service through an encoded URL-based interaction.
Sinusuri ang kakayahan ng browser na bumasa nang malakas…
Available ang babasahing ito sa Ingles sa ngayon. Ginagamit ng interface ang pinili mong wika.
Basahin ang orihinal na Ingles →LNURL-pay, specified in LUD-06, lets a wallet contact a service, learn payment parameters, and request an invoice for a chosen amount. It helps create reusable payment entry points instead of requiring the recipient to distribute a new fixed invoice manually for every payment. The resulting payment still relies on Lightning invoice and routing mechanics. LNURL-pay is not itself a new settlement network or an asset separate from bitcoin.
A typical interaction includes supported amount bounds, a callback endpoint, metadata, and an invoice returned for the selected amount. The specification defines checks connecting the invoice to the requested payment and metadata. For example, a wallet should not treat an invoice for a different amount as interchangeable merely because it came from the expected web page. The HTTPS service and its availability become part of the user experience before the Lightning payment is attempted.
A reusable address-like payment flow is convenient, but the service can learn request metadata and can become unavailable or change its responses. Wallets must still handle invoice expiry, failed routes, and user confirmation. The protocol does not prove that a merchant will deliver goods or that a displayed recipient name identifies the intended legal person. Distinguish the web-based request stage, the cryptographic invoice, and successful Lightning settlement when explaining what a completed payment screen actually confirms.