General description
This component aims to provide an outlet for communicating with Paynamics, a payment processor provider.
Context
This service was designed to be fully stateless which means that it currently has no database or cache. This means that all of the flows do not have our internal idempotency solution. Luckily for us, Paynamics disallows repeated use of any request id, so if a request gets replayed it will fail on the paynamics side meaning there will be no duplicate side effects. The only potential issue is this may cause a transaction to have a wrong status at some point so we should look into implementing our idempotency solution into this service.
In general, this service has communication facing two ways: one inside SaFi and the second with 3rd party vendor Paynamics. First, we will go over the communication with Paynamics:
WorkflowAPI - is 1 of 3 Apis provided by paynamics that we have integrated and it oversees mainly the top-up flows and cash-in. We integrate with this API using REST calls and it responds with the initial status of the transaction(this part of the communication is synchronous). In the REST requests, we specify URL that should be used for final notification and that is delivered via a callback. This API uses JSON.
Dgate API - is 1 of 3 Apis provided by paynamics that we have integrated and it oversees mainly the interbank transfer, e-wallet withdrawal and cashout. We integrate with this API using REST calls and it responds with the initial status of the transaction(this part of the communication is synchronous). In the REST requests, we specify URL that should be used for final notification and that is delivered via a callback. This API uses XML.
Dgate API - is 1 of 3 Apis provided by paynamics that we have integrated and it oversees mainly the bills payment and airtime load. We integrate with this API using REST calls and it responds with the final status of the transaction. This process is fully synchronous for both bills and airtime load. This API uses JSON.
In the second category are channels that are used for communicating inside SaFi project. We decided to split them based on which service is communicating with paynamics gateway.
Transaction processing manager - Most of the communication with TPM is handled via REST calls that are synchronous and all of them originate in the Transaction processor manager. These calls usually initiate the transaction and the process of communicating with a specific part of paynamics. The communication that originates in Paynamics gateway with TPM is done via Kafka and it contains the updates for transactions that we received via callbacks from Paynmics
Merchant manager - merchant manager uses paynamics gateway to query all of the products and plans for airtime load and save it internally in itself. This call is made over REST and is fully synchronous.
Transaction processing
The service as mentioned above is completely stateless which means that all transactions are not saved inside the service and the service knows the information only for the request it is currently executing. The service does pass the information that it receives through. This happens either from TPM to paynamics or the other way around.
Scalability
There should not be any limitations on the number of instances at this moment that we know of. There may be some with regard to paynamics, but those have not been specified in the documentation.
Approach to security
The service uses an authorization library for incoming rest calls looking for authorization from internal service, as it has no endpoints connected to the front end. For communication with Paynamics we have already implemented the use of their signature approach. This means that we concatenate specific fields from the request, that is being sent to them, into a String and hash this string for a signature. Paynamics also has this approach in their responses, but the verification of the signatures sent by them is not yet implemented.
Domain model
Please ideally use Draw.io and make the model “high level”. This means to put there just core entities. On top of that, describe their purpose by text below diagram itself.
Current technical debt
As mentioned previously implementing proper idempotency is not strictly required, but would benefit us greatly -
Another point that should be revisited is to have the communication from TPM to PaG converted from synchronous rest calls to asynchronous Kafka calls. This makes sense as multiple new steps introduced in transaction processing are asynchronous making the whole process for TPM asynchronous. This means that synchronous communication with paynamics makes little to no sense in this regard.