Processing Mastercard queues

From PegaWiki
Processing Mastercard Queue using Pega Agents / This is the approved revision of this page, as well as being the most recent.
Jump to navigation Jump to search

Processing Mastercard queues

Description Describes the process and configuration of Mastercard queues using Pega Agents
Version as of 7.4
Application Pega Disputes and Payments Exceptions
Capability/Industry Area Financial Services

This article describes the Smart Disputes configurations used to process the Mastercard batch queues.

Mastercard batch queue overview

Mastercard batch queues are lists of cases or transactions that are owned by a user's organization. Cases are used to manage a user's workflow. They require user action or indicate actions performed by the user.

The following are the Mastercard batch queue categories:

  • Category claims for chargebacks, re-presentments, rejects, fee collection and so on.
  • Category retrieval requests for actions performed by Issuers and Acquirers on retrieval requests
  • Category chargebacks for information on chargebacks and re-presentments and their corresponding documents
  • Category case filing

Before you begin

Issuer: The bank or financial institution that issues the credit or debit card to the account or cardholder.

Merchant: A seller of goods and/or services who accepts credit or debit card payments.

Acquirer: The financial institution that represents the merchant. For a transaction, the Acquirer receives electronic data from a Merchant and adds it to an interchange system.

Dispute: A situation in which a customer questions the validity of one or more transactions on a credit or debit card account.

Chargeback: The dispute raised by Issuer on behalf of the cardholder to the Mastercard association.

Processing Mastercard batch queues using Pega agents

The application provides several advanced agents rules to fetch, save, and process batch queue records retrieved from the Mastercard system.

Note: To prevent automatic processing of batch queue records, all the agents are disabled by default and must be enabled during implementation.

All the agent rules are configured to run the MCom_IssuerBQProcessing and MCom_AcquirerBQProcessing activity for Issuers and Acquirers respectively. These activities are responsible for retrieving the queue records, save, and process the corresponding disputes. MCom_IssuerBQProcessing / MCom_AcquirerBQProcessing accept the following parameters:

  • QueueName: The queue type from which the application for Issuer/Acquirer attempts to retrieve the records.
  • StageName: The stage at which the disputes have received response actions from the opposite party.·    

Fetching and saving queue records

The Invoke queue summary agent is configured to fetch the batch queue records from Mastercard. The GetQueueSummaryPost API is provided by Mastercard and is used to retrieve claims for a particular queue available to Issuer or Acquirer based on the member role sent in the request.

The MoveMCOMOldSummaryData activity is configured to move the claim records to sd_mcom_queuesummarylog table. Claimid and queuenames columns together comprise the unique identifier for the table. The isProcessed column value is set to N.

The MCOMSummaryCleanUp data transform is configured to contain the following:

  • The number of days the claim record is available for processing
  • The number of days before the claim is removed from the log table

Once the record is processed then the isProcessed column of the record is set to Y. If the record is not processed for the configured period, it is moved to the d_mcom_queuesummarylog log table .

The records are removed from the sd_mcom_queuesummarylog table after . The CleanUpQueueSummaryLogTable activity is configured to remove claims from the sd_mcom_queuesummarylog table.

Processing queue records

To process the claim records, Smart Dispute Issuer and Acquirer agents are configured with their corresponding queue and stage names as input parameters.

A case is considered to be valid if the claim records within the corresponding queue and stage name in the database has the isProcessed indicator set to N. The agent identifies a valid case, and moves it to a valid assignment.

In the MCom_IssuerBQProcessing activity, the available list of queue records are retrieved for processing as follows:

  • Acquirers: For incoming cases, if the case does not exist in the system with a ClaimID then a new case is created. Else, the case is processed to next assignment.
  • Cases are identified based on the queuename, stage name, and the ClaimID’s received in the batch queue record. After the cases are identified, the activity looks up the flow name, flow action name, flow assignment status in the GetMComQueueInputs decision table and resumes the cases.

The isProcessed column value is set to Y for processed claim records.

Configurable rules

The following rules can be overridden during implementation:

Decision table

The GetMComQueueInputs decision table in PegaCard-Sd-Dispute-MC and PegaCard-Sd-DisputeAcq-MC for Issuers and Acquirers respectively. This decision table is used to configure the flow name, flow action name and flow assignment status of the cases that need to be processed via MCOM agents.

Other rules

  • The PrepareMComQueueList data transform in PegaCard-Sd-Dispute-MC PegaCard-Sd-DisputeAcq-MC for Issuers and Acquirers respectively is used to build a list with available Mastercard queue names that is consumed in the application.
  • The MCOMClaimsMgrConfig data transform in PegaCard-Interface-Admin-MC-MCOM-CM-Config class is used to configure all the necessary environment properties required for dispute processing in MCOM.


The Issuer or Acquirer processes the Mastercard batch queues using agents .