SaFi Bank Space : Engineering handover - Transactions

Created by Slavomír Kocka, last modified by Jideo Pena (Unlicensed) on Dec 06, 2022
  • Jira - how is the work managed, how to work with it
  • Confluence - how is documentation structured, a brief overview
  • 3rd parties - what, for what, where it is documented
  • Contact persons/channels - for 3rd parties, products, …
  • Credentials - where are they, how are they managed
  • Dev level test - what is covered, what not, where to put the focus, where to be careful
  • Bugs/VAPT findings - which are there for SaFi to pick up
  • Planned development for MVP - what we were planning to do till the end of January (NFRs, tests, tech debt…)
  • Ownership handover

Jira

In our squad, we are using Kanban board for current sprint. The board can be found here: https://safibank.atlassian.net/jira/software/c/projects/SM/boards/6

We are following workflow defined for whole SaFi project described here: Jira Rules

Final note or recommendation would be, to always assign task to responsible person within the flow. So in final, intention is to do your work on the task and get rid of it. This was named by one colleague as “hot potato driven development”. By this approach, everyone would know, what to work on. PM would have instant overview on what is going on when everyone would move the state of the task according to rules.

Confluence

This confluence contains various information from HOW-TOs for architecture documentation. Here is the list related to our squad:

  • Documentation of processes and overall architecture within Transaction scope is here.

  • General section focused on tech people is here.

  • Section specific for developers suitable as part of onboarding process can be found within previous section, yet it is wort to mention and can be found here.

3rd parties

The list of 3rd parties is follows:

  • Paynamics - first implemented services provider. We currently use most of the services using them. Till Pesonet and Instapay is ready, Paynamics will also be used for outbound interbank transactions. (Both fast & slow). Paynamics are implemented within “Paynamics gateway” component. Sources can be found here. Services offered and used by SaFi are:

    • Debit card top-up

    • Bank top-up

    • Bank withdrawal (interbank outbound transaction)

    • OTC Cash-in

    • OTC Cash-out

    • E-wallet top-up

    • E-wallet withdrawal

    • Bill payments

    • Digital goods Mobile phone Airtime Load

    • Digital goods E-pins (not implemented, planned for public launch)

  • Pesonet - provides next day interbank transactions (inbound & outbound). The services, which will be offered by Pesonet are:

    • Inbound interbank transaction (bank top-up)

    • Outbound interbank transaction(bank withdrawal)

    • Inbound e-wallet

    • Outbound e-wallet

As Pesonet testing instance is not available, there is written Pesonet sandbox following its documentation.

  • Ecpay - is integrated using Ecpay gateway. It offers following services:

    • Bill payments (Automatic accreditation to all ECPay’s Billers, as mutually agreed upon)

    • Digital goods Mobile phone Airtime Load (Electronic Pre-Paid Loading of all Major Telecommunication Companies, Gaming and Internet)

  • Digipay - is integrated using Digipay gateway. It offers following services:

    • OTC Cash-in

  • Instapay - provides “fast” interbank transactions (inbound & outbound) within same day. This service has tricky SLAs and specific requirements including hardware. Its implementation was postponed. The services, which will be offered by Instapay would be identical to the ones offered by Pesonet:

    • Inbound interbank transaction (bank top-up)

    • Outbound interbank transaction(bank withdrawal)

    • Inbound e-wallet

    • Outbound e-wallet

  • Atome - Some initial analysis was done, however due to un-cooperation of the partner it was frozen. Some initial analysis can be found here. Atome should offer “Direct debit BNPL payment”.

All available documentation to 3rd parties is stored in the Lark here apart from Digipay, where we were providing our API to the partner.

Contact persons/channels

Please ask User 55816 or Jideo Pena (Unlicensed) for information regarding all partners as communication was mostly covered by them.

  • For Paynamics specifically, there exist Viber channel for direct communication with provider. Janjan or Jideo could add you there if needed. For issues, there is google doc for tracking issues.

Credentials

Developers have access to “dev” environment (current name is “brave”). Microservices do not use hardcoded credentials, but they use predefined set of environment entries, which are then set by Kubernetes. To access eg. database developer can credentials from Hashicorp Vault using these steps.

Dev level test

All transactions microservices have component tests within src/test folders. These follows rules defined for isolated tests and are environment independent. They are relying on JDK17 and Docker. Apart from that, they run using embedded gradle (gradlew) instance, yet they download the artefacts from Safi repository. Therefore internet connection is still required.

Bugs/VAPT findings

No VAPT findings.

Planned development for MVP

This is the list of epics planned but not finished (as of today 24.11.2022).

  • SM-1732 - Digital Goods: Mobile Top-up Airtime Load (Paynamics) In Review - finish review of FE implementation

  • SM-3092 - Push Notifications In Progress - some notifications still needs to be pushed

  • SM-3945 - MVP: Technical tasks, Refactoring & Debts In Progress - various tech debts planned for MVP. Mainly related to idempotency or edge cases to improve data consistency.

  • SM-1559 - Transaction Browsing in App In Progress - FE tasks to improve transaction browsing

  • SM-5060 - Attempted Failed Transaction - Error Messages (MVP) In Progress - Consistent handling of eror messages.

  • SM-4597 - Bank Statement (MVP) In Progress - Main task here is to pair balance change event with transaction. To day, this was just calculated.

  • SM-4720 - Slacker Integration in Transactions (MVP) In Progress - Slacker is already integrated, however there is work needed to polish some cases.

  • SM-4905 - Display List of Historical Transactions (MVP) In Progress - There is need to integrate into transaction history also transactions, which do not originate in TPM. Currently, there is need to add loan related transactions.

  • SM-5057 - Transfer money between intrabank accounts (MVP) In Progress - Intrabank is implemented however there are still some UX tweakts to be done.

  • SM-5059 - Transaction Fee & Remaining free transactions (MVP) In Progress - Vendor fee was not part of EPFS release. It is not yet done for MVP release.

  • SM-6503 - Design updates for Transactions MVP Flows In Progress - Design updates most likely finished before 2.12.

  • SM-5814 - Pesonet Integrations (MVP) In Progress - Pesonet is not yet merged. It still needs some polishing, and works on integration to TPM are parts of MVP.

  • SAF-999 - Internal accounts and transaction structure Backlog - This epic is covering multiple squads. There is idea to have library for postings generations. Such library would remove necessity to understand accounting structure of internal accounts. It is currently being implemented by account squad, and subsequently need to be used also in TPM (replacing producers and listeners handling communication with TM.)

  • SM-3743 - Audit logging for all domains In Progress - in MVP is expected audit log. We are curently gathering all the information to know, what to audit.

  • SM-624 - Automated Scheduling one-time & recurring (MVP) In Progress - Scheduling is WIP with many open topics.

Apart from these tasks, we were planning to use improve tests mostly on gateways after they start using database, mostly for idempotency and therefore also robustness of the whole solution. Key to transactions are retry-ability of the operations and its single execution, to achieve “exact one” case for each transaction in scope. This is ongoing MVP effort.

Ownership handover

New tech lead for transaction squad should be User 55816.

For developers

  • Code structure presented on handover sessions.

  • Architecture to be finished yet, including context diagrams.

  • The rest of information is in Dev HOW TO in Jira.

  • Simply described, transaction squad covers business functionality of:

    • Intrabank transactions

    • Inbound interbank transactions

    • Outbound interbank transactions

    • Various cash in and cash out options

    • Bill payments

    • Top ups from various sources