Intrabank transfers are the transfers between SaFi accounts.
Figma: https://www.figma.com/file/dkDQHRa1zq7tU58MiL6hBR/SaFi---UI---MVP-(Shared)?node-id=3145%3A56834&t=MSuT9DOK1RERIy7M-0

This flow consists of 2 sub flows: intrabank via account number and intrabank via phone number.

SendToScreen

Intrabank via account number

On the start of the flow the SendToScreen is presented to the user.
SafiTabList is switched to Account tab.

In the SendToInitial state of the SendToBloc we create the empty CreateTransactionEntity, which is responsible for collecting all the data (including the user input) for creating the intrabank transaction.
The user can manually input the account number and the recipient name.

Another possibility to input the account number is scanning the QR code, generated by the SaFi app for another user. If the code is valid, the account number and beneficiary name fields are getting automatically populated with the data, encoded in the scanned QR code.

After user inputs the required data and taps on Continue, the CreateTransactonEntity is updated with those values and the simple validation of the input is performed:

  • we make sure the account number is 10 digits and is divisible by 11 (the validation takes place in BeneficiaryReferenceAccount)

  • we make sure the beneficiary name is not empty (the validation takes place in _isHolderNameValid method of the SendToBloc)

If the validation fails, the error is presented to the user. Otherwise, we send 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 account number and and customer first name, and perform the navigation to the CreateTransferDetails screen.

Intrabank via phone number

On the start of the flow the SendToScreen is presented to the user.
SafiTabList is switched to Phone number tab.

In the SendToInitial state of the SendToBloc we create the empty CreateTransactionEntity, which is responsible for collecting all the data (including the user input) for creating the intrabank transaction.
The user can manually input the phone number and the recipient name.

Another possibility is to open the Contacts bottom sheet and select a contact from it. After that, the selected contact details (phone number and name) populate the corresponding input fields.

After the user taps on Continue, the CreateTransactonEntity is updated with those values and the simple validation of the input is performed:

  • phone number length should be more or equal to 3 and less or equal to 10, to match the phone numbers in Philippines;

  • we make sure the beneficiary name is not empty (the validation takes place in _isHolderNameValid method of the SendToBloc)

If the validation fails, the error is presented to the user. Otherwise, we send 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 account number and and customer first name, and perform the navigation to the CreateTransferDetails screen.

CreateTransferDetails

In this screen the user should input the amount for the transfer. The total balance available is also 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.

Also the user has a possibility to input the note to beneficiary. It is optional.

After user taps on Continue, the validation bottom sheet is presented to the user (in case the amount for transaction is valid; validation is performed in the CreateTransferDetailsBloc in _amountErrorMessage method).

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. 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/intrabank 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.

It should also be noted, that the validation of the fact that the account or phone number, that the user has input in SendTo screen, are registered to another SaFi user, is actually made in BE after the transaction is submitted to BE. So, there is no possibility for the user to scan the phone or account numbers and determine if there are users registered with those parameters.

In order to find accounts for testing and data for input, please follow the Test data link: Transactions - Test data