0

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.

1
  • 2
    In how many systems did you observe this on your own? Some system you can give a public reference to?
    – Doc Brown
    Sep 27, 2023 at 14:53

3 Answers 3

6

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.

6
  • 8
    I passionately hate the standard OOP introductory BankAccount example even more than the Car.wheels one. Banking is the original distributed system, and uses transactions precisely because it is a distributed system. When this system was invented, a transaction might be "in flight" for days, being carried on horse back from a remote branch office to the central bank. Locking both accounts for that time to make an atomic update to the balance would be utterly ridiculous. Sep 27, 2023 at 17:18
  • 2
    I posit that an abstracted version of a real banking system is not harder to understand than the toy one, so why isn't it taught that way? (Rant over.) Sep 27, 2023 at 17:21
  • 4
    @JörgWMittag I think a lot of people teaching OO have little to no experience with writing software professionally and even less with 'real economy' companies. In my CS program there were some professors that did have that experience and I have found what they taught me has proved to be far more valuable than what I was taught by the rest.
    – JimmyJames
    Sep 27, 2023 at 18:09
  • 3
    @JörgWMittag, you're missing the real trick: in a cross-ledger transaction mediated by horseback, you can't lock "both accounts" (i.e. all accounts concerned, there will be at least 4, not just 2), because those keeping the remote ledger don't know the transaction has occurred until they receive word via horseback. And once they do receive word, it's not necessary for the remote party to lock their accounts. The fact that such hidden "in-flight" effects exist, is one of the whales in the nightmares of bankers, and as much as possible they seek to control it with telecoms and computerisation.
    – Steve
    Sep 28, 2023 at 8:23
  • 2
    It probably upsets computer scientists more than accountants that banking transactions are not atomic, given how long the basic concepts of clearing and settlement have been around.
    – pjc50
    Sep 28, 2023 at 10:41
0

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.

0

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.

4
  • "the risk of fraud getting through undetected is quite close to 0" - please wait whilst I recompose myself from a fit of roaring laughter. The vast majority of fraud is controlled not by up-front detection, but by sanctioning fraudulent parties retrospectively, including by maintaining files on every individual in the country, entry onto which will cause a great many financial facilities to be denied or withdrawn, and heavy scrutiny of the use of anything that remains.
    – Steve
    Sep 28, 2023 at 10:44
  • Ofc, nobody tries to fraud via card payments cause its very difficult, except for attacks on the card itself. Thanks for proving my point.
    – Ccm
    Sep 28, 2023 at 11:44
  • Nobody tries fraud via card payments? I was defrauded of a small sum myself just a couple of years ago, on my credit card account.
    – Steve
    Sep 28, 2023 at 12:56
  • So card payments or account fraud? There's a difference :)
    – Ccm
    Sep 28, 2023 at 15:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.