LNURL-Pay and Withdrawal Standards

Audit your LNURL-pay callback endpoint for TLS downgrade and MITM vulnerabilities. The standard relies on a single HTTPS request to resolve a static QR code to a real invoice, making it a high-value target. Ensure your server enforces HSTS, validates the minSendable/maxSendable range strictly, and never exposes the underlying node's invoice generation to unauthenticated callers. Implement rate limiting on the callback URL to prevent probing attacks that could deanonymize your node's channel balances.

If you operate a Lightning Address service, begin serving a parallel BIP 353 DNS record. A user@domain.com identifier currently resolves via a centralized HTTPS request to domain.com/.well-known/lnurlp/user. BIP 353 resolves the same identifier via a DNS TXT record at user.user._bitcoin-payment.domain.com, removing the web server as a single point of failure. Run both resolution paths concurrently and monitor client adoption via the user-agent or a custom header before deprecating the HTTPS endpoint.

Adopting BOLT 12 Offers is not a simple format swap. It requires your node to support onion messaging for direct invoice requests over blinded paths. Verify that your Lightning implementation (LND, CLN, Eclair, LDK) has merged and enabled onion messaging support. For mobile wallets, this introduces a new connectivity requirement: the sender must be able to reach the receiver's node via the gossip network or a direct peer connection to fetch the invoice, unlike LNURL which works over a standard REST API.

LNURL-Pay's primary UX advantage is the static QR code. BOLT 12 Offers provide the same capability with better privacy but require a different encoding. Plan a transition where your point-of-sale or donation page displays both an LNURL-Pay QR and an Offer QR during a coexistence period. The Offer QR encodes a lno bech32 string, which is visually distinct. Test that your target wallets can parse and pay both formats before removing the LNURL fallback to avoid breaking payments for users on older software.

LNURL-Pay has no native recurring payment mechanism; services typically implement this by triggering a new LNURL withdrawal or pay request on a cron job. BOLT 12 Offers support recurring payments natively via the recurrence field in the offer. If you are building a subscription service, evaluate whether to maintain your custom LNURL-based billing engine or migrate to BOLT 12's declarative recurrence. The BOLT 12 approach shifts the payment initiation responsibility to the payer's wallet, which must support the recurrence schedule.

The LNURL-withdraw (lud-03) sub-protocol is critical for exchanges and LSPs enabling off-chain fund pulls. Review your implementation to ensure the k1 challenge is single-use and cryptographically verified before releasing funds. A reused or predictable k1 allows an attacker to drain the withdrawal endpoint. If you are an LSP using LSPS1 for just-in-time channels, ensure your LNURL-withdraw handler correctly interfaces with your channel-opening logic and does not leak information about your liquidity state through timing or error messages.

Start with the canonical Lightning URL Documents repository to identify the specifications and extensions relevant to an integration. Record which LUDs each wallet, gateway, or server supports, including encoding, callback, metadata, payer-data, and success-action behavior. Treat repository changes as application-layer compatibility changes rather than Lightning consensus changes. Pin reviewed behavior in implementation documentation and test unknown or optional fields explicitly, because two products described as supporting LNURL may implement different subsets of the documents.

Use LUD-06 as the primary source for LNURL-Pay request discovery, callback parameters, amount constraints, metadata commitments, and invoice retrieval. Implementers should validate callback URLs, enforce the advertised minimum and maximum sendable amounts, preserve the exact metadata used to obtain the invoice, and confirm that the returned BOLT 11 invoice matches the requested amount and expected metadata hash. Wallet and gateway teams should also define timeout, replay, malformed-response, and callback-origin policies before enabling static QR or web-based payment flows.

Use LUD-03 to review the LNURL-Withdraw flow in which a wallet supplies an invoice to a service callback. Validate the withdrawal identifier, callback origin, amount bounds, invoice amount, expiry, and one-time-use semantics. Services should prevent replay and concurrent redemption, avoid leaking sensitive withdrawal state through logs or analytics, and return errors without exposing internal payment infrastructure. Wallets should clearly distinguish a withdrawal request from a payment request and should not generate an invoice outside the service’s declared range.

LNURL-Pay returns a BOLT 11 invoice, while LNURL-Withdraw generally requires the wallet to create one. Review BOLT 11 alongside the LNURL documents to validate network, amount, expiry, payment hash, signature, routing hints, feature bits, and description or description-hash fields. Integration tests should reject invoices for the wrong Bitcoin network, unexpected amounts, expired timestamps, unsupported required features, or metadata commitments that do not match the LNURL response. This boundary is security-critical because a valid LNURL callback response does not automatically make its invoice acceptable.

Use the BOLT 12 specification when assessing whether reusable Offers can replace or complement LNURL-Pay for a product. Compare discovery requirements, invoice creation, blinded paths, payer interaction, transport dependencies, metadata, privacy exposure, and wallet support rather than treating the formats as interchangeable. A migration plan should retain explicit capability detection and fallback behavior until every target wallet and backend supports the required BOLT 12 flow. Teams should verify current implementation status against their selected Lightning clients and libraries before committing to production cutover.

Review optional LUDs before accepting fields beyond the base Pay or Withdraw flow, particularly success actions, payer data, callback status checks, and URL-scheme handling. Each extension changes the data exposed to servers or the actions a wallet may perform after payment. Maintain an allowlist of supported fields, apply strict URL and content validation, prevent automatic execution of untrusted actions, and test extension combinations across target wallets. Security reviews should include server-side request forgery exposure, open redirects, DNS and TLS assumptions, replay protection, identifier entropy, and accidental disclosure through callback logs.