Skip to main content


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

Pega Smart Dispute for Issuers 8.7.3

Updated on May 17, 2024

Pega Smart Dispute for Issuer 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

23.2 Compliance

This package contains 23.2 Compliance changes for Smart Dispute for Issuers and Smart Dispute for Acquirers applications. Detailed documentation about 23.2 Compliance and changes overview are available in My Pega Spaces (my.pega.com)Association Compliance SPACE.

Resolved issues in Pega Smart Dispute for Issuers 8.7.3

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

INC-A17594

INC-A17699

MCOM – AN 7046 – Pre-Compliance violation types
INC-A9063MCOM – Optimized property not identified as optimized in RD
US-574438MCOM – AN 7207 Revised Standards for Fraud Notification Service
BUG-832987MCOM – Incorrect results for number of chargebacks submitted on the account number
INC-A18007MCOM - Document attachment issue after CreateCB() failure
BUG-837666MCOM – Fraud – Edit 1 and Edit 2 messages are not updating with valid FNS
INC-A8665MCOM - Smart Dispute re triggering the API in infinite loop even after success
BUG-831047MCOM - Incorrect mapping of Violation code in footer
INC-A16347MCOM - FilingagainstICA not populating at Pre-Compliance
INC-A8310MCOM - Error in CreateCB() due to dispute amount not updated with posted amount
INC-A13641Visa – Reverse PC flag gets updated when PC is given for Reg E claims in bulk
INC-A20318

INC-A21008

Visa – Wait period not working for the dispute reason cancelled the merchandise/service (CS)
INC-A13937Visa - Case not moving to SLA breach path upon deadline expiry
INC-A14447Visa – Case resolution fixes for partial acceptance scenarios
INC-A13814Visa – Dispute amount fixes for 'I was charged the wrong amount' dispute reason
INC-A16966Visa - Arbitration SLA for Issuer is not set to 10 days
INC-A5699Visa - Reverse Provisional Credit Accounting is not happening
INC-A9362Chargeback amount & total recovered amt incorrect
INC- A13984Suspense details grid in the accounting tab is not consistent
INC-A12819Manual cases - Dispute create date time is updated
INC-A13356Dispute validation tab under claim summary is missing
INC-A13715Smart Dispute reports are not working as expected
BUG-831616MCOM DMT fraud questionnaire is not displayed under Qualification details tab
INC-A5402Audit tab fixes

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 – AN 7046 – Pre-Compliance violation types

ApplicationSmart Dispute for Issuers and Acquirers
Scheme ImpactMCOM
Scheme ReferenceAN7046_RevisedStandards
Dispute ReasonNA
Functional CategoryPre-Compliance
Effective DateNA
Reported IssueAs an Acquirer, when I initiate Pre-Compliance with violation type Send OI, the case is routing to Process Liability screen even if the Pre-Compliance timelines exist. Also, Send OI violation type is only applicable for Acquirers.

As an Acquirer, I should not have Send RI/Payment violation type in the Pre-Compliance violation type dropdown.

Smart Dispute Implementation
  1. Updated when rule WhenOtherViolationSource to include check for Send OI so that the case does not route to the Process Liability screen when Pre-Compliance is initiated with Send OI violation type.
  2. Updated data transform LoadPreComplianceViolationType so that Send OI violation type is not visible for Issuers.
  3. Updated data transform LoadPreComplianceViolationType on the Acquirer side so that the TypeOfVoilation drop down does not show Send RI/Payment for Acquirer.
How to test the functionalityIssuer:
  1. Create a MCOM dispute in Smart Dispute for Issuers application.
  2. Process Qualify dispute and proceed till the Answer Ancillary questionnaire screen.
  3. Select Initiate Pre-compliance from Other Actions and observe that Send OI violation type is not available in the violation type dropdown.

Acquirer:

  1. Create a Pre-Compliance case
  2. In the Pre-Compliance questionnaire, select Send OI as violation type and observe that Pre-Compliance is submitted successfully without the case getting routed to the Process liability screen. Also observe that Send RI/Payment is not visible in the violation types drop down.

MCOM – Optimized property not identified as optimized in RD

ApplicationSmart Dispute for Issuers
Scheme ImpactMCOM
Scheme ReferenceNA
Dispute ReasonNA
Functional CategoryGeneral
Effective DateNA
Reported IssueAs a developer, when I try to execute the report definition GetMCOMFraudReportId, an error is displayed.
Smart Dispute Implementation

