Add cancel_invoice to Bolt11Payment by benthecarman · Pull Request #846 · lightningdevkit/ldk-node

benthecarman · 2026-03-25T20:03:19Z

Allow cancelling a previously created BOLT11 invoice by payment hash. Enterprise integrators need this when they short-circuit an invoice with an internal database transfer or when an alternative payment method is used (e.g., on-chain payment via unified URI).

The PaymentClaimable event handler rejects HTLCs for cancelled invoices only when the preimage is known (auto-claim payments), preserving retry behavior for manual-claim (_for_hash) payments.

fail_for_hash already did the logic we needed so cancel_invoice just does a little bit extra pre-validation and then calls it. Could make the argument to just use fail_for_hash, update its docs, and the if statement to reject payments mark as failed in the PaymentClaimable. The only functionality change would be that if someone retries to do a payment after a fail_for_hash, we don't let the user evaluate again.

ldk-reviews-bot · 2026-03-25T20:03:23Z

I've assigned @tnull as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

Allow canceling a previously created BOLT11 invoice by payment hash. Enterprise integrators need this when they short-circuit an invoice with an internal database transfer or when an alternative payment method is used (e.g., on-chain payment via unified URI). cancel_invoice validates the payment is inbound and unclaimed, then delegates to fail_for_hash for the shared logic of marking the payment as failed and failing back any pending HTLCs. The PaymentClaimable event handler rejects HTLCs for cancelled invoices only when the preimage is known (auto-claim payments), preserving retry behavior for manual-claim (_for_hash) payments. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

tnull · 2026-03-26T07:14:03Z

