forked from ElementsProject/lightning
-
Notifications
You must be signed in to change notification settings - Fork 0
/
lightning-pay.7.txt
125 lines (104 loc) · 4.74 KB
/
lightning-pay.7.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
LIGHTNING-PAY(7)
================
:doctype: manpage
NAME
----
lightning-pay - Command for sending a payment to a BOLT11 invoice
SYNOPSIS
--------
*pay* 'bolt11' ['msatoshi'] ['description'] ['riskfactor'] ['maxfeepercent'] ['retry_for'] ['maxdelay']
DESCRIPTION
-----------
The *pay* RPC command attempts to find a route to the given destination,
and send the funds it asks for. If the 'bolt11' does not contain an amount,
'msatoshi' is required, otherwise if it is specified it must be 'null'. If
'bolt11' contains a description hash ('h' field) 'description' is
required, otherwise it is unused. The 'riskfactor' is described in detail
in lightning-getroute(7), and defaults to 1.0.
The 'maxfeepercent' limits the money paid in fees, and defaults to 0.5.
The `maxfeepercent' is a percentage of the amount that is to be
paid.
The `exemptfee` 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`
(default: 5000 millsatoshi).
The *pay* RPC command will randomize routes slightly, as long as the
route achieves the targeted 'maxfeepercent' and 'maxdelay'.
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.
The command will keep finding routes and retrying the payment until
it succeeds, or the given 'retry_for' seconds passes.
Note that the command may stop retrying while a pending payment is
ongoing, which you need to monitor with *listpayments* or *waitsendpay*.
'retry_for' defaults to 60 seconds and can only be an integer.
When using 'lightning-cli', you may skip optional parameters by using
'null'.
Alternatively, use *-k* option to provide parameters by name.
RETURN VALUE
------------
On success, this returns the payment 'preimage' which hashes to the
'payment_hash' to prove that the payment was successful.
It will also return, a 'getroute_tries' and a 'sendpay_tries'
statistics for the number of times it internally called *getroute*
and *sendpay*.
On error, if the error occurred from a node other than the final
destination, the route table will be updated so that getroute(7)
should return an alternate route (if any). An error from the final
destination implies the payment should not be retried.
The following error codes may occur:
* -1. Catchall nonspecific error.
* 200. Payment timed out while a payment is in progress. Monitor
the status of that payment with 'listpayments' command, or
wait for that payment to complete with 'pay' command.
* 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.
* 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.
AUTHOR
------
Rusty Russell <rusty@rustcorp.com.au> is mainly responsible.
SEE ALSO
--------
lightning-listpayments(7), lightning-decodepay(7),
lightning-listinvoice(7), lightning-delinvoice(7),
lightning-getroute(7), lightning-invoice(7).
RESOURCES
---------
Main web site: https://github.com/ElementsProject/lightning