Added the fraudid property in the external mapping tab for the following two classes:

  • PegaCard-Sd-Debit-MC-International
  • PegaCard-Sd-Dispute-MC-International-Wk
How to test the functionalityAs a developer, execute the report definition GetMCOMFraudReportId and observe that the results are displayed without any error.

MCOM – AN 7207 Revised Standards for Fraud Notification Service

ApplicationSmart Dispute for Issuers
Scheme ImpactMCOM
Scheme ReferenceAN 7207 Article from MasterCard
Dispute Reason4837,4840,4863,4870,4871
Functional CategoryFraud Disputes Standards
Reported IssueChanges implemented as per the Master card article AN 7207 revised standards for the fraud notification service counter (FNS)
Smart Dispute ImplementationIn this user story, the fraud submission logic is changed as per article AN 7207. From 7 November 2023, MasterCard will increase the current FNS counter from 15 to 35 fraud chargebacks per Account Number. Transactions authorized on or before 6 November 2023, are ineligible for fraud chargebacks when the FNS counter is between 16 and 35.
  1. In Smart Dispute Application, two dispute validations are created for transaction where the authorization date is on or before Nov 6, 2023 and transaction where the authorization date is on or after Nov 7, 2023.
  2. The data transform PegaCard-Sd-Dispute-SetFailToFNSCounter changes the outcome of the disputevalidations where when conditions are “FNSCounterCheck_DV”, “FNSCounterGT15” to fail for stale disputes checking the latest value of FNS counter from database. Added logic to check Authorization Date after cutoff or before cutoff and change the output for the respective dispute validation.
  3. In the PegaCard-Sd-Dispute CheckFraudFNSCounter existing when condition, logic is added/changed to check authdate and FNS counter for the dispute validations related to FNS counter.
In the PegaCard-Sd-Dispute-MC-IsFraudAuthDateAfterCutoff when condition, check if authorization date is after the cut off date.
How to test the functionality
  1. Create a Master Card fraud case
  2. Proceed till the Answer ancillary questions screen and submit chargeback
  3. The outcome of the dispute validation applicable when authorization date is before Nov 6, 2023, will be determined depending on the below criteria.
    • 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 less than 15, dispute validation outcome will be "Pass”.

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

  • The outcome of the dispute validation applicable when authorization date is after Nov 6, 2023, will be determined depending on the below criteria:
    • 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”.
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 – Incorrect results for number of chargebacks submitted on the account number

ApplicationSmart Dispute for Issuers
Scheme ImpactMCOM
Scheme ReferenceNA
Dispute ReasonNA
Functional CategoryData Integrity Monitoring Program
Reported IssueIn the existing Report definition GetMasterCardExcessiveCBS_GetCBCount, the sample account number is hardcoded in the filter condition.
Smart Dispute Implementation
  1. In the Report definition PegaCard-Sd-Dispute-MC- GetMasterCardExcessiveCBS_GetCBCount the filter condition of account number is changed to Param.AccountNumber.
  2. In the section PegaCard-Sd-Dispute-MC-ReasonCodeListForMCom in the dynamic layout the visibility condition is changed from expression to when condition DataIntegrityEdit1Check.
How to test the functionalityScenario 1:
  1. Create a MCOM dispute and proceed till the Answer Ancillary Questionnaire screen.
  2. If 20 chargebacks are submitted each in the current month and in the previous month, then observe that Edit 1 information message is displayed.
Scenario 2:
  1. Create a MCOM non-fraud dispute and proceed till the Answer Ancillary Questionnaire screen.
  2. If 15 fraud chargebacks and 5 non-fraud chargebacks are already submitted on the account number in the month, then observe that Edit 2 information message is displayed.

MCOM – Document attachment issue after CreateCB() failure

ApplicationSmart Dispute for Issuers
Scheme ImpactMCOM
Scheme ReferenceNA
Dispute ReasonNA
Functional CategoryMCOM API
Reported IssueMCOM CreateCB API failed because of the document status unavailable. Instead of landing on the Awaiting document assignment, the case landed on the MCOM service retry assignment. Hence, the CreateCB is triggered continuously, and no option is provided for the user to attach the document and call UpdateCB API.
Smart Dispute Implementation
  1. Added “unavailable” document status in the when condition CheckDocumentRejectedbyMCOM to handle the CreateCB failure scenario.
  2. Added “unavailable” document status in the when condition IsMCOMDocumentStatusFailed to handle the Pending doc queue scenario.
