This type of transactions allow user to top up user’s main account with the money from some debit card.
Figma: https://www.figma.com/file/dkDQHRa1zq7tU58MiL6hBR/SaFi---UI---MVP-(Shared)?node-id=3145%3A57575&t=wEb3xbRQrIGsaLdb-0

TopUpWithDebitCardAmountScreen

On the start of the flow the TopUpWithDebitCardAmountScreen is presented to the user.

The entity for collecting the data for this type of transaction is TopUpWithDebitCardEntity. It gets created in the TopUpWithDebitCardUsecase in the method createTransaction. This method sends a number of requests:

  • account manager, GET /v2/account/by-customer-id/$ownerId ; it doesn’t get fetched from the local database, since we need the most relevant value of the account balance;

  • merchants manager, GET /merchants/topup/debit-card to get the amount limits (max and min amounts) for this transaction;

  • customer manager, GET /v1/customers to get the details of the current customer; this may be fetched from local Hive database, in case it is present there, since we don’t expect this data to be changed frequently, also because those changes should be backed up by the Ably notifications;

  • fee manager, GET /fees/calculate/customer to get the number of the free transactions left.


All those requests are performed in parallel, so the end user should not wait much. When all the responses are received, the TopUpWithDebitCardEntity is created with the corresponding values set:
account number, account id, beneficiary name, customer id, first name, last name, email, address, remaining free transactions, and wether we should show the upgrade button in the number of free transactions left box at the bottom of the screen.

After all the preparations are done, the user is able to input the amount. Below the amount text input user can see the reference of minimum amount for the top up via debit card transaction. If the input amount is lower than the minimum, user would see the error right away.

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 user validates the transaction details in the verification bottom sheet and taps on Cash-in button, bloc sends the request to get the redirect link: transaction processor manager, POST /topup/debit-card. One of the values from the response should contain the redirect link.

This link is opened via the in-app web view to proceed with inputting the credit card details. Meanwhile the app is listening to all the redirects.

TopUpWithDebitCardCardDetailsScreen

This screen wraps the web view to follow the redirect from the previous step. It’s quite simple screen.
After loading the web resource by the link provided, it listens for all the redirects. If the redirect URL contains /redirect/transactions/top-up-money/success, this means that the user has successfully input all the details of the credit card and the transaction is in progress. So, we can present the TransactionResults screen with TransactionStatus.pending to the user. 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