SaFi Bank Space : Pesonet gateway - component description

General description

The aim of this component is to provide an outlet for communication with Pesonet, which is a payment processor..

Context

To explain communication of pesonet gateway we first need to look at some core concepts in Pesonet. Mainly the types of messages it works with. In general there are 2 different classification of messages, first according to the origination of message which splits into Outward and Inward and the second based on content which is Transaction and Transaction Status Update. Both of these classification need to be set for us to know what we are dealing with.

Outward Transactions - originate in SaFi and we need to propagate them to Pesonet. Origin of these transactions will be the Transaction Processor Manager(further TPM) and we receive them via Kafka with idempotent handling. As this integration s not yet done we have some development endpoints to simulate this behavior. Afterwards these transactions are stored within PeG and then synchronized with Pesonet according their cycle and also by our defined maximal batch size. These transactions are pending in our system until we receive status update from Pesonet. The messages that we send towards Pesonet should be in the pacs0008 message format of the ISO 20022 standard.
Inward transactions - originate in other banks and we receive them when we poll Pesonet for any such transactions in Pesonet cycles. These transactions are then queried from Pesonet via REST and we receive them in pacs0008 message format of the ISO 20022 standard and afterward are stored in db. After we store them in db propagated towards the rest of SaFi ecosystem via Kafka.
Outward Transaction Status Update - originate in other banks and we receive them in cycles as we poll for them via REST to Pesonet. Afterwards they are queried from Pesonet via REST and we receive them in the pacs0002 message format of the ISO 20022 standard. These messages are then used to update entities in the database of PeG to have the correct status. This change is then communicated via Kafka to the rest of the SaFi ecosystem.
Inward Transaction Status Update - originate in SaFi and need to be communicated toward Pesonet. The origin of them will be TPM, but as the integration is not done we have enpoints to simulate this behavior. After we recieve this message we update the entity in the db to correct status and then convert the update to pacs0002 message and send it to Pesonet via REST.

Except for these communications we communicate with Pesonet via REST to get information on the cycles.

There is also one other part of pesonet gateway when it comes to the database and that is that we store all of the requests and responses sent and received from Pesonet. These records are stored with id, timestamp when they were sent, the body in String format and the url to which they were sent.

Transaction processing

Describe, how TX (software dev meaning) are implemented ( eg. controller or service level, declarative, repositories TX.Mandatory? etc)

Scalability

Similar to most services with database and idempotent handling the main issue in scalability is the access to the same database for all instances and also correct handling of consuming kafka messages(for Inward Transaction Status Updates).

Approach to security

The communication with SaFi ecosystem is handled via kafka, which should be always authorized and for communication with Pesonet we use the credentials that are provided to us(apiKey and apiSecret).

Domain model

This is the domain model of the database in the PeG service. The request and response entities are explained above.

For the transaction entities they contain they are simplified view on the database model that can be found here: outward and inward.

Current technical debt

The code is tough to understand on first go through and also requires the understanding of Pesonet itself. It possibly could be improved in that way, but from functional standpoint there are only few things that might make sense to revisit:

Batch size - currently we use batch approach to synchronize transactions