Skip to main content


         This documentation site is for previous versions. Visit our new documentation site for current releases.      
 

Pega Smart Dispute for Acquirers patch release notes 8.7.4

Updated on February 29, 2024

Pega Smart Dispute for Acquirers provides several enhancements to the application including but not limited to, Visa, Mastercard and AMEX association specific updates and country specific regulations as applicable. For detailed information about the product, see Smart Dispute for Issuersproduct page. This release includes fixes for the Incidents received (INCs), and application bugs.

  • Application: Smart Dispute for Issuers and Acquirers
  • Schemes Impact: Visa, Mastercard, AMEX
Pega Smart Dispute for Acquirers Release Notes

Resolved issues in Pega Smart Dispute for Acquirers 8.7.4

This table describes issues resolved in this release that are of the most interest to and likely to have the most impact on the Pega user and developer community.

The following ID references are used:

  • Reference numbers beginning with “BUG-” refer to entries logged in the Pega issue-tracking system.
  • Reference numbers beginning with “SR-” refer to corresponding Support Requests logged in My Support Portal.
  • Reference numbers beginning with “US-” refer to internally driven development items.

Resolved issues

Ticket # or ID #Title and Description
INC-A28434MCOM - Initiate Representment validation error
INC-A25474MCOM – Get Claim API - Date formats corrected in Simulate Data transform
INC-A21103MCOM - LoadCBData API - Response mappings are absent for 2 properties
INC-A25475MCOM - Correct status display for Resolved-CardHolderLiable in Dispute validations screen
INC-A20735MCOM - RejectedByMCom flag is not reset causing infinite loop in the Chargeback Rejection flows
US-583001MCOM - FNS Counter -Authorization Date to be fetched from Banknet Date from GetAuthdetails API response
INC-A22424MCOM – Straight Trough Processing Issue - Data Integrity Monitoring Program Validation
INC-A14825MCOM - Incorrect/Old authorizationdateandtime” is mapped on Transaction selection screen
US-575206Visa - 10.4 Other card Absent Dispute Validation – 35 Disputes
INC-A24953Visa - Associated Transaction Selection Operation API – Stale VROL ID sent in Service Request
INC-A22812Visa - SubmitContactMessageResponseOperation API - Response mapping issue
INC-A19041Visa - Duplicates-Questionnaire not in sync with IES23.2
INC-27035Visa - Accounting tab table alignment format mismatch
INC-A18403Claim level Bulk processing – Accounting Issue - Last dispute case accounting data is copied to the other disputes in the Claim

Mastercard/MCOM issues addressed in this release

The following is a list of Mastercard/MCOM issues that have been resolved in this release that are of most interest and likely to have the most impact on the Pega user and developer community.

MCOM - Initiate Representment validation error

Issue details

ApplicationSmart Dispute for Acquirers
Scheme ImpactMCOM
Scheme ReferenceNA
Dispute ReasonNA
Functional CategoryMCOM Representment
Effective DateNA
Reported IssueSmart Dispute for Acquirers application is displaying validation errors on submit of the Initiate representment screen for the reason code RC4807 and RC4812
Smart Dispute Implementation
  1. In the ValidateRC4807 validate rule, the validations related to below properties are removed:
    • .RepresentmentData.EnrolledChipLiabilityShift
    • .RepresentmentData.EMVChipCard
    • .RepresentmentData.POITerminal
    • .RepresentmentData.CardSignatureDocAttached

      Added a new validation related to the .RepresentmentData.DoesTransSatisfyAllRepreConditions property when value is set to No/false.

  2. In the ValidateRC4812 validate rule, the validations related to below properties are removed:
    • .RepresentmentData.EnrolledChipLiabilityShift
    • .RepresentmentData.EMVChipCard
    • .RepresentmentData.POITerminal
    • .RepresentmentData.CardSignatureDocAttached
    Added a new validation related to the .RepresentmentData.DoesTransSatisfyAllRepreConditions property when value is set to No/false.
How to test the functionality
  1. Process a Mastercard charge back with reason code 4807 and 4812 in the Smart Dispute for Acquirer application.
  2. On the Review inbound chargeback screen select representment as the further processing.
  3. On the Initiate representment screen, choose the dropdown value for the Initiate Representment as Chip Liability Shift, provide valid values for all the mandatory questions and submit the case.
  4. Verify if the application does not display any validation when Yes is selected for the question Does the transaction satisfy ALL the below mentioned Representment conditions?
  5. Verify if the application displays validation error for an invalid Representment when No is selected for the question Does the transaction satisfy ALL the below mentioned Representment conditions?

MCOM – Get Claim API - Date formats corrected in Simulate Data transform

Issue details

ApplicationSmart Dispute for Issuers and Acquirers
Scheme ImpactMCOM
Scheme ReferenceNA
Dispute ReasonNA
Functional CategoryMCOM API
Effective DateNA
Reported IssueDate formats in the Simulate_GetClaim data transform are incorrect
Smart Dispute ImplementationIn the Simulate_GetClaim data transform, applicable date fields are updated with addToDate function and all the date fields are updated with the DateFormat function to show the MCOM simulated GetClaim response to the actual MCOM GetClaim response in the format of YYYY-MM-DD.
How to test the functionality
  1. Verify if simulation is enabled for Mastercard.
  2. Create a Mastercard dispute from the Smart Dispute for Issuers application.
  3. Process the applicable early resolution stages (if any).
  4. Process the Qualify Dispute screen.
  5. Process the Answer ancillary screen by responding to the questions.
  6. Submit the Chargeback to Mastercard.
  7. Proceed further with the Awaiting Acquirer response screen.
  8. Now under the MCOM_GetClaim page, all the date fields should be visible in the format of YYYY-MM-DD.

MCOM - LoadCBData API - Response mappings are absent for 2 properties

Issue details

ApplicationSmart Dispute for Issuers
Scheme ImpactMCOM
Scheme ReferenceNA
Dispute ReasonNA
Functional CategoryMCOM API
Effective DateNA
Reported IssueThe LoadCBData API response is not mapped to the clipboard when the API returned the success response.
Smart Dispute Implementation
  1. In the LoadCBData Connect-Rest rule, request header and body are included.
  2. In the LoadCBDataResponsePOST data transform, mapping of the API response back to the clipboard is included.
How to test the functionality
  1. Currently, the LoadCBData API is not invoked in the Smart Dispute for Issuers application. The implementation of the LoadCBData API invocation can be in one of the upcoming releases.
  2. For testing purpose, invoke the LoadCBData API in the flow rule after the TransClrDetail API and check the response that is mapped to the clipboard.

MCOM - Correct status display for Resolved-CardHolderLiable in Dispute validations screen

Issue details

ApplicationSmart Dispute for Issuers
Scheme ImpactMCOM
Scheme ReferenceNA
Dispute ReasonNA
Functional CategoryResolution Status
Effective DateNA
Reported IssueWhen a dispute is resolved as card holder liable from the dispute validations assignment, the case status should reflect the status as Resolved-CardHolderLiable as it does in all the other flows and scenarios with no space in the pyStatusWork and not as Resolved-CardHolder Liable.
Smart Dispute Implementation
  1. Updated pyStatusWork in the flow CHLiableAcctg to Resolved-CardHolderLiable.
  2. Deprecated pyStatusWork Resolved-CardHolderLiable.
Note: A utility needs to be created at the implementation layer to get the status updated for the old cases.
How to test the functionality
  1. Create a MasterCard case.
  2. Process the applicable early resolution stages (if any).
  3. Process the Qualify Dispute screen.
  4. Process the Answer ancillary screen by responding to the questions and submit the dispute case.
  5. Resolve the case as cardholder liable in Dispute validations screen and submit the dispute case.
  6. Verify that the case resolution status is Resolved-CardHolder Liable.

MCOM - RejectedByMCom flag is not reset causing infinite loop in the Chargeback Rejection flows

Issue details

ApplicationSmart Dispute for Issuers
Scheme ImpactMCOM
Scheme ReferenceNA
Dispute ReasonNA
Functional CategoryMCOM Chargeback – Rejection Response
Effective DateNA
Reported IssueWhen a chargeback is submitted to Mastercard and subsequently the Acquirer rejects the Collaboration request, then Issuer application should read the reject reason 5000 and Acquirer response code so that the case is routed to the appropriate assignment.
  • If Acquirer response code is 'C' and refund details are not available after 5 days (SLA expiry), the dispute should be routed to Awaiting Acquirer Response screen, considering the Collaboration Request as rejected and the flag RejectedByMCom is not reset to false.
  • If the Acquirer Response Code is 'E' (5000 E), then the case moves into Awaiting Acquirer Response considering the collaboration request as rejected and the flag RejectedByMCom is not reset to false.
In both the scenarios, as the flag is not reset, the dispute is in an infinite loop.
Smart Dispute ImplementationIn the MCFirstChargeback flow, the RejectedByMCom flag is reset to false in the outgoing connector named Reject Collaboration of First CB rejected subprocess.
How to test the functionality
  1. Create a MasterCard case.
  2. Process the applicable early resolution stages (if any).
  3. Process the Qualify Dispute screen.
  4. Process the Answer ancillary screen by responding to the questions.
  5. Submit the chargeback to Mastercard.
  6. Upon receiving the Acquirer response code as E, the dispute should be routed to Awaiting Acquirer Response assignment.
  7. Verify the RejectedByMCom property reset to false in the clipboard.
  8. Upon receiving the Acquirer response code as C, dispute should be routed to the Awaiting refund information from Acquirer assignment with SLA of 5 days.
  9. After SLA expiry, the dispute should be routed to Awaiting Acquirer Response screen, considering the Collaboration Request as rejected.
  10. Verify the RejectedByMCom property reset to false in the clipboard.

MCOM - FNS Counter -Authorization Date to be fetched from Banknet Date from GetAuthdetails API response

Issue details

ApplicationSmart Dispute for Issuers
Scheme ImpactMCOM
Scheme ReferenceAN 7207 Article from MasterCard
Dispute ReasonNA
Functional CategoryFraud Notification Service
Effective DateNA
Reported IssueMastercard confirmed to use BanknetDate from GetAuthdetails service as authorization date for FNS Counter validation.
Smart Dispute ImplementationBanknetDate from the GetAuthdetails service is used as authorization date for FNS Counter validation in the When condition IsFraudAuthDateAfterCutoff.
How to test the functionality
  1. Create a Mastercard fraud case.
  2. Process the applicable early resolution stages (if any).
  3. Process the Qualify Fraud Dispute screen.
  4. Process the Answer ancillary screen by responding to the questions and submit the dispute case.
  5. The outcome of the applicable dispute validation will be determined depending on the below criteria, when authorization date is before Nov 6, 2023:
    • If the number of Fraud-Related Chargebacks on the account is less than 15, dispute validation outcome will be Pass.

      OR

    • If the number of Fraud-Related Chargebacks on the account is more than or equal to 15, dispute validation outcome will be Fail.

    Dispute Validation: For transactions that are authorized on or before Nov 6, 2023: FNS Counter Exceeds 15 Fraud-Related Chargebacks. The Issuer submitted more than 15 chargebacks in aggregate involving the same account (as defined above) for message reason codes 4837, 4840, 4870, or 4871. Message reason code 4863 first chargebacks will be included in the FNS count once the FNS fraud chargeback count is two or greater

  6. The outcome of the applicable dispute validation will be determined depending on the below criteria, when authorization date is after Nov 6, 2023:
    • If the number of Fraud-Related Chargebacks on the account is less than 35, dispute validation outcome will be Pass.

      OR

    • If the number of Fraud-Related Chargebacks on the account is more than or equal to 35, dispute validation outcome will be Fail.

    Dispute validation: For transactions that are authorized on or after Nov 7, 2023: FNS Counter Exceeds 35 Fraud-Related Chargebacks. The issuer submitted more than 35 chargebacks in aggregate involving the same account (as defined above) for message reason codes 4837, 4840, 4870, or 4871. Message reason code 4863 first chargebacks will be included in the FNS count once the FNS fraud chargeback count is two or greater.

MCOM – Straight Trough Processing Issue - Data Integrity Monitoring Program Validation

Issue details

ApplicationSmart Dispute for Issuers
Scheme ImpactMCOM
Scheme ReferenceNA
Dispute ReasonNA
Functional CategoryStraight Trough Processing
Effective DateNA
Reported Issue
  • As a part of data integrity program, Edit 1 and Edit 2 validations have been introduced for Fraud/Non-Fraud disputes.
  • When any of these validations are true, an information message is displayed on screen at Answer ancillary questions assignment for the user to be compliant.
  • In a STP scenario, as this assignment is processed in the background, user does not get a chance to see these messages which is not the correct application behaviour
Smart Dispute Implementation
  1. Added data integrity check in the STP process.
  2. When any of the data integrity validations are evaluated to be true, the STP process halts and land on the Answer Ancillary Questions assignment.
How to test the functionality
  1. Create a Mastercard Claim with multiple dispute cases via web self-service API.
  2. Make sure any of the data integrity validations is true.
  3. Verify STP process halts and land on the Answer Ancillary Questions assignment

MCOM - Incorrect/Old authorizationdateandtime is mapped on Transaction selection screen

Issue details

ApplicationSmart Dispute for Issuers
Scheme ImpactMCOM
Scheme ReferenceNA
Dispute ReasonNA
Functional CategoryTransaction selection
Effective DateNA
Reported IssueIncorrect/Old authorizationdateandtime is mapped on Transaction selection screen.
Smart Dispute ImplementationUpdated the banknetDate for authorizationDateAndTime in the PreMCTranSelection data transform at line number 4.1.2.
How to test the functionality
  1. Create a Mastercard Non-Fraud dispute case with an ARN that has multiple records.
  2. Process the applicable early resolution stages (if any).
  3. Process the Qualify Dispute screen and submit the dispute case.
  4. Verify if the user navigates on Transaction selection screen.
  5. Verify if the authorization date column shows correct authorization date values.

Visa/VCR issues addressed in this release

The following is a list of Visa/VCR issues that have been resolved in this release that are of most interest and likely to have the most impact on the Pega user and developer community.

Visa - 10.4 Other card Absent Dispute Validation – 35 Disputes

Issue details

ApplicationSmart Dispute for Issuers
Scheme ImpactVisa
Scheme ReferenceNA
Dispute ReasonFraud 10.4 – Card Absent Environment
Functional CategoryFraud
Effective DateNA
Reported IssueIndividual transactions should contain Multiple Clearing Sequence Numbers that result from the same authorization are treated as one Transaction towards the 35 Fraud Transaction limit under Fraud 10.4 – Card Absent Environment.
Smart Dispute Implementation
  1. In the D_GetpastDisputes data page one more source is added to fetch the number of dispute transactions towards the 35 transaction limit for 10.4 dispute category condition.
  2. The GetPastDisputesForOtherCardAbsentDisputes report definition is created to fetch the number of dispute transactions towards the 35 transaction limit for 10.4 dispute category condition as a source for the D_GetpastDisputes data page.
  3. The GetPastDisputesForOtherCardAbsentDisputes response data transform is created to convert the individual transactions that contain a multiple clearing sequence number that result from the same authorization are treated as one transaction toward the 35 transaction limit for 10.4 dispute category condition.
  4. The WhenCardAbsentOtherDisputes when rule created to check the dispute category condition as 10.4 used in the D_GetpastDisputes data page
How to test the functionality
  1. Identify an account in Smart Dispute for Issuer application for which the Issuer has already submit 34 Disputes within 120 days under 10.4 dispute category.
  2. Now set up the test data in system of records for 3 transactions with same Transaction ID and Multiple Clearing Sequence number (MCSN) Example :13452617282726101, 13452617282726102, 13452617282726103
  3. Verify the TransactionID should have 17 digits. The first 15 digits are Transaction ID, and last 2 digits are Multiple Clearing Sequence Number (MCSN)
  4. Create fraud disputes for the above 3 selected transactions.
  5. Validate the dispute validation A Transaction on an Account Number for which the Issuer has initiated more than 35 Disputes within the previous 120 calendar days is pass for the three transactions.

Visa - Associated Transaction Selection Operation API – Stale VROL ID sent in Service Request

Issue details

ApplicationSmart Dispute for Issuers
Scheme ImpactVisa
Scheme ReferenceNA
Dispute ReasonNA
Functional CategoryVisa API
Effective DateNA
Reported Issue
  • Visa is returning the Error E-900000004 for the AssociatedTranSelectionOperation service response due to stale/old VROL ID sent in service request.
  • In Associated Transaction flow after the AssociatedTranList service is invoked, the case waits at the View transaction and order details screen.
  • The AssociatedTranList service is invoked again when the 10 days SLA expires.
  • A new VROL ID is appended to the existing list and not clearing the existing old data.
  • Due to above reason the next service call AssociatedTranSelectionOperation is failing with above mentioned error.
Smart Dispute ImplementationIn the data transform SetInfoPostGetAssocTransService steps have been added from 5 to Step 8 to remove the properties on Association data.
  • ATRListWithMS100MP1
  • ATRListWithMS100MP2
  • ATRListForSelection
  • ATRListOfAuthTxns
How to test the functionality
  1. Create a Visa dispute case.
  2. Process Potential duplicates assignment (if any).
  3. Process the Qualify dispute screen by selecting a dispute reason and corresponding questionnaire.
  4. Verify if the service AssociatedTranList service is invoked and the case waits in the View transaction and order details screen.
  5. Wait till the SLA is expired on the assignment.
  6. Verify if the AssociatedTranList service is invoked again.
  7. Submit the assignment and observe that the AssociatedTranSelectionOperationservice is invoked.
  8. Validate that the service request should contain the latest VROL ID sent to Visa.

Visa - SubmitContactMessageResponseOperation API - Response mapping issue

Issue details

ApplicationSmart Dispute for Issuers
Scheme ImpactVisa
Scheme ReferenceNA
Dispute ReasonNA
Functional CategoryVisa API
Effective DateNA
Reported Issue
  • ContactMessageId and ContactMessageResponseId properties in AssociationData page is not mapped.
  • The Contact Message ID and Contact Message Response ID are not shown in audit tab because of the above mentioned reason.
Smart Dispute ImplementationUpdated the MapRESTResponse Data Transform to include a response mapping for the SubmitContactMessageResponseOperation API to populate pyTempResponsePage holding the ContactMessageId & ContactMessageResponseId.
How to test the functionality
  1. Create a Visa dispute.
  2. Process the applicable early resolution stages (if any).
  3. Process the Qualify Dispute screen.
  4. Process the Dispute Questionnaire by responding to the questions.
  5. Submit for dispute case.
  6. Submit Review Inbound Pre-Arbitration & Process Inbound Pre-Arbitration assignments.
  7. Submit Visa dispute for Pre-Arbitration so that the case lands to wait for contact message & Review Inbound Arbitration details.
  8. Submit Wait for contact message assignment.
  9. Now submit Respond to case filing contact message assignment where the API - SubmitContactMessageResponseOperation is invoked.
  10. ContactMessageId and ContactMessageResponseId properties should be visible in audits tab with appropriate value.

Visa - Duplicates-Questionnaire not in sync with IES23.2

Issue details

ApplicationSmart Dispute for Issuers
Scheme ImpactVisa
Scheme ReferenceNA
Dispute ReasonI was charged/credited incorrectly
Functional CategoryDispute Questionnaire - Processing Errors
Effective DateNA
Reported IssueBelow mentioned field should not be displayed for Processing Errors -> Duplicates
  • Dispute reason: I was charged/credited incorrectly.
  • Sub dispute reason: I was charged more than once.
  • Field: Is the other transaction for the same merchant and on a different Visa Card owned by the same Issuer/Cardholder?

This field is not valid for Duplicates and should not be displayed.

Smart Dispute ImplementationIn the section rule DorPQuestionnaire the visibility condition in layout 1.1, .WhatIncorrectAboutTransaction == ”D” has been removed.
How to test the functionality
  1. Create a Visa Dispute case.
  2. Process the applicable early resolution stages (if any).
  3. On the Qualify Dispute screen, select Dispute Reason as I was charged/credited incorrectly and Sub dispute reason as I was charged more than once.
  4. Select the Are both transactions for the same merchant and on the same card? field as No.
  5. Verify if the field Is the other transaction for the same merchant and on a different Visa Card owned by the same Issuer/Cardholder is not visible.

Visa - Accounting tab table alignment format mismatch

Issue details

ApplicationSmart Dispute for Issuers
Scheme ImpactVisa
Scheme ReferenceNA
Dispute ReasonNA
Functional CategoryUser Interface
Effective DateNA
Reported IssueAlignment and format issues are observed under the Accountingtab for the Adjustment details and Suspense details tables.
Smart Dispute ImplementationSection Rules changes:
  1. AccountingDetails - Class-PegaCard-Sd-Claim: Updated the layout for Adjustments and updated the Suspense details embedded section to refer the SuspenseDetails section rule.
  2. AdjustmentDetails - Class -PegaAcct-Step-: Updated presentation tab and added collapsible header.
  3. Adjustments - Class -PegaCard-Sd-Dispute: Updated the layout to repeating dynamic layout and called the embedded section to refer the AdjustmentDetails.
  4. SuspenseDetails - Class -PegaCard-Sd-Claim: Updated the layout to repeating dynamic layout and called the embedded section SuspenseTransactionDetails.
  5. SuspenseDetails - Class -PegaCard-Sd-Dispute: Updated the layout to repeating dynamic layout and called the embedded section SuspenseTransactionDetails.
  6. SuspenseTransactionDetails - Class- PegaAcct-Step-: Updated presentation tab and added collapsible header.

Field value changes:

pyCaption Documents – New field value added in PegaCardSd ruleset.
How to test the functionality
  1. Create a Visa Dispute case.
  2. Process the applicable early resolution stages (if any).
  3. On the Qualify Dispute screen, select any Dispute Reason and proceed on the screen.
  4. Continue dispute and land on the Pending Acquirer Response screen.
  5. Scroll to the Accounting tab under case overview and verify the Adjustments table.

Base issues addressed in this release

The following is a list of common issues across schemes that have been resolved in this release that are of most interest and likely to have the most impact on the Pega user and developer community.

Claim level Bulk processing – Accounting Issue - Last dispute case accounting data is copied to the other disputes in the Claim

Issue details

ApplicationSmart Dispute for Issuers
Scheme ImpactVisa, MCOM and Amex
Scheme ReferenceNA
Dispute ReasonNA
Functional CategoryClaim Level Bulk Processing
Effective DateNA
Reported Issue
  • In a DMT (dispute multiple transactions under one claim) scenario, when a provisional credit is provided, or partial write-off is performed on the last dispute in the list processing them individually.
  • At claim level, processing the Dispute questionnaire (for Visa)/Answer Ancillary questions (for MCOM)/Processing chargeback (for Amex).
  • The accounting data of the last dispute case is copied to the other disputes in the list those are under the same claim case.
Smart Dispute ImplementationAdded the CopyQuesAfterBulkDQAQAndPrcCB activity to copy the dispute data to individual disputes without overriding the dispute's accounting data for each dispute and called from the ProcessSelectedDispute activity
How to test the functionality
  1. Create a Visa/MasterCard/Amex Claim with multiple dispute cases.
  2. Complete the applicable early resolution stages (if any).
  3. Proceed till the Dispute questionnaire (for Visa)/Answer Ancillary questions (for MCOM)/Processing chargeback (for Amex).
  4. On the last dispute, either perform a partial write-off or provide provisional credit.
  5. Perform a claim level processing for all the disputes by completing the Dispute questionnaire (for Visa)/Answer Ancillary questions (for MCOM)/Processing chargeback (for Amex) assignment from the local actions.
  6. Verify if the accounting information of last dispute is not copied to the other disputes of the claim.
  • Previous topic Pega Smart Dispute for Acquirers patch release notes 8.7.3
  • Next topic Pega Smart Dispute for Acquirers patch release notes 8.7.5

Have a question? Get answers now.

Visit the Support Center to ask questions, engage in discussions, share ideas, and help others.

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best.

Pega.com is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us