This documentation describes the flow of adjusting the amount held in an account after an outbound-authorisation transaction and then a settlement transaction after.
Process Flow
Execution Steps
Note: Steps 4 and onwards are being managed by the Temporal container
|
| |
|---|---|---|
| 1 | User initiates a transaction (e.g. BO) to adjust a previously authorised amount |
|
| 2 | Euronet initiates a request to the bank via the CTPM microservice API | POST /transaction/card-auth-adjustment-settlement {
"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"
}
|
| 3 | 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 |
|
| 4 | Temporal workflow starts with the request being validated for idempotency (making use of Temporal capabilities) and then proceed to further steps |
|
| 5 | Request is retrieved from the transactions database and saved if it still doesn’t exist | TABLE: card_dms_transaction |
| 6 | Request for adjustment 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}}",
"authorisation_adjustment": {
"replacement_amount": "2.03"
},
"instruction_details": {
"transaction_type": "AUTHORISATION_ADJUSTMENT"
}
}
]
}
}
requestId is the idempotency-key from the request header batchId is a random UUID |
| 7 | The temporal workflow is halted with the workflow’s initial status (set to PENDING) |
|
| 8 | The corebanking system publishes the response to a kafka-topic | TOPIC: integration.postings_api.card_transaction_manager_postings_client.response |
| 9 | CTPM listens for a message from the kafka-topic in the previous step and filters out card-transaction-type responses |
|
| 10 | 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 |
|
| 11 | The temporal workflow continues the process with the transaction status-update in the database |
|
| 12 | Another temporal-workflow is started (details TBD) |
|
| 13 | Temporal workflow for settlement is started | |
| 14 | Request for settlement 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}}",
"settlement": {
"final": "true"
},
"instruction_details": {
"transaction_type": "AUTHORISATION_ADJUSTMENT"
},
"category_code": {
"domain": "AAA",
"family": "AAA",
"subFamily": "AAA"
}
}
]
}
}
requestId is the idempotency-key from the request header batchId is a random UUID |
| 15 | The temporal workflow is halted with the workflow’s initial status (set to PENDING) |
|
| 16 | The corebanking system publishes the response to a kafka-topic | TOPIC: integration.postings_api.card_transaction_manager_postings_client.response |
| 17 | CTPM listens for a message from the kafka-topic in the previous step and filters out card-transaction-type responses |
|
| 18 | The temporal workflow continues the process with the transaction status-update in the database |
|
| 19 | Another temporal-workflow is started (details TBD) |
|
| 20 | Response is returned as either SUCCESS or FAILED together with the transaction ID |
|
References
Attachments:
image-20221125-004808.png (image/png)
image-20221125-005209.png (image/png)
card-transaction-adjustment.drawio (application/vnd.jgraph.mxfile)
card-transaction-adjustment.drawio.png (image/png)
