Module `Payment`
Payment management RPC methods
Module Payment
RPC module for channel management.
Method send_payment
Sends a payment to a peer.
Params
target_pubkey-Option<[Pubkey](#type-pubkey)>, The public key (Pubkey) of the payment target node, serialized as a hex string. You can obtain a node's pubkey via thenode_infoorgraph_nodesRPC.amount-Option<u128>, the amount of the payment, the unit is Shannons for non UDT payment If not set and there is a invoice, the amount will be set to the invoice amountpayment_hash-Option<[Hash256](#type-hash256)>, the hash to use within the payment's HTLC. If not set andkeysendis set to true, a random hash will be generated. If not set and there is apayment_hashin the invoice, it will be used. Otherwise,payment_hashneed to be set.final_tlc_expiry_delta-Option<u64>, the TLC expiry delta should be used to set the timelock for the final hop, in millisecondstlc_expiry_limit-Option<u64>, the TLC expiry limit for the whole payment, in milliseconds, each hop is with a default tlc delta of 1 day suppose the payment router is with N hops, the total tlc expiry limit is at least (N-1) days this is also the default value for the payment if this parameter is not providedinvoice-Option<String>, the encoded invoice to send to the recipienttimeout-Option<u64>, the payment timeout in seconds, if the payment is not completed within this time, it will be cancelledmax_fee_amount-Option<u128>, the maximum fee amounts in shannons that the sender is willing to pay. Note: In trampoline routing mode, the sender will use the max_fee_amount as the total fee as much as possible.max_fee_rate-Option<u64>, the maximum fee rate per thousand, default is 5 (0.5%)max_parts-Option<u64>, max parts for the payment, only used for multi-part paymentstrampoline_hops-Option<Vec<[Pubkey](#type-pubkey)>>, Optional explicit trampoline hops.
When set to a non-empty list [t1, t2, ...], routing will only find a path from the
payer to t1, and the inner trampoline onion will encode t1 -> t2 -> ... -> final.
keysend-Option<bool>, keysend paymentudt_type_script-Option<Script>, udt type script for the paymentallow_self_payment-Option<bool>, Allow paying yourself through a circular route, default is false. This is useful for channel rebalancing: the payment flows out of one channel and back through another, shifting liquidity between your channels without changing your total balance (only routing fees are deducted). Settarget_pubkeyto your own node pubkey andkeysendtotrueto perform a rebalance. Note:allow_self_paymentis not compatible with trampoline routing.custom_records-Option<[PaymentCustomRecords](#type-paymentcustomrecords)>, Some custom records for the payment which contains a map of u32 to Vec<u8> The key is the record type, and the value is the serialized data For example:
"custom_records": {
"0x1": "0x01020304",
"0x2": "0x05060708",
"0x3": "0x090a0b0c",
"0x4": "0x0d0e0f10010d090a0b0c"
}hop_hints-Option<Vec<[HopHint](#type-hophint)>>, Optional route hints to reach the destination through private channels. Note:- this is only used for the private channels with the last hop.
hop_hintsis only ahintfor routing algorithm, it is not a guarantee that the payment will be routed through the specified channels, it is up to the routing algorithm to decide whether to use the hints or not.
For example (pubkey, channel_outpoint, fee_rate, tlc_expiry_delta) suggest path router
to use the channel of channel_outpoint at hop with pubkey to forward the payment
and the fee rate is fee_rate and tlc_expiry_delta is tlc_expiry_delta.
dry_run-Option<bool>, dry_run for payment, used for check whether we can build valid router and the fee for this payment, it's useful for the sender to double check the payment before sending it to the network, default is false
Returns
payment_hash- Hash256, The payment hash of the paymentstatus- PaymentStatus, The status of the paymentcreated_at-u64, The time the payment was created at, in milliseconds from UNIX epochlast_updated_at-u64, The time the payment was last updated at, in milliseconds from UNIX epochfailed_error-Option<String>, The error message if the payment failedfee-u128, fee paid for the paymentcustom_records-Option<[PaymentCustomRecords](#type-paymentcustomrecords)>, The custom records to be included in the payment.routers-Vec<[SessionRoute](#type-sessionroute)>, The router is a list of nodes that the payment will go through. We store in the payment session and then will use it to track the payment history. If the payment adapted MPP (multi-part payment), the routers will be a list of nodes. For example:A(amount, channel) -> B -> C -> Dmeans A will sendamountwithchannelto B.
Method get_payment
Retrieves a payment.
Params
payment_hash- Hash256, The payment hash of the payment to retrieve
Returns
payment_hash- Hash256, The payment hash of the paymentstatus- PaymentStatus, The status of the paymentcreated_at-u64, The time the payment was created at, in milliseconds from UNIX epochlast_updated_at-u64, The time the payment was last updated at, in milliseconds from UNIX epochfailed_error-Option<String>, The error message if the payment failedfee-u128, fee paid for the paymentcustom_records-Option<[PaymentCustomRecords](#type-paymentcustomrecords)>, The custom records to be included in the payment.routers-Vec<[SessionRoute](#type-sessionroute)>, The router is a list of nodes that the payment will go through. We store in the payment session and then will use it to track the payment history. If the payment adapted MPP (multi-part payment), the routers will be a list of nodes. For example:A(amount, channel) -> B -> C -> Dmeans A will sendamountwithchannelto B.
Method build_router
Builds a router with a list of pubkeys and required channels.
Params
amount-Option<u128>, the amount of the payment, the unit is Shannons for non UDT payment If not set, the minimum routable amount1is usedudt_type_script-Option<Script>, udt type script for the payment routerhops_info-Vec<[HopRequire](#type-hoprequire)>, A list of hops that defines the route. This does not include the source hop pubkey. A hop info is a tuple of pubkey and the channel(specified by channel funding tx) will be used. This is a strong restriction given on payment router, which means these specified hops and channels must be adapted in the router. This is different from hop hints, which maybe ignored by find path. If channel is not specified, find path algorithm will pick a channel within these two peers.
An error will be returned if there is no router could be build from given hops and channels
final_tlc_expiry_delta-Option<u64>, the TLC expiry delta should be used to set the timelock for the final hop, in milliseconds
Returns
router_hops-Vec<[RouterHop](#type-routerhop)>, The hops information for router
Method send_payment_with_router
Sends a payment to a peer with specified router. This method differs from SendPayment in that it allows users to specify a full route manually.
A typical use case is channel rebalancing: you can construct a circular route (your node -> intermediate nodes -> your node) to shift liquidity between your channels.
To rebalance, follow these steps:
- Call
build_routerwithhops_infodefining the circular route you want, e.g. your_node -> peer_A -> peer_B -> your_node. - Call
send_payment_with_routerwith the returnedrouter_hopsandkeysend: true.
Only routing fees are deducted; your total balance across channels remains the same.
Params
payment_hash-Option<[Hash256](#type-hash256)>, the hash to use within the payment's HTLC. If not set andkeysendis set to true, a random hash will be generated. If not set and there is apayment_hashin the invoice, it will be used. Otherwise,payment_hashneed to be set.router-Vec<[RouterHop](#type-routerhop)>, The router to use for the paymentinvoice-Option<String>, the encoded invoice to send to the recipientcustom_records-Option<[PaymentCustomRecords](#type-paymentcustomrecords)>, Some custom records for the payment which contains a map of u32 to Vec<u8> The key is the record type, and the value is the serialized data. Limits: the sum size of values can not exceed 2048 bytes.
For example:
"custom_records": {
"0x1": "0x01020304",
"0x2": "0x05060708",
"0x3": "0x090a0b0c",
"0x4": "0x0d0e0f10010d090a0b0c"
}keysend-Option<bool>, keysend paymentudt_type_script-Option<Script>, udt type script for the paymentdry_run-Option<bool>, dry_run for payment, used for check whether we can build valid router and the fee for this payment, it's useful for the sender to double check the payment before sending it to the network, default is false
Returns
payment_hash- Hash256, The payment hash of the paymentstatus- PaymentStatus, The status of the paymentcreated_at-u64, The time the payment was created at, in milliseconds from UNIX epochlast_updated_at-u64, The time the payment was last updated at, in milliseconds from UNIX epochfailed_error-Option<String>, The error message if the payment failedfee-u128, fee paid for the paymentcustom_records-Option<[PaymentCustomRecords](#type-paymentcustomrecords)>, The custom records to be included in the payment.routers-Vec<[SessionRoute](#type-sessionroute)>, The router is a list of nodes that the payment will go through. We store in the payment session and then will use it to track the payment history. If the payment adapted MPP (multi-part payment), the routers will be a list of nodes. For example:A(amount, channel) -> B -> C -> Dmeans A will sendamountwithchannelto B.
Method list_payments
Lists all payments, optionally filtered by status.
Params
status-Option<[PaymentStatus](#type-paymentstatus)>, Filter payments by status. If not set, all payments are returned.limit-Option<u64>, The maximum number of payments to return. Default is 15.after-Option<[Hash256](#type-hash256)>, The payment hash to start returning payments after (exclusive cursor for pagination).
Returns
payments-Vec<[GetPaymentCommandResult](#type-getpaymentcommandresult)>, The list of payments.last_cursor-Option<[Hash256](#type-hash256)>, The last cursor for pagination. Use this asafterin the next request to get more results.