LIGHTNING-PAY(7)

📦

version 26.06.9 · 2 versions

26.06.9 · nixpkgs unstable (latest)
26.04.1 · nixos 26.05

💸 LIGHTNING-PAY(7) — the `pay` page, bestie edition 💅

okay so before we even start: this is LIGHTNING-PAY(7), the manual page for pay. it's giving "legacy icon who's retiring" and honestly we need to talk about it 🫶

✨ NAME ✨

pay — the command for sending a payment to a BOLT11/BOLT12 invoice. that's it. that's the whole vibe. 🎀

🌸 SYNOPSIS 🌸

pay bolt11 [amount_msat] [label] [riskfactor] [maxfeepercent]
[retry_for] [maxdelay] [exemptfee] [localinvreqid] [exclude] [maxfee]
[description] [partial_msat]

like, look at all those positional params. she's long. she's iconic. she's positional-argument-core. 😭

💖 DESCRIPTION 💖

bestie, listen. This command was deprecated in v26.06, and removed after v27.03. it's literally on its way out. 💀

NOTE: As of v26.06, xpay transparently handles most pay invocations, and pay is deprecated. so like… go hang out with xpay (that's lightning-xpay(7)) but the info's all here for you anyway, no gatekeeping 💜

So — what does the pay RPC command do? It attempts to find a route to the given destination, and send the funds it asks for. slay. that's the whole job.

The response will occur when the payment fails or succeeds. And here's the cute part: once a payment has succeeded, calls to pay with the same bolt11 will succeed immediately. no re-negotiating. she remembers. 👑

When using $ lightning-cli, you may skip optional parameters by using null. Alternatively, use the -k option to provide parameters by name. (the -k life hack, iykyk 🧚)

Now the params, one by one, no skips:

bolt11 (string) — NOTE: invstring is an alternate name for this parameter, since v26.06, for xpay compatibility. This is a Bolt11 or bolt12 invoice (such as one received from lightningd-fetchinvoice(7)). For a bolt11 invoice, if it does not contain an amount, amount_msat is required, otherwise if it is specified it must be null. so like, read the invoice first, don't just yolo it 🙈
amount_msat (msat, optional) — amount_msat is in millisatoshi precision; it can be a whole number, or a whole number with suffix msat or sat, or a three decimal point number with suffix sat, or an 1 to 11 decimal point number suffixed by btc. formats for days. ⭐
label (string, optional) — It is used to attach a label to payments, and is returned in lightning-listpays(7) and lightning-listsendpays(7). it's literally a name tag for your payment 🎀
riskfactor (number, optional) — The riskfactor is described in detail in lightning-getroute(7). The default is 10.
maxfeepercent (number, optional) — Percentage of the amount that is to be paid. The default is 0.5.
retry_for (u16, optional) — Until retry_for seconds passes, the command will keep finding routes and retrying the payment. The default is 60 seconds. she's persistent. she's not giving up on you. 😤
maxdelay (u16, optional) — A payment may be delayed for up to maxdelay blocks by another node; clients should be prepared for this worst case. plan accordingly bestie 🦋
exemptfee (msat, optional) — This option can be used for tiny payments which would be dominated by the fee leveraged by forwarding nodes. Setting exemptfee allows the maxfeepercent check to be skipped on fees that are smaller than exemptfee. The default is 5000 millisatoshi. tiny payment rights 💅
localinvreqid (hex, optional) — localinvreqid is used by offers to link a payment attempt to a local invoice_request offer created by lightningd-invoicerequest(7). This ensures that we only make a single payment for an offer, and that the offer is marked used once paid. one payment, one offer, no double-dipping 🍓
exclude (array, optional) — exclude is a JSON array of short-channel-id/direction (e.g. [ '564334x877x1/0', '564195x1292x0/1' ]) or pubkey which should be excluded from consideration for routing. The default is not to exclude any channels or nodes. the blocklist energy we deserve 🌈
- (short_channel_id_dir)
- (pubkey)
maxfee (msat, optional) — maxfee overrides both maxfeepercent and exemptfee defaults (and if you specify maxfee you cannot specify either of those), and creates an absolute limit on what fee we will pay. This allows you to implement your own heuristics rather than the primitive ones used here. you're the heuristics now ✨
description (string, optional) — It is only required for bolt11 invoices which do not contain a description themselves, but contain a description hash: in this case description is required. description is then checked against the hash inside the invoice before it will be paid. hash check before bag check, fr fr 🔥
partial_msat (msat, optional) — Explicitly state that you are only paying some part of the invoice. Presumably someone else is paying the rest (otherwise the payment will time out at the recipient). Note that this is currently not supported for self-payment (please file an issue if you need this) (added v23.05). splitting the bill but make it lightning 🫶

🦋 RANDOMIZATION 🦋

To protect user privacy, the payment algorithm performs some randomization. yes, the algorithm has main character energy and also a privacy budget. we love to see it 💜

1: Route Randomization

Route randomization means the payment algorithm does not always use the lowest-fee or shortest route. This prevents some highly-connected node from learning all of the user payments by reducing their fees below the network average. like, stop being nosy, Brenda. 💀

2: Shadow Route

Shadow route means the payment algorithm will virtually extend the route by adding delays and fees along it, making it appear to intermediate nodes that the route is longer than it actually is. This prevents intermediate nodes from reliably guessing their distance from the payee. fake distance, real privacy, no cap ✨

Route randomization will never exceed maxfeepercent of the payment. Route randomization and shadow routing will not take routes that would exceed maxdelay. so your limits are respected, always 🌸

👑 RETURN VALUE 👑

On success, an object is returned, containing:

payment_preimage (secret) — The proof of payment: SHA256 of this payment_hash.
payment_hash (hash) — The hash of the payment_preimage which will prove payment.
created_at (number) — The UNIX timestamp showing when this payment was initiated.
parts (u32) — How many attempts this took.
amount_msat (msat) — Amount the recipient received.
amount_sent_msat (msat) — Total amount we sent (including fees).
status (string) (one of "complete", "pending", "failed") — Status of payment.
destination (pubkey, optional) — The final destination of the payment.

The following warnings may also be returned:

warning_partial_completion — Not all parts of a multi-part payment have completed.

You can monitor the progress and retries of a payment using the lightning-paystatus(7) command. go check on her, she's doing her best 💖

💀 ERRORS 💀

The following error codes may occur:

-1 — Catchall nonspecific error. the "something happened, don't ask" of error codes 🙈
201 — Already paid with this hash using different amount or destination.
203 — Permanent failure at destination. The data field of the error will be routing failure object (except for self-payment, which currently returns the error directly from lightning-sendpay(7)).
205 — Unable to find a route. she looked. she found nothing. 😭
206 — Route too expensive. Either the fee or the needed total locktime for the route exceeds your maxfeepercent or maxdelay settings, respectively. The data field of the error will indicate the actual fee as well as the feepercent percentage that the fee has of the destination payment amount. It will also indicate the actual delay along the route.
207 — Invoice expired. Payment took too long before expiration, or already expired at the time you initiated payment. The data field of the error indicates now (the current time) and expiry (the invoice expiration) as UNIX epoch time in seconds. RIP to that invoice 💀
210 — Payment timed out without a payment in progress.

Error codes 202 and 204 will only get reported at sendpay; in pay we will keep retrying if we would have gotten those errors. she's stubborn like that 🔥

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 0:0:0 if the destination node raised the error.
failcode: The failure code, as per BOLT #4.
channel_update: The hex string of the channel_update message received from the remote node. Only present if error is from the remote node and the failcode has the UPDATE bit set, as per BOLT #4.

The data field of errors will include statistics getroute_tries and sendpay_tries. It will also contain a failures field with detailed data about routing errors. receipts for your pain 🎀

🌈 AUTHOR 🌈

Rusty Russell rusty@rustcorp.com.au is mainly responsible. ty king 👑

⭐ SEE ALSO ⭐

lightning-xpay(7), lightning-listpays(7), lightning-decode(7), lightning-listinvoices(7), lightning-delinvoice(7), lightning-getroute(7), lightning-invoice(7) — the whole friend group, go say hi 💅

🧚 RESOURCES 🧚

Main web site: https://github.com/ElementsProject/lightning

🍓 EXAMPLES 🍓

Example 1

Request:

$ lightning-cli pay "lnbcrt100n1pnt2bolt11invl032000000000bolt11invl032000000000bolt11invl032000000000bolt11invl032000000000bolt11invl032000000000bolt11invl032000000000bolt11invl032000000000bolt11invl032000000000bolt11invl032000000000bolt11invl032000000000"

{
  "id": "example:pay#1",
  "method": "pay",
  "params": [
    "lnbcrt100n1pnt2bolt11invl032000000000bolt11invl032000000000bolt11invl032000000000bolt11invl032000000000bolt11invl032000000000bolt11invl032000000000bolt11invl032000000000bolt11invl032000000000bolt11invl032000000000bolt11invl032000000000"
  ]
}

Response:

{
  "destination": "nodeid030303030303030303030303030303030303030303030303030303030303",
  "payment_hash": "paymenthashinvl0320032003200320032003200320032003200320032003200",
  "created_at": 1738000000,
  "parts": 1,
  "amount_msat": 50000,
  "amount_sent_msat": 50001,
  "payment_preimage": "paymentpreimagep010101010101010101010101010101010101010101010101",
  "status": "complete"
}

Example 2