How to test the functionality
  1. Create an MCOM dispute case.
  2. Submit answer ancillary questions screen to submit the chargeback.
  3. Make the CreateCB service fail because of the document status as Unavailable which comes from GetClaim service.
  4. Observe that case lands Awaiting document assignment.
  5. Attach the document and submit.
  6. Verify that the UpdateCB service is invoked.

MCOM – Fraud – Edit 1 and Edit 2 messages are not updating with valid FNS

ApplicationSmart Dispute for Issuers
Scheme ImpactMCOM
Scheme ReferenceAN 8068
Dispute ReasonNA
Functional CategoryData Integrity Monitoring Program
Reported IssueWhile verifying the MCOM edit 1 and edit 2 messages for fraud claims, the FNS values are not updating with exact values in the message description even after submitting the chargeback post 7th November. Still the values before 7th November are being displayed.
Smart Dispute ImplementationUpdated the Section ReasonCodeListForMCom to update the visibility conditions of Edit1 and Edit2 message labels.
How to test the functionalityScenario 1: Edit 1 message
  1. Create a Mastercard dispute case.
  2. Check if already 40 or more chargebacks are submitted in previous month and 40 or more chargebacks are submitted in Current month.
  3. Verify the Edit 1 message displayed in Answer ancillary screen for the 41st dispute.

Scenario 2: Edit 2 message

  1. Create a Mastercard dispute case.
  2. Check if already 35 fraud chargebacks are submitted in current month.
  3. Also submit 5 Non fraud chargeback after fraud chargebacks are submitted.
  4. Verify the Edit 2 message in Answer ancillary screen for the 6 sixth Non fraud dispute.

MCOM – Smart Dispute re-triggering the API in infinite loop even after success

ApplicationSmart Dispute for Issuers
Scheme ImpactMCOM
Scheme ReferenceNA
Dispute ReasonNA
Effective DateNA
Functional CategoryNA
Reported IssueMCOM CreateCB API failed due to an outage and dispute in Smart Dispute for Issuers application landed onto retry service exception flow. Post the outage, the service is retried, and successful response is retrieved from MCOM, but the dispute is still in the retry error flow and continuing to retry the API.
Smart Dispute Implementation
  1. HealthCheck API call step has been added to both CreateCB and CreateFiling connectors in HandleServiceSpecificErrors flow.
  2. From the connection problem flow, the subsequent call to GetClaim will happen only when the HealthCheck is successful to ensure the services are up and running.
How to test the functionality
  1. Create a MCOM dispute case.
  2. Submit Answer ancillary questions screen to submit the chargeback.
  3. Make the CreateCB and healthcheck service fail with outage.
  4. Observe that case lands on retry service error assignment and in the audit HealthCheck API is called after createCB failure and Getclaim is not invoked.
  5. Remove the outage failure and case resumes with GetClaim API call and CreateCB API call.
  6. Verify the dispute case lands on Awaiting Acquirer response screen.

MCOM – Incorrect mapping of Violation code in footer

ApplicationSmart Dispute for Issuers
Scheme ImpactMCOM
Scheme ReferenceAN7046_RevisedStandards
Dispute ReasonNA
Effective DateNA
Functional CategoryPre-Compliance
Reported IssueAs an Issuer, when I submit Pre-Compliance with Violation type as ‘ATM Dynamic Currency Conversion’, the value of the Type of violation field is incorrectly displayed as “Interchange Discrepancy” under the read only footer section MasterCom footer.
Smart Dispute ImplementationUpdated property PreCompTypeOfViolationSource with correct field value, so that the value for the field “Type of violation” is displayed as “ATM Dynamic Currency Conversion” in the read only sections in the Smart Dispute for Issuers application.
How to test the functionality
  1. Create a MCOM dispute case from Smart Dispute Issuers application.
  2. Submit Qualify dispute screen.
  3. Initiate Pre-Compliance.
  4. Select “ATM Dynamic Currency Conversion” Violation type and submit the Pre-Compliance Screen.
  5. Verify if the value of the “Type of violation” field is displayed as “ATM Dynamic Currency Conversion” in the read-only section in the MasterCom tab.

MCOM – FilingagainstICA not populating at Pre-Compliance

