Definitely keep all bitcoins they send :)
I still wouldn't fire any event for an invoice not being paid - it's a non-event. There is no event to track. Every invoice, until the "InvoiceOver/Paid" event is seen is considered "Not Paid". If the merchant has to issue a correction to the invoice there should be an event to signify this - this is an important part of the domain. "InvoiceCorrected" would contain the data, and then a listener decides if a refund is required, and triggers that process if necessary. I'd probably do something like this - and we tend to favour the microservice approach at the moment, so it does look like a lot of "things"....we also use event sourcing, so I may be muddying the water by cross contamination of concepts :-)
User send "Payment" object to "ProcessPayment" command handler. "ProcessPayment" emits"PaymentReceied" (if command is valid...you know you're logic here).
"MarkInvoiceAsPaid" listener responds to "PaymentReceived" event and emits "InvoicePaid" event if invoice balance goes through zero (as in the change takes it from a positive balance to zero, or negative). Talk to your domain expert if you ever think the balance of an invoice could increase (dodgy refunds?) and how to handle that. Maybe having two "InvoicePaid" events is fine (probably is).
"IssueRefundIfOverPaid" listener responds to "PaymentReceived" event and issues "Refund" object to "IssueRefund" command handler. "IssueRefund" emits "UserRefunded" (or something) depending on logic...has invoice got negative balance.
Our listeners have an internal state that they build to keep a track of objects they are interested in (and just the bits they need, not the full object). They neatly describe our business rules, keep them encapsulated in a single place and only change if they absolutely have to (I prefer to deploy new things). I'd also have other listeners building view models for the interface...