+	///
+	/// Will check that the payment is known and has not already been claimed, and will return an
+	/// error otherwise.
+	pub fn cancel_invoice(&self, payment_hash: PaymentHash) -> Result<(), Error> {


Hmm, I always found LND's terminology of 'cancelling an invoice' very confusing. In LDK Node it's even more so confusing as we don't store invoices (yet, cf. #811), so I really don't know what 'cancelling an invoice' is supposed to mean in this context.
As part of the move towards the payment metadata store we will also finally stop tracking expected inbound BOLT11 payments in the payment store (but then rather store the actual invoices/offers for the user), which means the logic in the event handler won't work as it does now. Let me see to finish #811 and #784 finally, and then we can decide how invoice 'cancellation' could make the most sense.
Somewhat orthogonally I do wonder if it would be best to actually do this properly in LDK, i.e., add a remove_payment method on ChannelManager that has it forget the preimage, simply?

Somewhat orthogonally I do wonder if it would be best to actually do this properly in LDK, i.e., add a remove_payment method on ChannelManager that has it forget the preimage, simply?
I don't think that is possible, invoice creation is stateless, its not storing the preimage.

IMO this whole concept is an anti-pattern. If someone wants to pay you extra money in LN you cannot stop them, there are a number of ways in which they can do it, and we're not gonna try to close them all. Further, storing invoices/offers before they're paid is an anti-pattern - creation is stateless for a reason, and tons of people are going to expose APIs where you can request an invoice be created, suddenly subjecting yourself to arbitrary DoS attacks filling your payment store. Unless you actually have to pay for it, free DoS is a really shitty API.

I don't think that is possible, invoice creation is stateless, its not storing the preimage.
Ah, lol, true.
IMO this whole concept is an anti-pattern.
+1 on this, though users seem to expect to have the functionality by now (see elsewhere). But probably we should simply push back on that.
Further, storing invoices/offers before they're paid is an anti-patter
Well, that in turn has been a big feature request by users for a long time now. And someone will need to store the invoice/offers so just handing the responsibility to the user doesn't actually solve the issue necessarily. In our case we also need to store some metadata based on the payment type (pre-negotiated LSP fees, but preimages could also count towards that). So we will add storage for it, but will attempt to make it optional (cf. #51).

Well, that in turn has been a big feature request by users for a long time now. And someone will need to store the invoice/offers so just handing the responsibility to the user doesn't actually solve the issue necessarily.
I'd like to better understand the use-cases here. For something like a merchant running an online store, their current architecture probably includes storing invoices/payment hashes in their payments/orders db already, so that when they receive a payment they can match it to the order. LDK Node (or any lightning node) could of course allow the downstream logic to store additional metadata in a payment store around an invoice, allowing the matching to be done by putting the order id in the lightning node, but you still have that order information elsewhere.
If we end up offering storage to downstream code in an invoice store, though, we should actually not store it at all and put it in the invoice payment-metadata. I think its now been more than long enough that that is likely reliably usable on the network, and it avoids storing entirely, at the cost of being rather data limited because it ends up in the QR code and onion. This only works for the "store only an order id" usecase, not full order info.
Are there other reasons why people want to store the full generated-invoice history?
In our case we also need to store some metadata based on the payment type (pre-negotiated LSP fees, but preimages could also count towards that). So we will add storage for it, but will attempt to make it optional (cf. #51).
If its small enough, this seems like a great use for payment metadata. We might want to have the payment secret commit to the (encrypted, but not-MAC'd) payment metadata, though...

benthecarman · 2026-03-25T20:03:19Z

Allow cancelling a previously created BOLT11 invoice by payment hash. Enterprise integrators need this when they short-circuit an invoice with an internal database transfer or when an alternative payment method is used (e.g., on-chain payment via unified URI).

The PaymentClaimable event handler rejects HTLCs for cancelled invoices only when the preimage is known (auto-claim payments), preserving retry behavior for manual-claim (_for_hash) payments.

fail_for_hash already did the logic we needed so cancel_invoice just does a little bit extra pre-validation and then calls it. Could make the argument to just use fail_for_hash, update its docs, and the if statement to reject payments mark as failed in the PaymentClaimable. The only functionality change would be that if someone retries to do a payment after a fail_for_hash, we don't let the user evaluate again.

ldk-reviews-bot · 2026-03-25T20:03:23Z

I've assigned @tnull as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

Allow canceling a previously created BOLT11 invoice by payment hash. Enterprise integrators need this when they short-circuit an invoice with an internal database transfer or when an alternative payment method is used (e.g., on-chain payment via unified URI). cancel_invoice validates the payment is inbound and unclaimed, then delegates to fail_for_hash for the shared logic of marking the payment as failed and failing back any pending HTLCs. The PaymentClaimable event handler rejects HTLCs for cancelled invoices only when the preimage is known (auto-claim payments), preserving retry behavior for manual-claim (_for_hash) payments. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

tnull · 2026-03-26T07:14:03Z

+	///
+	/// Will check that the payment is known and has not already been claimed, and will return an
+	/// error otherwise.
+	pub fn cancel_invoice(&self, payment_hash: PaymentHash) -> Result<(), Error> {


Hmm, I always found LND's terminology of 'cancelling an invoice' very confusing. In LDK Node it's even more so confusing as we don't store invoices (yet, cf. #811), so I really don't know what 'cancelling an invoice' is supposed to mean in this context.
As part of the move towards the payment metadata store we will also finally stop tracking expected inbound BOLT11 payments in the payment store (but then rather store the actual invoices/offers for the user), which means the logic in the event handler won't work as it does now. Let me see to finish #811 and #784 finally, and then we can decide how invoice 'cancellation' could make the most sense.
Somewhat orthogonally I do wonder if it would be best to actually do this properly in LDK, i.e., add a remove_payment method on ChannelManager that has it forget the preimage, simply?

Somewhat orthogonally I do wonder if it would be best to actually do this properly in LDK, i.e., add a remove_payment method on ChannelManager that has it forget the preimage, simply?
I don't think that is possible, invoice creation is stateless, its not storing the preimage.

IMO this whole concept is an anti-pattern. If someone wants to pay you extra money in LN you cannot stop them, there are a number of ways in which they can do it, and we're not gonna try to close them all. Further, storing invoices/offers before they're paid is an anti-pattern - creation is stateless for a reason, and tons of people are going to expose APIs where you can request an invoice be created, suddenly subjecting yourself to arbitrary DoS attacks filling your payment store. Unless you actually have to pay for it, free DoS is a really shitty API.

I don't think that is possible, invoice creation is stateless, its not storing the preimage.
Ah, lol, true.
IMO this whole concept is an anti-pattern.
+1 on this, though users seem to expect to have the functionality by now (see elsewhere). But probably we should simply push back on that.
Further, storing invoices/offers before they're paid is an anti-patter
Well, that in turn has been a big feature request by users for a long time now. And someone will need to store the invoice/offers so just handing the responsibility to the user doesn't actually solve the issue necessarily. In our case we also need to store some metadata based on the payment type (pre-negotiated LSP fees, but preimages could also count towards that). So we will add storage for it, but will attempt to make it optional (cf. #51).

Well, that in turn has been a big feature request by users for a long time now. And someone will need to store the invoice/offers so just handing the responsibility to the user doesn't actually solve the issue necessarily.
I'd like to better understand the use-cases here. For something like a merchant running an online store, their current architecture probably includes storing invoices/payment hashes in their payments/orders db already, so that when they receive a payment they can match it to the order. LDK Node (or any lightning node) could of course allow the downstream logic to store additional metadata in a payment store around an invoice, allowing the matching to be done by putting the order id in the lightning node, but you still have that order information elsewhere.
If we end up offering storage to downstream code in an invoice store, though, we should actually not store it at all and put it in the invoice payment-metadata. I think its now been more than long enough that that is likely reliably usable on the network, and it avoids storing entirely, at the cost of being rather data limited because it ends up in the QR code and onion. This only works for the "store only an order id" usecase, not full order info.
Are there other reasons why people want to store the full generated-invoice history?
In our case we also need to store some metadata based on the payment type (pre-negotiated LSP fees, but preimages could also count towards that). So we will add storage for it, but will attempt to make it optional (cf. #51).
If its small enough, this seems like a great use for payment metadata. We might want to have the payment secret commit to the (encrypted, but not-MAC'd) payment metadata, though...

benthecarman · 2026-03-25T20:03:19Z

Allow cancelling a previously created BOLT11 invoice by payment hash. Enterprise integrators need this when they short-circuit an invoice with an internal database transfer or when an alternative payment method is used (e.g., on-chain payment via unified URI).

The PaymentClaimable event handler rejects HTLCs for cancelled invoices only when the preimage is known (auto-claim payments), preserving retry behavior for manual-claim (_for_hash) payments.

fail_for_hash already did the logic we needed so cancel_invoice just does a little bit extra pre-validation and then calls it. Could make the argument to just use fail_for_hash, update its docs, and the if statement to reject payments mark as failed in the PaymentClaimable. The only functionality change would be that if someone retries to do a payment after a fail_for_hash, we don't let the user evaluate again.

ldk-reviews-bot · 2026-03-25T20:03:23Z

I've assigned @tnull as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

Allow canceling a previously created BOLT11 invoice by payment hash. Enterprise integrators need this when they short-circuit an invoice with an internal database transfer or when an alternative payment method is used (e.g., on-chain payment via unified URI). cancel_invoice validates the payment is inbound and unclaimed, then delegates to fail_for_hash for the shared logic of marking the payment as failed and failing back any pending HTLCs. The PaymentClaimable event handler rejects HTLCs for cancelled invoices only when the preimage is known (auto-claim payments), preserving retry behavior for manual-claim (_for_hash) payments. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

tnull · 2026-03-26T07:14:03Z

+	///
+	/// Will check that the payment is known and has not already been claimed, and will return an
+	/// error otherwise.
+	pub fn cancel_invoice(&self, payment_hash: PaymentHash) -> Result<(), Error> {


Hmm, I always found LND's terminology of 'cancelling an invoice' very confusing. In LDK Node it's even more so confusing as we don't store invoices (yet, cf. #811), so I really don't know what 'cancelling an invoice' is supposed to mean in this context.
As part of the move towards the payment metadata store we will also finally stop tracking expected inbound BOLT11 payments in the payment store (but then rather store the actual invoices/offers for the user), which means the logic in the event handler won't work as it does now. Let me see to finish #811 and #784 finally, and then we can decide how invoice 'cancellation' could make the most sense.
Somewhat orthogonally I do wonder if it would be best to actually do this properly in LDK, i.e., add a remove_payment method on ChannelManager that has it forget the preimage, simply?

Somewhat orthogonally I do wonder if it would be best to actually do this properly in LDK, i.e., add a remove_payment method on ChannelManager that has it forget the preimage, simply?
I don't think that is possible, invoice creation is stateless, its not storing the preimage.

IMO this whole concept is an anti-pattern. If someone wants to pay you extra money in LN you cannot stop them, there are a number of ways in which they can do it, and we're not gonna try to close them all. Further, storing invoices/offers before they're paid is an anti-pattern - creation is stateless for a reason, and tons of people are going to expose APIs where you can request an invoice be created, suddenly subjecting yourself to arbitrary DoS attacks filling your payment store. Unless you actually have to pay for it, free DoS is a really shitty API.

I don't think that is possible, invoice creation is stateless, its not storing the preimage.
Ah, lol, true.
IMO this whole concept is an anti-pattern.
+1 on this, though users seem to expect to have the functionality by now (see elsewhere). But probably we should simply push back on that.
Further, storing invoices/offers before they're paid is an anti-patter
Well, that in turn has been a big feature request by users for a long time now. And someone will need to store the invoice/offers so just handing the responsibility to the user doesn't actually solve the issue necessarily. In our case we also need to store some metadata based on the payment type (pre-negotiated LSP fees, but preimages could also count towards that). So we will add storage for it, but will attempt to make it optional (cf. #51).

Well, that in turn has been a big feature request by users for a long time now. And someone will need to store the invoice/offers so just handing the responsibility to the user doesn't actually solve the issue necessarily.
I'd like to better understand the use-cases here. For something like a merchant running an online store, their current architecture probably includes storing invoices/payment hashes in their payments/orders db already, so that when they receive a payment they can match it to the order. LDK Node (or any lightning node) could of course allow the downstream logic to store additional metadata in a payment store around an invoice, allowing the matching to be done by putting the order id in the lightning node, but you still have that order information elsewhere.
If we end up offering storage to downstream code in an invoice store, though, we should actually not store it at all and put it in the invoice payment-metadata. I think its now been more than long enough that that is likely reliably usable on the network, and it avoids storing entirely, at the cost of being rather data limited because it ends up in the QR code and onion. This only works for the "store only an order id" usecase, not full order info.
Are there other reasons why people want to store the full generated-invoice history?
In our case we also need to store some metadata based on the payment type (pre-negotiated LSP fees, but preimages could also count towards that). So we will add storage for it, but will attempt to make it optional (cf. #51).
If its small enough, this seems like a great use for payment metadata. We might want to have the payment secret commit to the (encrypted, but not-MAC'd) payment metadata, though...

benthecarman · 2026-03-25T20:03:19Z

Allow cancelling a previously created BOLT11 invoice by payment hash. Enterprise integrators need this when they short-circuit an invoice with an internal database transfer or when an alternative payment method is used (e.g., on-chain payment via unified URI).

The PaymentClaimable event handler rejects HTLCs for cancelled invoices only when the preimage is known (auto-claim payments), preserving retry behavior for manual-claim (_for_hash) payments.

fail_for_hash already did the logic we needed so cancel_invoice just does a little bit extra pre-validation and then calls it. Could make the argument to just use fail_for_hash, update its docs, and the if statement to reject payments mark as failed in the PaymentClaimable. The only functionality change would be that if someone retries to do a payment after a fail_for_hash, we don't let the user evaluate again.

ldk-reviews-bot · 2026-03-25T20:03:23Z

I've assigned @tnull as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

Allow canceling a previously created BOLT11 invoice by payment hash. Enterprise integrators need this when they short-circuit an invoice with an internal database transfer or when an alternative payment method is used (e.g., on-chain payment via unified URI). cancel_invoice validates the payment is inbound and unclaimed, then delegates to fail_for_hash for the shared logic of marking the payment as failed and failing back any pending HTLCs. The PaymentClaimable event handler rejects HTLCs for cancelled invoices only when the preimage is known (auto-claim payments), preserving retry behavior for manual-claim (_for_hash) payments. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

tnull · 2026-03-26T07:14:03Z

+	///
+	/// Will check that the payment is known and has not already been claimed, and will return an
+	/// error otherwise.
+	pub fn cancel_invoice(&self, payment_hash: PaymentHash) -> Result<(), Error> {


Hmm, I always found LND's terminology of 'cancelling an invoice' very confusing. In LDK Node it's even more so confusing as we don't store invoices (yet, cf. #811), so I really don't know what 'cancelling an invoice' is supposed to mean in this context.
As part of the move towards the payment metadata store we will also finally stop tracking expected inbound BOLT11 payments in the payment store (but then rather store the actual invoices/offers for the user), which means the logic in the event handler won't work as it does now. Let me see to finish #811 and #784 finally, and then we can decide how invoice 'cancellation' could make the most sense.
Somewhat orthogonally I do wonder if it would be best to actually do this properly in LDK, i.e., add a remove_payment method on ChannelManager that has it forget the preimage, simply?

Somewhat orthogonally I do wonder if it would be best to actually do this properly in LDK, i.e., add a remove_payment method on ChannelManager that has it forget the preimage, simply?
I don't think that is possible, invoice creation is stateless, its not storing the preimage.

IMO this whole concept is an anti-pattern. If someone wants to pay you extra money in LN you cannot stop them, there are a number of ways in which they can do it, and we're not gonna try to close them all. Further, storing invoices/offers before they're paid is an anti-pattern - creation is stateless for a reason, and tons of people are going to expose APIs where you can request an invoice be created, suddenly subjecting yourself to arbitrary DoS attacks filling your payment store. Unless you actually have to pay for it, free DoS is a really shitty API.

I don't think that is possible, invoice creation is stateless, its not storing the preimage.
Ah, lol, true.
IMO this whole concept is an anti-pattern.
+1 on this, though users seem to expect to have the functionality by now (see elsewhere). But probably we should simply push back on that.
Further, storing invoices/offers before they're paid is an anti-patter
Well, that in turn has been a big feature request by users for a long time now. And someone will need to store the invoice/offers so just handing the responsibility to the user doesn't actually solve the issue necessarily. In our case we also need to store some metadata based on the payment type (pre-negotiated LSP fees, but preimages could also count towards that). So we will add storage for it, but will attempt to make it optional (cf. #51).

Well, that in turn has been a big feature request by users for a long time now. And someone will need to store the invoice/offers so just handing the responsibility to the user doesn't actually solve the issue necessarily.
I'd like to better understand the use-cases here. For something like a merchant running an online store, their current architecture probably includes storing invoices/payment hashes in their payments/orders db already, so that when they receive a payment they can match it to the order. LDK Node (or any lightning node) could of course allow the downstream logic to store additional metadata in a payment store around an invoice, allowing the matching to be done by putting the order id in the lightning node, but you still have that order information elsewhere.
If we end up offering storage to downstream code in an invoice store, though, we should actually not store it at all and put it in the invoice payment-metadata. I think its now been more than long enough that that is likely reliably usable on the network, and it avoids storing entirely, at the cost of being rather data limited because it ends up in the QR code and onion. This only works for the "store only an order id" usecase, not full order info.
Are there other reasons why people want to store the full generated-invoice history?
In our case we also need to store some metadata based on the payment type (pre-negotiated LSP fees, but preimages could also count towards that). So we will add storage for it, but will attempt to make it optional (cf. #51).
If its small enough, this seems like a great use for payment metadata. We might want to have the payment secret commit to the (encrypted, but not-MAC'd) payment metadata, though...

benthecarman · 2026-03-25T20:03:19Z

Allow cancelling a previously created BOLT11 invoice by payment hash. Enterprise integrators need this when they short-circuit an invoice with an internal database transfer or when an alternative payment method is used (e.g., on-chain payment via unified URI).

The PaymentClaimable event handler rejects HTLCs for cancelled invoices only when the preimage is known (auto-claim payments), preserving retry behavior for manual-claim (_for_hash) payments.

fail_for_hash already did the logic we needed so cancel_invoice just does a little bit extra pre-validation and then calls it. Could make the argument to just use fail_for_hash, update its docs, and the if statement to reject payments mark as failed in the PaymentClaimable. The only functionality change would be that if someone retries to do a payment after a fail_for_hash, we don't let the user evaluate again.

ldk-reviews-bot · 2026-03-25T20:03:23Z

I've assigned @tnull as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

Allow canceling a previously created BOLT11 invoice by payment hash. Enterprise integrators need this when they short-circuit an invoice with an internal database transfer or when an alternative payment method is used (e.g., on-chain payment via unified URI). cancel_invoice validates the payment is inbound and unclaimed, then delegates to fail_for_hash for the shared logic of marking the payment as failed and failing back any pending HTLCs. The PaymentClaimable event handler rejects HTLCs for cancelled invoices only when the preimage is known (auto-claim payments), preserving retry behavior for manual-claim (_for_hash) payments. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

tnull · 2026-03-26T07:14:03Z

+	///
+	/// Will check that the payment is known and has not already been claimed, and will return an
+	/// error otherwise.
+	pub fn cancel_invoice(&self, payment_hash: PaymentHash) -> Result<(), Error> {


Hmm, I always found LND's terminology of 'cancelling an invoice' very confusing. In LDK Node it's even more so confusing as we don't store invoices (yet, cf. #811), so I really don't know what 'cancelling an invoice' is supposed to mean in this context.
As part of the move towards the payment metadata store we will also finally stop tracking expected inbound BOLT11 payments in the payment store (but then rather store the actual invoices/offers for the user), which means the logic in the event handler won't work as it does now. Let me see to finish #811 and #784 finally, and then we can decide how invoice 'cancellation' could make the most sense.
Somewhat orthogonally I do wonder if it would be best to actually do this properly in LDK, i.e., add a remove_payment method on ChannelManager that has it forget the preimage, simply?

Somewhat orthogonally I do wonder if it would be best to actually do this properly in LDK, i.e., add a remove_payment method on ChannelManager that has it forget the preimage, simply?
I don't think that is possible, invoice creation is stateless, its not storing the preimage.

IMO this whole concept is an anti-pattern. If someone wants to pay you extra money in LN you cannot stop them, there are a number of ways in which they can do it, and we're not gonna try to close them all. Further, storing invoices/offers before they're paid is an anti-pattern - creation is stateless for a reason, and tons of people are going to expose APIs where you can request an invoice be created, suddenly subjecting yourself to arbitrary DoS attacks filling your payment store. Unless you actually have to pay for it, free DoS is a really shitty API.

I don't think that is possible, invoice creation is stateless, its not storing the preimage.
Ah, lol, true.
IMO this whole concept is an anti-pattern.
+1 on this, though users seem to expect to have the functionality by now (see elsewhere). But probably we should simply push back on that.
Further, storing invoices/offers before they're paid is an anti-patter
Well, that in turn has been a big feature request by users for a long time now. And someone will need to store the invoice/offers so just handing the responsibility to the user doesn't actually solve the issue necessarily. In our case we also need to store some metadata based on the payment type (pre-negotiated LSP fees, but preimages could also count towards that). So we will add storage for it, but will attempt to make it optional (cf. #51).

Well, that in turn has been a big feature request by users for a long time now. And someone will need to store the invoice/offers so just handing the responsibility to the user doesn't actually solve the issue necessarily.
I'd like to better understand the use-cases here. For something like a merchant running an online store, their current architecture probably includes storing invoices/payment hashes in their payments/orders db already, so that when they receive a payment they can match it to the order. LDK Node (or any lightning node) could of course allow the downstream logic to store additional metadata in a payment store around an invoice, allowing the matching to be done by putting the order id in the lightning node, but you still have that order information elsewhere.
If we end up offering storage to downstream code in an invoice store, though, we should actually not store it at all and put it in the invoice payment-metadata. I think its now been more than long enough that that is likely reliably usable on the network, and it avoids storing entirely, at the cost of being rather data limited because it ends up in the QR code and onion. This only works for the "store only an order id" usecase, not full order info.
Are there other reasons why people want to store the full generated-invoice history?
In our case we also need to store some metadata based on the payment type (pre-negotiated LSP fees, but preimages could also count towards that). So we will add storage for it, but will attempt to make it optional (cf. #51).
If its small enough, this seems like a great use for payment metadata. We might want to have the payment secret commit to the (encrypted, but not-MAC'd) payment metadata, though...

benthecarman · 2026-03-25T20:03:19Z

Allow cancelling a previously created BOLT11 invoice by payment hash. Enterprise integrators need this when they short-circuit an invoice with an internal database transfer or when an alternative payment method is used (e.g., on-chain payment via unified URI).

The PaymentClaimable event handler rejects HTLCs for cancelled invoices only when the preimage is known (auto-claim payments), preserving retry behavior for manual-claim (_for_hash) payments.

fail_for_hash already did the logic we needed so cancel_invoice just does a little bit extra pre-validation and then calls it. Could make the argument to just use fail_for_hash, update its docs, and the if statement to reject payments mark as failed in the PaymentClaimable. The only functionality change would be that if someone retries to do a payment after a fail_for_hash, we don't let the user evaluate again.

ldk-reviews-bot · 2026-03-25T20:03:23Z

I've assigned @tnull as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

Allow canceling a previously created BOLT11 invoice by payment hash. Enterprise integrators need this when they short-circuit an invoice with an internal database transfer or when an alternative payment method is used (e.g., on-chain payment via unified URI). cancel_invoice validates the payment is inbound and unclaimed, then delegates to fail_for_hash for the shared logic of marking the payment as failed and failing back any pending HTLCs. The PaymentClaimable event handler rejects HTLCs for cancelled invoices only when the preimage is known (auto-claim payments), preserving retry behavior for manual-claim (_for_hash) payments. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

tnull · 2026-03-26T07:14:03Z

+	///
+	/// Will check that the payment is known and has not already been claimed, and will return an
+	/// error otherwise.
+	pub fn cancel_invoice(&self, payment_hash: PaymentHash) -> Result<(), Error> {


Hmm, I always found LND's terminology of 'cancelling an invoice' very confusing. In LDK Node it's even more so confusing as we don't store invoices (yet, cf. #811), so I really don't know what 'cancelling an invoice' is supposed to mean in this context.
As part of the move towards the payment metadata store we will also finally stop tracking expected inbound BOLT11 payments in the payment store (but then rather store the actual invoices/offers for the user), which means the logic in the event handler won't work as it does now. Let me see to finish #811 and #784 finally, and then we can decide how invoice 'cancellation' could make the most sense.
Somewhat orthogonally I do wonder if it would be best to actually do this properly in LDK, i.e., add a remove_payment method on ChannelManager that has it forget the preimage, simply?

Somewhat orthogonally I do wonder if it would be best to actually do this properly in LDK, i.e., add a remove_payment method on ChannelManager that has it forget the preimage, simply?
I don't think that is possible, invoice creation is stateless, its not storing the preimage.

IMO this whole concept is an anti-pattern. If someone wants to pay you extra money in LN you cannot stop them, there are a number of ways in which they can do it, and we're not gonna try to close them all. Further, storing invoices/offers before they're paid is an anti-pattern - creation is stateless for a reason, and tons of people are going to expose APIs where you can request an invoice be created, suddenly subjecting yourself to arbitrary DoS attacks filling your payment store. Unless you actually have to pay for it, free DoS is a really shitty API.

I don't think that is possible, invoice creation is stateless, its not storing the preimage.
Ah, lol, true.
IMO this whole concept is an anti-pattern.
+1 on this, though users seem to expect to have the functionality by now (see elsewhere). But probably we should simply push back on that.
Further, storing invoices/offers before they're paid is an anti-patter
Well, that in turn has been a big feature request by users for a long time now. And someone will need to store the invoice/offers so just handing the responsibility to the user doesn't actually solve the issue necessarily. In our case we also need to store some metadata based on the payment type (pre-negotiated LSP fees, but preimages could also count towards that). So we will add storage for it, but will attempt to make it optional (cf. #51).

Well, that in turn has been a big feature request by users for a long time now. And someone will need to store the invoice/offers so just handing the responsibility to the user doesn't actually solve the issue necessarily.
I'd like to better understand the use-cases here. For something like a merchant running an online store, their current architecture probably includes storing invoices/payment hashes in their payments/orders db already, so that when they receive a payment they can match it to the order. LDK Node (or any lightning node) could of course allow the downstream logic to store additional metadata in a payment store around an invoice, allowing the matching to be done by putting the order id in the lightning node, but you still have that order information elsewhere.
If we end up offering storage to downstream code in an invoice store, though, we should actually not store it at all and put it in the invoice payment-metadata. I think its now been more than long enough that that is likely reliably usable on the network, and it avoids storing entirely, at the cost of being rather data limited because it ends up in the QR code and onion. This only works for the "store only an order id" usecase, not full order info.
Are there other reasons why people want to store the full generated-invoice history?
In our case we also need to store some metadata based on the payment type (pre-negotiated LSP fees, but preimages could also count towards that). So we will add storage for it, but will attempt to make it optional (cf. #51).
If its small enough, this seems like a great use for payment metadata. We might want to have the payment secret commit to the (encrypted, but not-MAC'd) payment metadata, though...

benthecarman · 2026-03-25T20:03:19Z

Allow cancelling a previously created BOLT11 invoice by payment hash. Enterprise integrators need this when they short-circuit an invoice with an internal database transfer or when an alternative payment method is used (e.g., on-chain payment via unified URI).

The PaymentClaimable event handler rejects HTLCs for cancelled invoices only when the preimage is known (auto-claim payments), preserving retry behavior for manual-claim (_for_hash) payments.

fail_for_hash already did the logic we needed so cancel_invoice just does a little bit extra pre-validation and then calls it. Could make the argument to just use fail_for_hash, update its docs, and the if statement to reject payments mark as failed in the PaymentClaimable. The only functionality change would be that if someone retries to do a payment after a fail_for_hash, we don't let the user evaluate again.

ldk-reviews-bot · 2026-03-25T20:03:23Z

I've assigned @tnull as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

Allow canceling a previously created BOLT11 invoice by payment hash. Enterprise integrators need this when they short-circuit an invoice with an internal database transfer or when an alternative payment method is used (e.g., on-chain payment via unified URI). cancel_invoice validates the payment is inbound and unclaimed, then delegates to fail_for_hash for the shared logic of marking the payment as failed and failing back any pending HTLCs. The PaymentClaimable event handler rejects HTLCs for cancelled invoices only when the preimage is known (auto-claim payments), preserving retry behavior for manual-claim (_for_hash) payments. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

tnull · 2026-03-26T07:14:03Z

+	///
+	/// Will check that the payment is known and has not already been claimed, and will return an
+	/// error otherwise.
+	pub fn cancel_invoice(&self, payment_hash: PaymentHash) -> Result<(), Error> {


Hmm, I always found LND's terminology of 'cancelling an invoice' very confusing. In LDK Node it's even more so confusing as we don't store invoices (yet, cf. #811), so I really don't know what 'cancelling an invoice' is supposed to mean in this context.
As part of the move towards the payment metadata store we will also finally stop tracking expected inbound BOLT11 payments in the payment store (but then rather store the actual invoices/offers for the user), which means the logic in the event handler won't work as it does now. Let me see to finish #811 and #784 finally, and then we can decide how invoice 'cancellation' could make the most sense.
Somewhat orthogonally I do wonder if it would be best to actually do this properly in LDK, i.e., add a remove_payment method on ChannelManager that has it forget the preimage, simply?

Somewhat orthogonally I do wonder if it would be best to actually do this properly in LDK, i.e., add a remove_payment method on ChannelManager that has it forget the preimage, simply?
I don't think that is possible, invoice creation is stateless, its not storing the preimage.

IMO this whole concept is an anti-pattern. If someone wants to pay you extra money in LN you cannot stop them, there are a number of ways in which they can do it, and we're not gonna try to close them all. Further, storing invoices/offers before they're paid is an anti-pattern - creation is stateless for a reason, and tons of people are going to expose APIs where you can request an invoice be created, suddenly subjecting yourself to arbitrary DoS attacks filling your payment store. Unless you actually have to pay for it, free DoS is a really shitty API.

I don't think that is possible, invoice creation is stateless, its not storing the preimage.
Ah, lol, true.
IMO this whole concept is an anti-pattern.
+1 on this, though users seem to expect to have the functionality by now (see elsewhere). But probably we should simply push back on that.
Further, storing invoices/offers before they're paid is an anti-patter
Well, that in turn has been a big feature request by users for a long time now. And someone will need to store the invoice/offers so just handing the responsibility to the user doesn't actually solve the issue necessarily. In our case we also need to store some metadata based on the payment type (pre-negotiated LSP fees, but preimages could also count towards that). So we will add storage for it, but will attempt to make it optional (cf. #51).

Well, that in turn has been a big feature request by users for a long time now. And someone will need to store the invoice/offers so just handing the responsibility to the user doesn't actually solve the issue necessarily.
I'd like to better understand the use-cases here. For something like a merchant running an online store, their current architecture probably includes storing invoices/payment hashes in their payments/orders db already, so that when they receive a payment they can match it to the order. LDK Node (or any lightning node) could of course allow the downstream logic to store additional metadata in a payment store around an invoice, allowing the matching to be done by putting the order id in the lightning node, but you still have that order information elsewhere.
If we end up offering storage to downstream code in an invoice store, though, we should actually not store it at all and put it in the invoice payment-metadata. I think its now been more than long enough that that is likely reliably usable on the network, and it avoids storing entirely, at the cost of being rather data limited because it ends up in the QR code and onion. This only works for the "store only an order id" usecase, not full order info.
Are there other reasons why people want to store the full generated-invoice history?
In our case we also need to store some metadata based on the payment type (pre-negotiated LSP fees, but preimages could also count towards that). So we will add storage for it, but will attempt to make it optional (cf. #51).
If its small enough, this seems like a great use for payment metadata. We might want to have the payment secret commit to the (encrypted, but not-MAC'd) payment metadata, though...

benthecarman · 2026-03-25T20:03:19Z

Allow cancelling a previously created BOLT11 invoice by payment hash. Enterprise integrators need this when they short-circuit an invoice with an internal database transfer or when an alternative payment method is used (e.g., on-chain payment via unified URI).

The PaymentClaimable event handler rejects HTLCs for cancelled invoices only when the preimage is known (auto-claim payments), preserving retry behavior for manual-claim (_for_hash) payments.

fail_for_hash already did the logic we needed so cancel_invoice just does a little bit extra pre-validation and then calls it. Could make the argument to just use fail_for_hash, update its docs, and the if statement to reject payments mark as failed in the PaymentClaimable. The only functionality change would be that if someone retries to do a payment after a fail_for_hash, we don't let the user evaluate again.

ldk-reviews-bot · 2026-03-25T20:03:23Z

I've assigned @tnull as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

Allow canceling a previously created BOLT11 invoice by payment hash. Enterprise integrators need this when they short-circuit an invoice with an internal database transfer or when an alternative payment method is used (e.g., on-chain payment via unified URI). cancel_invoice validates the payment is inbound and unclaimed, then delegates to fail_for_hash for the shared logic of marking the payment as failed and failing back any pending HTLCs. The PaymentClaimable event handler rejects HTLCs for cancelled invoices only when the preimage is known (auto-claim payments), preserving retry behavior for manual-claim (_for_hash) payments. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

tnull · 2026-03-26T07:14:03Z

+	///
+	/// Will check that the payment is known and has not already been claimed, and will return an
+	/// error otherwise.
+	pub fn cancel_invoice(&self, payment_hash: PaymentHash) -> Result<(), Error> {


Hmm, I always found LND's terminology of 'cancelling an invoice' very confusing. In LDK Node it's even more so confusing as we don't store invoices (yet, cf. #811), so I really don't know what 'cancelling an invoice' is supposed to mean in this context.
As part of the move towards the payment metadata store we will also finally stop tracking expected inbound BOLT11 payments in the payment store (but then rather store the actual invoices/offers for the user), which means the logic in the event handler won't work as it does now. Let me see to finish #811 and #784 finally, and then we can decide how invoice 'cancellation' could make the most sense.
Somewhat orthogonally I do wonder if it would be best to actually do this properly in LDK, i.e., add a remove_payment method on ChannelManager that has it forget the preimage, simply?

Somewhat orthogonally I do wonder if it would be best to actually do this properly in LDK, i.e., add a remove_payment method on ChannelManager that has it forget the preimage, simply?
I don't think that is possible, invoice creation is stateless, its not storing the preimage.

IMO this whole concept is an anti-pattern. If someone wants to pay you extra money in LN you cannot stop them, there are a number of ways in which they can do it, and we're not gonna try to close them all. Further, storing invoices/offers before they're paid is an anti-pattern - creation is stateless for a reason, and tons of people are going to expose APIs where you can request an invoice be created, suddenly subjecting yourself to arbitrary DoS attacks filling your payment store. Unless you actually have to pay for it, free DoS is a really shitty API.

I don't think that is possible, invoice creation is stateless, its not storing the preimage.
Ah, lol, true.
IMO this whole concept is an anti-pattern.
+1 on this, though users seem to expect to have the functionality by now (see elsewhere). But probably we should simply push back on that.
Further, storing invoices/offers before they're paid is an anti-patter
Well, that in turn has been a big feature request by users for a long time now. And someone will need to store the invoice/offers so just handing the responsibility to the user doesn't actually solve the issue necessarily. In our case we also need to store some metadata based on the payment type (pre-negotiated LSP fees, but preimages could also count towards that). So we will add storage for it, but will attempt to make it optional (cf. #51).

Well, that in turn has been a big feature request by users for a long time now. And someone will need to store the invoice/offers so just handing the responsibility to the user doesn't actually solve the issue necessarily.
I'd like to better understand the use-cases here. For something like a merchant running an online store, their current architecture probably includes storing invoices/payment hashes in their payments/orders db already, so that when they receive a payment they can match it to the order. LDK Node (or any lightning node) could of course allow the downstream logic to store additional metadata in a payment store around an invoice, allowing the matching to be done by putting the order id in the lightning node, but you still have that order information elsewhere.
If we end up offering storage to downstream code in an invoice store, though, we should actually not store it at all and put it in the invoice payment-metadata. I think its now been more than long enough that that is likely reliably usable on the network, and it avoids storing entirely, at the cost of being rather data limited because it ends up in the QR code and onion. This only works for the "store only an order id" usecase, not full order info.
Are there other reasons why people want to store the full generated-invoice history?
In our case we also need to store some metadata based on the payment type (pre-negotiated LSP fees, but preimages could also count towards that). So we will add storage for it, but will attempt to make it optional (cf. #51).
If its small enough, this seems like a great use for payment metadata. We might want to have the payment secret commit to the (encrypted, but not-MAC'd) payment metadata, though...

ldk-reviews-bot requested a review from tnull March 25, 2026 20:13

benthecarman force-pushed the cancel-invoice branch from 211f84b to f04c76aCompare March 25, 2026 20:48

benthecarman force-pushed the cancel-invoice branch from f04c76a to 6a9e155Compare March 25, 2026 21:26

tnull reviewed Mar 26, 2026
View reviewed changes

ldk-reviews-bot requested a review from tnull March 25, 2026 20:13

benthecarman force-pushed the cancel-invoice branch from 211f84b to f04c76aCompare March 25, 2026 20:48

benthecarman force-pushed the cancel-invoice branch from f04c76a to 6a9e155Compare March 25, 2026 21:26

tnull reviewed Mar 26, 2026
View reviewed changes

ldk-reviews-bot requested a review from tnull March 25, 2026 20:13

benthecarman force-pushed the cancel-invoice branch from 211f84b to f04c76aCompare March 25, 2026 20:48

benthecarman force-pushed the cancel-invoice branch from f04c76a to 6a9e155Compare March 25, 2026 21:26

tnull reviewed Mar 26, 2026
View reviewed changes

ldk-reviews-bot requested a review from tnull March 25, 2026 20:13

benthecarman force-pushed the cancel-invoice branch from 211f84b to f04c76aCompare March 25, 2026 20:48

benthecarman force-pushed the cancel-invoice branch from f04c76a to 6a9e155Compare March 25, 2026 21:26

tnull reviewed Mar 26, 2026
View reviewed changes

ldk-reviews-bot requested a review from tnull March 25, 2026 20:13

benthecarman force-pushed the cancel-invoice branch from 211f84b to f04c76aCompare March 25, 2026 20:48

benthecarman force-pushed the cancel-invoice branch from f04c76a to 6a9e155Compare March 25, 2026 21:26

tnull reviewed Mar 26, 2026
View reviewed changes

ldk-reviews-bot requested a review from tnull March 25, 2026 20:13

benthecarman force-pushed the cancel-invoice branch from 211f84b to f04c76aCompare March 25, 2026 20:48

benthecarman force-pushed the cancel-invoice branch from f04c76a to 6a9e155Compare March 25, 2026 21:26

tnull reviewed Mar 26, 2026
View reviewed changes

ldk-reviews-bot requested a review from tnull March 25, 2026 20:13

benthecarman force-pushed the cancel-invoice branch from 211f84b to f04c76aCompare March 25, 2026 20:48

benthecarman force-pushed the cancel-invoice branch from f04c76a to 6a9e155Compare March 25, 2026 21:26

tnull reviewed Mar 26, 2026
View reviewed changes

ldk-reviews-bot requested a review from tnull March 25, 2026 20:13

benthecarman force-pushed the cancel-invoice branch from 211f84b to f04c76aCompare March 25, 2026 20:48

benthecarman force-pushed the cancel-invoice branch from f04c76a to 6a9e155Compare March 25, 2026 21:26

tnull reviewed Mar 26, 2026
View reviewed changes

Uh oh!

Conversation

benthecarman commented Mar 25, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ldk-reviews-bot commented Mar 25, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tnullMar 26, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Uh oh!

Conversation

benthecarman commented Mar 25, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ldk-reviews-bot commented Mar 25, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tnullMar 26, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Uh oh!

Conversation

benthecarman commented Mar 25, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ldk-reviews-bot commented Mar 25, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tnullMar 26, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

benthecarman commented Mar 25, 2026•
edited
Loading

ldk-reviews-bot commented Mar 25, 2026•
edited
Loading

tnullMar 26, 2026•
edited
Loading

benthecarman commented Mar 25, 2026•
edited
Loading

ldk-reviews-bot commented Mar 25, 2026•
edited
Loading

tnullMar 26, 2026•
edited
Loading

benthecarman commented Mar 25, 2026•
edited
Loading

ldk-reviews-bot commented Mar 25, 2026•
edited
Loading

tnullMar 26, 2026•
edited
Loading

benthecarman commented Mar 25, 2026•
edited
Loading

ldk-reviews-bot commented Mar 25, 2026•
edited
Loading

tnullMar 26, 2026•
edited
Loading