ApplicationSmart Dispute for Issuers
Scheme ImpactMCOM
Scheme ReferenceNA
Dispute ReasonNA
Effective DateNA
Functional CategoryPre-Compliance
Reported IssueFilingagainstICA not populating at Pre-Compliance screen when the dispute is closed and reopened at Answer ancillary questions assignment.
Smart Dispute ImplementationUpdated step 23 to step 19 in MCOMPreInitiatePreCompOrSAFEFraudReport Activity.
How to test the functionality
  1. Create MCOM Fraud/Non-Fraud dispute case.
  2. Proceed till Answer ancillary questions assignment.
  3. Click on Other Actions and click Initiate Pre-Compliance.
  4. Observe FilingagainstICA value populating on Pre-Compliance screen.
  5. Close the dispute and reopen it.
  6. Click on Other Actions and click Initiate Pre-Compliance again.
  7. FilingagainstICA value should be populating on Pre-Compliance screen.

MCOM – Error in CreateCB() due to dispute amount not updated with posted amount

ApplicationSmart Dispute for Issuers
Scheme ImpactMCOM
Scheme ReferenceNA
Dispute ReasonNA
Effective DateNA
Functional CategoryChargeback submission
Reported IssueAs an Issuer, when I attempt to submit a dispute on Pending authorization to Posted transaction, the dispute amount holds the authorized amount due to which CreateCB service call fails with validation message saying “createCB1Amount is higher than the allowed amount.
Smart Dispute ImplementationUpdated the FindAuthTransactionMatch activity to set the dispute amount to posted amount once transaction is posted.
How to test the functionality
  1. Create a dispute for a pending transaction.
  2. Process the Answer ancillary questions stage after the matching posted transaction is found.
  3. Submit the chargeback.
  4. The CreateCB service call parameter page should hold the posted amount.

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 – Reverse PC flag gets updated when PC is given for Reg E claims in bulk

ApplicationSmart Dispute for Issuers
Scheme ImpactVisa
Scheme ReferenceNA
Dispute ReasonNA
Effective DateNA
Functional CategoryProvisional credit
Reported IssueAs an Issuer, when I attempt to create a Reg E eligible claim with multiple disputes, provide provisional credit and perform write-off by selecting process dispute validations from bulk action, then the reverse PC flag is getting updated in claim summary tab.
Smart Dispute Implementation
  1. Created a data transform rule SetReversePCDateWrapper to call SetReversePCDate only if the cardholder is liable.
  2. Updated dispute validation option’s action set to call SetReversePCDateWrapper in ProcessDispValidationsForVCR section.
How to test the functionality
  1. Create a Visa claim case by disputing multiple transactions those are eligible Reg E.
  2. Submit Qualify dispute screen.
  3. Provisional Credit should be given to Cardholder after attestation.
  4. Submit the dispute questionnaire screen.
  5. Bulk process the Process dispute validation and perform write-off.
  6. Validate if the Reverse PC flag is not updated in claim summary tab.

Visa – Wait period not working for the dispute reason cancelled the merchandise/service (CS)

ApplicationSmart Dispute for Issuers and Acquirers
Scheme ImpactVisa
Scheme ReferenceNA
Dispute ReasonI cancelled the merchandise/service (CS)
Effective DateNA
Functional CategoryWait period
Reported Issue

As an Issuer, when I am submitting a Visa dispute with the Dispute reason I cancelled the merchandise/service, cases are not moving to 15 days wait period for merchandise.

Scenario 1: Customer cancelled the merchandise and returned. Disputes are not waiting for 15 days after submitting the Qualify Dispute screen.

Scenario 2: Customer has returned the merchandise. Disputes are not waiting for 15 days after submitting Qualify Dispute screen.

Scenario 3: Customer has cancelled the merchandise. Disputes are not waiting for 15 Days after Qualify Dispute screen.
Smart Dispute ImplementationIn the data transform rule “SetTimeLinesFor15DaysWaitPeriod:
  1. In Step 6.1.2, added wait period of 15 days when merchandise is cancelled and returned.
  2. In Step 6.1.3, added wait period of 15 days when merchandise is returned.
  3. In step 6.1.4, added wait period of 15 days when merchandise is cancelled.
How to test the functionalityScenario 1:
  1. Create a Visa dispute case.
  2. Perform Qualify dispute screen by selecting the dispute reason as “I cancelled the Merchandise/Services".
  3. Select “Did the cardholder cancel “-Yes and enter Cancellation date.
  4. Select “Did the cardholder return the merchandise”-Yes and enter the return date.
  5. Submit the Qualify Dispute screen.
  6. Observe that the dispute should wait for 15 days from the recent date compared between the two given dates.
