Interbank transfers are the transfers from the SaFi account to the account in another bank.
Figma: https://www.figma.com/file/dkDQHRa1zq7tU58MiL6hBR/SaFi---UI---MVP-(Shared)?node-id=3145%3A53043&t=fxlu2sUgL99ACXXG-0
InterSendToScreen
On the start of the flow the InterSendToScreen is presented to the user.
In the InterSendToInitial state of the InterSendToBloc we create the empty CreateInterTransactionEntity, which is responsible for collecting all the data (including the user input) for creating the interbank transaction.
Upon the initialisation, the transaction entity gets updated with
The user should manually input the recipient name and account number and select the bank, that account belongs to.
The bottom sheet for selecting the bank contains the list of suggested banks, as well as the full list of banks with the possibility of search by the bank name. To get the list of banks, the GET request to merchants manager is sent: /merchants/withdrawals/banks. The list of available banks from response is cached in RAM until the next app launch.
After user inputs the required data and taps on Continue, the CreateInterTransactonEntity is updated with those values and the simple validation of the input is performed:
we make sure the account number is not empty (the validation takes place in
_isAccountNumberValidmethod of theInterSendToBloc)we make sure the beneficiary name is not empty (the validation takes place in
_isHolderNameValidmethod of theInterSendToBloc)
If the validation fails, the error is presented to the user. Otherwise, we perform the navigation to the CreateInterTransactionDetails screen.
CreateInterTransactionDetails
In this screen the user should input the amount for the transfer, as well as select how quickly the transaction should be processed (asap or up to the next day). The total balance available is presented to the user for reference. If the amount, that the user inputs, exceeds the balance available, the amount is highlighted in red, letting the user know that it’s impossible to proceed with such an amount.
The user has a possibility to input the note to beneficiary. It is optional.
At the bottom of the screen the user can see the number of free transactions left in the user’s current subscription plan, and the button to upgrade the plan (in case the user’s subscription is not the best one).
At the loading stage the CreateInterTransactionDetailsBloc sends the GET request to the account manager with URL /v2/main-account/by-customer/$customerId to get the account details for the current user. If it succeeds, we update our entity with the customer’s account number, account id, and customer first name. Also values for the customer id and timestamp are set. Also the bloc checks what are the available options (asap | up to the next day) for the selected bank, and notifies the ui to update accordingly.
The validation of the amount is performed in the CreateInterTransferDetailsScreen in _errorMessageFromState method upon user typing the amount in the corresponding text input.
After the user taps on Continue button, bloc sends the request to the fee manager to calculate the fee for the current transaction (GET /fees/calculate/customer). The response contains the number of free transaction left, or the fee value and total with fee amount for the current transaction, if there are no free transactions left in the subscription plan for the current user.
Inside the validation bottom sheet some of the information about the transaction is present to the user to validate if everything seems to be correct, including fees if applicable. Also, the validation sheet allows to input the note to myself, so the user would be able to identify this transaction from the TransactionsHistory thereafter.
After the user taps on Send, the POST request /transaction/v2/interbank to the transaction processor manager is performed. The transaction gets uuid assigned (which was generated at FE); this is a subject to change, since the backend also has a generated transaction id. At this step CreateTransferEntity is getting transformed into json payload for the request body.
If the request fails, we show the TransactionResults screen with TransactionStatus.failed.
If the request succeeds, we show the TransactionResults screen with TransactionStatus.success. This screen is common for all the transactions. It contains some basic data about the transaction. There’s also a possibility to show the TransactionDetails screen from the results screen, which would display all the relevant details of the transaction.
In order to find accounts for testing and data for input, please follow the Test data link: Transactions - Test data