Open MrHash opened 4 years ago
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).
Merchant Troubleshooting
— credit @pavelex