Scenario 2:
  1. Create a Visa dispute case.
  2. Perform Qualify dispute screen by selecting the dispute reason as “I cancelled the Merchandise/Services".
  3. Select “Did the cardholder cancel “-No.
  4. Select “Did the cardholder return the merchandise”. -Yes and enter return date.
  5. Submit the Qualify Dispute screen.
  6. Observe the dispute should wait for 15 days from the given returned date.
Scenario 3:
  1. Create a Visa dispute case.
  2. Perform Qualify dispute screen by selecting the dispute reason as “I cancelled the Merchandise/Services".
  3. Select “Did the cardholder cancel “-Yes and enter Cancellation date.
  4. Select “Did the cardholder return the merchandise”. -No
  5. Submit the Qualify Dispute screen.
  6. Observe the dispute should wait for 15 days from the given cancellation date.

Visa – Case not moving to SLA breach path upon deadline expiry

ApplicationSmart Dispute for Acquirers
Scheme ImpactVisa
Scheme ReferenceNA
Dispute ReasonNA
Effective DateNA
Functional CategoryGeneral
Reported IssueScenario 1: In VISA collaboration flow, when Issuer initiates a dispute and Acquirer declines it, case is at 'Awaiting Issuer Response' stage. If no response is received from the Issuer and deadline expires, the dispute case proceeds to Initiate Arbitration instead of resolving the case as Issuer-liable.

Scenario 2: In VISA collaboration flow, when Issuer initiates Pre-Arbitration and Acquirer partially accepts the Pre-arbitration, the case moves to 'Awaiting Issuer Response' where issuer can initiate Arbitration. Upon deadline expiry, if no response is received from the Issuer, the case proceeds to Initiate Arbitration instead of resolving the case as Issuer-liable.

Scenario 3: In VISA allocation flow, when the Issuer initiates a dispute and Acquirer submits Pre-Arbitration in response, the case is in 'Awaiting Issuer Response for Pre-Arbitration'. The dispute case proceeds to Initiate Arbitration instead of resolving the case as Issuer-liable.

Scenario 4: In VISA collaboration flow, when issuer initiates the Pre-Compliance and Acquirer declines it , the case moves to Awaiting Issuer response. The case proceeds to Initiate Compliance instead of resolving the case as Issuer-liable.
Smart Dispute Implementation
  1. Created properties which acts as a flag upon deadline expiry-AwaitingDisputeResponseFromIssuerSLAFlag,AwaitingPreCompIssuerResponseSLAFlag and PreArbitrationIssuerResponseSlaFlag.
  2. Created data transform rule which checks if the properties are true- SetSlaFlagForAwaitingIssuerResponse,SetSLAFlagForPreArb, SetSLAFlagForPreComp.
  3. Updated the SLA deadline escalation to call the data transform- AwaitingDisputeResponseFromIssuerSLA,PreArbitrationIssuerResponseSLA,PreCompIssuerRespSLA,AwaitingissuerPreArbResponseSLA.
  4. Updated when rules to check if the deadline has expired- IsDispIssuerResSLAExpired,IsIssuerPrearbResSlaExpired, IsIssuerPreCompResSlaExpired.
How to test the functionalityScenario 1:
  1. Create a VISA collaboration case from the Issuer application.
  2. Process the dispute screen by declining the Acquirer response and submit from the Acquirer application.
  3. The case is at Awaiting Issuer response. Upon 30 days, if no response is received and the deadline expires, the case should be resolved as Issuer liable.
Scenario 2:
  1. Initiate a Pre-Arbitration for VISA collaboration case from the Issuer application.
  2. Process the dispute screen by partially accepting the Acquirer response and submit from the Acquirer application.
  3. The case will be at Awaiting Issuer response. Upon 30 days, if no response is received and the deadline expires, the case should be resolved as Issuer liable.
Scenario 3:
  1. Create a VISA allocation case from the Issuer application.
  2. Process the dispute response by initiating Pre-Arbitration.
  3. The case is at awaiting issuer response. Upon 30 days, if no response is received and the deadline expires, the case should be resolved as Issuer liable.
Scenario 4:
  1. Create a VISA allocation case from the Issuer application.
  2. Process the dispute screen by choosing Accept and Initiate Pre-Compliance and submit the Acquirer application.
  3. Process the Initiate Compliance
  4. The case is at Awaiting Issuer response. Upon 30 days, if no response is received and the deadline expires, the case should be resolved as Issuer liable.

