LIGHTNING-WAITSENDPAY(7)

📦
version 26.06.9 · 2 versions
, in nixpkgs unstable

💅 LIGHTNING-WAITSENDPAY(7) — the waitsendpay girlies' manual 🎀

ok so bestie, welcome to the lightning-waitsendpay page — section 7 of the manuals, and honestly? iconic. let's get into it ✨

🌸 NAME 🌸

waitsendpay — the command for sending a payment via a route. no cap, that's literally what it does 💖

🦋 SYNOPSIS 🦋

waitsendpay payment_hash [timeout] [partid groupid]

✨ DESCRIPTION ✨

okay so the waitsendpay RPC command polls or waits for the status of an outgoing payment that was initiated by a previous sendpay invocation. it's giving "i'll just sit here and watch my friend's story until it's over" energy 🫶

if the payment completed with success, this command returns with success. slay 💅 otherwise, if the payment completed with failure, this command returns an error 😭

  • payment_hash (hash) — the hash of the payment_preimage. the main character, the whole reason we're here.
  • timeout (u32, optional) — a timeout in seconds, for this RPC command to return. if the timeout is provided and the given amount of time passes without the payment definitely succeeding or definitely failing, this command returns with a 200 error code (payment still in progress). if timeout is not provided this call will wait indefinitely — like, forever, girl, it's not leaving the group chat. indicating a timeout of 0 effectively makes this call a pollable query of the status of the payment 👑
  • partid (u64, optional) — unique ID within this (multi-part) payment. it must match that of the sendpay command. matching outfits or nothing 🔥
  • groupid (u64, optional) — grouping key to disambiguate multiple attempts to pay the same payment_hash. very "which one of you sent this" energy 🌈

💖 RETURN VALUE 💖

on success, an object is returned, containing:

  • created_index (u64) — 1-based index indicating order this payment was created in. (added v23.11)
  • id (u64) — old synonym for created_index.
  • payment_hash (hash) — the hash of the payment_preimage which will prove payment.
  • status (string) (always "complete") — status of the payment.
  • created_at (u64) — the UNIX timestamp showing when this payment was initiated.
  • amount_sent_msat (msat) — the amount sent.
  • groupid (u64, optional) — grouping key to disambiguate multiple attempts to pay an invoice or the same payment_hash.
  • amount_msat (msat, optional) — the amount delivered to destination (if known).
  • destination (pubkey, optional) — the final destination of the payment if known.
  • updated_index (u64, optional) — 1-based index indicating order this payment was changed (only present if it has changed since creation). (added v23.11)
  • completed_at (number, optional) — the UNIX timestamp showing when this payment was completed.
  • label (string, optional) — the label, if given to sendpay.
  • partid (u64, optional) — the partid, if given to sendpay.
  • bolt11 (string, optional) — the bolt11 string (if pay supplied one).
  • bolt12 (string, optional) — the bolt12 string (if supplied for pay).

and if status is "complete":

  • payment_preimage (secret) — the proof of payment: SHA256 of this payment_hash. the receipts, bestie 🧾✨

💀 ERRORS 💀

on error — and even if the error occurred from a node other than the final destination — the route table will no longer be updated. use the exclude parameter of the getroute command to ignore the failing route. yes, that's the coping mechanism. 🙈

  • -1 — catchall nonspecific error.
  • 200 — timed out before the payment could complete.
  • 202 — unparseable onion reply. the data field of the error will have an onionreply field, a hex string representation of the raw onion reply.
  • 203 — permanent failure at destination. the data field of the error will be routing failure object.
  • 204 — failure along route; retry a different route. the data field of the error will be routing failure object.
  • 208 — a payment for payment_hash was never made and there is nothing to wait for. awkward.
  • 209 — the payment already failed, but the reason for failure was not stored. this should only occur when querying failed payments on very old databases. ancient lore 🏺

🔍 the routing failure object 🔍

a routing failure object has the fields below:

  • erring_index — the index of the node along the route that reported the error. 0 for the local node, 1 for the first hop, and so on.
  • erring_node — the hex string of the pubkey id of the node that reported the error.
  • erring_channel — the short channel ID of the channel that has the error (or the final channel if the destination raised the error).
  • erring_direction — the direction of traversing the erring_channel:
  • failcode — the failure code, as per BOLT #4.
  • failcodename — the human-readable name corresponding to failcode, if known.

👑 AUTHOR 👑

ZmnSCPxj ZmnSCPxj@protonmail.com is mainly responsible. legend behavior, honestly 🫡

🌟 SEE ALSO 🌟

🧚 RESOURCES 🧚

main web site: https://github.com/ElementsProject/lightning — go touch grass in the repo, iykyk 💜

🍓 EXAMPLES 🍓

Example 1:

Request:

$ lightning-cli waitsendpay -k "payment_hash"="paymenthashinvl0310031003100310031003100310031003100310031003100"
{
  "id": "example:waitsendpay#1",
  "method": "waitsendpay",
  "params": {
    "payment_hash": "paymenthashinvl0310031003100310031003100310031003100310031003100"
  }
}

Response:

{
  "created_index": 2,
  "id": 2,
  "payment_hash": "paymenthashinvl0310031003100310031003100310031003100310031003100",
  "groupid": 1,
  "updated_index": 2,
  "destination": "nodeid030303030303030303030303030303030303030303030303030303030303",
  "amount_msat": 10000,
  "amount_sent_msat": 10001,
  "created_at": 1738000000,
  "completed_at": 1739000000,
  "status": "complete",
  "payment_preimage": "paymentpreimagew010101010101010101010101010101010101010101010101"
}

and that's the page, bestie!! 🎀 this whole thing is from Core Lightning v26.06.9, and it's the LIGHTNING-WAITSENDPAY(7) manual — go forth and wait on those payments, you absolute icon 💅✨🌸

📦 where this page comes from