Why do payment systems verify the transaction once it has been completed?

Question

I've noticed this kind of architecture in hub payment systems(system where you can pay to multiple merchants at one place-thus called hub).

payment app-->payment mediator-->bank server

• Bank server deducts money
• Bank server responds that it deducted money to payment mediator
• Now payment mediator requests for verification by sending a hmacsha512 hash.
• Bank server responds sucess or failure

I don't understand why are we checking integrity and authenticity after deducting the bank server says it has deducted the balance?

IMO it should be done atomically.

Answer 1

When you write "deducted the balance" it suggests you might be missing a key thing that is important to understand about banking systems. They don't really store 'a balance' for each account. Bank accounts are stored as a series of transactions. The balance is simply the total sum of all the transactions (some positive, some negative) that are considered valid.

When you withdraw or make a payment, that's simply an additional transaction added to the 'legder' for that account. As to why there is a second validation step, I would wager that it's to reduce the risk of a transaction being confirmed but not stored successfully. If one party receives payment, it's crucial that there is a corresponding negative ledger entry stored on the other party's account. Otherwise, money has just been created from thin air and the numbers won't add up correctly. Bankers really need their numbers to work out in order to stay on the right side of the law. Bugs and system errors happen. Double-checking a transaction helps ensure that things are done and done correctly. It also might give the banks time to get the transaction through their COBOL/RPG mainframe pachinko machine.

Answer 2

We can only speculate, but my suspicion is that what's happening here isn't that the transaction is being confirmed twice.

Rather, what's happening is that the first response confirms that the payment order has been received. The second response, following a second call slightly later in time, checks whether the order has been executed (and as the case may be, the result).

Systemic problems may mean payment orders cannot be executed on usual timeframes. The originator of the payment order (the vendor of the goods or whatever) then has the option either to dispense the goods to the buyer regardless (knowing that the payment order is indeed lodged, but not yet confirmed and may still fail), or to cancel the trade.

The system as a whole must be capable of accomodating both tactics, because many retailers would prefer to bear the risk of some payment failures, than to close their shutters every time the payment infrastructure isn't fully available.

Answer 3

Multiple parties and multiple verification are involved in order to prevent fraud. For example, the credit card system typically have several parties (payer bank, payer bank processor, card schema, recipient bank processor, recipient bank) and the risk of fraud getting through undetected is quite close to 0.

But this is not mandatory. In-house transactions made using most home banking apps do not go through a third party. The whole IBAN system also doesn't require a third party like the card system does.

In your particular case, the integrity check is done to adhere to best security practices. Since every entity in the chain is a third party to the others, it is mandatory to verify that they are who they say they are, and that the message hasn't been tampered with. Apps installed on client's phones or PCs are a source of pain when it comes to financial applications - there needs to be tight identity control in place. While those checks are not mandatory per say, they are useful so each party in the chain gains public trust and therefore more clients. You don't want your money handled by sketchy apps.