Visa – Case resolution fixes for partial acceptance scenarios

ApplicationSmart Dispute for Issuers and Acquirers
Scheme ImpactVisa
Scheme ReferenceNA
Dispute ReasonNA
Effective DateNA
Functional CategoryProcess liability
Reported IssueWhen Issuer partially accepts the Inbound Pre-arbitration, two assignments are created - 'Process Issuer Liability' & 'Awaiting Acquirer Pre-arb'. When SLA expires on 'Awaiting Acquirer Pre-arb', the dispute is resolved as Acquirer liable while the 'Process Issuer Liability’ assignment is Open which is incorrect.
Smart Dispute ImplementationSetStatusForProcessLiability data transform is created & UpdatePreArbStatus activity and PreArbResponseAcctng flow rules are updated to resolve the dispute after processing all the open assignments.
How to test the functionality
  1. Create a fraud dispute for the Visa transaction.
  2. Complete the pre-dispute stages and raise a dispute to Visa.
  3. As part of dispute response initiate a Pre-Arbitration from Acquirer application.
  4. As part of the dispute Select ‘Accept partially’ in the Inbound pre-arbitration screen from Issuer application.
  5. Verify the case status is "Pending-Closure" when SLA expires on 'Awaiting Acquirer Pre-arb' assignment.
  6. Verify the case status is "Resolved-AcquirerLiable" after completing 'Process Issuer Liability' assignment.

Visa – Dispute amount fixes for 'I was charged the wrong amount' dispute reason

ApplicationSmart Dispute for Issuers
Scheme ImpactVisa
Scheme ReferenceNA
Dispute ReasonI was charged the wrong amount
Effective DateNA
Functional CategoryDispute submission
Reported IssueDispute amount is incorrectly calculated for cross currency transactions when disputed with the reason 'I was charged the wrong amount'.
Smart Dispute ImplementationThe data transform rule PegaCard-Sd-Dispute-Visa-.SetReceiptAmount is modified to update at step 2.1 for proper evaluation of Dispute amount.
How to test the functionality
  1. Create dispute for the Visa cross currency transaction.
  2. Process Qualify dispute screen with reason ‘I was charged the wrong amount’.
  3. Enter amount on the cardholder's receipt & confirm the currency on the receipt as transaction currency.
  4. Verify the Dispute amount is calculated correctly.

Visa – Arbitration SLA for Issuer is not set to 10 days

ApplicationSmart Dispute for Acquirers
Scheme ImpactVisa
Scheme ReferenceNA
Dispute ReasonNA
Effective DateNA
Functional CategoryArbitration
Reported Issue

As an Issuer, when I raise a Pre-Arbitration and Acquirer declines the Pre-Arbitration, the case moves to 'Awaiting Issuer Response' where Issuer can initiate Arbitration. The timeframe here for Issuer to initiate Arbitration after Acquirer declines Pre-Arbitration is set as 30 days.

As per VISA, the timeframe here for Issuer to initiate Arbitration after Acquirer declines Pre-Arbitration is 10 days.
Smart Dispute Implementation
  1. Updated SLA goal and deadline to 10 days and added offset days to goal and deadline from DSS in SetPreArbIssuerResSLA Data transform.
  2. Updated SLA property in section AwaitProcessPrearbResponse.
How to test the functionality
  1. Create a VISA collaboration case from the Issuer application.
  2. Process the dispute screen by declining the Acquirer response and submit from the Acquirer application.
  3. Initiate the Pre-Arbitration from the Issuer application.
  4. Process Inbound Pre-Arbitration in Acquirers application.
  5. Case moves to ‘Awaiting Issuer Response'. Verify that the SLA deadline should be 10days+ offset days from DSS.

Visa – Reverse Provisional Credit Accounting is not happening

ApplicationSmart Dispute for Issuers
Scheme ImpactVisa
Scheme ReferenceNA
Dispute ReasonNA
Effective DateNA
Functional CategoryAccounting
Reported IssueAs an Issuer, when I attempt to submit a Reg E eligible debit dispute case for partial write-off /cardholder liable through process liability and later if user is resolving the case by responding Yes to the question ‘Do the order details help to resolve the dispute?’ then accounting is failing for Reverse Provisional Credit.
Smart Dispute ImplementationUpdated step 1 to set .DisputeAmount to .VCRDQMPCHAmt in PurchaseInquiryAccounting Activity.
How to test the functionality
  1. Create Visa debit dispute case by selecting a transaction that is eligible for Reg E.
  2. Submit Qualify dispute screen.
  3. Provisional Credit is given to Cardholder after attestation.
  4. Dispute case navigates to Review order insight details, choose process liability from Other Actions.
  5. Proceed with partial write-off/cardholder liable option.
  6. Resolve the case by answering Yes to the question ‘Do the order details help to resolve the dispute?’.
  7. As cardholder is liable for remaining amount, PC should be reversed i.e liable amount should be debited from cardholder.

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.

Chargeback amount & total recovered amt incorrect

ApplicationSmart Dispute for Issuers
Scheme ImpactVisa and MCOM
Scheme ReferenceNA
Dispute ReasonNA
Effective DateNA
Functional CategoryGeneral
Reported IssueAs an Issuer, when I create a claim with multiple disputes having partial merchant credits in one of the disputes, then the Total chargeback amount and the Total recovered amount are being calculated incorrectly (considering posted amount instead chargeback amount) that is displayed in risk summary tab of claim case.
Smart Dispute ImplementationUpdated step 8.1 to set. chargeback amount if. chargebackprocessed is “Y” to. VCRDQMPCHAmt in GetDisputeCaseDetailsList Activity.
How to test the functionality
  1. Create a Visa claim case by disputing multiple transactions with at least one transaction having a merchant credit.
  2. Submit Qualify dispute screen.
  3. Select a transaction in associated transactions screen and perform partial merchant credit.
  4. Process till Dispute validation.
  5. Select Continue dispute option and submit.
  6. Navigate to Risk summary tab and verify Total chargeback amount and Total recovered amount.

Suspense details grid in the accounting tab is not consistent

ApplicationSmart Dispute for Issuers
Scheme ImpactVisa and MCOM
Scheme ReferenceNA
Dispute ReasonNA
Effective DateNA
Functional CategoryGeneral
Reported IssueAs an Issuer, when I try to submit a dispute case and provide provisional credit and check for the credit entry in the accounting tab at the dispute level, the grid elongates abnormally.
Smart Dispute ImplementationIn SuspenseDetails section, updated the table’s style to “transparent”, container to “default” and width of content to “Fill (100%)”.
How to test the functionality
  1. Create a dispute case.
  2. Process the Qualify dispute screen.
  3. Process provisional credit to the dispute.
  4. Click on accounting tab.
  5. Click on suspense details table. Verify that the table should not elongate beyond the row contents.

Manual cases - Dispute create date time is updated (INC-A12819)

ApplicationSmart Dispute for Issuers
Scheme ImpactVisa and MCOM
Scheme ReferenceNA
Dispute ReasonNA
Effective DateNA
Functional CategoryManual case – Regulation E
Reported IssueDisputes create date time is updated in REG E Manual cases because of the pyDefault Data transform which gets triggered from the activity ValidateAndProceedWithManualCase and AttachTransaction.
Smart Dispute Implementation

Updated below Activities –

  • ValidateAndProceedWithManualCase (Class:PegaCard-Sd-Dispute-),
  • ValidateAndProceedWithManualCase (Class:PegaCard-Interface-Transaction-ACH),
  • AttachTransaction (Class:PegaCard-Interface-Transaction-ACH )
The activities are updated to store pyWorkPage.pxCreateDateTime before calling the pyDefault data transform and copying that same parameter value back to pyWorkPAge.pxCreateDateTime property after calling pyDefault DT.
How to test the functionality

Scenario 1:

  1. Create a Manual Case from Smart Dispute for Issuers Application.
  2. Enter the transaction details and Select Type of Transaction as ACH and proceed with Manual Case Creation.
  3. Provide mandatory additional details.
  4. Now before attaching the transaction check the pxCreateDateTime.
  5. In the Update Transaction Details assignment, attach the correct transaction details.
  6. Now verify that the pxCreateDateTime is not updated after Attach Transaction is done.

Scenario 2:

  1. Create Manual Case from Smart Dispute for Issuers Application.
  2. Enter the transaction details and proceed with Manual case creation.
  3. Provide mandatory additional Details.
  4. When we land on the Update Transaction Details assignment, check the pxCreateDateTime.
  5. From local actions, click Validate and proceed with Manual Case Creation. Now verify that the pxCreateDateTime is not updated after we submit “Validate and Proceed with Manual Case Creation”.

