This documentation describes the flow of card transfer-transaction from a synchronous-request coming in via the Euronet-Gateway microservice and asynchronous-handling behaviour of the corebanking-system (Thought Machine).
Process Flow
Execution Steps
Note: Steps 5 and onwards are being managed by the Temporal container
| 1 | User initiates a transaction (e.g. ATM) to transfer an amount to another account-number | |
| 2 | Euronet initiates a request to the bank via the Euronet-Gateway microservice API | POST /transaction/card-transfer {
"mti": "string",
"proxyNumber": "string",
"processingCode": "string",
"transactionAmount": 1.09,
"cardHolderBillingAmount": 0,
"transmissionDateTime": "string",
"systemTraceAuditNumber": "string",
"localTransactionDateTime": "string",
"merchantCategoryCode": "string",
"acquirerCountryCode": "string",
"panEntryMode": "string",
"networkID": "string",
"PosDataSF4": "string",
"PosDataSF5": "string",
"PosDataSF7": "string",
"PosDataSF10": "string",
"acquirerID": "string",
"retrievalReferenceNumber": "string",
"authorizationID": "string",
"cardAcceptorTerminalID": "string",
"cardAcceptorMerchantID": "string",
"cardAcceptorTermName": "string",
"transactionCurrencyCode": "PHP",
"cardHolderCurrencyCode": "PHP",
"transactionID": "{{transactionID}}",
"OrgtransactionID": "string",
"threeDsAuthTID": "string",
"DCCIndicator": "string",
"ECOMindicator": "string",
"UCAFIndicator": "string",
"threeDsValidation": "string",
"PANValidation": "string",
"expiryDateValidation": "string",
"pinValidation": "string",
"CVVValidation": "string",
"CVV2Validation": "string",
"EMVValidation": "string",
"MSTransactionTypeId": "string",
"MSTransactionRefData": "string",
"senderInfo": {
"accountId": "327994d9-ccf6-4cc5-9127-232bde6425a4"
},
"beneficiaryInfo": {
"accountId": "{{beneficiaryAccountId}}"
},
"cardInfo": {
"proxyNumber": "string",
"maskedCardNumber": "string",
"cardVendor": "MASTERCARD"
},
"fee": {
"amount": 0,
"currency": "PHP"
},
"transactionType": "string",
"transactionCode": "string",
"note": "string",
"noteToSelf": "string",
"categoryCode": "ATM",
"isReversal": "false"
}
|
| 3 | The incoming request is delegated downstream to the CTPM (card transaction processor manager) microservice | |
| 4 | The request is intercepted and validated against fraud via the slacker-manager microservice to proceed to the succeeding steps See for Card Transaction Anti-Fraud Check for documentation on different anti-fraud status | |
| 5 | Temporal workflow starts with the request being validated for idempotency (making use of Temporal capabilities) and then proceed to further steps | |
| 6 | Request is retrieved from the transactions database and saved if it still doesn’t exist | TABLE: card_sms_transaction |
| 7 | Request is posted to the corebanking system | POST /posting-instruction-batches:asyncCreate {
"request_id": "{{requestId}}",
"posting_instruction_batch": {
"client_id": "CardTransactionManagerPostingClient",
"client_batch_id": "{{batchId}}",
"posting_instructions": [
{
"client_transaction_id": "{{transactionId}}",
"transfer": {
"amount": "1.03",
"denomination": "PHP",
"debtor_target_account": {
"account_id": "327994d9-ccf6-4cc5-9127-232bde6425a4"
},
"creditor_target_account": {
"account_id": "{{beneficiaryAccountId}}"
},
},
"instruction_details": {
"transaction_type": "TRANSFER"
},
"category_code": {
"domain": "AAA",
"family": "AAA",
"subFamily": "AAA"
}
}
]
}
}
requestId is the idempotency-key from the request header batchId is a random UUID |
| 8 | The temporal workflow is halted with the workflow’s initial status (set to PENDING) | |
| 9 | The corebanking system publishes the response to a kafka-topic | TOPIC: integration.postings_api.card_transaction_manager_postings_client.response |
| 10 | CTPM listens for a message from the kafka-topic in the previous step and filters out card-transaction-type responses | |
| 11 | The listener triggers a signal-method (from the Temporal workflow started in Step 5) to update the status based on response from the previous step | |
| 12 | The temporal workflow continues the process with the transaction status-update in the database | |
| 13 | Another temporal-workflow is started (details TBD) | |
| 14 | Response is returned as either SUCCESS or FAILED together with the transaction ID |
References
Attachments:
image-20221124-032628.png (image/png)
image-20221124-032756.png (image/png)
image-20221124-230435.png (image/png)
image-20221124-231421.png (image/png)
image-20221124-232653.png (image/png)
card-transaction-transfer.drawio (application/vnd.jgraph.mxfile)
card-transaction-transfer.drawio.png (image/png)
