PoC to demonstrate distributed transaction logic in realtime payment.
It should show that network error does not cause unwanted issues.
Out of scope - how local db transactions work.
A has to pay B Rs. 10 in realtime.
Bank account of A: Rs.100.
Bank account of B: Rs.0.
So following is done (order may be subject to fine-tuning):
1. Rs. 10 is set aside from A's account into a field that is the amount locked for paying out.
So we get:
A's available funds = Rs. 90
A's funds locked for paying out = Rs. 10
2. A new unique transaction id is generated. A UUID can be used for this; it is supposed to be unique in space and time.
The 'unique in space' part of time comes from the unique MAC address of the network card of the generating machine.
The transaction id noted down is noted down more or less permanently (say 5-10 years).
3. The new transaction id, the payee's account and bank details, and the payer's bank and account details are sent over the internet using a suitable signed and secured format to the bank of the payee.
4. The payee credits the money to account of B, notes down the transaction id and informs A that it has processed the transaction.
The transaction id noted down is noted down more or less permanently (say 5-10 years).
5. Once A gets notification that the transaction has been processed, it makes A's funds locked for paying out = Rs. 0 and marks the 
transaction as successful.
6. If in step 3, B did not respond or in step 4 the message from B somehow did not reach A, then A can retry sending the transaction information for (say) 2 more times, after which A will
show a message to the user and in the background will keep trying to contact B but at a lower frequency for 24 hours. After 24 hours 
if B does not respond, the money will be reverted to A's available funds, which will again become Rs. 100. In the background, the 
bank of A will 'forever' ask B to cancel the transaction or get confirmation from B that it never received news about the transaction.
7. If in step 6 retry within 24 hours by A receives response from B, the transaction will succeed and A will mark the transaction as 
succeeded and  makes A's funds locked for paying out = Rs. 0.

So overall we have:
- A 10 second window for the realtime transaction to succeed, with 2 or 3 retries.
- A 24-hour window for transaction to succeed or rollback if the server of bank 'B' is down.
- A 5 or 6 year persistent record of the transaction.

A js demo can be built where we have a button to click to initiate the payment, and another button to simulate a communication
loss of the message currently being transmitted when clicked.
This demo can show how the system recovers from the communication losses and ensures that the transaction is processed.