Scenario 3:

  1. Create Manual Case from Smart Dispute for Issuers Application.
  2. Enter the transaction details and Select Type of Transaction as ACH and proceed with Manual Case Creation.
  3. Provide mandatory additional details.
  4. When we land on the Update Transaction Details Assignment, check the pxCreateDateTime.
  5. From local actions, click Validate and proceed with Manual Case Creation. Now verify that the pxCreateDateTime is not updated after we submit “Validate and Proceed with Manual Case Creation”.

Dispute validation tab under claim summary is missing

ApplicationSmart Dispute for Issuers
Scheme ImpactVisa and MCOM
Scheme ReferenceNA
Dispute ReasonNA
Effective DateNA
Functional CategoryGeneral
Reported IssueThe Dispute Validations tab under the Claim Summary is missing in case of a claim having multiple Reg E transactions for Resolved-WriteOff, Resolved-CardholderLiable claims.
Smart Dispute ImplementationCommented Step 9 -Page-Remove in the activity rule: RemoveRegEAssignmentSOnClaimClose.
How to test the functionality
  1. Create a claim case with more than one REG E eligible transactions.
  2. Process the disputes till Dispute validation screen.
  3. At the claim level notice that we have dispute validations tab, and it is also present under Claim summary.
  4. Select all the disputes and perform Claim level action “Process Dispute Validations”.
  5. Resolve the disputes as write-off.
  6. Verify the claim level “Dispute Validations” tab is displayed and is also available under Claim Summary.

Smart Dispute reports are not working as expected

ApplicationSmart Dispute for Issuers
Scheme ImpactVisa and MCOM
Scheme ReferenceNA
Dispute ReasonNA
Effective DateNA
Functional CategoryReports
Reported IssueAs an Issuer, when I attempt to run the MCom Disputes List With Status, Display report for disputes by dispute stage reports, an error is displayed on the screen.
Smart Dispute Implementation
  • Shortcut rule: McomDisputesListWithStatus- Updated and applies to class PegaCard-Sd-Dispute-MC-International-Wki.
  • Report Definition: VCRDisputesByStage- Updated to Select "Include Implementation class only" under "Report on descendant class instances" under Data Access tab.
How to test the functionality
  1. Launch the Disputes manager portal in the Smart Disputes Issuer application.
  2. Click Reports on the left panel.
  3. Select MCom Reports->” Mcom Disputes List With Status”.
  4. Verify the report runs successfully with correct data.
  5. Select VCR Reports->” Display report for disputes by dispute stage”.
  6. Verify the report runs successfully with correct data.

Fraud questionnaire is not displayed under Qualification details tab

ApplicationSmart Dispute for Issuers and Acquirers
Scheme ImpactVisa, MCOM, and Amex
Scheme ReferenceNA
Dispute ReasonNA
Effective DateNA
Functional CategoryGeneral
Reported IssueMCOM fraud questionnaire is not displayed under Qualification details tab.
Smart Dispute ImplementationAdded IsResolvedNoAction in visibility condition for non-cross network transactions.
How to test the functionality
  1. Create Visa/MCOM fraud dispute claim with multiple transactions.
  2. Proceed till Qualify fraud dispute assignment.
  3. Answer the questionnaire, choose the option as “No” for the questions “Do you want to continue as fraud?” and "Do you want to continue to Dispute?” and submit.
  4. The claim case gets resolved with status as “Resolved-NoAction”. Verify if the fraud questionnaire is not displayed under Qualification details tab.

Audit - History tab fixes

ApplicationSmart Dispute for Issuers and Acquirers
Scheme ImpactVisa and MCOM
Scheme ReferenceNA
Dispute ReasonNA
Effective DateNA
Functional CategoryAudit History
Reported IssueAs an Issuer or an Acquirer, when I click on Attach new hyperlink in the Attachments section and try to attach long URLs to the case at any stage, the URLs are not handled gracefully and overflows the table borders.
Smart Dispute ImplementationIn SDCaseHistory section rule, changed the container to default. In a cell configuration of message column, changed control to "text" and in presentation tab checked "Break the long word".
How to test the functionality
  1. Create Visa/MCOM dispute case.
  2. Proceed till Qualify dispute screen.
  3. In the Attachments section, click on “Attach new” hyperlink and choose URL.
  4. In subject field, give any text and in the URL field, give a long URL and submit.
  5. Verify the URL should not overflow the table in the History tab.

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