lightning-pay -- Command for sending a payment to a BOLT11
  invoice
pay bolt11 [amount_msat] [label]
    [riskfactor] [maxfeepercent] [retry_for]
    [maxdelay] [exemptfee] [localinvreqid] [exclude]
    [maxfee] [description] [partial_msat]
The pay RPC command attempts to find a route to the given
    destination, and send the funds it asks for. .
The response will occur when the payment fails or succeeds. Once a
    payment has succeeded, calls to pay with the same bolt11 will
    succeed immediately.
When using $ lightning-cli, you may skip optional
    parameters by using null. Alternatively, use -k option to
    provide parameters by name.
  - bolt11 (string): 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.
    
  
- 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.
    
  
- label (string, optional): It is used to attach a label to payments,
      and is returned in lightning- listpays(7) and lightning-listsendpays(7).
    
  
- 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.
    
  
- maxdelay (u16, optional): A payment may be delayed for up to
      maxdelay blocks by another node; clients should be
      prepared for this worst case.
    
  
- 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.
    
  
- 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.
    
  
- 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.:
  - (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.
    
  
- 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.
    
  
- 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)
To protect user privacy, the payment algorithm performs some
    randomization.
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.
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.
Route randomization will never exceed maxfeepercent of the
    payment. Route randomization and shadow routing will not take routes that
    would exceed maxdelay.
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.
The following error codes may occur:
  - -1: Catchall nonspecific error.
    
  
- 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.
    
  
- 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.
    
  
- 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.
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.
lightning-listpays(7), lightning-decodepay(7),
    lightning-listinvoices(7), lightning-delinvoice(7), lightning-getroute(7),
    lightning-invoice(7)
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:
Request:
$ lightning-cli pay -k "bolt11"="lnbcrt100n1pnt2bolt11invl030300000000bolt11invl030300000000bolt11invl030300000000bolt11invl030300000000bolt11invl030300000000bolt11invl030300000000bolt11invl030300000000bolt11invl030300000000bolt11invl030300000000bolt11invl030300000000"
{
  "id": "example:pay#2",
  "method": "pay",
  "params": {
    "bolt11": "lnbcrt100n1pnt2bolt11invl030300000000bolt11invl030300000000bolt11invl030300000000bolt11invl030300000000bolt11invl030300000000bolt11invl030300000000bolt11invl030300000000bolt11invl030300000000bolt11invl030300000000bolt11invl030300000000"
  }
}
Response:
{
  "destination": "nodeid030303030303030303030303030303030303030303030303030303030303",
  "payment_hash": "paymenthashinvl0330033003300330033003300330033003300330033003300",
  "created_at": 1738000000,
  "parts": 1,
  "amount_msat": 100000,
  "amount_sent_msat": 100000,
  "payment_preimage": "paymentpreimagep020202020202020202020202020202020202020202020202",
  "status": "complete"
}