The sendpay RPC command attempts to send funds associated with the
given payment_hash, along a route to the final destination in the
route.
Generally, a client would call lightning-getroute(7) to resolve a route,
then use sendpay to send it. If it fails, it would call
lightning-getroute(7) again to retry.
The response will occur when the payment is on its way to the
destination. The sendpay RPC command does not wait for definite
success or definite failure of the payment. Instead, use the
waitsendpay RPC command to poll or wait for definite success or
definite failure.
The label and bolt11 parameters, if provided, will be returned in
waitsendpay and listsendpays results.
The msatoshi amount must be provided if partid is non-zero, otherwise
it must be equal to the final
amount to the destination. By default it is in millisatoshi precision; it can be a whole number, or a whole number
ending in msat or sat, or a number with three decimal places ending
in sat, or a number with 1 to 11 decimal places ending in btc.
The payment_secret is the value that the final recipient requires to
accept the payment, as defined by the payment_data field in BOLT 4
and the s field in the BOLT 11 invoice format. It is required if
partid is non-zero.
The partid value, if provided and non-zero, allows for multiple parallel
partial payments with the same payment_hash. The msatoshi amount
(which must be provided) for each sendpay with matching
payment_hash must be equal, and sendpay will fail if there are
already msatoshi worth of payments pending.
The localofferid value indicates that this payment is being made for a local
send_invoice offer: this ensures that we only send a payment for a single-use
offer once.
groupid allows you to attach a number which appears in listsendpays so
payments can be identified as part of a logical group. The pay plugin uses
this to identify one attempt at a MPP payment, for example.
payment_metadata is placed in the final onion hop TLV.
Once a payment has succeeded, calls to sendpay with the same
payment_hash but a different msatoshi or destination will fail;
this prevents accidental multiple payments. Calls to sendpay with
the same payment_hash, msatoshi, and destination as a previous
successful payment (even if a different route or partid) will return immediately
with success.
The sendpay RPC command attempts to send funds associated with the given payment_hash, along a route to the final destination in the route.
Generally, a client would call lightning-getroute(7) to resolve a route, then use sendpay to send it. If it fails, it would call lightning-getroute(7) again to retry.
The response will occur when the payment is on its way to the destination. The sendpay RPC command does not wait for definite success or definite failure of the payment. Instead, use the waitsendpay RPC command to poll or wait for definite success or definite failure.
The label and bolt11 parameters, if provided, will be returned in waitsendpay and listsendpays results.
The msatoshi amount must be provided if partid is non-zero, otherwise it must be equal to the final amount to the destination. By default it is in millisatoshi precision; it can be a whole number, or a whole number ending in msat or sat, or a number with three decimal places ending in sat, or a number with 1 to 11 decimal places ending in btc.
The payment_secret is the value that the final recipient requires to accept the payment, as defined by the
payment_datafield in BOLT 4 and thesfield in the BOLT 11 invoice format. It is required if partid is non-zero.The partid value, if provided and non-zero, allows for multiple parallel partial payments with the same payment_hash. The msatoshi amount (which must be provided) for each sendpay with matching payment_hash must be equal, and sendpay will fail if there are already msatoshi worth of payments pending.
The localofferid value indicates that this payment is being made for a local send_invoice offer: this ensures that we only send a payment for a single-use offer once.
groupid allows you to attach a number which appears in listsendpays so payments can be identified as part of a logical group. The pay plugin uses this to identify one attempt at a MPP payment, for example.
payment_metadata is placed in the final onion hop TLV.
Once a payment has succeeded, calls to sendpay with the same payment_hash but a different msatoshi or destination will fail; this prevents accidental multiple payments. Calls to sendpay with the same payment_hash, msatoshi, and destination as a previous successful payment (even if a different route or partid) will return immediately with success.