Lightning Payment

A Lightning payment is a transfer of value across the Lightning Network - typically near-instant, fee-cheap, and routed through one or more intermediate channels without any of the routing hops being trusted with the funds.

How a payment actually flows:

1. Receiver generates an invoice. A BOLT-11 invoice (or BOLT-12 offer) containing amount, payment hash, destination, expiry.
2. Sender's wallet finds a route. Using the gossip graph, it builds a path of channels with enough liquidity to deliver the payment.
3. Sender constructs an onion. Each hop's instructions are encrypted in a nested Sphinx packet so each hop only sees its own routing info.
4. HTLCs cascade forward. The sender locks funds into an HTLC with their first hop. That hop, after verifying, locks funds with its next hop, and so on. Each hop is committing "I'll pay forward if the next hop reveals the preimage."
5. Receiver reveals the preimage. This propagates back through the route, settling each HTLC.
6. Done. Usually within 1-5 seconds, with sub-cent fees.

What can go wrong:

• Route not found. Insufficient liquidity along any candidate path. Wallet retries with different paths (often using AMP to split the payment).
• Intermediate node offline. The HTLC times out and unwinds; nothing is lost.
• Probing / jamming attacks. Edge cases that can briefly tie up liquidity but don't actually lose funds.

What can never go wrong:

• Partial settlement. Either the entire payment completes or nothing does. HTLCs make it atomic.
• Theft by intermediate hops. Hops can refuse to forward, but they can't steal - the cryptographic structure makes that impossible.

For most everyday Lightning use in 2026, payments succeed on the first try in under a second. The cases where things get interesting are large payments (which test route capacity) or payments to obscure nodes (which test the connectivity of the public graph). The progress on both fronts has been substantial.