Processing Visa Queue using Pega Agents

From PegaWiki
Revision as of 14:30, 1 February 2021 by Karnm (talk | contribs) (→‎Configurable rules:: Updated sub headings)

Jump to navigation Jump to search


Curator Assigned
Request to Publish
Description Defining the process of handling Visa Batch Queue records using Pega Agents
Version as of 7.48
Application Smart Dispute for Issuers & Acquirers
Capability/Industry Area Financial Services

↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓ Please Read Below ↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓

Enter your content below. Use the basic wiki template that is provided to organize your content. After making your edits, add a summary comment that briefly describes your work, and then click "SAVE". To edit your content later, select the page from your "Watchlist" summary. If you can not find your article, search the design pattern title.

When your content is ready for publishing, next to the "Request to Publish" field above, type "Yes". A Curator then reviews and publishes the content, which might take up to 48 hours.

↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓ The above text will be removed prior to being published ↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓

Visa Batch Queue overview[edit]

This topic defines the design used in implementing the process of reading and processing the actions performed on the disputes by the two opposite parties i.e., the Issuer and Acquirer through the association VISA on regular intervals by using Pega agent rules.

Visa Batch Queues are lists of cases or transactions that are owned by a user’s organization, either cases requiring action from the user or showing actions by the user and are used 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, misc. fees, etc.
  • 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 and/or services who accepts credit or debit cards in payment

Acquirer: The financial institution that is the merchant’s representative in the transaction and receives a financial transaction's electronic data from a 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 inadvertent 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 VCR_IssuerBQProcessing activity for Issuer and VCR_AcquirerBQProcessing activity for Acquirer that takes the following parameters:

  • BatchQueueName depends on the queue from which Pega Smart Dispute for Issuers/Acquirers attempts to retrieve the records
  • ProcessBatchQueue which determines whether Pega Smart Dispute for Issuers/ 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 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]

The below mentioned API’s are provided by Visa to read and mark the queue record as read:

  • GetBatchQueueOperation - Used to retrieve transactions from an RTSI Batch Queue based on the member role, 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 - Used to mark a transaction as read and remove it from the RTSI Batch Queue using BatchQueueItemSID value to prevent the records from appearing in the queue during 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 1 page is processed at once, the retrieved records will be 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. This attribute uniquely identifies a queue record. Only selected attributes from the queue record are stored 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 / Acquirers or a corresponding entry in another staging table has been processed, and 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 agents were configured to 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”, records that are already present in the staging table will be processed; otherwise, new records will be 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 if case does not exist in the system with the VisaCaseNumber, then a case is created. Otherwise, if a dispute exists, processing is done to the existing case.
  • In all other cases, the dispute will wait for a response from the opposite party. In such cases, the activity will identify the case which is waiting for the response by using the VisaCaseNumber. After the case is found, the activity will look up the Flow and Flow Action name in the FlowNameLookupForVCRDQueue, FlowNameLookupForVCRSQueue, and FlowNameLookupForVCRRandTQueues decision tables, and then resume the flow.

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

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

The queue record will not contain the complete information. For complete information pertaining to 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 will later be replaced by class of the work object being resumed.
  • ReportName – The name of the Report Definition rule which is used to identify the work object to be resumed.
  • DTName – The data transform rule for initiating the work page.
  • FlowName – In case of issuer, if a pre-compliance request is received in the absence of an existing work object, this flow should create a work object and start the pre-compliance flow.
  • VCR_MaxRecordsForBQProcessing – The maximum batch queue records which will be 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 case status of the queue record, which can be used 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. These classes should be replaced by the implementation layer integration classes.

  • Customers can extend AdditionalExceptionProcessing activity rule in the PegaCard- Sd-Visa- class to handle exceptions caught during the processing of queue records.

Results[edit]

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