[Bug]: Payment incorrectly marked as "settled" in csv after payjoin error

[Liongrass]

What is your BTCPay version?

BTCPay Server v1.9.2+6193835ea

How did you deploy BTCPay Server?

Lunanode installer

What happened?

I'm using BTCPayServer to process on-chain and off-chain payments. I have payjoin enabled. A customer tried to make a payjoin payment but it failed (the payment was never made), yet in the csv the payment shows up as paid, although the invoice is marked as expired. The relevant line in the csv can be found below.

How did you encounter this bug?

1. Create invoice
2. User tries to pay with Bluewallet
3. User sees error message and lets invoice time out
4. Invoice is marked as expired in the BTCPay dashboard, but the csv marks the amount as paid

Relevant log output

ReceivedDate	StoreId	OrderId	InvoiceId	InvoiceCreatedDate	InvoiceExpirationDate	InvoiceMonitoringDate	PaymentId	Destination	PaymentType	CryptoCode	Paid	NetworkFee	ConversionRate	PaidCurrency	InvoiceCurrency	InvoiceDue	InvoicePrice	InvoiceItemCode	InvoiceItemDesc	InvoiceFullStatus	InvoiceStatus	InvoiceExceptionStatus	BuyerEmail	Accounted

04/28/2023 02:30:57 | HoyPithshvkRMADckPTCx1ZmvUmbZNYwPTjeKyBX2CED | pos-app_4C3Ei2pnpG463BAMwyHwBNhMaHvW | PKCxdf4wjJt37FeGqDMBq4 | 04/28/2023 02:27:21 | 04/28/2023 02:42:21 | 04/29/2023 02:42:21 | 593206df1398bd99d614565328c43a312945be4bcc518f2508030395dcfbbd7a-0 | bc1qyysm5qleqrxc38fqp6ml8wx85f3rpd9ac36t9g | On-Chain | BTC | 0.0021 | 0 | 100000000 | 210000 | SATS | 0 | 210000 | join | Join | Expired | expired |   | redacted@gmail.com | False

The lifecycle of this invoice:

27/4/2023, 7:27 pm | Creation of invoice starting
-- | --
27/4/2023, 7:27 pm | BTC_SATS: The rating rule is 1 / 0.00000001
27/4/2023, 7:27 pm | BTC_SATS: The evaluated rating rule is 1 / 0.00000001
27/4/2023, 7:27 pm | BTC (On-Chain): Payjoin is enabled for this invoice.
27/4/2023, 7:27 pm | BTC (On-Chain): Payment method details creation took 434 milliseconds
27/4/2023, 7:27 pm | BTC (LNURL-Pay): Payment method details creation took 721 milliseconds
27/4/2023, 7:27 pm | BTC (Off-Chain): Payment method details creation took 755 milliseconds
27/4/2023, 7:27 pm | Saving invoice took 242 milliseconds
27/4/2023, 7:27 pm | Invoice PKCxdf4wjJt37FeGqDMBq4 new event: invoice_created (1001)
**27/4/2023, 7:30 pm | Payjoin error: Not enough money is sent to pay for the additional payjoin inputs**
27/4/2023, 7:30 pm | Invoice PKCxdf4wjJt37FeGqDMBq4 new event: invoice_receivedPayment (1002)
27/4/2023, 7:30 pm | Invoice status is Processing
27/4/2023, 7:30 pm | Invoice PKCxdf4wjJt37FeGqDMBq4 new event: invoice_paidInFull (1003)
27/4/2023, 7:42 pm | Invoice status is New
27/4/2023, 7:42 pm | Invoice status is Expired
27/4/2023, 7:42 pm | Invoice PKCxdf4wjJt37FeGqDMBq4 new event: invoice_expired (1004)

### What browser do you use?

_No response_

### Additional information

_No response_

### Are you sure this is a bug report?

- [X] I confirm this is a bug report

[pavlenex]

@Kukks could you take a look?

[Kukks]

Hi, @Liongrass

Please note that the last column, Accounted, is false for that row. That means it is not a payment that is counted toward settling the invoice.

[Liongrass]

How do I read the csv correctly? What does it mean when ReceivedDate is filled? Or what does the amount in Paid signal?

[Kukks]

You can take all rows where accounted is true. In your case, someone initiated a payjoin and we recorded it internally, but they did not finish.

[Liongrass]

So this is intended behavior? To see how many sats I received I must not sum up the field "Paid", but rather I have to cross-validate if "Accounted" is also set to true? Highly counter-intuitive at the very least and will make accounting for me more complicated in the future. Paid should mean Paid!

If I turn off coinjoin, are there any other known instances where a payment shows up as "Paid" that is in fact unpaid? Because I'd rather turn off coinjoin than teach everyone who processes payments through my BTCPay to make the correct IF statements in LibreOffice.

[Kukks]

Turning off payoin does not remove this check requirement. A transaction that gets sent to pay the invoice but then gets double spent also creates the same record. You should check invoices for a settled/complete status not paid, as l Paid means payment detected but not final

…

On Fri, May 5, 2023, 8:29 PM Leonhard Weese ***@***.***> wrote: So this is intended behavior? To see how many sats I received I must not sum up the field "Paid", but rather I have to cross-validate if "Accounted" is also set to true? Highly counter-intuitive at the very least and will make accounting for me more complicated in the future. Paid should mean Paid! If I turn off coinjoin, are there any other known instances where a payment shows up as "Paid" that is in fact unpaid? Because I'd rather turn off coinjoin than teach everyone who processes payments through my BTCPay to make the correct IF statements in LibreOffice. — Reply to this email directly, view it on GitHub <#4936 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAN357UVUJROX3GL4OLZXA3XEVBHTANCNFSM6AAAAAAXPVYMIM> . You are receiving this because you were assigned.Message ID: ***@***.***>

[Liongrass]

Ah thanks. Will turn off on-chain payments too.

[Kukks]

Ah thanks. Will turn off on-chain payments too.

Lol what? This is not the way and definitely not what im advising

[NicolasDorier]

@Liongrass the CSV export in the invoice list is actually the export of payments. (except if the invoice is expired)
I think we should remove the CSV export of the invoice list, as we now have the Reporting feature.