This documentation describes the flow of authorised-amount-settlement to settle an amount previously held by an outbound-authorisation transaction

Process Flow

Execution Steps

Note: Steps 5 and onwards are being managed by the Temporal container

 

 

1

User initiates a transaction (e.g. BO) to settle an amount authorised based on a previously executed outbound-authorisation transaction

 

2

Euronet initiates a request to the bank via the CTPM microservice API

POST /transaction/card-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": "MASTERCARD"
    },
    "cardInfo": {
        "proxyNumber": "string",
        "maskedCardNumber": "string",
        "cardVendor": "MASTERCARD"
    },
    "fee": {
        "amount": 0,
        "currency": "PHP"
    },
    "transactionType": "string",
    "transactionCode": "string",
    "note": "string",
    "noteToSelf": "string",
    "categoryCode": "ATM",
    "isFinal": "true"
}

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 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

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)

See Card Transaction Events

 

13

Response is returned as either SUCCESS or FAILED together with the transaction ID

 

 

References

Card Transaction Processor Manager API

Attachments: