Difference between revisions of "Processing Visa Queue using Pega Agents"

From PegaWiki
Jump to navigation Jump to search
(updated application name)
Tag: Visual edit
(updated version as of)
Tag: Visual edit
 
Line 1: Line 1:
{{Design pattern|Title=Processing Visa Queue using Pega Agents|Description=Defining the process of handling Visa Batch Queue records using Pega Agents|Version=7.48|Applications=Pega Disputes and Payments Exceptions|Capability Area=Financial Services|Owner=Bharr1}}
+
{{Design pattern|Title=Processing Visa Queue using Pega Agents|Description=Defining the process of handling Visa Batch Queue records using Pega Agents|Version=7.4|Applications=Pega Disputes and Payments Exceptions|Capability Area=Financial Services|Owner=Bharr1}}
  
 
==Visa Batch Queue overview==
 
==Visa Batch Queue overview==

Latest revision as of 19:25, 29 June 2021

Processing Visa Queue using Pega Agents

Description Defining the process of handling Visa Batch Queue records using Pega Agents
Version as of 7.4
Application Pega Disputes and Payments Exceptions
Capability/Industry Area Financial Services



Visa Batch Queue overview[edit]

This topic defines the design used in implementing reading and processing the actions performed on the disputes by the two opposite parties, the issuer, and acquirer, through the VISA association on regular intervals by using Pega agent rules.

Visa Batch Queues are lists of cases or transactions that a user's organization owns. They are either the cases that require user action or those showing user actions to manage a user's workflow.

The following are the different types of Batch Queue formats provided by Visa:

  • Queue format T for RFC, collaboration requests and responses, miscellaneous fees, and more
  • Queue format R for all rejects
  • Queue format S for legacy pre-compliances, pre-arbitrations, and case filings
  • Queue format D for all acceptances, awaiting action disputes, and VCR pre-filings

(Application rules: CheckIfQueueCanBeProcessedInSD (Issuer) and CheckIfQueueCanBeProcessedInSDForAcquirer (Acquirer) rules can be referred to check the corresponding D Queue, S Queue, T Queue and R Queue items based on the Batch queue type and cases status)

Before you begin[edit]

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

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

Acquirer: The merchant's representative financial institution in the transaction that receives the financial transaction's electronic data from the merchant and places that data into 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

Processing Visa Queues using Pega Agents[edit]

Pega Smart Dispute provides several advanced agents rules to fetch, save, and process the Batch Queue records retrieved from VROL.

Note: To prevent accidental processing of batch queue records, the application disables all the agent records by default. You should enable them during implementation.

All the agent rules are configured to run the VCR_IssuerBQProcessing activity for the issuer and VCR_AcquirerBQProcessing activity for the acquirer with the following parameters:

  • BatchQueueName depends on the queue from which Pega Smart Dispute for issuers or acquirers attempts to retrieve the records.
  • ProcessBatchQueue determines whether Pega Smart Dispute for issuers or acquirers fetches new records from the Visa Batch Queue or processes the records which have already been inserted into the Batch Queue staging tables when the value is true.

The VCR_BatchQueueProcessing activity rule in the PegaCard-Sd-Dispute-Visa- class is the core activity responsible for performing the following actions:

Fetching and saving queue records[edit]

VISA provides the following APIs to read and mark the queue record as read:

  • GetBatchQueueOperation: retrieves transactions from an RTSI Batch Queue based on the member role and BatchQueueType and page number sent in the request. Each page contains 400 records or the number configured by the member in the VROL System.
  • MarkBatchQueueItemAsReadOperation: Marks a transaction as read and removes it from the RTSI Batch Queue using BatchQueueItemSID value to prevent the records from appearing in the queue during the next batch queue operation.

After fetching the records, they are saved to the Smart Dispute batch queue staging tables listed below before marking them as read and processing.

If multiple pages exist, only one page is processed at once, and the retrieved records are marked as read and removed from the queue. GetBatchQueueOperation is invoked again to fetch the new set of records.

Each staging table stores records related to a particular queue format:

  • SD_VCR_DQUEUE table mapped to the PegaCard-Int-Visa-FormatDQueueItemType integration layer class stores records that belong to the D queue format.
  • SD_VCR_TQUEUE table mapped to the PegaCard-Int-Visa- FormatTQueueItemType integration layer class stores records that belong to the T queue format.
  • SD_VCR_RQUEUE table mapped to the PegaCard-Int-Visa-FormatRQueueItemType integration layer class stores records that belong to the R queue format.
  • SD_VCR_SQUEUE table mapped to the PegaCard-Int- Visa-FormatSQueueItemType integration layer class stores records that belong to the S queue format.

BatchQueueItemSID is the primary key for all the above tables, which uniquely identifies a queue record. The application stores only selected attributes from the queue record in the staging tables.

SD_VCR_OTHER table mapped to PegaCard-Int-Visa-OtherQueueType integration layer class is an additional staging table that stores:

  • Records that cannot be processed because either the Visa Case Status is not applicable to Pega Smart Dispute for issuers or acquirers, a corresponding entry in another staging table has been processed, or the dispute case already resumed. This duplicate message can be skipped
  • Records from the other batch queue staging tables that have exceeded the maximum number of retries for processing.

If the retry count exceeds the specified threshold, the VCR_UnProcessedQueueItemFilterForIssuer activity moves the batch queue records from the respective staging tables to SD_VCR_OTHER table. The following four agent configurations filter the staging tables:

  • Cleanup of Unprocessed cases D Queue
  • Cleanup of Unprocessed cases S Queue
  • Cleanup of Unprocessed cases T Queue
  • Cleanup of Unprocessed cases R Queue
  • Cleanup of OtherTable

The VCR_CleanUpOtherTable activity removes items from the SD_VCR_OTHER staging table based on an interval defined in the BQRecordCleanUpInterval dynamic system setting.

Processing queue records[edit]

Separate Smart Dispute for issuers and acquirer agents are responsible for handling records on the Batch Queues and processing them within the application. When the ProcessQueueRecord parameter is set to true, the records that are already present in the staging table are processed. Otherwise, new records are fetched from the Visa Batch Queue and stored in the Smart Dispute staging tables.

In VCR_BatchQueueProcessing activity, the available list of queue records are browsed in the local database for processing.

  • For acquirers only: for incoming disputes for which the case does not exist in the application with the VisaCaseNumber, the appliation creates a case. Otherwise, the existing case goes into processing.
  • In all other cases: the dispute waits for a response from the opposite party. In such cases, the activity identifies the case that is waiting for the response by using the VisaCaseNumber. After finding the case, the activity looks up the Flow and Flow Action name in FlowNameLookupForVCRDQueue, FlowNameLookupForVCRSQueue, and the FlowNameLookupForVCRRandTQueues decision tables, and then resume the flow.

After successful processing, the record gets deleted from the database table.

Note: There should be only one dispute with a unique VisaCaseNumber in the application.

The queue record doesn't contain the complete information. For complete information about the record, either a Hyper search request or any other related service needs to be invoked in the flow that is being resumed.

Configurable rules[edit]

The following rules can be overridden during implementation:

Activity rule[edit]

The VCR_IssuerBQProcessing activity rule in the PegaCard-Sd-Dispute-Visa- class with the following parameters:

  • WorkPageClass: Your default work class for Visa international dispute. The class of the work object is later replaced by the class of the resuming work object.
  • ReportName – The name of the Report Definition rule that is used to identify the work object to be resumed.
  • DTName – The data transform rule for initiating the work page.
  • FlowName – In the issuer case, if a pre-compliance request is received in the absence of an existing work object, this flow creates a work object and starts the pre-compliance flow.
  • VCR_MaxRecordsForBQProcessing – The maximum batch queue records that are processed when a queue agent runs.
Decision tables[edit]

The following decision tables in PegaCard-Sd-Dispute-Visa- class:

  • FlowNameLookupForVCRDQueue
  • FlowNameLookupForVCRSQueue
  • FlowNameLookupForVCRRandTQueues
Other Rules[edit]

These rules will set the Flow Name and the Flow Action name to be resumed. These values must be configured based on the queue name being processed and the queue record's case status to identify the record type (Pre-Arb, Pre- Arb response, Pre-Comp, Pre-Comp response, etc.)

  • The MapBatchQueueType map value rule in the PegaCard-Sd-Dispute-Visa- class returns the integration class based on the Queue Name. The name of the integration class is required to retrieve the records saved in a database table. The implementation layer integration classes should replace these classes.
  • Customers can extend the AdditionalExceptionProcessing activity rule in the PegaCard- Sd-Visa- class to handle exceptions caught during queue records processing.

Results[edit]

The Issuer or Acquirer will be able to process the Visa batch queues using agents.