How to Check the Status of a Lightning Payment in BlueWallet

Understanding Lightning Payment Lifecycle

1. A Lightning payment initiates when the sender constructs an invoice containing a payment hash, amount, and expiry time.

2. The sender’s node routes the payment through one or more intermediate channels until it reaches the recipient’s node.

3. Upon successful receipt, the recipient’s node reveals the preimage, which propagates back along the same route to confirm settlement.

4. If any channel along the path lacks sufficient liquidity or fails verification, the payment fails instantly without locking funds.

5. Unlike on-chain Bitcoin transactions, Lightning payments do not appear in block explorers—status must be inferred from wallet-internal events.

BlueWallet’s Built-in Status Indicators

1. After initiating a payment, BlueWallet displays a real-time status badge: “Pending”, “Confirmed”, or “Failed”.

2. Tapping the transaction row opens a detailed view showing routing attempts, hop-by-hop latency, and final error code if applicable.

3. For outbound payments, the “Sent” tab shows timestamps for invoice generation, first route attempt, and preimage confirmation.

4. Inbound payments appear under “Received” only after the preimage is verified and balance updated—no unconfirmed entries are shown.

5. BlueWallet does not display “0-conf” or intermediate states; it waits for full cryptographic confirmation before updating UI state.

Manual Verification via Channel State

1. Navigate to Settings → Lightning → “View Channels” to inspect local channel balances and commitment transaction IDs.

2. Cross-reference the payment hash against the channel’s latest commitment transaction using a compatible block explorer like 1ML or Amboss.

3. If the hash appears in the commitment output script, the payment is cryptographically bound to that channel state.

4. Use the “Export Logs” function to retrieve raw HTLC records, including cltv_expiry, amt_to_forward, and custom_records.

5. Compare the payment_hash field in logs with the original invoice hash to rule out hash collision or misrouting.

Common Failure Triggers Observed in Practice

1. Expiry mismatch: Invoice expiry set too low causes nodes to reject forwarding before reaching destination.

2. Insufficient channel balance: Intermediate node lacks enough outbound capacity to relay the requested amount.

3. CLTV delta misalignment: Mismatch between sender’s cltv_expiry and node policy results in immediate rejection at first hop.

4. Network partitioning: Temporary loss of connectivity between nodes prevents preimage propagation even after successful delivery.

5. Invoice reuse: Attempting to pay the same invoice twice triggers automatic rejection by compliant Lightning implementations.

Frequently Asked Questions

Q: Can I see pending HTLCs in BlueWallet before they resolve?A: No. BlueWallet intentionally hides unconfirmed HTLCs to prevent user confusion. Only fully settled or definitively failed payments appear in the UI.

Q: Does BlueWallet store preimages locally after payment success?A: Yes. Preimages are encrypted and stored in the device’s secure enclave. They are never transmitted to servers or exposed in export logs.

Q: Why does a payment show “Confirmed” but not reflect in my on-chain balance?A: Lightning balances are off-chain. Confirmation means the HTLC was settled within the channel graph—not that BTC moved on-chain.

Q: Can I manually force-close a channel to recover funds from a stuck payment?A: Force-closing initiates a 144-block dispute window. It does not accelerate HTLC resolution and may result in lost fees if misused.