While adding BIP21 URI support to ldk-node, I've faced some complexities when URIs include an offer in the lightning parameter.
During testing, I attempted to send a payment with an amount larger than what's available on the channel. Ideally, the lightning parameter with an offer or invoice should fail and move on to the on-chain payment.
When paying a BOLT11 invoice, the PaymentId is returned only if the payment is successful making it easy to handle and move on. However, with BOLT12, sending a payment returns a PaymentId whether the payment is successful or not. We should resolve the difference in behavior between BOLT11 and BOLT12.
When given an offer in the lightning parameter, it would be nice to handle whether the payment was a success or failure before moving on to the next payment option.
While adding BIP21 URI support to ldk-node, I've faced some complexities when URIs include an offer in the lightning parameter.
During testing, I attempted to send a payment with an amount larger than what's available on the channel. Ideally, the lightning parameter with an offer or invoice should fail and move on to the on-chain payment.
When paying a BOLT11 invoice, the
PaymentId
is returned only if the payment is successful making it easy to handle and move on. However, with BOLT12, sending a payment returns aPaymentId
whether the payment is successful or not. We should resolve the difference in behavior between BOLT11 and BOLT12.When given an offer in the lightning parameter, it would be nice to handle whether the payment was a success or failure before moving on to the next payment option.