Add failure reason for failed payments

[MrHash]

No description provided.

[johnsBeharry]

Merchant Troubleshooting

— credit @pavelex

In preparation for the next payment [design] sprint, started drafting the troubleshooting flow, when on vs off chain is put side by side it's interesting to see how certain things are easier with LN, however that opens a new infrastructural question that we have to see how and if we include in the payments guide in particular or is it better suited elsewhere.

I have to investigate how different LN implementation handle over-payments, underpayments etc, because LND apparently allows this, which is a bit of a deal breaker for certain use-case - merchants.

[MrHash]

Interesting flows similar to things i've been through while developing satbased. You might have seen the current event board i produced:

The satbased project is designed for "event first" development within the broader concept of DDD. What that means is that the actual entity states are results of the event that occur in "real-life". The diagram describes a Payment resource that is specified with two independent state machines depending on direction (incoming/outgoing). This enables us to think of payments in a real world sense simply as "payments in and out". This approach significantly reduces the complexity of the classic deposit/withdrawal concepts and actual aligns better with the original transaction concept of bitcoin (i.e. direction agnostic).

In short the states in the Payment entity are reflected by the events, eg. made, reqeuested, sent, failed, cancelled etc. and seem to be able to encapsulate all the states offered by the various implementations across the bitcoin stack (e.g. bitcoind, various LN impls (incl. hold invoice), elementsd, and even other wallet abstractions).

Regarding failure reason, the handling of failures depends on a strategy. Satbased supports customizable automated retry/failure strategies, and can also just defer to human decision (hence the need for an explaination phrase).