The $300 payment can be modeled as a payment whose state mutated later.
Or it can be modeled as event stream where on {id=2, t=2, +$300} was posted, and {id=2, t=4, -$300} was declined. If you want to distinguish between a "retry" or a "remainder", you add that into the tuple within the event stream.
That is the idea when you control the system. This however is not a system, it is an ecosystem - payments ecosystem. No one party controls the interfaces or implementations between any two counter-parties, let alone multiple counter-parties along the line. The point I was making was infact about lack of control over externalities like this one. For those in payments, this actually is a real problem, especially with small merchants in developing countries but true for even large ones in the west. And this does not even go into the details of cash oriented systems in india, china and elsewhere.
Or it can be modeled as event stream where on {id=2, t=2, +$300} was posted, and {id=2, t=4, -$300} was declined. If you want to distinguish between a "retry" or a "remainder", you add that into the tuple within the event stream.