3

We're arranging UI screens for mobile banks. To perform "transactions", the system needs to communicate with the core bank mainframe.

Sometimes, we don't receive the response after sending a request, thus we don't know the transaction the user did has been successfully processed or not.

This causes a weird situation:

(1) The transaction might be successful, prompting users to do the action again leads to duplicate transactions (eg. transferring their money twice).

(2) The transaction might fail, Optimistically telling users to assume the result is good is sometimes not correct (eg. they thought they've transferred the money however it's not).

What is the best way to handle this situation?

1
  • even when the transaction is successful, a user is prompted to do the transaction again? Is the validation of a transaction being successful shown to a user even before their transfer has been processed? Dec 24 '20 at 3:28
3

A transparent way to handle the situation is telling the user what actually happened, what are the options and the recommended next steps: Your transaction cannot be confirmed at the moment. Please wait for the confirmation before starting the transaction again. For assistance please contact customer support.

I've seen this kind of messages in flight booking sites, for example.

A data driven approach could be helpful here: Knowing how many times a non confirmed request has failed and how easy/difficult is to reverse a duplicate transaction could help to take a decision about what to recommend to the user.

0
2

In the case of transactions - it is dangerous and critical to process them in this way - entropy and errors may occur - which are difficult to reverse.

If the banking system is overloaded with a large number of requests or waiting for a response from their API takes a long time.

It is worth considering switching supplier - due to economic reasons it is not always possible, so you have to systematically take into account a given affordance.

According to second Nielsen Heuristic - Be consistent between the system and reality - incorrectly informing user isn't good practise.


I suggest introduce something something similar to the transaction status - enum in the system - which contains information about the states of transactions.

In this case, something like pending should fix the problem

A given solution should be characterized on the basis of the entire system (if there is no transaction list - then message should be allocated in details page or something)

enter image description here


enter image description here

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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