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

Updated on February 29, 2024

This section provides release notes for the Pega Smart Dispute for Issuers 8.7.1 patch release. 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 Issuers product page. This patch release includes Compliance updates released post Smart Dispute for Issuers and Acquirers 8.7 general available release, fixes for the Incidents received (INCs), and application bugs listed below.

22.2 Compliance and 23.1 Compliance release documentation is available in My Pega Spaces (my.pega.com)Association Compliance SPACE.

Pega Smart Dispute for Acquirers Release Notes

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.

Note: The patch release notes include all issues resolved across patch releases. For each issue, a reference number is provided, and the prefix of the reference number indicates the issue type. You can use the reference number of an issue in your related conversations with Pega Support.

The release notes include the following issue types:

INCs
Customer-reported incidents. For example, INC-267185.
BUG
Refers to entries logged in the Pega issue-tracking system.

Resolved issues in Pega Smart Dispute for Issuers and Acquirers 8.7.1

Ticket # or ID#Title and Description
INC-267185MCOM – Creation of Collaboration cases
INC-270948MCOM – Collaboration layer updates for Acquirer response code ‘Initiating Refund (C)’
BUG-766254MCOM – Process Liability options at Initiate Compliance screen
BUG-791274MCOM – Pre-Compliance Supporting Documents
INC-266059MCOM – Pre-Compliance questionnaire for violation type ‘Same Day Processing of Chargeback Reversal and Second Presentment’
INC-270182MCOM – Pre-Arbitration fixes
INC-266649MCOM – Disable fraud types 55 and 56
INC-259103MCOM – Timeframes for Credit Not Processed
INC-261723Visa – INCOMING_BQ_ACCEPTANCES_RECEIVED queue processing for disputes resolved through Rapid Dispute Resolution (RDR)
INC-269605Visa – Transaction inquiry fixes
INC-268037Visa – Pre-Arbitration fixes for Remedy – Prior Undisputed Non-Fraud transactions
INC-260715Visa – Pre-Compliance fixes
INC-269208Visa – Update to Pre-Compliance Response instructions
INC-270216Visa – Cancelled Recurring Transaction questionnaire
INC-269717Visa – Other Fraud – Card Absent Environment (10.4) dispute validation for fully authenticated U.S. domestic token transactions
INC-261191Visa – Slowness in opening cases with huge attachments
BUG-797644AMEX – Pre-Compliance response fixes
INC-268885Ethoca – Transaction amount and currency mapping
INC-267269On-Us eligibility for Fraud disputes
INC-265368Currency code mapping for EUR
INC-227919MCOM – Audit history
INC-228042/INC-228555/INC-233580/INC-234749MCOM – Exception handling for Gateway Exceptions/MCOM Outages
INC-227091/INC-226641/INC-223314/INC-223578MCOM - Cases moving to Process Liability
INC-220566/BUG-713358MCOM - EBDR Form Fixes
INC-213047MCOM - Label change on pre-arbitration
INC-218558 MCOM - Exception Handling Changes
INC-221188MCOM - Provisional Credit Reversal Changes
INC-210780MCOM - Validation on attachment sent to Mastercard
INC-218921MCOM - Documents not getting deleted
INC-224611MCOM - Questionnaire Fixes
INC-222309MCOM – 4834CC3 ATM Dispute Changes
US-480529AN 5211 Revised chargeback standards for AFD transactions
BUG-694571MCOM - Acquirer Pre-compliance timeframes
BUG742439/BUG732119MCOM – Accounting fixes
INC-226464Visa – Incorrect mapping of Dispute Stage at Pre-arbitration
INC-231437/INC-235852Visa – Allowed formats for Supporting Documents
INC-226767Visa – Pre-Arbitration details in VCR tab
INC-230325Visa – Manage Associated Transactions
INC-233913Visa – Pre-Compliance Response Details in VCR Tab
INC-232855Visa – Dispute Response Details in VCR Tab
INC-222088Visa – Manual Case Fixes
INC-222089Visa – Case status fixes
INC-219270Visa – Auto populate amounts on Process Liability
INC-225008 Visa – Field values for Brazil and Colombia
US-483974Visa – EMV Liability Updates
US-473347Visa – Information Message on attaching documents
US-483978Visa – 10.3 Dispute validations update
BUG-729510AMEX – Multiprong Option is not available in the Final Chargeback
US-488875AMEX: Accounting for Pre-compliance
INC-218554Regulation E evaluations for DST to DMT claim conversion
INC-229346Regulation E eligibility
INC-233437Process Liability for Regulation E disputes
INC-229341ATM Questionnaire
INC-231153Claim resolution through Ethoca – Third Party Resolution
INC-226861RegE Dates Evaluation
INC-223384Partial Amount received for ATM Disputes
INC-223886Task Status displayed in French
INC-218094HND – Claim Status fixes
INC-214871ATM flow for Manual Case
INC-216996WSS – Work object not deleted
INC-214605Verifi – Authorization Code addition
INC-221841AMEX – Questionnaire fixes
BUG-715395CSFS – Account Search error
INC-238315Visa - Appeal final ruling
INC-231738 MCOM – Chargeback Timeframes for Goods or Services Not Provided (4853-2)
INC-232929Visa – Reset of flag ‘isChagebackProcessed
INC-236381Visa – Arbitration Association Ruling
INC-236680 Visa – Compliance Association Ruling
INC-239221WSS – Attachments deleted for disputes created through any channel, cases getting corrupted because of assignments deletion
BUG-748714Visa – Review inbound Cancelled Merchandise/Services dispute
INC-241302Visa – Cancelled Merchandise/Service Questionnaire
US-499744MCOM – AN 5803 Revised Standards for Merchant Surcharging at the Point-of-Interaction in the Canada Region
US-501666MCOM – CVM limit updates
US-501679MCOM – AN 4655 Inclusion of Acquirers in the Mastercom Collaboration Process
INC-239822MCOM – C86 validation at Choose a reason code screen
US-500993MCOM – Point of Interaction Error questionnaire for ATM disputes
INC-240054MCOM – Transaction Selection Fixes for Force Post transactions
INC-242849Visa – Mapping of Pre-Compliance violation code for ‘Compliance Right for Improperly Assessed Surcharge’
INC-240524Visa – Mapping of IsChargeBackProcessed flag
INC-243033Visa – Cancelled Merchandise/Services Dispute Questionnaire
INC-236121Visa – Batch Queue fixes for pxUpdateDateTime property when cases are resolved as ‘Resolved-AcqAccepted’
INC-243776Visa – Information message in Supporting Documents section
INC-233322Visa – Audit history fixes
INC-242640 Visa – Batch Queue fixes
INC-240231Visa – Dispute response supporting documents for Paid by Other Means/Duplicate Processing
INC-240449Visa – Enabling Multipart message structure for Contact Message Response
INC-240050Regulation E fixes when Cardholder is made liable
INC-238943Legacy rule fixes
INC-240934/INC244193Visa – Acquirer Transaction Inquiry
INC-246176MCOM – ‘Acquirer Case Filing Retrieve Documents’ agent not resuming Pre-Arbitration cases that are waiting for documents
INC-243229MCOM – ‘Acquirer Inbound documents’ agent not resuming PreArbitration cases that are waiting for documents
INC-241388Commit issues while performing Cardholder liable action from bulk actions
INC-243219Visa – Mapping of Outstanding amount in VCR tab
INC-243800MCOM – Fixes for Service Exceptions
INC-240063Regulation-E eligibility evaluation
BUG-766445MCOM – Association Decision not processed
BUG-767599Visa – Validation on Pre-Compliance Amount
INC-247191C86 Regulation Evaluation
INC-244193Visa – Batch Queue fixes (Other Queue)
INC-248736Visa – Mapping of Transaction details after receiving Pre-arbitration Response
INC-247512Visa – Inbound dispute questionnaire for Duplicate Processing (12.6) and Merchandise/Services Not Received (13.1)
BUG-763654MCOM – CreateClaim API Failure
INC-247345Visa – Audit tab fixes for Pre-Compliance
INC-244192MCOM – Flow not resumed after first Chargeback SLA expiry
INC-250465MCOM – Dispute Validations for 4837
BUG-761975MCOM – Reason code description in Mastercom First Chargeback footer tab
INC-245993MCOM – Mismatch in the work status after Process Liability
INC-246872Visa – Appeal final ruling
INC-244277Visa – Incorrect API name in Third party tab
BUG-766336Visa – Process Acquirer Liability screen fixes
BUG-760818Visa – VCR Configurations - Batch Queue Debug tool is inaccessible
INC-242239Visa – Error Handling - Display previous Assignment is not removed from dispute
INC-245026Visa – Past disputes counter-based validation for Fraud disputes is not working properly when concurrent disputes are processed
INC-256121MCOM – Withdraw Case Filing
INC-255126MCOM – Case Filing API fixes
INC-256127/INC-260032 MCOM – EBDR fixes
INC-253690MCOM – New cases are created when Pre-Compliance is received for existing dispute
US-527749MCOM – Addition of Mastercard Fraud Types 55 and 56
INC-254167Visa – Process Liability amount in Audit history
BUG-781161Visa – Cancelled Merchandise/Services Questionnaire
INC-255406Visa – Audit history update
INC-255606Visa – Fraud Report
INC-256093Visa – Appeal case filing amount
INC-257271Claim level Pulse Gadget
INC-258585/INC-259004/INC-261088/INC-258775Regulation-E fixes
INC-247088Timeframe expiry fixes
US-530741MCOM – AN 7077 Revised Chargeback Standards for Currency Errors
INC-253403MCOM – Case filing batch queue fixes
INC-264178/ INC-264741Visa – Cancelled Recurring Transaction Questionnaire
US-530736Visa – Other Fraud – Card Absent Environment (10.4) dispute validation for fully authenticated U.S. domestic token transactions
BUG-787321Visa – Pre-Arbitration: Remedy – Prior Undisputed Non-Fraud Transactions questionnaireUI fixes
INC-248089Visa – Minimum dispute amount dispute validation for Travel and Entertainment transactions
INC-246534/ INC-263073Visa – Refine Transaction Selection Criteria
INC-266786Visa – Cancelled Merchandise/Services Questionnaire
US-536339Visa – Supporting documentation for Incorrect Amount disputes
US-536297Regulation-E eligibility criteria

Mastercard/MCOM issues

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.

Creation of Collaboration cases

MCOM - Creation of collaboration cases

ApplicationSmart Dispute for Acquirers
Scheme ImpactMCOM
Functional CategoryMCOM Collaboration for Acquirers
Reported IssueAs an Acquirer operator, I’m not able to see the inbound collaboration cases created through batch queue agent for Acquirer Collaboration Unworked queue as standardclaims property is not available in case of collaboration requests
Smart Dispute ImplementationThe activity rule CaseCreationFromQueue is modified to add step 11. Property value for Param.MComClaimID is updated in steps 12 and 15.
How to test the functionalityVerify inbound collaboration cases are created through batch queue agent for ‘Acquirer Collaboration Unworked’ queue.

MCOM – Collaboration layer updates for Acquirer response code ‘Initiating Refund (C)’

ApplicationSmart Dispute for Issuers and Acquirers
Scheme ImpactMCOM
Functional CategoryMCOM Collaboration Layer for Issuers and Acquirers
Reported Issue
  1. When an Acquirer responds to Inbound collaboration request with acquirer response code ‘Initiating Refund’ (C) and updates the collaboration response with refund details, MCOM is throwing error as ‘Not Allowed to change the Acquirer Response code from C to B’. When the refund details are updated, AcquirerResponseCode should be sent as ‘C’ instead of ‘B’ in the API request.
  2. In Smart Dispute for Issuers application, when a 5000-chargeback reject is received with Acquirer response code as ‘C’, dispute waits at ‘Awaiting refund information from Acquirer’ assignment for 5 days. Currently, application triggers MCOM API GetClaim every day to verify if the refund details are available using the decision table SetFlowPathsFromAcqRespCode. However, for initiating refund response, since acquirer response code remains as C even after the refund is successfully processed, the outcome of the decision table is always InitiatingRefund. Hence, disputes will not be routed to Awaiting Merchant Credits assignment.
Smart Dispute Implementation
  1. The activity rule PostUpdateCollabResponse is modified to remove AcquirerResponseCd mapping in step 3. When Acquirer updates the collaboration response with refund details, AcquirerResponseCd is sent as ‘C’ instead of ‘B’ in the API request.
  2. The decision table SetFlowPathsFromAcqRespCode is updated to add row for AcquirerResponseCode ‘C’ with evaluation condition as RefundDetailsAvailable. This condition checks if the acquirer has already sent the refund details.
How to test the functionalityAcquirer:
  1. Create an inbound collaboration request case in Smart Dispute for Acquirers application.
  2. Select acquirer response code as ‘Initiating Refund’ in the Review inbound Collaboration request details screen.
  3. Provide Refund details in the ‘Update Collaboration response’ screen.
  4. Verify the collaboration response is successfully submitted to MCOM and AcquirerResponseCd is sent as ‘C’ in the API request.

Issuer:

  1. Create a MCOM case.
  2. Process Qualify dispute with any dispute reason and complete the questionnaire.
  3. Process Answer Ancillary Questionnaire and submit the chargeback.
  4. If MCOM reject is received with reject reason as 5000 and Acquirer response code as ‘C’, observe that the case is routed to Awaiting refund information from Acquirer.
  5. As application triggers GetClaim API daily, if the refund details are available i.e., if refundReversalType is REFUND, then verify that application routes the dispute to Awaiting Merchant Credits.

MCOM – Process liability options at Initiate Compliance screen

ApplicationSmart Dispute for Acquirers
Scheme ImpactVISA
Functional CategoryPre-compliance
Reported IssueIn the Initiate Compliance screen, if Process liability option is selected from other actions, then Cardholder liable option is displayed instead of Merchant liable option.
Smart Dispute ImplementationUpdated local action in PegaCard-Sd-DisputeAcq-MC InitiateCompliance flow from "ProcessLiabilityatAQScreen" to "AcqPartialProcessLiability" on Initiate Compliance assignment.
How to test the functionality
  1. Create an Acquirer case with any inbound chargeback reason.
  2. At ‘Review inbound chargeback’ screen, answer ‘Select appropriate action for further processing’ as ‘Accept’ and submit the screen.
  3. Verify application routes the dispute to Process liability screen.
  4. In the Process liability screen, select ‘Initiate Pre-Compliance’ from other actions and proceed till ‘Initiate Compliance’ screen.
  5. In the ‘Initiate Compliance’ screen, select Process liability from other actions.
  6. Verify liability options are displayed as ‘Write-off’ and ‘Merchant Liable’.

MCOM – Pre-Compliance supporting documents

ApplicationSmart Dispute for Issuers
Scheme ImpactMCOM
Functional CategoryPre-compliance
Reported IssueWhen the Pre-compliance violation type is selected as “All Other Rules Violations - Third-Party Processed Transactions”, under ‘Supporting documents’ section, ‘Other’ document is displayed as optional instead of mandatory.
Smart Dispute ImplementationIn ‘CheckIfPreCompDocForViolationMandatory’, added “All Other Rules Violations - Third-Party Processed Transactions” violation type.
How to test the functionality
  1. Create a MCOM dispute.
  2. Submit Qualify dispute screen with any dispute reason.
  3. In the Answer Ancillary Questionnaire screen, select Initiate Pre-Compliance from other actions.
  4. Select ‘Type of violation’ as “All Other Rules Violations - Third-Party Processed Transactions” and verify ‘Other’ document as mandatory under supporting documents section.

MCOM – Pre-Compliance questionnaire for violation type ‘Same Day Processing of Chargeback Reversal and Second Presentment’

ApplicationSmart Dispute for Issuers
Scheme ImpactMCOM
Functional CategoryPre-compliance
Reported IssueWhen an issuing operator is trying to submit Pre-compliance with violation type "Same Day Processing of Chargeback Reversal and Second Presentment", MCOM is throwing an error that PrimaryAcountNum is not getting initialized. In Create Filing API request, application is not passing the primary account number when the chargeback reference number (.chargebackRefNum) is entered in the Pre-compliance questionnaire.
Smart Dispute ImplementationChargeback reference number in Pre-compliance questionnaire is mapped to a new property .CBRefNumber instead of using existing property .chargebackRefNum. .CBRefNumber is mapped to field .memo in CreateFiling API request.

In section InitiatePreCoplianceForMCOM, property name in dynamic layout 1.1.3 is updated to CBRefNumber. In the data transform CreateFilingForPreCompliance, steps 25, 26 are added to set memo using decision table SetSenderMemoPrecomp.

How to test the functionality
  1. Create a MCOM dispute.
  2. Submit Qualify dispute screen with any dispute reason.
  3. In the Answer Ancillary Questionnaire screen, select Initiate Pre-Compliance from other actions.
  4. Select ‘Type of violation’ as ‘Same Day Processing of Chargeback Reversal and Second Presentment’.
  5. Enter chargeback reference number and completed the questionnaire.
  6. Verify Pre-compliance is successfully submitted to MCOM

MCOM – Pre-arbitration fixes

ApplicationSmart Dispute for Issuers
Scheme ImpactMCOM
Dispute Reason4837 – No Cardholder Authorization
Functional CategoryPre-arbitration
Reported IssueFor 4837-No Cardholder Authorization disputes, if Issuer initiates Pre-Arbitration with reason as "Compelling Evidence for Airline, Recurring, Installment-based Repayment, ECommerce, and MO/TO Transactions", Pre-Arbitration memo text area is not pre-populated with default value.
Smart Dispute ImplementationIn decision table PopulatePreArbCommentsForArbReason, arbitration reason column has been updated.
How to test the functionality
  1. Create a MCOM dispute case.
  2. Submit Qualify dispute screen.
  3. Submit Answer ancillary questions screen.
  4. Proceed to chargeback submission.
  5. In the Review Second Presentment assignment, select Initiate Pre-Arbitration and proceed.
  6. In the Initiate Pre-Arbitration assignment, select Arbitration reason as “Compelling Evidence for Airline, Recurring, Installment-based Repayment, ECommerce, and MO/TO Transactions” and observe that Pre-Arbitration memo is pre-populated.

MCOM – Disable fraud types 55 and 56

ApplicationSmart Dispute for Issuers
Scheme ImpactMCOM
Functional CategoryFraud
Reported IssueIn Smart Dispute for Issuers application, when Fraud disputes are created and submitted, application automatically submits fraud report using createFraud MCOM API. MCOM is throwing the below error when Fraud Types 55 (Modification of Payment Order) & 56 (Manipulation of Cardholder) are submitted: "INVALID_INPUT_VALUE" error for fraud types 55 & 56.

As per latest update from Mastercard, Issuers cannot report Fraud Types 55 or 56 using Mastercom API as the current version of Mastercom does not support Fraud Types 55 or 56.

Fraud types 55 and 56 should not be displayed in Smart Dispute for Issuers application until the changes are effective in MCOM.

Smart Dispute ImplementationThe data transform rules MapFraudTypeForSafeReport, PopulateFraudTypeAppMCOMList, PopulateFraudTypeMCOMList are updated to disable fraud types ‘Modification of Payment Order’ (55) & ‘Manipulation of Cardholder’ (56).
How to test the functionality
  1. Create a fraud MCOM dispute.
  2. Verify the fraud types ‘Modification of Payment Order’ & ‘Manipulation of Cardholder’ are not available when user qualifies the fraud dispute/ submits a chargeback/ reports the transaction to SAFE using local action ‘Report transaction to SAFE’ from Answer ancillary questions screen.

MCOM – Timeframes for Credit Not Processed

ApplicationSmart Dispute for Issuers
Scheme ImpactMCOM
Scheme ReferencePages 71-75 of Chargeback guide
Dispute Reason4853-5 Credit Not Processed
Functional CategoryChargeback Timeframes
Reported IssueAs an issuing bank operator, if I create a ‘Credit Not Processed’ dispute, application is considering the dispute timeframe as expired and routing the dispute to Process liability for transactions with central processing date older than 540 days from current date. But as per chargeback guide, timeframes are defined as:

Non-travel transactions in all regions except China domestic 120 days from the date on the credit documentation, or the date the service was cancelled, or the goods were returned.

Non-travel China domestic transactions 90 days from the date on the credit documentation, or the date the service was cancelled, or the goods were returned.

Smart Dispute ImplementationData transform PegaCard-Sd-Dispute-MC- SetTimelinesForDisputeTimeFrameExpiry is updated as mentioned below: Step 14: Maximum limit for dispute timeframes is not set if Param.ConditionCode=="5” Step 38: Timeframe property is set as 90 for China domestic non-travel transactions.
How to test the functionality
  1. Create a MCOM dispute case on a transaction older than 540 days from current date.
  2. Submit Qualify dispute screen by selecting the dispute reason as ‘I have not received expected credit’.
  3. Complete the questionnaire such that either of the following date fields are within 120 days from current date:
    • Date on the credit documentation
    • Date the service was cancelled
    • Goods returned date
  4. Verify Answer ancillary questions screen is displayed, and dispute is not routed to Process Liability.

MCOM – Chargeback Timeframes for Goods or Services Not Provided (4853- 2)

ApplicationSmart Dispute for Issuers
Scheme ImpactMCOM
Scheme ReferenceChargeback Guide
Dispute ReasonGoods or Services Not Provided (4853-2)
Functional CategoryDispute Questionnaire
Reported IssueWhen a chargeback is initiated with reason code Goods or Services Not Provided (4853-2), application is evaluating the maximum time frame limit as 540 days from central processing date for the below scenarios but as per chargeback guide the 540 days maximum time frame limit is not applicable.

For China domestic transactions

The chargeback time frame for ‘Delayed delivery of goods or services - Delivery date was specified’ is 90 days from the expected delivery date of the goods or services. The chargeback time frame for cases ‘Involving the purchase of a merchant-branded prepaid gift card with an expiration date printed on the card and that merchant subsequently goes out of business’ is 120- calendar days from the expiration date printed on the card.

Other transactions

The chargeback time frame for ‘Delayed delivery of goods or services - Delivery date was specified’ is 120 days from the expected delivery date of the goods or services.

The chargeback time frame for cases ‘Involving the purchase of a merchant-branded prepaid gift card with an expiration date printed on the card and that merchant subsequently goes out of business’ is 120- calendar days from the expiration date printed on the card.

Smart Dispute ImplementationFor reason code 4853-2, the data transform SetTimelinesForDisputeTimeFrameExpiry is updated such that the maximum time frame limit of 540 days from Central Processing Date is applicable only when the date properties ExpectedReceiptDate or ExpirationDate are not available.
How to test the functionality
  1. Create a MCOM dispute on a transaction that had occurred more than 540 days past the dispute creation date and select the dispute reason as ‘I have not received the merchandise/service’.
  2. Answer the question ‘Select appropriate condition for the Chargeback’ as Delayed delivery of goods or services and the delivery or performance date was specified.
  3. Enter a date that is within 120 days past the current date in the field ‘What was the expected delivery date of the goods or services’.
  4. Observe the chargeback is successfully submitted to Mastercard and case is not routed to ‘Process Liability.

MCOM – AN 5803 Revised Standards for Merchant Surcharging at the Point-of-Interaction in the Canada Region

ApplicationSmart Dispute for Issuers and Acquirers
Scheme ImpactMCOM
Scheme ReferenceMCOM – AN 5803 Revised Standards for Merchant Surcharging at the Point-of-Interaction in the Canada Region
Dispute ReasonImproper Merchant Surcharge (4834-8)
Functional CategoryDispute Questionnaire
Reported IssueAs per Mastercard bulletin, “AN 5803 Revised Standards for Merchant Surcharging at the Point-ofInteraction in the Canada Region”, Issuers could raise chargeback under 4834 - Improper Merchant Surcharge for Canada domestic transactions if the merchant applied improper surcharge to the total transaction amount.

Effective October 6th, 2022, Issuers can dispute a Canada domestic transaction under dispute reason code: Improper Merchant Surcharge: 4834-8.

Smart Dispute ImplementationUpdated decision table FilterReasonCodes_MasterCard to add WhenCanadaDomesticTxn rule in return value for 4834-8. Updated data transform SetTimelinesForDisputeTimeFrameExpiry to add step 40 for 4834-8 timeframes
How to test the functionality
  1. Create a MCOM dispute on a Canada domestic transaction.
  2. In Qualify dispute screen, select “I have another issue with this transaction” in dispute reason dropdown and submit the questionnaire.
  3. In Choose a reason code, select “Point of Interaction Error-4834” in Reason code dropdown.
  4. Verify “Improper Merchant Surcharge-8” is displayed in Condition code dropdown and observe the questionnaire is displayed.
  5. Answer the questionnaire and observe the dispute is submitted to Mastercard.
  6. Verify the dispute is at “Awaiting Acquirer response”

MCOM – CVM limit updates

ApplicationSmart Dispute for Issuers
Scheme ImpactMCOM
Scheme ReferenceAN 6908 Revised Standards for CVM Limits in Nepal

AN 6907 Revised Standards for CVM Limits in Sri Lanka

AN 6857 Revised Standards for CVM Limits in Select Countries in the Latin America and the Caribbean Region

Dispute Reason4808, 4837, 4870, 4871
Functional CategoryCVM Limits
Effective DateAN 6908 Revised Standards for CVM Limits in Nepal: November 1st, 2022

AN 6907 Revised Standards for CVM Limits in Sri Lanka: November 1st, 2022

AN 6857 Revised Standards for CVM Limits in Select Countries in the Latin America and the Caribbean Region: October 1st, 2022
Reported IssueThis change is as part of Mastercard guidelines and CVM limit updates are made to be in compliant with the scheme changes.
Smart Dispute ImplementationIn the decision table rule PegaCard-SdDispute-MC- PayPassAmounts, transaction amount is updated as below:
  • Nepal: 3,635 NPR for Merchant category codes 4111, 4131, 4784
  • Sri Lanka: 7,500 LKR for Merchant category codes 4111, 4131, 4784
  • Chile: 20,000 CLP (Merchant category code -ALL,4111,4131,4784)
  • Paraguay is updated from PYG 2,84,135 to PYG 100,000 (Merchant category code -ALL,4111,4131,4784)
  • Colombia is updated from COP 100,000 to COP 250,000 (Merchant category code -ALL,4111,4131,4784)
  • Mexico is updated from MXN 928 to MXN 400(Merchant category code - ALL,4111,4131,4784)

In the decision table rule PegaCard-SdDispute-MC- PayPassAmntsForOtherMCC, below countries are added:

  • Transaction amount for Nepal is 5,000 NPR for contactless transactions
  • Transaction amount for Sri Lanka is 25,000 LKR for contactless transactions
How to test the functionality
  1. Create a MCOM dispute on a contactless Nepal contactless transit aggregated transaction (Merchant category code 4111) with amount less than 3,635 NPR.
  2. Process ‘Qualify dispute’ by selecting the dispute reason as ‘I have another issue with transaction’.
  3. In ‘Choose a Reason Code’ screen, select Reason code as ‘No Cardholder Authorization-4837’, answer the questionnaire and submit the screen.
  4. Observe that application throws error

MCOM – AN 4655 Inclusion of Acquirers in the Mastercom Collaboration Process

ApplicationSmart Dispute for Issuers and Acquirers
Scheme ImpactMCOM
Scheme ReferenceAN 4655 Inclusion of Acquirers in the Mastercom Collaboration Process
Dispute ReasonNA
Functional CategoryMastercom Collaboration Process for Acquirers
Effective DateNA
Reported IssueAs per recent Mastercard scheme update, Acquirer Collaboration Layer Process is deferred but the changes for Acquirer Collaboration Requests were already delivered as part of April Smart Dispute Maintenance Release. As the changes are available in production, the agents for Collaboration Requests in the Issuer and Acquirer applications must be updated such that only Collaboration Requests (Retrieval Requests) for US health care transactions are processed.

The MCOM queues Issuer Collaboration Unworked and Acquirer Collaboration Unworked are not live in production and hence should not be used. The MCOM queues Issuer RR Unworked and Acquirer RR Unworked must be used to process Collaboration Requests/Retrieval Requests for US health care transactions.

Smart Dispute ImplementationUpdated data transform PrepareMComQueueList to process "Issuer RR Unworked" and “Acquirer RR Unworked” instead of “Issuer Collaboration Unworked” & “Acquirer Collaboration Unworked” queues in Smart Disputes Issuer and Acquirer applications.
Note: Clients are advised to ENABLE ‘Issuer RR Unworked’ & ‘Acquirer RR Unworked’ agents and DISABLE ‘Issuer Collaboration Unworked’ & ‘Acquirer Collaboration Unworked’ agents to process only Collaboration requests (Retrieval requests) for US healthcare transactions.
How to test the functionality
  1. Create a MCOM dispute on a US healthcare transaction.
  2. In Qualify dispute screen, select ‘I have another issue with this transaction’ as dispute reason and submit.
  3. In ‘Choose a Reason Code’ screen, select ‘Initiate Collaboration request’ from ‘Other actions’.
  4. Now, as an Acquirer, verify inbound Collaboration Request (Retrieval Request) cases are created and the case is waiting at Review inbound Collaboration request details assignment.

MCOM – C86 validation at Choose a reason code screen

ApplicationSmart Dispute for Issuers
Scheme ImpactMCOM
Scheme ReferenceNA
Dispute ReasonFraud
Functional CategoryCanada (C86) Regulations
Effective DateNA
Reported IssueIn ‘Choose a reason code’ screen, when the operator answers C86 related questionnaire and saves the questionnaire, the operator is unable to make the Cardholder as liable through ‘Process Liability’ option because of validations related to C86.
Smart Dispute ImplementationC86 related validations are only applicable after submitting ‘Choose a reason code’ screen. Hence, call to the activity ValidateC86Regulation is removed from PostProcessliabilityatAQScreen activity.
How to test the functionality
  1. Create a MCOM Fraud dispute on a Canada credit card transaction that is eligible for C86 and submit ‘Qualify fraud disputes’ screen.
  2. In ‘Choose a reason code’ screen, answer “Does the fraud transaction qualify to be a result of gross negligence by cardholder” as ‘No’ and “Was the issuer notified of Loss/Stolen/Unauthorized use of card before the transaction date?” as ‘No’.
  3. Answer the remaining questionnaire and save the screen.
  4. Select ‘Process liability’ option from ‘Other actions’ and select Cardholder liable option.
  5. Verify the case should resolve as Cardholder liable without any C86 restrictions.

MCOM – Point of Interaction Error questionnaire for ATM disputes

ApplicationSmart Dispute for Issuers
Scheme ImpactMCOM
Scheme ReferenceNA
Dispute ReasonPoint of Interaction Error – ATM Disputes
Functional CategoryDispute Questionnaire
Effective DateNA
Reported IssueIn the Qualify dispute screen, when ‘I did not receive cash/received partial cash at ATM’ is selected as the dispute reason and the Issuer enters access fee, application is not adding the access fee to the dispute amount for domestic transactions.
Smart Dispute ImplementationUpdated PrePickReasonCodeForMCom pre-processing data transform for dispute amount calculations based on access fee.

Created SetDisputeAmtForRC4843CC3 data transform to update dispute amount based on access fee and called this data transform in PostPickReasonCodeForMCom activity.

How to test the functionality
  1. Create a MCOM dispute and select ‘I did not receive cash/received partial cash at ATM’ as dispute reason in Qualify dispute screen.
  2. Select ‘Some or all of the funds debited from the cardholder’s account as the result of an ATM withdrawal were not dispensed.’ from the dropdown ‘Select the nature of the dispute’.
  3. Select ‘Yes’ for the question ‘Is the Chargeback for the full amount of the original transaction?
  4. Enter fee amount in ‘Access Fee, if any’ question and submit.
  5. Verify dispute amount is updated in ‘Overview’ tab.
  6. In ‘Choose a reason code’ screen click on submit and verify that the dispute is successfully submitted to MasterCard with updated dispute amount.

MCOM – Transaction Selection Fixes for Force Post transactions

ApplicationSmart Dispute for Issuers
Scheme ImpactMCOM
Scheme ReferenceNA
Dispute ReasonAll
Functional CategoryTransaction Selection
Effective DateNA
Reported IssueFor Force Post transactions that require Transaction Selection, when user selects a transaction, the selected clearing transaction is copied into ‘.TransactionAuthDetails’ page. Later, in GetTransactionAuthDetails activity, system overwrites ‘.TransactionAuthDetails’ using TranSearch API response data, i.e. .MCOM_TranSearch.authorizationSummary(1). Eventually CreateClaim API is invoked using wrong transaction id.
Smart Dispute ImplementationIn GetTransactionAuthDetails activity, conditions to evaluate if .TransactionAuthDetails page is loaded already are incomplete for Force Post transactions. Additional conditions have been added to account for Force Post transactions.

A new validation has been added to prevent users from choosing a Reversal transaction in Transaction Selection screen.

How to test the functionality
  1. Create a MCOM claim on a Force Post transaction that is eligible for Transaction Selection.
  2. Qualify the dispute.
  3. In Transaction Selection screen, choose a transaction that has Reversed = Y and click Submit.
  4. System should throw an error message “Dispute not allowed on Sale or Credit Reversal. Please select another transaction.”
  5. Now, choose any transaction for which Reversed = N and click Submit.
  6. Ensure that system uses the clearing transaction Id corresponding to the selected transaction for CreateClaim API – This can be verified by reviewing the Request payload for CreateClaim API under Audit > Third Party tab.

MCOM – ‘Acquirer Case Filing Retrieve Documents’ agent not resuming Pre-Arbitration cases that are waiting for documents

ApplicationSmart Dispute for Acquirers
Scheme ImpactMCOM
Scheme ReferenceNA
Dispute ReasonNA
Functional CategoryBatch Queues
Effective DateNA
Reported IssueWhen the Acquirer receives an Inbound Pre-Arbitration and the Acquirer case routes to ‘Waiting for docs’ assignment with status as ‘Pending-DocAtCaseFiling’, the agent ‘Acquirer Case Filing Retrieve Documents’ is not resuming the case after the documents are received.
Smart Dispute Implementation
  1. The Report Definition PegaCard-Sd-Dispute- MC GetWorkObjectByMComCaseStatus is saved into acquirer class PegaCard-Sd-DisputeAcq-MC GetWorkObjectByMComCaseStatus, the column ‘.MCOM_CreateClaim.claimId’ is removed. ‘Display unoptimized properties in data explorer’ checkbox is unchecked in Data Access Tab.
  2. Step 8.2 is modified in the activity PegaCard-SdDispute-MC- CaseFilingDocumentProcessing to set WOListByMComCaseStatus.pxResults(<CURRENT>). MCOMClaimId
How to test the functionality
  1. Process an MCOM Acquirer case by submitting a representment.
  2. Observe the case waits at ‘Awaiting Issuer response’ assignment.
  3. When the Acquirer receives an inbound Prearbitration and the documents are yet to be submitted by the Issuer, the Acquirer case waits at ‘Waiting for docs’ assignment.
  4. When the documents are received, observe the agent ‘Acquirer Case Filing Retrieve Documents’ resumes the case.

MCOM – ‘Acquirer Inbound documents’ agent not resuming Pre-Arbitration cases that are waiting for documents

ApplicationSmart Dispute for Acquirers
Scheme ImpactMCOM
Scheme ReferenceNA
Dispute ReasonNA
Functional CategoryBatch Queues
Effective DateNA
Reported IssueIssue 1:

When the Acquirer receives an Inbound chargeback and the Acquirer case routes to ‘Waiting for docs’ assignment with status as ‘PendingDocumentation’, the agent ‘Acquirer Inbound documents’ is not resuming the case after receiving the documents.

Issue 2:

When the Acquirer receives an Inbound chargeback and the Acquirer case is at ‘Waiting for docs’ assignment, GetCBStatus MCOM API is invoked in the flow PegaCard-Sd-DisputeAcq-MC WaitingForDocuments. In case of any service exceptions and user attempts to retry the API call, the retry attempts are failing.

Smart Dispute ImplementationIssue 1:

In the data transform PegaCard-Sd-DisputeAcq-MC GetCBStatus, step 3.1 is modified to verify if MCOM_GetClaim.claimId!="" .

Issue 2:

In the data transform PegaCard-Sd-DisputeAcq-MC GetCBStatus, step 2 is added. In case of any exceptions, when the operator retries the API call, DisputeListByMComCaseStatus page should exist for successful retry attempt. If the page does not exist, then PreparePageforGetCBStatus data transform is invoked to populate the page DisputeListByMComCaseStatus. In the Report Definition PegaCard-Sd-DisputeAcq-MC GetDisputeByMComCaseStatus, the checkbox ‘Display unoptimized’ is unchecked in Data Access Tab.

In the activity PegaCard-Sd-Dispute-MCProcessGetCBStatusResponse, the value for parameter SkipPostResumeWO is passed as ‘true’ in step 5.1.

How to test the functionality
  1. Create an incoming MCOM chargeback Acquirer case such that the case waits at ‘Waiting for docs’ assignment after the MCOM API call GetCBstatus.
  2. When the documents are received, observe the agent ‘Acquirer Inbound documents’ resumes the case.

MCOM – Fixes for Service Exceptions

ApplicationSmart Dispute for Issuers
Scheme ImpactMCOM
Scheme ReferenceNA
Dispute ReasonNA
Functional CategoryService Exceptions
Effective DateNA
Reported IssueWhen a fraud dispute is submitted after Answer ancillary questions, application invokes MCOM API CreateFraud to report the Fraud. When there is any service exception during the invocation of CreateFraud API, application routes the dispute to MCOM Service Exception assignment. If the operator clicks on Back button in the assignment, then the application should route back to previous assignment, but the dispute case does not contain any open assignments.
Smart Dispute ImplementationIn the when rule IsLocalActionServiceError, another condition is added to check if CreateFraud API is invoked through local action. The property CreateFraudLocal is used to check if the call is being made through the local action. In the activity PostReportTransToSAFEAtClaim, the property CreateFraudLocal is set to ‘true’ in step 8.2.
How to test the functionality
  1. Create a MCOM Fraud dispute
  2. Process Qualify fraud dispute assignment
  3. Verify dispute routes to Answer ancillary questions assignment.
  4. Answer the ancillary questions and submit the assignment.
  5. Continue the chargeback if there are any dispute validations.
  6. Let CreateFraud API fail and observe the dispute routes to MCOM Service Error assignment.
  7. Click Back button and observe the dispute is routed back to the previous assignment.

MCOM – Association Decision not processed

ApplicationSmart Dispute for Acquirers
Scheme ImpactMCOM
Scheme ReferenceNA
Dispute ReasonNA
Functional CategoryCase filing
Effective DateNA
Reported IssueWhen Acquirer receives either Inbound Compliance or Arbitration and the case is waiting at the assignment Awaiting Association Decision, then the case is not getting resumed further after the association decision is received.
Smart Dispute ImplementationIn the flow, PegaCard-Sd-DisputeAcq-MC AcqArbAssociationReviewForMCOM, a new Service Level Agreement (SLA) PegaCard-Sd-DisputeAcqMCAwaitingAssociationRespSLA is configured for the assignment Awaiting Association Decision
How to test the functionality
  1. Create a MCOM Acquirer case for an inbound PreCompliance and proceed till the Acquirer receives inbound Compliance from the Issuer.
  2. Observe the case waits at the assignment Review inbound Compliance details.
  3. Select Reject as the Acquirer response and verify the case waits at the assignment Awaiting Association Review. After the SLA resumes the assignment, the case waits at Awaiting Association Decision assignment.
  4. The SLA configured on Awaiting Association Decision assignment resumes the case when the association decision is received.
  5. Observe the case waits at assignment Process Association Decision.

MCOM – CreateClaim API Failure

ApplicationSmart Dispute for Issuers
Scheme ImpactMCOM
Scheme ReferenceNA
Dispute ReasonNA
Functional CategoryCreate Claim
Effective DateNA
Reported IssueMCOM API CreateClaim service call is failing
Smart Dispute ImplementationIn the data page D_CreateClaim, the checkbox Pass current parameter page is selected for the connector rule.
How to test the functionality
  1. Create a MCOM dispute.
  2. Process Qualify dispute with any dispute reason and submit the screen.
  3. Observe the API call CreateClaim is successful.

MCOM – Flow not resumed after first Chargeback SLA expiry

ApplicationSmart Dispute for Acquirers
Scheme ImpactMCOM
Scheme ReferenceNA
Dispute ReasonNA
Functional CategoryInbound chargeback
Effective DateNA
Reported IssueWhen an Acquirer fails to respond to an inbound chargeback within timelines, the Acquirer case is not resumed to Process liability screen.
Smart Dispute ImplementationUpdated the data transform rule SetCBSLAExpiryDefault to add step 3 for setting ‘.ReasonCode.ConditionCode’ value.
How to test the functionality
  1. Create a MCOM Acquirer inbound chargeback case.
  2. Verify the case is routed to Process liability assignment when the Acquirer doesn’t respond to the inbound within the time frames.

MCOM – Dispute Validations for 4837

ApplicationSmart Dispute for Issuers
Scheme ImpactMCOM
Scheme ReferencePage 97, Fraud-related Chargebacks, MCOM Chargeback guide October 2022
Dispute ReasonNo Cardholder Authorization - 4837
Functional CategoryDispute validations
Effective DateNA
Reported IssueNo Cardholder Authorization (4837) chargeback is invalid for a face-to-face transaction at an attended terminal with card-read (not key-entered) account information.

In Smart Dispute for Issuers application, when a chargeback is submitted with reason code ‘No Cardholder Authorization – 4837’, there is no validation to check whether the terminal is attended or not.

The dispute validation outcome for ‘A face-to-face transaction at an attended terminal with card-read (not key-entered) account information’ is returned as ‘Pass’ for attended terminal which is incorrect.
Smart Dispute ImplementationWhen rule CardPresentAndNonManualPANEntry is updated to add conditions F & F1 for evaluation of attended terminal.
How to test the functionality
  1. Create a MCOM fraud dispute on a face-to-face transaction that occurred at an attended terminal with card-read (not key-entered) account information.
  2. Complete Qualify fraud disputes with fraud type ‘Lost Fraud’.
  3. Complete Answer ancillary questions with reason code 4837-No Cardholder Authorization.
  4. Verify the dispute validation outcome for ‘A face-toface transaction at an attended terminal with cardread (not key-entered) account information’ is returned as ‘Fail’.

MCOM – Reason code description in Mastercom First Chargeback footer tab

ApplicationSmart Dispute for Issuers
Scheme ImpactMCOM
Scheme ReferenceNA
Dispute ReasonPoint of Interaction Error - 4834
Functional CategoryDispute Questionnaire
Effective DateNA
Reported IssueWhen a Point of Interaction Error – 4834 chargeback is submitted with condition code Improper Merchant Surcharge-8, the reason code description is displayed as incorrectly as Improper Merchant Surcharge - 4834 instead of Point of Interaction Error - 4834 in ‘Mastercom First Chargeback’ footer tab.
Smart Dispute ImplementationUpdated description for dispute reason code rules 4834-6, 4834-8, 4834-9 to ‘Point of Interaction Error’.
How to test the functionality
  1. Create a MCOM dispute.
  2. Process Qualify dispute screen by selecting the dispute reason as ‘I have another issue with this transaction’.
  3. In Choose a reason code screen, select the Reason code as ‘Point of Interaction Error-4834’ and Condition code as ‘Improper Merchant Surcharge-8’
  4. In the MasterCom footer tab, verify the reason code is displayed as ‘Point of Interaction Error - 4834’ under the First chargeback section.

MCOM – Mismatch in the work status after Process Liability

ApplicationSmart Dispute for Issuers
Scheme ImpactMCOM
Scheme ReferenceNA
Dispute ReasonNA
Functional CategoryRegulation-E
Effective DateNA
Reported IssueFor a Regulation-E eligible dispute, if a split liability of Write-off and Cardholder-liable is chosen in Process Liability screen, then post completion of Reverse Provisional Credit assignment, the dispute case is getting resolved as Resolved-CardholderLiabile instead of Resolved-SplitLiability
Smart Dispute ImplementationIn PegaCard-Sd-Debit-MC RegEEligibleReversePC flow, the utilities CheckIfAnyOpenAssignmentExists and UpdateStatus are removed. In SetDisputeStatustoCHLiableOrSplitLiability data transform, steps 1, 3 are added and step 4.1.2 is updated.
How to test the functionality
  1. Create a Regulation-E eligible MCOM dispute.
  2. Process Qualify dispute screen by selecting any dispute reason.
  3. Submit Select charge fees and Verbal attestation screens.
  4. Submit Give Provisional Credit parallel assignment to provide provisional credit.
  5. Complete Ancillary questions screen and submit the dispute to association.
  6. At Review second presentment screen, select ‘Initiate Pre-Arbitration’ and proceed further till Review PreArbitration response screen.
  7. At Review Pre-arbitration response, select ‘Accept’ and click Submit.
  8. Case should route to Process Issuer liability screen, select both ‘Write-off’ & ‘Cardholder Liable’ and click Submit.
  9. At Reverse provisional credit assignment, let the SLA expire 10. Verify case is resolved with status as ‘ResolvedSplitLiablity.

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 – INCOMING_BQ_ACCEPTANCES_RECEIVED queue processing for disputes resolved through Rapid Dispute Resolution (RDR)

ApplicationSmart Dispute for Issuers
Scheme ImpactVISA
Functional CategoryBatch Queues
Reported IssueAs an issuing disputes operator, when I create a dispute on a transaction which is eligible for Rapid Dispute Resolution (RDR), application routes the dispute to Awaiting- Visa RDR Credit assignment when merchant accepts to provide RDR credit. Disputes will be resolved if the Issuer confirms receival of RDR credit or if the Issuer does not take an action for 3 days.

In Smart Dispute for Issuers application, INCOMING_BQ_ACCEPTANCES_RECEIVED queue is used to process the disputes that are accepted by Acquirer at various stages of dispute life cycle. But all RDR disputes that are accepted by the merchant are also placed by Visa in INCOMING_BQ_ACCEPTANCES_RECEIVED queue. Application is trying to resume flow action Awaiting Acquirer Response for RDR disputes and throwing error as the RDR disputes will either be at Awaiting-Visa RDR Credit assignment or in a resolved state.

Smart Dispute ImplementationActivity VCR_BatchQueueProcessing is updated to add steps 4.7 and 4.8 in order to skip processing of RDR disputes.
How to test the functionality
  1. Create a VCR dispute on a transaction eligible for Rapid Dispute Resolution.
  2. Process Qualify dispute screen with any dispute reason.
  3. Process Dispute questionnaire screen and submit the dispute.
  4. Verify VROLFinancialID received in the response of RTSI SubmitDisputeQuestionnaireOperation. If the merchant accepts to provide RDR credit, Visa creates financial request and VROLFinancialID starts with ‘M-‘. This indicates Visa will provide RDR credit to the Issuer in 72 hours.
  5. Observe dispute is routed to Awaiting-Visa RDR Credit assignment.
  6. Once the batch queue agent reads RDR records from “INCOMING_BQ_ACCEPTANCES_RECEIVED” queue, processing agent should add history notes to the disputes that the processing has been skipped and the corresponding records are deleted from queue table.

Note: Note: RdrEligibilityInd property indicates whether transaction is eligible for RDR or not. This is received in the response of RTSI SubmitTranInquiryOperation.

Visa – Transaction inquiry fixes

ApplicationSmart Dispute for Issuers
Scheme ImpactVISA
Functional CategoryTransaction Inquiry
Reported IssueIn Smart Dispute for Issuers application, after a dispute is qualified, SubmitTransactionInquiryOperation API is invoked to retrieve the VROL transaction details.

When the RTSI service returns multiple results, the system routes the dispute to Transaction selection assignment. Operators must manually review the transactions, select an appropriate transaction, and submit. System will use the ROLTransactionId of the selected transaction for further processing. The results are displayed until the goal time of the assignment (3 days or dispute timeframe expiry whichever is earliest).

When the goal time is reached, the system hides the transaction results and displays the message “Deadline to select a transaction has passed. Refine the criteria and proceed further.”, indicating that Transaction Inquiry results have expired, and operators must manually retry Transaction Inquiry again using the alternate action Refine criteria. Upon retry, if multiple results are found, the system routes back to the Transaction selection assignment and displays the latest results retrieved. After 23.1 Test hotfix, despite manual retry, the latest transaction results were not displayed.

Smart Dispute ImplementationSmart Dispute for Issuers application leverages the flag TranSelectionDeadlineReached to determine if the Transaction Inquiry results have expired or not. After the first expiry, TranSelectionDeadlineReached is initialized to ‘Y’. But the flag was not reset when the operator manually retried using alternate action Refine criteria.

RemoveRolTransactionId data transform is updated to reset the flag TranSelectionDeadlineReached appropriately.

How to test the functionality
  1. Create a VCR dispute.
  2. In Qualify dispute screen, fill in the questionnaire and submit.
  3. Observe that SubmitTransactionInquiryOperation API is invoked. To test further, this API must return multiple transaction results.
  4. Observe that the dispute is routed to Transaction selection assignment.
  5. Wait until 3 days so that the transaction results retrieved from Transaction Inquiry expire.
  6. Now open the Transaction selection assignment.
  7. Observe that system displays the message, Deadline to select a transaction has passed. Refine the criteria and proceed further.
  8. Click Actions > Refine criteria.
  9. Ensure Start Date, End Date and Transaction ID / Acquirer Reference Number is carefully selected.
  10. Submit the screen to retry SubmitTransactionInquiryOperation again. The API must return multiple results again to test further.
  11. Observe that the dispute is routed to the Transaction selection assignment.
  12. Open the assignment and observe that the latest results are displayed.

Visa – Pre-Arbitration fixes for Remedy – Prior Undisputed Non-Fraud transactions

ApplicationSmart Dispute for Issuers
Scheme ImpactVISA
Dispute ReasonOther Fraud – Card Absent Environment (10.4)
Functional CategoryPre-arbitration
Reported IssueWhen an acquiring disputes operator is initiating a pre-arbitration using the reason Remedy – Prior Undisputed Non-Fraud Transactions for an inbound 10.4 (Other Fraud – Card Absent Environment) dispute, Smart Dispute provides the following two capabilities to find and add the historical transactions.
  • Find by Visa transaction inquiry
  • Enter transaction details manually
When the historical transactions are added manually, the currency for that transaction amount is a 3-character alphabetic currency code. This resulted in the following error from Visa when the Pre-arbitration is submitted: undisputedTransactions. undisputedTransaction[1].historicalTranAmount.currency : must match "[0-9][0-9][0-9]"
Smart Dispute ImplementationIn the data transform CreatePreArbRequestForRE, currency is directly mapped from the case without converting the alphabetic currency code to numeric code.

Data transform is updated to convert the 3-character alphabetic currency code to 3-digit numeric currency code using the existing Map Value rule CurrencyTypeMapping.

Note: When the currency does not match, the Map Value CurrencyTypeMapping returns 840 (USD) as the default result. Clients must ensure that all the currencies and currency codes handled in their application are defined in the Map Value rule.
How to test the functionality
  1. As an Acquirer, open an inbound 10.4 (Other Fraud – Card Absent Environment) dispute.
  2. Click Process inbound Dispute assignment. User is shown the Process incoming dispute screen.
  3. Select Initiate Pre-arbitration and click Submit.
  4. In Complete Pre-arbitration questionnaire screen, select pre-arbitration reason as Remedy – Prior Undisputed Non-Fraud transactions.
  5. Click Add / Edit undisputed historical transactions button.
  6. In the pop-up, select Enter transaction details manually tab.
  7. Enter two different transaction details and add them.
  8. Click Submit.
  9. Fill in remaining questionnaire and click Submit.
  10. Observe that Pre-arbitration is submitted successfully to Visa.
  11. If the application is enabled to log VCR request and response (available under VCR Configurations in Dev Studio), in Third Party tab, observe that the numeric currency codes are sent in the Pre-arbitration request.

Visa – Pre-Compliance fixes

ApplicationSmart Dispute for Issuers
Scheme ImpactVISA
Scheme ReferenceIES for Release 23.1_Pub 12.16.22, Sheet - Dispute; RTSI Function: SICreateDisputePreCompRequest
Functional CategoryPre-compliance
Reported IssueIssue 1: An Acquirer may receive an inbound dispute with dispute amount different from the actual transaction amount. This can happen due to:
  • Disputes raised for partial amount
  • Disputes with reason Incorrect Amount
  • FX Gain / Loss in cross-currency disputes etc
In such scenarios, when Acquirer accepts and initiates Pre-compliance for the full dispute amount, Visa is returning the following error: One or more required fields are missing. Please correct the following errors:DisputeAmountChangeReason. Smart Dispute does not prompt the user to enter dispute amount change reason in the above scenario.

Issue 2: When Pre-compliance amount is different from the dispute amount, system displays multi-pronged options prompting the user to record liabilities for the remaining amount. When the amounts entered do not balance against the dispute amount, system throws the error Total multi-pronged amount should be equal to the dispute amount. This error message is incorrect.

Smart Dispute Implementation
  1. Smart Dispute was displaying the field, “Why are you changing the dispute amount?”, only if the Pre-compliance amount entered is different from the inbound dispute amount. However, as per IES, this field is mandatory when Pre-compliance amount is different from actual transaction amount. The visibility condition for the field, “Why are you changing the dispute amount?” is modified to .PreComplianceAmount!=.AssociationData.TransactionAmount per IES specifications.
  2. Error message is updated to Sum of the total multi-pronged amount and the pre-compliance amount should be equal to the dispute amount.
How to test the functionality
  1. As an Acquirer, open an inbound dispute in which dispute amount is different from actual transaction amount.
  2. Click Process inbound Dispute assignment. User is shown the Process incoming dispute screen.
  3. Select Accept and Initiate Pre-Compliance action and click Submit.
  4. In the next screen, retain action as Accept and Initiate Pre-Compliance and click Submit.
  5. Click and open the assignment Initiate Pre-compliance assignment.
  6. Observe that, the mandatory field “Why are you changing the dispute amount?” is displayed to the user.
  7. Reduce the Pre-compliance amount and observe that Multi-pronged options are displayed.
  8. Enter the Write-off and Merchant liable amounts such that the sum of Pre-compliance amount, write-off amount and merchant liable amount does not equal to the dispute amount.
  9. Fill in rest of the mandatory fields to initiate Pre-compliance and click Submit.
  10. Observe that system throws the error ‘Sum of the total multi-pronged amount and the pre-compliance amount should be equal to the dispute amount.’

Visa – Update to Pre-Compliance Response instructions

ApplicationSmart Dispute for Issuers
Scheme ImpactVISA
Functional CategoryPre-compliance Response
Reported IssueIn Smart Dispute for Acquirers application, when Acquirer receives inbound Pre-compliance response, the instructions for Process pre-compliance response assignment are incorrectly displayed as Assigned to VCR Acquirer to ‘dgdfgdg’.
Smart Dispute ImplementationUpdated flow ProcessPreCompResp to add proper instructions on 'Process Pre-compliance response' assignment.
How to test the functionality
  1. Create an outbound Pre-compliance case from Smart Dispute for Acquirers application.
  2. When Pre-compliance response is received from Issuer, case lands on 'Process Pre-compliance response' assignment.
  3. Verify the instructions are properly logged in Audit tab as Assigned to VCR Acquirer to ‘Process pre-compliance response’.

Visa – Cancelled Recurring Transaction questionnaire

ApplicationSmart Dispute for Issuers
Scheme ImpactVISA
Scheme ReferenceIES for Release 23.1_Pub 12.16.22
Dispute ReasonCancelled Recurring Transaction
Functional CategoryDispute Questionnaire
Reported IssueAs part of 23.1 Compliance, in Cancelled Recurring transaction questionnaire, ‘Cancellation date’ label was updated to "Date cardholder withdrew permission to charge the payment credentials" for all jurisdictions. However, this change is only applicable for jurisdictions other than Europe.
Smart Dispute ImplementationCreated the below rules to update label, information message and validation message:

EnterCancelOrAcctClosureDateForVE – Message

CancelDateWhenVEDomestic – Field value

CancelOrAcctClosureDateForVEDomestic – Field value

Updated above rules in CustomerDisputeQuestionnaireCR section and ValidateCRQuestionnaire validate rule.
How to test the functionality
  1. Create a VCR dispute (Europe regional or domestic).
  2. In Qualify dispute screen, select I cancelled the recurring transaction as dispute reason.
  3. Verify information message is displayed as “Provide either cancellation date or date issuer informed merchant of account closure, not both “and label as “Cancellation date” for date field.

Visa – Other Fraud – Card Absent Environment (10.4) dispute validation for fully authenticated U.S. domestic token transactions

ApplicationSmart Dispute for Issuers
Scheme ImpactVISA
Scheme ReferenceU.S. Domestic Token Transactions in High-Risk MCCs Will Continue to Have Issuer Fraud Dispute Rights, Regardless of ECI Classification
Dispute ReasonOther Fraud – Card Absent Environment (10.4)
Functional CategoryDispute Validations
Reported IssueAs per Visa guidelines, Issuers will have dispute rights under ‘Other Fraud – Card Absent Environment (10.4)’ dispute sub-category for fully authenticated U.S. domestic token transactions irrespective of electronic commerce indicator (ECMOTO) value in case of high-risk merchants. The below merchant category codes (MCCs) are considered as high-risk merchants: 4829, 5967, 6051, 6540, 7801, 7802, 7995.

For non-US transactions, irrespective of merchant category code, the dispute validation outcome should evaluate to ‘Fail’ when ECMOTO value is 5.

Smart Dispute ImplementationIn when rule Eval_104_7, the logic string is updated such that the rule returns true for non-US transactions with ECMOTO value as 5.
How to test the functionality
  1. Create a VCR fraud dispute on a non-U.S. domestic fully authenticated token transaction (Electronic commerce indicator value – 05) performed at a high-risk merchant (MCC 4829).
  2. In Qualify fraud dispute screen, answer the questionnaire, and submit the fraud dispute.
  3. In Dispute Questionnaire screen, click on submit.
  4. For Other Fraud – Card Absent Environment(10.4) disputes, in the VCR tab  Dispute details: Dispute validations, observe the outcome of the below dispute validation as ‘Fail’:

    “A Secure Electronic Commerce Transaction processed with Electronic Commerce Indicator value 5 in the Authorization Request with exception of U.S domestic transactions conducted with high-risk merchants (MCC-4829, 5967, 6051, 6540, 7801, 7802, 7995)” .

Visa – Slowness in opening cases with huge attachments

ApplicationSmart Dispute for Issuers and Acquirers
Scheme ImpactVISA
Reported IssueAs an Issuer/Acquirer, when I open a claim case containing multiple disputes with attachments, it is observed that a considerable amount of time is taken for the case to load.

This is because, when I am trying to submit documents to Visa using SOAP services, Smart Dispute creates temporary pages to hold the attachment details.

These pages are not cleared after the related data has been pushed to the respective APIs.

As these temporary pages are not being removed in case of SOAP services, the attachment stream related data is getting pushed to BLOB and when user tries to load the case, it takes considerable amount of time which is leading to performance issues.

Smart Dispute ImplementationThe existing code base was referring the embedded page “DisputeAttachmentDescriptor” without prefix “.”

As part of fix in the Smart Dispute application, below change has been made:

Reference of “DisputeAttachmentDescriptor” embedded page in the API response data transforms are prefixed with “.” to remove “.DisputeAttachmentDescriptor” page.

Note: Please refer the rule inventory document for list of rules that are updated.
How to test the functionality
  1. Create a VCR dispute case.
  2. Submit Qualify dispute screen with any of the dispute reasons that fall under ‘Processing Errors’ or ‘Consumer Disputes’ category and complete the questionnaire.
  3. Submit Dispute questionnaire screen and proceed till Pre-Arbitration.
  4. Initiate Pre-Arbitration by attaching documents in the supporting document section and submit the case.
  5. User can verify performance by closing the case and opening it without any latency in case loading and all the documents attached should be available for the user on the dispute case.
  6. This could also be verified on the Clipboard: “DisputeAttachmentDescriptor” embedded page should not be present under pyWorkPage.
    Note: Slowness of case loading is applicable only for clients using Visa SOAP services.

Visa – Arbitration Association Ruling

ApplicationSmart Dispute for Acquirers
Scheme ImpactVISA
Functional CategoryArbitration Association Ruling
Reported IssueIn Smart Dispute for Acquirers application, when the Acquirer receives inbound Arbitration from Issuer, application waits at assignment ‘Review Inbound Arbitration’. When the association ruling is received from Visa, application should proceed further and wait at ‘Process Association ruling’. But the application is not resuming the assignment ‘Review Inbound Arbitration’
Smart Dispute ImplementationIn the activity GetInboundArbResponse,when condition in Step 9 is updated to ‘AssociationRuleGiven’.
How to test the functionality
  1. Create an inbound Consumer dispute Acquirer case and proceed till Inbound Arbitration from Issuer.
  2. Observe that the application waits at ‘Review Inbound Arbitration’ assignment.
  3. In the SLA escalation activity of the assignment ‘Review Inbound Arbitration’, application checks if the association ruling is given by Visa.
  4. When the association ruling is received from Visa, observe that the flow advances to ‘Process Association Ruling’.

Visa – Compliance Association Ruling

ApplicationSmart Dispute for Acquirers
Scheme ImpactVISA
Functional CategoryCompliance Association Ruling
Reported IssueIn Smart Dispute for Acquirers application, when the Acquirer initiates Compliance, application waits at assignment ‘Awaiting Final decision by Visa’. When the association ruling is received from Visa, application should proceed further and wait at ‘Process Compliance ruling’. But the application is not resuming the assignment ‘Awaiting Final decision by Visa’.
Smart Dispute ImplementationIn the flow ComplianceAssociationDecision, the SLA on the assignment ‘Awaiting Final decision by Visa’ is updated to ‘SLAForVCRComplianceRuling’. Created new SLA rule SLAForVCRComplianceRulingand new escalation activity rule GetComplianceFinalDecision. The activity GetComplianceFinalDecision resumes the flow action AwaitingAssociationRulingFromVisawhen the association ruling is received.
How to test the functionality
  1. Create an inbound Acquirer VCR dispute and initiate Compliance.
  2. Observe application waits at ‘Awaiting Final decision by Visa’ assignment.
  3. In the SLA escalation activity of the assignment ‘Awaiting Final decision by Visa’, application checks if the association ruling is given by Visa.
  4. When the association ruling is received from Visa, observe that the flow advances to ‘Process ComplianceRuling’.

Visa – Appeal Final Ruling

ApplicationSmart Dispute for Acquirers
Scheme ImpactVISA
Functional CategoryAppeal final ruling
Reported IssueIn Smart Dispute for Acquirers application, when the Arbitration final ruling is received in favor of the Acquirer, application should wait for Inbound Appeal from Issuer. The flow is not getting resumed when Issuer appeals for Arbitration final ruling as the passed deadline is not properly configured on the ‘Awaiting Issuer response’ assignment SLA.
Smart Dispute ImplementationUpdated time interval as 1 Day for passed deadline in ArbRulingForIssuerLiable SLA
How to test the functionality
  1. When the Arbitration final decision by Visa is received as Issuer liable, the Issuer can appeal for final ruling when the filing amount is greater than 5000 USD.
  2. Verify that the acquirer flow is resumed properly when Issuer appeals for final ruling.

Visa – Review inbound Cancelled Merchandise/Services dispute

ApplicationSmart Dispute for Acquirers
Scheme ImpactVISA
Dispute ReasonCancelled Merchandise or Services
Functional CategoryInbound Dispute Questionnaire
Reported IssueIn Smart Dispute for Acquirers application, when the Acquirer receives inbound Cancelled Merchandiseor Services dispute, ‘Did cardholder cancel before ship date?’question is not displayed in ‘Process incoming dispute’ screen.
Smart Dispute ImplementationUpdated GetDisputeDetailsResponse_CD_CSdata transform to map DidCardholderCancelBeforeShipping property.
How to test the functionality
  1. Create an inbound Cancelled Merchandise/Services Acquirer VCR dispute.
  2. In ‘Process incoming dispute’ screen, verify ‘Did cardholder cancel before ship date?’ is displayed properly.

Visa – Reset of flag ‘isChagebackProcessed’

ApplicationSmart Dispute for Acquirers
Scheme ImpactVISA
Dispute ReasonNA
Functional CategoryCompliance Association Ruling
Reported IssuePost dispute submission to Visa, if a multi-prong action of Write-off or Cardholder liable is taken at any stage later, the flag isChagebackProcessed is reset to blank. This is impacting reports referring to isChagebackProcessed flag.
Smart Dispute ImplementationIn SetTimelinesForDisputeTimeFrameExpiry data transform, mapping of property isChagebackProcessed is removed. The step isChagebackProcessed==”’ is commented in the data transforms SetCHLAmount and SetWOAmount.
How to test the functionality
  1. Create a VCR Consumer dispute case and proceed till Pre-Arbitration.
  2. Select Write-off or Cardholder-liable option and submit the case.
  3. Observe, the isChagebackProcessed has value in the clipboard.
  4. Verify reports referring to isChagebackProcessed now has fields populated

Visa – Cancelled Merchandise/Service Questionnaire

ApplicationSmart Dispute for Issuers and Acquirers
Scheme ImpactVISA
Dispute ReasonCancelled Merchandise/Service
Functional CategoryDispute Questionnaire
Reported IssueWhen a “Consumer Disputes-Cancelled Merchandise/Service” dispute is submitted to Visa with the below questionnaire, Visa is throwing error that 'Was a cancellation policy provided?' field is mandatory.

What was purchased? - Merchandise

Did the cardholder receive the merchandise? - Yes

Was a cancellation policy provided? – Blank (optional field)

Error thrown from Visa:

E-200100002 One or more required fields are missing. Please correct the following errors: CancellationPolicyProvidedInd

Smart Dispute Implementation“Was a cancellation policy provided?” field is displayed as optional when “Did the cardholder cancel?” is answered as ‘Yes’ & “Did cardholder cancel before ship date?” is answered as ‘No’. Otherwise, this field is displayed as mandatory.

Created when rule IsCancellationPolicyIndReq, to add required when condition for “Was a cancellation policy provided?” field in CancellationRelatedQuestions section.

Note: There is a discrepancy observed in the Visa IES specification and the MTE2 behaviour for the question “Was a cancellation policy provided?”. A query is raised with Visa. This fix is provided to align with MTE2 observations and avoid production blockers during 22.2 October cut-over.
How to test the functionality
  1. Create a VCR dispute.
  2. In Qualify dispute screen, select “I cancelled the merchandise/service” in dispute reason dropdown.
  3. Select ‘Merchandise’ for the question “What was purchased?”.
  4. Select ‘Yes’ for the question “Did the cardholder receive the merchandise?”.
  5. Verify the Question “Was a cancellation policy provided?” is optional when “Did the cardholder cancel?” is Yes & “Did cardholder cancel before ship date?” is No.
  6. Answer the remaining questionnaire and click on submit.
  7. In Dispute Questionnaire screen, click on submit and verify that the dispute is successfully submitted to Visa.

Visa – Mapping of Pre-Compliance violation code for ‘Compliance Right for Improperly Assessed Surcharge’

ApplicationSmart Dispute for Issuers and Acquirers
Scheme ImpactVISA
Dispute ReasonNA
Functional CategoryPre-Compliance
Reported IssueIn Smart Dispute for Issuers application, Issuer is unable to submit Pre-Compliance with violation type ‘Compliance Right for Improperly Assessed Surcharge’ as Visa throws below RTSI error:

“E-121005201: Member submitted one or more invalid RuleViolatedCodes for the case jurisdiction and the supplied NetworkID. Please correct and resubmit.”

Smart Dispute ImplementationUpdated violation code from ‘C135’ to ‘C027’ for violation type ‘Compliance Right for Improperly Assessed Surcharge’ in MapViolationSource map value.
How to test the functionality
  1. Create a VCR dispute on a Canada domestic transaction.
  2. In Qualify dispute screen, select ‘I have another issue with this transaction’ dispute reason and submit.
  3. In Dispute questionnaire screen, select ‘Initiate Precompliance’ from ‘Other actions’ tab.
  4. In Initiate Pre-compliance screen, select violation type ‘Compliance Right for Improperly Assessed Surcharge’ and verify the pre-compliance is successfully submitted to Visa.

Visa – Mapping of IsChargeBackProcessed flag

ApplicationSmart Dispute for Issuers
Scheme ImpactVISA
Dispute ReasonNA
Functional CategoryNA
Reported IssueIn Smart Dispute for Issuers application, IsChargeBackProcessed flag is incorrectly set as ‘Y’ before dispute submission is successful.

Issuer is unable to process the disputes in bulk when the Issuer is re-routed to Dispute questionnaire screen to review delta associated transactions or to provide chip card information.

Smart Dispute ImplementationUpdated DisputeCreationFlow flow, SetDispCreationDetails data transform to set IsChargeBackProcessed flag as ‘Y’ after chargeback submission.

Updated UpdatedATRsExistatDQ and GetUpdatedAssocTrans activities to map DisputeQuestionnaireStage and DisputeInitStage property values for bulk dispute processing.

How to test the functionality
  1. Create a VCR claim with multiple transactions such that one transaction has delta associated transactions and another transaction requires chip card information post dispute questionnaire submission.
  2. Process Qualify dispute screen in bulk using ‘Other actions’ and proceed till Dispute Questionnaire screen.
  3. Process Dispute Questionnaire screen in bulk using ‘Other actions’.
  4. Verify the disputes are routed back to Dispute questionnaire screen in case of delta associated transactions or when additional chip card information is required.
  5. After reviewing the delta associated transactions or updating the chip card information in Dispute questionnaire, process the disputes in bulk again using ‘Process dispute questionnaire’ option in ‘Other actions’ menu.
  6. Verify ‘IsChargeBackProcessed’ flag is set to ‘Y’ only after chargeback submission to Visa.

Visa – Cancelled Merchandise/Services Dispute Questionnaire

ApplicationSmart Dispute for Issuers
Scheme ImpactVISA
Dispute ReasonCancelled Merchandise/Services
Functional CategoryDispute Questionnaire
Reported IssueIn Dispute Questionnaire screen, when user changes the dispute reason from Cancelled Merchandise/Services to any other reason, “Was a cancellation policy provided?” field is not reset.
Smart Dispute ImplementationClearVCRCancelledProps has been updated to remove following properties: CancellationPolicyProvidedInd, DidCardholderCancelBeforeShipping, CardholderReceiveMerchandiseInd.
How to test the functionality
  1. Create a VCR claim.
  2. In Qualify Dispute, choose “I cancelled the merchandise/service” as “Dispute reason” and “Merchandise” for “What was purchased?”
  3. Fill other details as necessary and submit.
  4. In Dispute Questionnaire screen, change the value in “Dispute is due to” from “Cancelled Merchandise/Services”.
  5. Now, choose “Dispute is due to” as “Cancelled Merchandise/Service” again and “Merchandise” for “What was purchased?”
  6. Choose ‘Yes’ as the answer for “Did cardholder receive the merchandise?”
  7. Ensure “Was a cancellation policy provided” is reset and does not retain old answers.

Visa – Batch Queue fixes for pxUpdateDateTime property when cases are resolved as ‘Resolved-AcqAccepted’

ApplicationSmart Dispute for Issuers
Scheme ImpactVISA
Dispute ReasonCancelled Merchandise/Services
Functional CategoryBatch Queue Processing – Acquirer Acceptance
Reported IssueWhen dispute cases are resolved as ‘ResolvedAcqAccepted’, pxUpdateDateTime property is not updated correctly.
Smart Dispute ImplementationDefer save in ResumeVCRFlow activity is modified to use OOTB activity RecalculateAndSave instead of ‘Obj-Save’ method so that all relevant OOTB system properties (such as pxUpdateOperator, pxUpdateSystemID etc.) are initialized appropriately.
Note: As part of RecalculateAndSave execution, additional OOTB system properties are also set.
How to test the functionality
  1. Create a Visa - Consumer Dispute and submit to acquirer for chargeback.
  2. When VROL case status is “Consumer Dispute – Accepted by Acq”, wait until case is resolved by VCR Issuer Process agents.
  3. Upon case resolution, ensure pxUpdateDateTime is updated with the latest case resolution timestamp.

Dispute Scenario VROL Case Status
Chargeback for Processing ErrorProcessing Error Dispute - Accepted by Acq
Chargeback for Consumer DisputeConsumer Dispute - Accepted by Acq
Pre-Arb for Processing ErrorProcessing Error Dispute - Pre-Arb Accepted by Acq
Pre-Arb for Consumer DisputeConsumer Dispute - PreArb Accepted by Acq
Pre-CompIss Pre-Comp - Accepted by Acq
Fraud ChargebackFraud Dispute - Accepted by Acq
Authorization Dispute ChargebackAuthorization Dispute - Accepted by Acq
Pre-Arb response for Fraud DisputesFraud Dispute - Pre-Arb Response Accepted by Acq
Pre-Arb response for Authorization disputes Authorization Dispute - Pre-Arb Response Accepted by Acq

Visa – Information message in Supporting Documents section

ApplicationSmart Dispute for Issuers
Scheme ImpactVISA
Scheme ReferencePage 42, Visa Resolve Online (VROL) Real Time Systems Interface Development Guide for Release 22.2
Functional CategorySupporting Documents
Reported IssueFor Visa Debit disputes, the message displayed under Supporting Documents is “Attachments with PDF,JPEG and TIFF formats are only supported” instead of “Attachments with JPEG and TIFF formats are only supported up to 10 MB file size. Attachment with PDF format is only supported up to 2 MB file size.”
Smart Dispute ImplementationVCRAttachments section in Visa Debit class layer has been updated to use the latest field value pyCaption • DisplayValidVisaAttachmentMessage.
How to test the functionality
  1. Create a claim for a Visa Debit transaction.
  2. In the dispute case, ensure that in all screens where Supporting Documents can be attached (Qualify Dispute, Dispute Questionnaire, Initiate Pre-arbitration etc.), “Attachments with JPEG and TIFF formats are only supported up to 10 MB file size. Attachment with PDF format is only supported up to 2 MB file size.” message is shown.

Visa – Audit history fixes

ApplicationSmart Dispute for Issuers
Scheme ImpactVISA
Scheme ReferenceNA
Functional CategoryArbitration – Audit History
Reported IssueIn Smart Dispute Issuers application, when Issuer submit a Visa case and performs Arbitration, in the audit history ‘DisputeFilingItemId’ is not mapped. However, this works for Compliance.
Smart Dispute ImplementationIn the data transform ‘PegaCard-Sd-Dispute-Visa SubmitDisputeFilingResponse’, the below steps are added:

Step 2: To capture Dispute Stage into a Param

Steps 6 and 7: Sets Param.TempFilingType based on the Service invoked (Arbitration / Compliance).

Step 8: Param.TempFilingType is passed to Param.FilingType which is a parameter to the data transform SetDisputeFilingItemId.
How to test the functionality
  1. Create a VCR dispute.
  2. Qualify the dispute by selecting any of the consumer disputes or processing errors related dispute reason.
  3. Process Dispute Questionnaire and proceed till Arbitration.
  4. Once the case is waiting at ‘Awaiting Arbitration acknowledgement’ screen, observe the Audit history for the below entry: “Case Filing has been successfully created with ID: ********”

Visa – Batch Queue fixes

ApplicationSmart Dispute for Acquirers
Scheme ImpactVISA
Scheme ReferenceNA
Functional CategoryInbound dispute for Acquirers
Reported IssueFor inbound dispute cases created through Acquirer batch queue agents, Goal and Deadline values are not getting set in disputes, at Case level “Overview” tab.
Smart Dispute ImplementationAdded steps 1 and 2 in CreateAcquirerCase activity where “pyWorkPage.pySLAName” property is assigned to ‘DisputeMainFlow’ SLA in first step and ‘DefineSLATimes’ activity is invoked in second step to execute SLA.
How to test the functionalityReview inbound Acquirer cases created through Acquirer agents and observe that Goal and Deadline values are displayed in ‘Overview’ tab of the Acquirer case.

Visa – Dispute response supporting documents for Paid by Other Means/Duplicate Processing

ApplicationSmart Dispute for Acquirers
Scheme ImpactVISA
Dispute ReasonPaid by Other Means/Duplicate Processing
Functional CategorySupporting Documents
Reported IssueWhen Acquirer accepts full liability on an inbound ‘Paid by Other Means’ or ‘Duplicate Processing’ dispute, application is displaying mandatory supporting documents.
Smart Dispute ImplementationThe logic in the when rule VCRConfig_Acquirer_DisputeResponse_Reason_ID is modified as below: ((A && B) && ((C || D || E || G) && M) || ((J && M) && (K || L) ))
How to test the functionality
  1. As an Acquirer, process an inbound ‘Paid by Other Means’ or ‘Duplicate Processing’ dispute.
  2. Select Acquirer response as ‘Accept fully’ in Process inbound dispute screen.
  3. Verify application displays assignment Capture Acquirer Response.
  4. Process the assignment with Acquirer response as ‘Accept fully’.
  5. Verify documents are not displayed in the Supporting Documents section.

Visa – Enabling Multipart message structure for Contact Message Response

ApplicationSmart Dispute for Issuers and Acquirers
Scheme ImpactMCOM
Dispute ReasonNA
Functional CategoryContact Message
Reported IssueSubmitContactMessageResponseOperation REST service when invoked with/without attachments errors out as shown below.

"E-300100000 : Internal system error has occurred. Please contact your regional ROL Help Desk.

SubmitContactMessageResponseOperation is not supported for multipart message structure in the OOTB application. As per Visa, attachments must be sent as part of multipart request.

Smart Dispute Implementation"SubmitContactMessageResponseOperation" is added as a condition in the when rule “SendMultiPartRequest” of class “@baseclass”.
How to test the functionality
  1. Create a VCR dispute.
  2. Proceed until Arbitration and submit the Arbitration.
  3. Once this is done, at the “Awaiting Arbitration acknowledgement”, we can see a parallel assignment “Wait for Contact Message”.
  4. Once the “Wait for Contact Message” assignment gets submitted, at the “Respond to Case Filing Contact Message”, try to submit the assignment with and without attachments and the assignment should be submitted without any error messages.

Visa – Acquirer Transaction Inquiry

ApplicationSmart Dispute for Acquirers
Scheme ImpactVISA
Dispute ReasonNA
Functional CategoryTransaction Inquiry
Reported IssueIssue 1:

In the Acquirer case, when the operator clicks on ‘More details’ link in ‘Transaction’ tab, Visa transaction inquiry RTSI service SubmitDisputeQuestionnaireOperation is invoked. If the response from Visa is asynchronous, i.e., if TIEventID is received, then application creates a parallel assignment ‘Retry’ which automatically triggers RTSI services GetTransInquiryResultsOperation and GetTransDetailsOperation to fetch the transaction inquiry results upon the assignment deadline expiry. The SLA AsyncTIWaitDateTimeSLA on the ‘Retry’ assignment is not advancing the flow action when the deadline is passed.

Issue 2:

The transaction inquiry details received from Visa are not getting persisted in the Acquirer case.

Smart Dispute ImplementationThe activity PegaCard-Sd-DisputeAcq InvokeAcquirerTI is updated to remove steps related to Property-Set of ‘.InvokedAcquirerTI’, ‘.AcquirerTISuccessful’. Steps 5, 6 and 7 are newly added.
How to test the functionality
  1. Create a VCR Acquirer case.
  2. Simulate the response of RTSI service SubmitDisputeQuestionnaireOperation such that ‘TIEventID’ is received instead of ‘RolTransactionId’. This is required to simulate asynchronous transaction inquiry response.
  3. In the ‘Transaction’ tab of the Acquirer case, click on ‘More details’ link.
  4. Observe that there are no details populated in Additional transaction details section in ‘Transaction’ tab.
  5. Refresh case assignments to see ‘Retry’ assignment.
  6. Wait until the ‘Retry’ assignment is processed and verify that Additional transaction details are available in ‘Transaction’ tab.

Visa – Mapping of Outstanding amount in VCR tab

ApplicationSmart Dispute for Issuers
Scheme ImpactVISA
Dispute ReasonNA
Functional CategoryPre-Compliance
Reported IssueIn the VCR tab, under ‘Pre-compliance response details’ section, ‘AmountOutstanding’ is displayed as a negative value when the Pre-Compliance is partially accepted by the Acquirer.
Smart Dispute ImplementationIn the data transform GetDispPreCompRespDetRes, Param.PreCompAmount is set in step 3 and current parameter page is passed in step 4.

In the data transform SetAmountOutstandingPreCompResponse, step 1 is added to check Param.PreCompAmount ==””.

How to test the functionality
  1. Create a VCR dispute.
  2. Process Qualify dispute screen by selecting any dispute reason.
  3. In Dispute Questionnaire screen, select ‘Initiate PreCompliance’ option from ‘Other Actions’ tab.
  4. Simulate Pre-Compliance response such that the Pre-Compliance is partially accepted by the Acquirer.
  5. Review the Pre-Compliance response and verify AmountOutstanding value is displayed properly in ‘Pre-compliance response details’ section of VCR tab.

Visa – Validation on Pre-Compliance Amount

ApplicationSmart Dispute for Issuers
Scheme ImpactVISA
Dispute ReasonNA
Functional CategoryPre-Compliance
Reported IssueWhen Pre-Compliance amount is entered as zero in Initiate Pre-Compliance screen, then application is throwing invalid error as ‘Total multi-pronged amount should be equal to the dispute amount.
Smart Dispute ImplementationIn the activity PegaCard-Sd-DisputeVisa- PostSubmitInitiatePreComplianceVCRIssuer, step 1 is added to set page-set message ‘PreCompAmountZeroErrMsg’ when the Pre-Compliance amount is zero.
How to test the functionality
  1. Create a VCR dispute.
  2. Process Qualify dispute screen by selecting any dispute reason.
  3. In Dispute Questionnaire screen, select ‘Initiate PreCompliance’ option from ‘Other Actions’ tab.
  4. Enter Pre-Compliance amount as zero, answer the Pre-Compliance questionnaire and submit the screen.
  5. Verify the error message ‘Pre-Compliance amount should be greater than zero.’ is displayed.

Visa – Batch Queue fixes (Other Queue)

ApplicationSmart Dispute for Acquirers
Scheme ImpactVISA
Dispute ReasonNA
Functional CategoryBatch Queues
Reported IssueAs an Acquirer, when the Acquirer case is waiting at any stage for inbound response from Issuer and the case status received in the GetBatchQueueOperation for the Acquirer/Dispute case does not match with the case statuses configured in Smart Dispute for Acquirers application, then the cases are routed to ‘Other queue’.

In such cases, the Acquirer is unable to open the Acquirer cases because the DATA-ADMIN-DB-TABLE for OtherQueue class is missing in the Acquirer application.

Smart Dispute ImplementationThe below rules are added in the package:

DATA-ADMIN-DB-TABLE PEGACARD-INT-VISAOTHERQUEUETYPE

DATA-ADMIN-DB-TABLE PEGACARD-INTERFACE-MC-MCOMCM-RETRIEVERECONREPORT

The data transform MapDQueueItems is updated to map the properties Jurisdiction and Dispute amount properly.

How to test the functionalityObserve that the batch queue records are moved to Other queue table when the incoming case status in the batch queue item does not match with the status values configured in the decision table ‘CheckIfQueueCanBeProcessedInSDForAcquirer.

Visa – Mapping of Transaction details after receiving Pre-arbitration Response

ApplicationSmart Dispute for Acquirers
Scheme ImpactVISA
Dispute ReasonNA
Functional CategoryPre-arbitration
Reported IssueWhen the Pre-arbitration response is received, the transaction data on pyWorkPage.AssociationData is erased.
Smart Dispute ImplementationIn the data transform PegaCard-Sd-Dispute-VisaGetDisputePreArbResponseDetailsResponse, Param.SourcePage is updated from steps 1.13 to 1.17.
How to test the functionality
  1. Process a VCR Acquirer fraud case.
  2. In Process incoming dispute screen, select action as ‘Initiate Pre-arbitration’ and complete the Prearbitration questionnaire.
  3. Observe case waits as ‘Awaiting issuer response for Pre-arbitration’ assignment.
  4. When the Pre-arbitration response is received, observe that transaction details are available in the clipboard page ‘pyWorkPage.AssociationData’.

Visa – Inbound dispute questionnaire for Duplicate Processing(12.6) and Merchandise/Services Not Received(13.1)

ApplicationSmart Dispute for Acquirers
Scheme ImpactVISA
Dispute ReasonNA
Functional CategoryInbound Dispute Questionnaire
Reported IssueIssue 1:

In ‘Process incoming dispute’ screen, the below questionnaire element is not visible for Duplicate Processing (12.6) disputes even though the details are received in RTSI response of GetDisputeDetailsOperation: Is the other transaction for the same merchant and on a different Visa Card owned by the same Issuer/Cardholder?

Issue 2:

In the ‘Process incoming dispute’ screen, the below questionnaire element is not visible for Merchandise/Services Not Received (13.1) disputes even though the details are received in RTSI response of GetDisputeDetailsOperation:

Explanation of dispute initiated prior to the expected delivery date

Smart Dispute ImplementationIn section rule PegaCard-Sd-Dispute-VisaDorPQuestionnaire, the visibility condition in dynamic layout 1.1 is updated.

When rule PegaCard-Sd-Dispute-VisaWhenExpectedReceiptDateIsInFuture is updated.

How to test the functionalityScenario 1:
  1. Process a VCR Acquirer Duplicate Processing-12.6 dispute
  2. In Process incoming dispute screen, when ‘Are both transactions for the same merchant and on the same card?’ is received as ‘Yes’, then verify the question

    ‘Is the other transaction for the same merchant and on a different Visa Card owned by the same Issuer/Cardholder?’ is displayed.

Scenario 2:

  1. Process a VCR Acquirer Merchandise/Services Not Received-13.1 dispute
  2. In Process incoming dispute screen, when ‘What was the last expected receipt date?’ is received as a future date, then verify the question

‘Explanation of dispute initiated prior to the expected delivery date’ is displayed.

Visa – Audit tab fixes for Pre-Compliance

ApplicationSmart Dispute for Acquirers
Scheme ImpactVISA
Dispute ReasonNA
Functional CategoryPre-Compliance
Reported IssueWhen Acquirer receives inbound Pre-compliance response, the instructions for ‘Process pre-compliance response’ assignment are incorrectly displayed as Assigned to VCR Acquirer to ‘dgdfgdg’ in audit history.
Smart Dispute ImplementationUpdated flow ‘ProcessPreCompResp’ to add proper instructions on 'Process Pre-compliance response' assignment.
How to test the functionality
  1. Create a VCR Acquirer collaboration dispute.
  2. In Process incoming dispute screen, select ‘Accept and Initiate Pre-Compliance’ option.
  3. Submit Initiate Pre-Compliance screen and observe that case waits at Awaiting Pre-Compliance response assignment.
  4. When Pre-Compliance response is received from Issuer, the case advances to 'Process Pre-compliance response' assignment.
  5. Verify the instructions are properly logged in Audit tab as Assigned to VCR Acquirer to ‘Process precompliance response’.

Visa – Appeal final ruling

ApplicationSmart Dispute for Issuers and Acquirers
Scheme ImpactVISA
Dispute ReasonNA
Functional CategoryNA
Reported IssueWhen a VCR Issuer dispute case waits at 'Awaiting Final decision by Visa’ assignment, the SLA configured on the assignment verifies if final decision ruling is received from Visa or not. If the appeal final ruling is received, then the RTSI service GetDisputeFilingDetailsOperation is invoked. DisputeFilingItemID parameter is incorrectly passed in the request
Smart Dispute ImplementationAdded new 2,4 & 6 steps in ‘GetFinalDecision’ activity to set latest ‘DisputeFilingItemID’ and removed existing 8 & 9 steps
How to test the functionality
  1. Create a VCR dispute and select any dispute reason in Qualify dispute screen.
  2. Complete Dispute Questionnaire screen and submit the dispute to Visa.
  3. Process the dispute through agents till appeal final ruling.
  4. At 'Awaiting final decision by Visa' assignment, let the SLA expire.
  5. When the final appeal ruling is received from Visa, observe that case resumes AwaitingAssociationRulingFromVisa flow action.
  6. Verify case lands at ‘Process appeal final ruling’ assignment

Visa – Incorrect API name in Third party tab

ApplicationSmart Dispute for Issuers
Scheme ImpactVISA
Dispute ReasonNA
Functional CategoryAssociated transactions at Dispute Questionnaire
Reported IssueWhen delta associated transactions are available at Dispute Questionnaire and user selects “Manage Associated Transactions” from other actions, the thirdparty tab shows incorrect service name. AssociatedTranSelectionOperation service is displayed instead of GetAssociatedTransactionListOperation service
Smart Dispute ImplementationIn VCRConnector activity, added 1st step to set ServiceKey property value based on parameter param.servicekey.
How to test the functionality
  1. Create a VCR dispute.
  2. Submit Qualify Dispute screen by selecting any dispute reason.
  3. Submit Dispute Questionnaire screen and ensure that there are delta associated transactions for the disputed transaction.
  4. Observe application stays on Dispute Questionnaire screen and an information message is displayed to review the delta associated transactions using Manage Associated Transactions option from Other Actions.
  5. Select Managed Associated transactions from Other Actions menu and submit.
  6. Verify GetAssociatedTransactionListOperation service is displayed first and then AssociatedTranSelectionOperation service call is displayed in third-party tab.

Visa – Process Acquirer Liability screen fixes

ApplicationSmart Dispute for Acquirers
Scheme ImpactVISA
Dispute ReasonNA
Functional CategoryPre-Arbitration
Reported IssueWhen an Acquirer case is at Inbound Pre-Arbitration screen, if the SLA expires, the case should route to Process Acquirer Liability screen. Acceptance amount is displayed as zero in the Process Acquirer Liability screen
Smart Dispute ImplementationIn AcquirerVCRPreArbFlow flow, FinReceivableOpenSTP sub-flow is added. PreArbAcceptanceAmount and AccountingAmount properties are set at the leading connector of SLA Breach decision shape that is after Record Pre-Arb response assignment.

In ResponseByAcq section, visible when condition is added in 2.2 dynamic layout and added layout 2.4.

How to test the functionality
  1. Create a VCR Acquirer collaboration case.
  2. In Process incoming dispute screen, select action as ‘Decline’ and submit the screen.
  3. Observe case is routed to Awaiting Issuer response assignment.
  4. When the inbound Pre-Arbitration is received from the Issuer, the assignment Awaiting Issuer response advances to Review Pre-Arbitration Details screen.
  5. If the Acquirer does not respond within the timeframe, observe the case is routed to Process Acquirer Liability screen.
  6. Verify acceptance amount is displayed properly in Process Acquirer Liability screen.

Visa – Error Handling - Display previous Assignment is not removed from dispute

ApplicationSmart Dispute for Issuers and Acquirers
Scheme ImpactVISA
Dispute ReasonNA
Functional CategoryVCR – Exception handling
Reported Issue

In a Visa dispute, when a technical exception is encountered while invoking Visa RTSI APIs, the case is routed to ProblemFlowWorkBasket. Upon retry when a business exception is encountered in the API, system creates a Display Previous Assignment instead of automatically routing the dispute to a valid previous assignment.

Smart Dispute ImplementationDisplayPreviousAssignment assignment in VCRRESTConnectionProblem and VCRSOAPConnectionProblem exception handling flows is configured as an auto-process assignment. The flow action resumed is DisplayPreviousAssignment which uses GoToPreviousTask GUI API as the post processing activity. The explicit commit performed in the GoToPreviousTask resulted in failure of flow level commit implicitly issued by Pega Platform, consequently resulting in Rollback and unexpected behaviour
How to test the functionality
  1. Create a VCR claim.
  2. Perform Qualify dispute by selecting any dispute reason.
  3. Ensure that Transaction Inquiry fails due to a technical exception.
  4. Observe that dispute lands into ProblemFlowWorkBasket.
  5. Open ProblemFlowWorkBasket assignment and click Submit to retry the API.
  6. Ensure that Transaction Inquiry fails due to a business exception.
  7. Observe that case is rerouted to Qualify dispute assignment.

Visa – Past disputes counter-based validation for Fraud disputes is not working properly when concurrent disputes are processed

ApplicationSmart Dispute for Issuers and Acquirers
Scheme ImpactVISA
Scheme ReferenceVisa Core Rules and Visa Product and Service Rules (October 2022) - Table 11-28: Dispute Condition 10.4: Other Fraud – Card-Absent Environment – Invalid Disputes Pg. 952
Dispute ReasonOther Fraud – Card Absent Environment (10.4)
Functional CategoryDispute Validations
Reported Issue

When multiple 10.4 fraud disputes are processed concurrently, either through bulk processing from Claim or through STP from Web Self Service(WSS) API, the past disputes counter (DisputesLimit) is stale resulting in incorrect outcomes for the below dispute validation:

A Transaction on an Account Number for which the Issuer has initiated more than 35 Disputes within the previous 120 calendar days

Smart Dispute ImplementationThis counter-based validation was performed only once in the dispute lifecycle in EvaluateDisputeValidations utility. However, when disputes were submitted to association concurrently within a single interaction (bulk processing from Claim or STP through WSS API), D_GetpastDisputes was not reloaded resulting in incorrect counter. This scenario is handled by reloading the data page for every dispute in SetFlagsBasedOnPastDisputes data transform.

In addition, when a dispute awaits in an assignment on or after Dispute Validations but before SubmitDisputeQuestionnaire API is successful, other disputes for the same customer account could be submitted to chargeback resulting in counter exceeding the threshold. In such cases where the updated counter makes the dispute ineligible for chargeback will have to be reviewed by the user. This is handled by reverifying such dispute validations that have the potential to become stale over time. This reverification is performed immediately after Dispute Validations and before SubmitDisputeQuestionnaire API invocation using the new utility ReverifyStaleDisputeValidations.

How to test the functionality
  1. Create two VCR disputes for an account that already has 34 chargebacks in the past 120 days.
  2. Using claim level bulk actions, process both the disputes and submit to Association.
  3. Observe that, one dispute should be successfully submitted Association and is routed to Awaiting Acquirer Response while the other is routed back to Dispute Validations and the outcome of 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 FAIL.
  4. Audit messages are added indicating a change in the dispute counter and the need for reviewing Dispute Validations.

Visa – VCR Configurations - Batch Queue Debug tool is inaccessible

ApplicationSmart Dispute for Issuers and Acquirers
Scheme ImpactVISA
Scheme ReferenceNA
Dispute ReasonAll
Functional CategoryVCR configurations
Reported IssueIn the VCR Configurations landing page, VCR Batch Queue Debug Tool is showing a blank page.
Smart Dispute ImplementationThe page context to render Batch Queue Debug tool section is not loaded due to incorrect loading data transform for VCR Configuration option in SmartDisputeConfigurations navigation rule.

The data transform has been corrected to PreVCRConfigurations.

How to test the functionality
  1. Log in as System Administrator (Dev Studio).
  2. Click Dev StudioSmart Dispute ConfigurationsVCR Configurations.
  3. In the Configurations landing page that loads, click VCR Batch Queue Debug Tool.
  4. System administrator should be able to choose batch queue(s) and review the items in the respective queue(s).

AMEX issues addressed in this release

The following is a list of AMEX 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.

AMEX – Pre-Compliance response fixes

ApplicationSmart Dispute for Issuers and Acquirers
Scheme ImpactAMEX
Reported IssueIn Record Pre-Compliance Response screen, when the Issuer selects acquirer response as ‘Reject’ and action code as ‘Write-off’, application is throwing the below error:

“Case has been resolved as Write-Off” is too long maximum length allowed is 32.

Smart Dispute ImplementationIn the flow rule PegaCard-Sd-Dispute-AMEX- OutboundWriteOff , the utility ‘Update Status’ is updated with the below parameter values: Param.ConfirmationNote==”Case has been resolved as Write-Off” Param.StatusWork=="Resolved-WriteOff" .
How to test the functionality
  1. Create an AMEX dispute case.
  2. Submit Qualify dispute screen with dispute reason code as “I was charged/credited incorrectly” and dispute sub-reason as “Currency discrepancy”.
  3. Process until chargeback and “Reopen” the dispute with resolution solution as “Representment”.
  4. Process Representment documents screen.
  5. Select Representment code as “General - invalid Chargeback (2000)” and process inbound representment.
  6. At initiate Pre-Compliance, select Type of violation as “Missing Required Transaction Information and submit”.
  7. At Record Pre-Compliance response screen, select Acquirer response as “Rejected” and Action code as “Write-Off”.
  8. Case should be resolved as “Resolved-WriteOff”.

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.

Ethoca – Transaction amount and currency mapping

ApplicationSmart Dispute for Issuers
Scheme ImpactEthoca
Functional CategoryEthoca dispute processing
Reported IssueAs an issuing disputes operator, when I submit a dispute eligible for Ethoca (third party dispute resolution network), transaction amount and transaction currency fields in CreateEthocaCase API are incorrectly mapped to posted amount and currency respectively.
Smart Dispute ImplementationIn data transform PegaCard-Sd-Dispute- InitiateCreateEthocaCase, steps 1 and 4 have been updated with values:

Param.amount = @(Pega-RULES:String).trim(.AccountTransaction.TransactionAmount)

Param.currency = @(Pega-RULES:String).trim(.AccountTransaction.TransactionCurrencyDesc).

How to test the functionality
  1. ConfigureSmart Dispute ConfigurationsThird Party Resolution Network Panel, enable Third party dispute resolution network.
  2. Create a Mastercard dispute case.
  3. Submit Qualify dispute screen with any of the dispute reason.
  4. Verify request and response of API CreateEthocaCase in Third party tab. The values mapped for amount and currency should be the Transaction amount and Transaction currency.

On-Us eligibility for Fraud disputes

ApplicationSmart Dispute for Issuers
Scheme ImpactVISA, MCOM
Functional CategoryOn-Us
Reported IssueOn-Us processing eligibility is applicable when DSS EnableOnUS is enabled. However, even On-Us processing is disabled in the DSS rule EnableOnUS, application is routing Fraud cases to On-Us processing after submitting Qualify fraud dispute screen.
Smart Dispute ImplementationIn PostQualifyFraudDisputes data transform, removed CheckCaseLock activity check and updated when condition as below :

(@Default.PageExists("pyWorkCover")) && pyWorkCover.OnUsTransaction==true

How to test the functionality
  1. Create a MCOM Fraud dispute which is not eligible for On-Us (Disable On-Us via DSS).
  2. Submit Qualify fraud disputes screen.
  3. Verify the case should not route to On-Us flow

Currency code mapping for EUR

ApplicationSmart Dispute for Issuers
Scheme ImpactAll
Reported IssueIn Smart Dispute for Issuers application, Europe currency code is incorrectly mapped in CurrencyTypeMapping.
Smart Dispute ImplementationIn PegaCard-Sd-Dispute- CurrencyTypeMapping map value rule, the numeric currency code for EUR is updated.
How to test the functionality
  1. Create a dispute on a Europe transaction.
  2. Verify the currency is displayed as EUR throughout the dispute case lifecycle.

Regulation E fixes when Cardholder is made liable

ApplicationSmart Dispute for Issuers
Scheme ImpactAll
Functional CategoryRegulation E
Reported IssueWhen Reverse Provisional Credit assignment SLA is 3 days and Wait for Reg E Final 45/90 assignment SLA is 2 Days, application sends Final Credit Letter after completing “Wait for Reg E Final 45/90” assignment by stating that the provisional credit is final. However, post completion of Reverse Provisional Credit assignment, application sends another communication that the provisional credit will be reversed for ACH transactions.

When reverse provisional credit is initiated for Cardholder liable scenarios, application should not make the provisional credit as final.

Smart Dispute ImplementationUpdated ‘PegaCard-Sd-Debit WaitForRegEFinal45’ , “PegaCard-Sd-Debit WaitForRegEFinal90” flow rues and “MakeProvisionalCreditFinalForDispute” activity so that the provisional credit is not made final when Reverse Provisional credit assignment is available in the dispute case.
How to test the functionality
  1. Create a Regulation-E eligible dispute on an ACH transaction.
  2. Select any dispute reason in “Return code advisor” screen and submit “Select charge fees” screen.
  3. Observe that application displays “Verbal Attestation”, “Wait for Reg E Final 45/ 90“, and “Give Provisional Credit” assignments.
  4. In Verbal Attestation screen, select ‘No’ for “Do you wish to attest that this transaction for XXX.00 / USD was debited from your account on MM DD, YYYY and it was not authorized or was processed in error?” and submit.
  5. Submit “Give Provisional Credit” parallel assignment to provide provisional credit to the Cardholder.
  6. In “Completed ACH Case Investigation” screen, select ‘No’ for “Did an error occur?” question and “Confirm Investigation Completion” by selecting the checkbox and submit.
  7. Verify “Wait for Reg E Final 45/90” and “Reverse Provisional Credit” parallel assignments are available in the dispute.
  8. Submit “Wait for Reg E Final 45/90” assignment and verify audit message at audit history tab as “Provisional Credit processed on the account will not be made final as Reverse Provisional Credit has been initiated for the dispute”.
  9. Verify case is resolved as “Resolved-Cardholder liable” after completion of “Reverse Provisional Credit” assignment SLA and the provisional credit is reversed

Legacy rule fixes

ApplicationSmart Dispute for Issuers
Scheme ImpactAll
Functional CategoryNA
Reported IssueWhen the user runs application validation, system throws error for legacy rules which are not used in the application.
Smart Dispute ImplementationProvided fix for invalid rules as part of this fix and withdrawn few of the legacy rules which are not being used in Smart Disputes 8.7 application.
How to test the functionality
  1. Create a VCR/MCOM/AMEX case.
  2. Test the end-to-end case lifecycle.
  3. User should not receive any error while processing the case.

MCOM – Audit history

ApplicationSmart Dispute for Issuers
Scheme ImpactMCOM
Functional CategoryAudit
Reported IssueIn Review Dispute validations screen, when the operator selects Write-off or Cardholder Liable option and resolves the case, then application is displaying the below audit entries twice: Status changed to Resolved-CardHolder Liable Status changed to Resolved-WriteOff
Smart Dispute ImplementationModified the flows CHLiableAcctg and WriteOffAcctg to remove the audit note in SetConfirmationNote
How to test the functionality
  1. Create a MCOM Dispute and process till Review Dispute validations screen.
  2. Select Write-off option and resolve the case 10. Observe that the audit note “Status changed to Resolved-WriteOff” is not captured twice.

MCOM – Exception handling for Gateway Exceptions/MCOM Outages

ApplicationSmart Dispute for Issuers
Scheme ImpactMCOM
Functional CategoryMastercom API Connectivity – Exception handling
Reported IssueIssue 1:

When there is a Gateway error in any MCOM services, the response payload did not comply with the structure used for parsing. Hence, system threw an exception. When this issue is encountered for TranSearch API, Smart Dispute showed the exception to end user and MCOM Service Error assignment was not created.

Issue 2:

When such gateway error was returned due to MCOM Outage for other scenarios such as Create Chargeback, Get Claim etc., the API response processing abruptly exited without completing the error handling steps. Existing logic is such that, if the response does not indicate failure, then it is treated as Success and case continues processing. This resulted in the APIs taking the success path although the response was not processed.

Smart Dispute ImplementationIssue 1:

As part of the fix, the response parsing structure has been updated in the data transform MapJSONErrorToPage.

Issue 2:

The logic to find API errors has been made more robust by relying on the HTTP Response Code and the status returned by the MasterCom APIs. Also contrary to existing logic, when the response does not indicate success, it is evaluated to Fail scenario to ensure users are always kept aware in the event of any error(s). The users can examine the errors and take necessary actions to resume the dispute.

How to test the functionality
  1. As a pre-requisite, you must configure your API in such a way that it returns Gateway errors. Following article from MasterCom shows various Gateway errors : Gateway Error Codes | Mastercard Developers Platform.
  2. Turn off the MCOM simulations from the MCOM Claims Manager Configurations landing page.
  3. Create a MCOM dispute.
  4. Qualify the dispute and submit.
  5. Observe that when TranSearch API fails due to Gateway error, system creates MCOM Service Error assignment.
  6. Now disable Gateway errors and retry TranSearch API so that case moves forward to Answer Ancillary Questions.
  7. Enable Gateway errors and submit to the dispute to Chargeback.
  8. Observe that the case is routed to appropriate MCOM Service Error assignment.

MCOM – Cases moving to Process Liability

ApplicationSmart Dispute for Issuers
Scheme ImpactMCOM
Scheme ReferenceAN 5483 Revised Chargeback Standards for Travel or Entertainment Services Not Provided
Functional CategoryTimeframes
Reported IssueWith the latest implementation of AN 5483 as part of 22.1 compliance, the 4853CC2 (Not as described) cases are moving to process liability even though the timeframes have not expired. This happens for transactions which are not US/Canada/China domestic transactions.
Smart Dispute ImplementationUpdated data transform ‘SetTimelinesForDisputeTimeFrameExpiry’ to evaluate the timeframes for T&E transactions initiated after 22.1 correctly.
How to test the functionality
  1. Pick a T&E transaction which was posted after 22nd April 2022
  2. Create a MCOM Dispute on the transaction.
  3. Qualify the dispute as Not as described.
  4. Ensure the case is not moving to process liability if the dates are not crossing 120-day time limits.

MCOM – EBDR Form Fixes

ApplicationSmart Dispute for Issuers
Scheme ImpactMCOM
Dispute ReasonAll
Functional CategoryEBDR
Reported IssueFor pending transaction, the EBDR Form generated have dispute amount as blank and currency as USD for all cases. EBDR is also missing details when a fraud is converted to non-Fraud .
Smart Dispute ImplementationUpdated data transform ‘GetConditionCodeForMCOM’ to add steps 2.5.1.4 & 2.5.1.5.

Updated data transform ‘PrePickReasonCodeForMCom’ to add steps from 7.4.4 to 7.4.7. Updated activity ‘GetLongDesc’ to get rid of USD as default currency.

How to test the functionality
  1. Create a dispute on Pending Transaction.
  2. Once the transaction is posted submit the chargeback and verify the EBDR.
  3. The EBDR form should have all details.
  4. Verify the EBDR form when a dispute is qualified as Fraud and then submitted with non-fraud reason code.

MCOM – Label change on pre-arbitration screen

ApplicationSmart Dispute for Issuers
Scheme ImpactMCOM
Dispute ReasonAll
Functional CategoryPre-Arbitration
Reported IssueThe ‘Due Date’ field on pre-arbitration screen does not give a significant description of the information needed.
Smart Dispute ImplementationThe Label is updated to ‘Pre-arbitration response expected by’ to indicate the field indicating the date by when the issuer is expecting to receive a response or raise arbitration. Created a field value rule ‘PreArbDueDate’ to display the date field as ‘Prearbitration response expected by’.
How to test the functionality
  1. Create a MCOM Claim.
  2. Proceed till pre-arbitration stage and verify the label updated for Due date.

MCOM – Exception Handling Changes

ApplicationSmart Dispute for Issuers
Scheme ImpactMCOM
Dispute ReasonAll
Functional CategoryException Handling
Reported IssueIn MCOM application, when a service exception occurs on optional actions of Ancillary questionnaire like Create Fraud an exception handling assignment is created. When user clicks on back button on the exception assignment the ancillary questionnaire is going back to qualify dispute which is incorrect.
Smart Dispute ImplementationUpdated the current exception handling to delete the exception handling assignment for optional actions.
How to test the functionality
  1. Create MCOM Fraud Case and proceed till AQ Screen.
  2. Perform the Local action to submit Fraud Report.
  3. Ensure there is an exception received from MCOM.
  4. On the Exception handling click on Back Button.
  5. Verify the ancillary questionnaire assignment is unchanged and user is able to submit the chargeback.

MCOM – Provisional Credit Reversal Changes

ApplicationSmart Dispute for Issuers
Scheme ImpactMCOM
Dispute ReasonAll
Functional CategoryProvisional Credit
Reported IssueFor a Debit card disputes, the cardholder is been debited immediately when a credit is found in the merchant credit scenario.
Smart Dispute ImplementationUpdated AccountingforMerchantCredits flow for PC reversal..
How to test the functionality
  1. Create a RegE eligible MCOM claim.
  2. Process Qualify dispute and provisional credit.
  3. Now verify for merchant credits and ensure a credit is found.
  4. Now associate the credit and try to resolve the case.
  5. Verify the case moves to reverse PC assignment and gives 5 days’ notice to cardholder.

MCOM – Validation on attachment sent to Mastercard

ApplicationSmart Dispute for Issuers
Scheme ImpactMCOM
Scheme ReferencesMastercom User Guide, March 1st, 2022, Page 15
Dispute ReasonAll
Functional CategorySupporting Documents
Reported IssueAs per the Mastercom user guide, the attached document should not exceed 300 PPI. But SD system is allowing them under supporting documents due to which they’re being rejected by Mastercom.
Smart Dispute ImplementationUpdated field value rule ‘AttachmentsValidFormat’ to display the appropriate information message ‘Attachments with PDF, JPEG and TIFF formats up to 300 PPI resolution are only supported.’ under supporting documents.
How to test the functionality
  1. Create a MCOM Dispute.
  2. Verify the information message ‘Attachments with PDF, JPEG and TIFF formats up to 300 PPI resolution are only supported.’ Is displayed under supporting documents section.

MCOM – Documents not getting deleted

ApplicationSmart Dispute for Issuers
Scheme ImpactMCOM
Dispute ReasonAll
Functional CategorySupporting Documents
Reported IssueUser is unable to delete the documents added when user decides to change the reason code.
Smart Dispute ImplementationUpdated GetMCOMDocs Data Transform to enable deletion of user attached documents.
How to test the functionality
  1. Create a MCOM Dispute.
  2. At the Qualify dispute stage add a new document in supporting document section.
  3. Now change the reason code and verify the user added document is not visible when section is refreshed.

MCOM – Questionnaire Fixes

ApplicationSmart Dispute for Issuers
Scheme ImpactMCOM
Dispute ReasonAll
Functional CategoryQualify Dispute
Reported IssueWhen user selects, I do not recognize the transaction to qualify the dispute and answers the question 'Does this help you recognize the transaction?' as Yes, the case does not proceed forward even when the reason code is changed .
Smart Dispute ImplementationUpdated Data transform SetRCForDQ to clean up unnecessary values on clipboard.
How to test the functionality
  1. Create a MCOM Dispute.
  2. Select 'I do not recognize this transaction' as the dispute reason in Qualify Dispute screen.
  3. Answer Yes to 'Does this help you recognize the transaction?'.
  4. Change the dispute reason to any other, answer the respective questionnaire and Submit QD.
  5. Verify the case is going to Answer ancillary questions screen.

MCOM – 4834CC3 ATM Dispute Changes

ApplicationSmart Dispute for Issuers
Scheme ImpactMCOM
Dispute Reason4834 CC3
Functional CategoryChargeback
Reported IssueWhen user initiates a chargeback with 4834CC3 – ATM disputes, there is an option to also chargeback an access fee. However, when access fee is entered the dispute amount calculation is incorrect.
Smart Dispute ImplementationProvided an option for users to select the access fee currency in case of cross currency scenarios. Updated data transform ‘PrePickReasonCodeForMCom’ to calculate the dispute amount correctly when access fee is entered.

For some of the missing currencies like COP, updated Map Value rule ‘ConvertNumericCurrCodeToAlphabetic’ to accommodate all the valid currencies.

How to test the functionality
  1. Create a MCOM ATM dispute.
  2. Select a cross currency transaction which has ATM dispute.
  3. Select the dispute reason "I did not receive cash/received partial cash at ATM".
  4. Select the nature of dispute "Some or all of the funds debited from the cardholder’s account as the result of an ATM withdrawal were not dispensed".
  5. Select Is the Chargeback for the full amount of the original transaction? -- as Yes.
  6. Verify user is able to enter access fee and submit the chargeback. Verify the dispute amount.

MCOM – AN 5211 Revised chargeback standards for AFD transactions

ApplicationSmart Dispute for Issuers
Scheme ImpactMCOM
Scheme ReferenceAN 5211 Revised Chargeback Standards for Automated Fuel Dispenser in U.S. Region
Dispute Reason4808 CC1
Functional CategoryDispute validations
Reported IssueAs part of AN 5211, Mastercard has updated the amounts for 4808CC1 – Authorization not obtained chargebacks for AFD transactions.
Smart Dispute ImplementationUpdated 4808 1 rule, created MCC5542TxmAmtLT175 MCC5542TxmAmtLT500 when rules for new dispute validations on AFD transactions.
How to test the functionality
  1. Create a MCOM claim on a AFD transaction.
  2. Process the dispute with 4808 – 1 reason code.
  3. Verify the dispute validations are triggered based on the new article.

MCOM – Acquirer Pre-compliance timeframes

ApplicationSmart Dispute for Issuers
Scheme ImpactMCOM
Dispute ReasonAll
Functional CategoryPre-Compliance
Reported IssueFor Initiate Pre-Compliance, case does not go to process liability when time frame expires.
Smart Dispute ImplementationUpdated PreCompOutboundForMCOMAcq Flow for timeliness check.
How to test the functionality
  1. For an MCOM Acquirer Inbound dispute, Initiate a Pre-Compliance.
  2. Select the date of violation which is 120 days older.
  3. Verify on Submit the case moves to Process Liability.

MCOM – Accounting fixes

ApplicationSmart Dispute for Issuers
Scheme ImpactMCOM
Dispute ReasonAll
Functional CategoryAccounting
Reported IssueIssue 1:

When Cardholder liable option is selected in Process liability, accounting steps are missing in the ‘Accounting’ tab.

Issue 2:

When Cardholder liable option is selected in multipronged actions at Review second representment, the accounting steps are missing in the ‘Accounting’ tab.

Smart Dispute ImplementationUpdated accounting parameter for LowerDrCHCrR subflow (from DrCardHolderCrReceivableLower to LowerDrCardHolderCrReceivable ) in ‘DrCardHolderCrReceivableLowerFlow’ flow.
How to test the functionality
  1. Create a MCOM dispute.
  2. Submit Qualify Dispute with any dispute reason.
  3. At Dispute Questionnaire screen, select Process Liability from Other Actions menu.
  4. Select Cardholder Liable at Process Liability screen and submit.
  5. Verify accounting tab in footer for Cardholder liable accounting.

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 – Third Party Audit for Transaction Inquiry Service Call

ApplicationSmart Dispute for Issuers
Scheme ImpactVISA
Dispute ReasonI do not recognize this transaction (DNR)
Functional CategoryThird Party Audit
Reported IssueAt Qualify Dispute screen, when the dispute reason is selected as ‘I do not recognize this transaction’ and transaction details are retrieved, the service name for Transaction Inquiry Service is blank in ‘Third Party’ audit tab after dispute submission.
Smart Dispute ImplementationUpdated activity PegaCard-Sd-Dispute- .VCRConnector to set ServiceKey property value so that service name is displayed correctly in the Third Party audit tab.
How to test the functionality
  1. Create a VCR non-fraud case.
  2. In Qualify Dispute screen select 'I do not recognize this transaction' as dispute reason.
  3. Click on Retrieve transaction details button to get transaction details.
  4. Answer the questions as ‘Yes’ for "Do you believe your card or account number has been lost or stolen?" and "Do you want to continue as fraud?". Answer the remaining questions as ‘No’.
  5. Case will be routed to Qualify Fraud Dispute screen.
  6. Check if Service name is present, and services are logged properly in the ‘Third Party’ tab.

Visa – Incorrect mapping of Dispute Stage at Pre-arbitration

ApplicationSmart Dispute for Issuers
Scheme ImpactVISA
Functional CategoryPre-arbitration
Reported IssueWhen the Issuer receives inbound Pre-Arbitration from Acquirer, the VCRDisputeStage is not mapped properly.

When the dispute is at the review harness of Inbound Pre-arbitration assignment, the dispute stage is DisputeInit and when the assignment is opened, the dispute stage is PrearbRespIssuerInit. The VCRDisputeStage value should be consistent at any dispute stage.

Smart Dispute ImplementationUpdated the data transforms SetInitPreArbRespSLA and SetInboundPreArbResponseProperties to set VCRDisputeStage as ‘PrearbRespIssuerInit’.
How to test the functionality
  1. Create a VCR Fraud dispute and proceed till Dispute Questionnaire submission.
  2. Ensure Acquirer initiates Pre-Arbitration, and the Issuer receives the inbound Pre-Arbitration.
  3. Observe the dispute is at Inbound Pre-Arbitration assignment.
  4. Verify the value of VCRDisputeStage in the clipboard is ‘PrearbRespIssuerInit’.

Visa – Allowed formats for Supporting Documents

ApplicationSmart Dispute for Issuers
Scheme ImpactVISA
Functional CategorySupporting Documents
Reported IssueFollowing message under Supporting documents is confusing for PDF files: "Attachments with PDF, JPEG and TIFF formats are only supported up to 10 MB file size. Attachment with PDF format is only supported up to 2 MB file size".
Smart Dispute ImplementationThe message has been updated to "Attachments with JPEG and TIFF formats are only supported up to 10 MB file size. Attachment with PDF format is only supported up to 2 MB file size".
How to test the functionality
  1. Create a VCR dispute.
  2. Across the dispute lifecycle, wherever Supporting Documents can be added (Qualify Dispute, Answer Ancillary Questions, Initiate Pre-arbitration et al.), ensure the new message is reflected.

Visa – Pre-Arbitration details in VCR tab

ApplicationSmart Dispute for Issuers
Scheme ImpactVISA
Functional CategoryPre-Arbitration
Reported IssueApplication is displaying Pre-arbitration details in VCR tab before Pre-arbitration is submitted.
Smart Dispute ImplementationUpdated Activity ‘PostPreArbitrationQuestionnaire’ to validate sum of IssliabMPCHAmt and IssliabMPWOAmt to DisputeAmount before setting PreArbInitStage property value.
How to test the functionality
  1. Create a Visa dispute, proceed till dispute submission.
  2. The issuer receives the response from the acquirer when it is declined.
  3. At Process Acquirer Response, choose multiprong option and resolve the case as 'Split-Liability' without initiating Pre-Arbitration.
  4. Observe that VCR tab does not show the Pre-Arb details section.

Visa – Manage Associated Transactions

ApplicationSmart Dispute for Issuers
Scheme ImpactVISA
Functional CategoryDelta Associated Transactions at Dispute Questionnaire
Reported IssueWhen delta associated transactions are available at Dispute Questionnaire and user selects on Manage Associated Transactions from Other Actions, the user is unable to select credit transaction with Matching Score 100 and Match Pass 1 as the checkbox is disabled.
Smart Dispute ImplementationUpdated when rule ATR_Disable to disable checkbox for authorization transactions. Authorization transactions are evaluated using when rule WhenAuthTran.
How to test the functionality
  1. Create a VCR dispute.
  2. Submit Qualify Dispute screen by selecting any dispute reason.
  3. Submit Dispute Questionnaire screen and ensure that there are delta associated transactions for the disputed transaction.
  4. Observe application stays on Dispute Questionnaire screen and an information message is displayed to review the delta associated transactions using Manage Associated Transactions option from Other Actions.
  5. Select Managed Associated transactions from Other Actions menu.
  6. Identify a Credit transaction with Matching Score 100 and Match Pass 1, observe that the user can select the transaction.

Visa – Pre-Compliance Response Details in VCR Tab

ApplicationSmart Dispute for Issuers
Scheme ImpactVISA
Functional CategoryPre-Compliance Response
Reported IssueWhen the Issuer receives inbound Pre-Compliance response with partial acceptance and the Issuer initiates Compliance for the remaining dispute amount, Issuer Liable Amount under Pre-Compliance response section of VCR tab is getting updated.
Smart Dispute ImplementationUpdated data transform GetDispPreCompRespDetRes to set outstanding amount and acceptance amount. The amounts are mapped in SetAmountOutstandingPreCompResponse data transform. Updated section PreCompRespByAcqVCRTab to add AmountOutstandingPreCompRes instead of IssuerLiableAmount.
How to test the functionality
  1. Create a VCR dispute.
  2. Submit Qualify Dispute screen by selecting any dispute reason.
  3. In Dispute Questionnaire screen, select Initiate PreCompliance action from Other Actions menu.
  4. Submit Pre-Compliance and ensure that the Acquirer accepts the Pre-Compliance partially.
  5. After receiving Inbound Pre-Compliance Response from Acquirer, observe Pre-Compliance Response details in VCR tab.
  6. Verify Acceptance amount and Outstanding amount are properly displayed.
  7. Initiate Compliance with the remaining dispute amount and observe Pre-Compliance Response details are not updated in the VCR tab.

Visa – Dispute Response Details in VCR Tab

ApplicationSmart Dispute for Issuers
Scheme ImpactVISA
Functional CategoryDispute Response in VCR tab
Reported IssueWhen the Issuer receives Dispute Response as Accept Full, the dispute response details in the VCR tab are displayed twice.
Smart Dispute ImplementationUpdated visibility conditions for Dispute Response in section VCRTab_Dispute.
How to test the functionality
  1. Create a VCR dispute.
  2. Submit Qualify Dispute screen by selecting any dispute reason. Submit Dispute Questionnaire screen and observe dispute is waiting at
  3. Awaiting Acquirer Response screen.
  4. Ensure Acquirer accepts the dispute fully.
  5. Verify Dispute Response in VCR tab is displayed only once.

Visa – Manual Case Fixes

ApplicationSmart Dispute for Issuers
Scheme ImpactVISA
Functional CategoryManual Case
Reported IssueWhen user creates manual case and proceeds without attaching a transaction just by validating the details manually the visa service is failing as currency format is incorrect.
Smart Dispute ImplementationUpdated ValidateAndProceedWithManualCase Activity, for manual cases posted currency is converted to numeric value.
Instructions to CustomerComplete Manual case operation should be used only in exception cases. Transaction data manually entered by operators is error prone and cannot be validated against the original transaction.
How to test the functionality
  1. Create a Manual Case for Visa.
  2. Post Qualify dispute, select validate and proceed with manual case.
  3. Verify the user is able to submit the chargeback successfully to Visa.

Visa – Case status fixes

ApplicationSmart Dispute for Issuers
Scheme ImpactVISA
Functional CategoryCase Status
Reported IssueWhen the case is on dispute validations, the status captured in audit is incorrect.
Smart Dispute ImplementationOpen-ReviewValidations Field Value status is modified.
How to test the functionality
  1. Create a Visa Claim and proceed to Dispute Questionnaire.
  2. Submit the questionnaire and ensure case lands on dispute validations.
  3. Verify the Audit in the history tab shows as ‘OpenReviewValidations’.

Visa – Auto populate amounts on Process Liability

ApplicationSmart Dispute for Issuers
Scheme ImpactVISA
Functional CategoryProcess Liability
Reported IssueThe liability amount is not populated when write-off/ cardholder liable is selected in Process liability screen for Visa disputes.
Smart Dispute ImplementationUpdated Data transforms SetWOCHAmounts & ClearProcessLiabilityProps to populate the respective liability amounts for Write-off/ Cardholder liable.
How to test the functionality
  1. Create a Visa dispute and perform the process liability.
  2. Verify the respective Write-off amount/ Cardholder liable amount is populated when Write-off/ Cardholder liable check box is selected.

Visa – Field values for Brazil and Colombia

ApplicationSmart Dispute for Issuers
Scheme ImpactVISA
Functional CategoryCase Creation
Reported IssueWhile initializing Cardholder work party, if country code is not defined as pyCountry field value, system throws an error and acquirer dispute is not created.
Smart Dispute ImplementationCreated pyCountry Field Values for Brazil and Colombia countries
How to test the functionalityVerify Visa Acquirer case is created successfully for a Brazil or Colombia transaction.

Visa – EMV Liability Updates

ApplicationSmart Dispute for Issuers
Scheme ImpactVISA
Scheme ReferenceVisa Core Rules, April 2022, Page 182
Dispute Reason10.1 and 10.2
Functional CategoryFraud
Reported IssueEffective December 2021, Indonesia domestic ATM transactions are not exempted from EMV evaluation and hence should be removed from EMV exemptions.
Smart Dispute ImplementationConditions applied for Indonesia ATM transactions in When rules EMVExemptions and EMVExemptions_DV have been removed. Hence, Indonesia ATM transaction related disputes will also be evaluated against EMV Liability Shift related validations.
How to test the functionality
  1. Create a Visa claim on an Indonesia ATM transaction.
  2. Qualify the dispute as Fraud and submit.
  3. Based on the Fraud type chosen, verify the transaction is evaluated to 10.1 or 10.2.
  4. Ensure other conditions needed for 10.1 or 10.2 are satisfied to see that the fraud is qualified as 10.1 or 10.2 .

Visa – Information Message on attaching documents

ApplicationSmart Dispute for Issuers
Scheme ImpactVISA
Scheme ReferenceRTSI Dev Guide, Page 43
Dispute ReasonAll
Functional CategorySupporting Documents
Reported IssueAs per the Visa RTSI guide, the attached pdf document should not exceed 2 mb. The system is allowing them under supporting documents, and they are rejected by Visa.
Smart Dispute ImplementationUpdated the field value ‘DisplayValidVisaAttachmentMessage’ to ‘Attachments with PDF, JPEG and TIFF formats are only supported up to 10 MB file size. Attachment with PDF format is only supported up to 2 MB file size.’ to display the appropriate message under supporting documents.
How to test the functionality
  1. Create a Visa dispute.
  2. Verify the information message ‘Attachments with PDF, JPEG and TIFF formats are only supported up to 10 MB file size. Attachment with PDF format is only supported up to 2 MB file size.’ is shown under supporting documents section.

Visa – 10.3 Dispute validations update

ApplicationSmart Dispute for Issuers
Scheme ImpactVISA
Scheme ReferenceVisa Core Rules, April 2022, Page 930
Dispute Reason10.3
Functional CategoryDispute Validations
Reported IssueVisa has added a new condition under Invalid disputes for 10.3. Dispute is invalid if the transaction is an automated fuel dispenser transaction that occurred at a chip-reading device and merchant is in the U.S region.
Smart Dispute ImplementationA new Dispute validation rule using When rule Eval_103_13 has been defined under VCR Configurations > Dispute Validations for dispute category, Fraud and dispute sub-category, Other Fraud - Card Present Environment.
How to test the functionality
  1. Create a Visa dispute.
  2. Ensure the transaction is a AFD transaction carried out in U.S at a Chip Reading Device.
  3. Qualify the dispute as Fraud.
  4. Verify on submit of dispute questionnaire the case moves to dispute validation.
  5. The new Validation added should return a Fail outcome

AMEX issues addressed in this release

The following is a list of AMEX 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.

AMEX – Multiprong Option is not available in the Final Chargeback

ApplicationSmart Dispute for Issuers
Scheme ImpactAMEX
Dispute ReasonGoods and Services Not Received – 4554-3
Functional CategoryFinal Chargeback
Reported IssueWhen the user is trying to process final chargeback and reason code is changed to “Goods and Services Not Received - 4554”, Multiprong option is not available, and the user is unable to submit the chargeback.
Smart Dispute ImplementationUpdated MultiProngDisplayFinalChargeback decision table to add Svdf funds category as ‘False’ for 4554 reason code and 3 condition code. Within Section PegaCard-Sd-Dispute-AMEX-. RC4554CC3, for the radio button field .SVDFFundsCategory under the Actions tab for Click event, added ‘Refresh-Other Section’ as PegaCard-Sd-Dispute-AMEX-. FinalChargeBack.
How to test the functionality
  1. Create an AMEX case and proceed till Final Chargeback screen.
  2. Select ‘Yes’ for Do you want to change the reason code.
  3. Select Reason code and Condition code as ‘4554_SVDF-3’.
  4. Answer question Please select category as applicable as "Funds only partially loaded into SVDF".
  5. Enter ‘400’ in Enter the authorization amount (In posted currency) .
  6. Answer all other mandatory questions and submit.
  7. Observe that Multiprong details are displayed for process liability of 400.

AMEX: Accounting for Pre-compliance

ApplicationSmart Dispute for Issuers
Scheme ImpactAMEX
Dispute ReasonAll
Functional CategoryOutbound Pre-Compliance
Reported IssueIssue 1:

When user initiates Pre-Compliance before giving the credit to the cardholder, Accounting is being performed for provisional credit on submit initiate PreCompliance screen.

Issue 2:

When user enters Pre-Compliance amount less than dispute amount, there is no accounting for multiprong actions even user entered the write off or cardholder liable amounts in the initiate Pre-Compliance screen in all scenarios (Credit given or not given scenarios).

Issue 3:

After submitting the Pre-Compliance from issuer side, when user records the pre-Compliance response that he gets from Acquirer, and selected Acquirer response as Accept Partially, There is no accounting for Accepted Amount.

Smart Dispute Implementation
  1. InitiatePreCompliance Flow in AMEX is updated to handle Partial Pre-Compliance accounting when credit not given by checking flags for provisional Credit(.ProvisionalCredit) and Chargeback Processed(.IsChargeBackProcessed).
  2. PreComplianceOutbound Flow in AMEX is updated to remove the accounting for Pre-Compliance.
  3. Removal of FinHasOutstandingBalance check and SuspenseOpen sub flow was done as Accounting is not needed for Pre-Compliance.
  4. Accounting for Credit not given scenario in case of Granted and Granted Partially are considered.
  5. Updates to Activity PreComplianceGrantedPartial to handle Accepted Partial accounting in Credit not given scenario specific to AMEX in PegaCard-SdDispute-AMEX- class.
  6. Updates to Compliance Flow For AMEX to handle accounting when credit not given by checking flags for provisional Credit(.ProvisionalCredit) and Chargeback Processed(.IsChargeBackProcessed).
  7. FinalAccountingwithoutPC Flow rule was added to handle final ruling accounting without opening suspense in case credit not given to cardholder.
How to test the functionality
  1. Create an AMEX case.
  2. Proceed until Choose a reason code screen.
  3. Initiate Pre-Compliance from other actions.
  4. Enter the Pre-Compliance amount less than dispute amount. Select Multiprong actions for rest of the amount by giving Write off and Cardholder liable amounts.
  5. On Submit, as credit is not given to cardholder, accounting entry should be added for only Write off amount where amount should be debited from Write off account and credited to Cardholder.
  6. Process the case till Record Pre-Compliance response assignment.
  7. Select Accepted Partially as acquirer response, enter valid Accepted Amount by giving all necessary fields.
  8. On Submit, verify accounting entry is added for Accepted amount and verify accounting is proper.
  9. Run the flow till final ruling and verify Accounting is proper.
  10. Also verify accounting is as expected when PreCompliance is initiated after Representment and run till final ruling.

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.

Regulation E evaluations for DST to DMT claim conversion

ApplicationSmart Dispute for Issuers
Scheme ImpactAll
Dispute ReasonNA
Functional CategoryRegulation E
Reported Issue

When a new dispute is added to an existing claim with single dispute, Regulation E (Reg E) evaluations are not happening.

Smart Dispute ImplementationRegulation E evaluations for claims with multiple disputes (DMT – Dispute Multiple Transactions) are performed in the claim level and Reg E assignments are created in claim level whereas for claims with single dispute (DST – Dispute Single Transaction), the Reg E assignments are created in dispute level.

When a new dispute is added to a DST claim, since the Reg E assignments for the existing dispute are already created at dispute level, the Reg E assignments for the new dispute are also created at the dispute level. Application will not create any claim level Reg E assignments in case of conversion of DST to DMT claims.

How to test the functionality
  1. Create a claim with a single dispute such that the transaction is eligible for Reg E.
  2. Observe that the Reg E assignments are created at dispute level.
  3. Add a dispute to the claim by clicking on ‘Add multiple disputes to case’ button available in the review harness of the claim. This would convert the claim from DST to DMT.
  4. Observe that the Reg E assignments are created for the new dispute at the dispute level.

Regulation E eligibility

ApplicationSmart Dispute for Issuers
Scheme ImpactAll
Dispute ReasonNA
Functional CategoryRegulation E
Reported Issue

As per Regulation E guidelines, a transaction is Reg E eligible if the transaction falls within 60 calendar days from the last statement date (the date when the statement was made available to the cardholder). Application is evaluating the limit as 2 months instead of 60 calendar days.

Smart Dispute ImplementationFunction GetSecondLastStatementDate is updated.
How to test the functionality
  1. Create a dispute on a U.S. debit transaction that has occurred 62 days after the last statement was generated.
  2. Verify the dispute is not Regulation E eligible as the transaction did not happen within 60 days from the last statement date.

Process Liability for Regulation E disputes

ApplicationSmart Dispute for Issuers
Scheme ImpactAll
Dispute ReasonNA
Functional CategoryRegulation E
Reported Issue

Liability processing date field is displayed in Process Liability screen when Cardholder Liable option is selected for disputes without Provisional Credit. This field should be displayed only for disputes where Provisional Credit is already given. Liability processing date indicates that the given Provisional Credit will be reversed on that date. Hence, the field is not applicable for disputes without provisional credit.

Smart Dispute ImplementationIn the when rules starting with ‘ShowLiabilityProcessingDate’, a condition is added to check whether Provisional Credit is given or not.
How to test the functionality
  1. Create a VCR/MCOM Reg E eligible dispute.
  2. In Qualify Dispute screen, select any dispute reason and proceed till Dispute Questionnaire screen without giving Provisional Credit.
  3. In Dispute Questionnaire screen, select Process Liability from Other Actions menu.
  4. In Process Liability screen, select Cardholder Liable option and verify Liability processing date is not displayed on the screen.

ATM Questionnaire

ApplicationSmart Dispute for Issuers
Scheme ImpactAll
Dispute ReasonPartial Amount Received
Functional CategoryATM Dispute Questionnaire
Reported Issue

In Partial Amount Received questionnaire, when ‘Did the ATM machine dispense the wrong amount of cash’ is answered as ‘Yes’ initially and then updated to ‘No’ without entering the amount, application is throwing error ‘ATM Dispensed amount: value should be greater than 0’ upon submitting the questionnaire screen.

Smart Dispute ImplementationUpdated validate rule ‘ValidateATMDetails’, for “Value should be greater than 0” row, we have added one more check to throw the error only when the question ‘Did the ATM machine dispense the wrong amount of cash’ has value ‘Yes’.
How to test the functionality
  1. Create an ATM dispute.
  2. In Qualify dispute screen, select the dispute reason as Partial Amount Received.
  3. Select ‘Did the ATM machine dispense the wrong amount of cash?’ as ‘Yes.
  4. Then change ‘Did the ATM machine dispense the wrong amount of cash?’ answer to ‘No’ without entering any amount in ATM Dispensed amount field.
  5. Click on Submit button, observe that there is no error message thrown on the screen.

Claim resolution through Ethoca – Third Party Resolution

ApplicationSmart Dispute for Issuers
Scheme ImpactAll
Dispute ReasonAll
Functional CategoryThird party resolution network
Reported Issue

The status for Claim is shown as 'Resolved-Credit' though it has open disputes in progress when processed through Ethoca flow.

Smart Dispute ImplementationUpdated Activity ‘AutoResolveDisputeCase’, removed UpdateStatus activity (Step #2). Claim case resolution is handled as part of first step.
How to test the functionality
  1. Create two disputes with transactions that are eligible for processing through Ethoca Third Party Resolution Network.
  2. Qualify the first dispute with any of the dispute reasons and submit.
  3. In the ‘Simulate merchant outcome’ assignment, select Response as Unresolved – Dispute and Refund status and submit.
  4. In the ‘Wait for auto credit process’ assignment select a credit transaction and select full credit and submit.
  5. Verify Claim case status, it should be ‘Open’.
  6. Repeat the same steps 2-5 steps for second dispute, and verify the Claim case status should be updated to ‘Resolved-Credit’.

RegE Dates Evaluation

ApplicationSmart Dispute for Issuers
Scheme ImpactAll
Dispute ReasonAll
Functional CategoryRegE
Reported Issue

RegE dates are getting set for all cases created from CSR even if the case does not fall under RegE conditions.

Smart Dispute ImplementationUpdated CheckCSRDisputeReasonsValidation activity to set the dates only when the case is RegE Eligible.
How to test the functionality
  1. Login with CSR operator.
  2. Create a MCOM dispute on a debit card which is not eligible for RegE.
  3. Complete the Qualify stage.
  4. Verify the RegE Dates should be set on the case.

Partial Amount received for ATM Disputes

ApplicationSmart Dispute for Issuers
Scheme ImpactATM
Dispute ReasonAll
Functional CategoryATM
Reported Issue

Smart Dispute supports ATM network disputes. The process is just limited to chargeback. When multiple ATM transactions are disputed, user is unable to see the ‘partial amount received’ reason.

Smart Dispute ImplementationUpdated Data transform PopulateReturnCodeCategoryForATM to add step 4.5.1
How to test the functionality
  1. In SD OOTB, take the account number 99077324 if the sample data is installed.
  2. The account has ATM transactions, select 2 or more transactions, and create claim.
  3. On the Qualify stage which should be processed individually, verify the partial amount received reason is available.

Task Status displayed in French

ApplicationSmart Dispute for Issuers
Scheme ImpactAll
Dispute ReasonAll
Functional CategoryOn-Us
Reported Issue

For On-Us cases, the work status is displayed in French as Attente-OnUsDisputes instead of English.

Smart Dispute ImplementationFor On-Us transactions, the status in clipboard is properly set in English. However, the status display was localized in French. As a fix, pyStatusLabel • Pending- OnUsDisputes field value has been updated to PendingOnUsDisputes in English.
How to test the functionality
  1. The Issue observed is in legacy On-Us Process and so ensure the necessary configuration are available.
  2. Create a claim for a transaction eligible for On-Us processing.
  3. Ensure the status of the dispute and task is displayed in English.

HND – Claim Status fixes

ApplicationSmart Dispute for Issuers
Scheme ImpactAll
Dispute ReasonFraud
Functional CategoryHND
Reported Issue

In Smart disputes for Issuer application, when the HND cases are created the Claim status is displayed as New whereas it should be Open.

Smart Dispute ImplementationCreated SetHNDClaimStatus data transform & updated CreateDisputeCasesByAgent and UpdateStatus activities to set the HND Claim status as Open once the disputes are created.
How to test the functionality
  1. Create a HND Claim.
  2. Verify the case status is Open once the disputes are created.

ATM flow for Manual Case

ApplicationSmart Dispute for Issuers
Scheme ImpactATM
Dispute ReasonNA
Functional CategoryATM
Reported Issue

When a Manual case is created for an ATM transaction, the cases are getting tagged to Visa class.

Smart Dispute ImplementationUpdated Data transform ‘SetWorkObjectClassForManualCase’ to map the correct work object class for ATM disputes during manual submission.
How to test the functionality
  1. Create a manual case. Provide the required transaction details.
  2. Select the transaction type as ‘ATM’ on the Manual case entry screen and proceed.
  3. Qualify the dispute and proceed further.
  4. Select ‘Update transaction details from the ‘Actions’ and provide the required additional information.
  5. Select ‘Validate and proceed with manual case’ from ‘actions’.
  6. Verify the case is routed to the appropriate flow.

WSS – Work object not deleted

ApplicationSmart Dispute for Issuers
Scheme ImpactAll
Dispute ReasonAll
Functional CategoryWSS
Reported Issue

When cases are created through WSS API and an exception occurs, the claim work object is deleted but the dispute work objects are not deleted.

Smart Dispute ImplementationCreated new activity DeleteDisputes to delete disputes which is referenced in activity svcMapRespForTechExcep at step 4.
How to test the functionality
  1. Create a case using WSS API with some mandatory field missing to receive an exception.
  2. Verify if report definition pyGetAllAttachments disputes are deleted if there is exception when initiating WSS case creation.
  3. Verify the dispute is deleted from the main worktable.

Verifi – Authorization Code addition

ApplicationSmart Dispute for Issuers
Scheme ImpactAll
Dispute ReasonAll
Functional CategoryVerifi
Reported Issue

In Smart Disputes Issuers Application, there is no mapping of Authorization Code in the request for CreateVerifiCase API.

Smart Dispute ImplementationUpdated Data transform ‘CCRequestPOST’, added mapping for AuthorizationCode to send in the request for CreateVerifiCase API.
How to test the functionality
  1. Create a dispute with a transaction which is eligible for processing through Verifi Third Party Resolution Network.
  2. Qualify the dispute with any of the dispute reasons and submit.
  3. Verify the ‘AuthorizationCode’ property is sent in the request for CreateVerifiCase API from the ‘Third Party’ tab under ‘Audit’.

AMEX – Questionnaire fixes

ApplicationSmart Dispute for Issuers
Scheme ImpactAMEX
Dispute ReasonI have returned/cancelled the item
Functional CategoryAMEX
Reported Issue

When an AMEX dispute is created with dispute reason as ‘I have returned/cancelled the item and haven’t been credited’ and on submit of qualify dispute the application is throwing an error.

Smart Dispute ImplementationChanged the existing when rules IsExpectedDateRequired, IsMerchantDishonourVoucher, IsVoucherExpirationDateRequired which are used in common sections of MCOM and AMEX to be evaluated for MCOM only.
How to test the functionality
  1. Create an AMEX dispute.
  2. Qualify the dispute with the reason ‘I have returned/cancelled the item and haven’t been credited’.
  3. Verify the qualify stage is successfully submitted and case moves to next assignment.

CSFS – Account Search error

ApplicationSmart Dispute for Issuers
Scheme ImpactAll
Dispute ReasonNA
Functional CategoryCSFS
Reported Issue

When Smart Dispute is used along with Customer Service for Financial Services (CSFS), operator is not able to search for accounts tagged as premier account type.

Smart Dispute ImplementationWhen rule ‘IsAccountTypeChecking’ in class ‘PegaFS-DataAccountRef’ is provided as extension to configure the necessary account types.
How to test the functionalityThis is only for clients using CSFS with Smart Dispute.
  1. Login to CSFS application.
  2. Enter an account number and perform the search.
  3. Verify the transactions are returned.

WSS – Attachments deleted for disputes created through any channel, cases getting corrupted because of assignments deletion

ApplicationSmart Dispute for Issuers
Scheme ImpactAll
Dispute ReasonNA
Functional CategoryWSS
Reported Issue

When cases are created through WSS API and a technical exception occurs in claim creation, the claim work object is deleted along with the associated disputes. When application is deleting the underlying disputes of an exception claim, in step 1 of DeleteDisputes activity, if any item in pxCoveredInsKeys value list happens to be blank due to an undetermined reason, Obj-Browse method in step 1.1 is fetching incorrect disputes. The attachments and assignments routed to workbaskets of the fetched disputes are being deleted resulting in corruption of the dispute cases. In step 1.7, as the Param.InsKey is blank, there are no dispute work objects for deletion.

Attachments, assignments routed to workbaskets are getting deleted for random disputes retrieved in step 1.1.

Note: The reported issue is sporadic and observed only in cases where there is a technical exception in WSS claim creation and if any item in pxCoveredInsKeys value list happens to be blank due to an undetermined reason.
Smart Dispute ImplementationAs part of June maintenance release, DeleteDisputes activity was created to delete the disputes of a claim, when there is any issue in WSS claim creation.

DeleteDisputes was invoked in the activity svcMapErrorResponseMessage. In DeleteDisputes activity, there is no blank check on Param.InsKey in step 1.1 and hence Obj-Browse is fetching incorrect results. This is resulting in inappropriate deletion of attachments and assignments.

The changes delivered in June maintenance release in PegaCard-Sd-.svcMapErrorResponseMessage are reverted. The rule is resaved from the version before June release.

Note: Clients must not have any references to DeleteDisputes activity as the call to this activity is removed in the rule svcMapErrorResponseMessage.
How to test the functionality
  1. Create a case using WSS API such that there is a technical exception.
  2. Verify only the Claim object with the exception is deleted. The dispute work objects are not deleted.

C86 Regulation Evaluation

ApplicationSmart Dispute for Issuers
Scheme ImpactVisa, Mastercard
Dispute ReasonFraud
Functional CategoryC86 Regulation
Reported IssueC86 Regulations evaluation is not happening for Visa fraud disputes that were created before C86 Regulations patch release and processed after C86 Regulations patch release. For all such inflight cases, the C86 questionnaire is not displayed in the Dispute Questionnaire assignment.
Smart Dispute ImplementationDynamic layout 1.6 is updated with when rule DisplayC86Questionnaire in the section rule PegaCardSd-Dispute-Visa- FraudQuestionnaire

DisplayC86Questionnaire when rule is saved in the class PegaCard-Sd- and ruleset PegaCardSd

In the activity PegaCard-Sd-Dispute-MCPostProcessliabilityatAQScreen, step 4 has been added.

How to test the functionality
  1. Disable C86 configurations from Dev Studio Smart Dispute ConfigurationsC86 ConfigurationsDisable.
  2. Create VCR fraud case.
  3. Process Qualify fraud dispute assignment and proceed till Dispute Questionnaire screen.
  4. Verify C86 related questionnaire is not displayed in Dispute Questionnaire screen.
  5. Now enable C86 configurations from Dev Studio Smart Dispute ConfigurationsC86 ConfigurationsEnable.
  6. Close dispute case and reopen the dispute case.
  7. Verify the below C86 questions are displayed:

    Does the fraud transaction qualify to be a result of gross negligence by cardholder?

    Was the issuer notified of Loss/Stolen/Unauthorized use of card before the transaction date?

Commit issues while performing Cardholder liable action from bulk actions

ApplicationSmart Dispute for Issuers
Scheme ImpactVisa, Mastercard
Dispute ReasonNA
Functional CategoryBulk actions – Cardholder liable
Reported IssueAs an Issuer, when I perform Cardholder liable action in bulk (claim level actions) for multiple debit disputes, Smart Dispute for Issuers application is throwing a commit error: . Save, Delete or Commit has failed because lock "PEGACARD-SD-CLAIM C-*****" is not held.
Smart Dispute ImplementationIn the Activity PegaCard-Sd-Claim PostCustomerLiableAction, added step 3 to acquire the lock on claim page which will be lost in the previous steps. Unchecked the Commit check box in Step 2.3.2 and added step 4 for exceptional handling.
How to test the functionality
  1. Create a MCOM or VCR debit claim with multiple transactions.
  2. Select the payment channel as Debit and then Qualify the disputes in bulk.
  3. From Claim level actions, select Process Provisional Credit for some disputes.
  4. Now select the remaining disputes and select Customer Liable action from claim level actions.
  5. Observe the dispute cases are processed without any error.

Regulation-E eligibility evaluation

ApplicationSmart Dispute for Issuers and Acquirers
Scheme ImpactVisa, Mastercard
Dispute ReasonNA
Functional CategoryRegulations-E
Reported IssueAs per Regulations, a dispute is eligible for Regulation-E if the dispute is initiated by the cardholder no later than 60 days after the institution sends the periodic statement or provides the passbook documentation, on which the alleged error is first reflected.
Smart Dispute ImplementationA new data transform rule PegaCard-Sd-Debit EvaluateNoREGECreditDate is created. The data transform PegaCard-Sd-Debit SetNoREGECreditDate to call the data transform EvaluateNoREGECreditDate and removed the function call ‘Get Second last statement date’.

The decision table PegaCard-Sd-Debit RegEEligible is updated with request date in the last column instead of transaction date. When rule PegaCard-Sd-Debit IsRegECreditRequired is updated with request date.

How to test the functionality
  1. Create a VCR dispute on a debit card transaction that happened on October 1st, 2022.
  2. Assume statement gets generated on every 15th day of the month, the reported transaction appears in the October statement on October 15th, 2022 3.
  3. The 60-day window period for Regulation-E begins from the statement date and hence the dispute must be reported on or before 14th December 2022 in order to be Reg-E eligible.
  4. If the cardholder reports the dispute before 14th December 2022, then application should consider the dispute as Reg-E eligible.
  5. If the cardholder reports the dispute after 14th December 2022, then application should not consider the dispute as Reg-E eligible.

MCOM – Withdraw Case Filing

ApplicationSmart Dispute for Issuers and Acquirers
Scheme ImpactMCOM
Dispute ReasonAll
Functional CategoryWithdraw Case Filing
Reported IssueIn Smart Dispute for Issuers application, if the Issuer files Arbitration and dispute reaches final ruling stage for association review, the Issuer is unable to Withdraw the case filing. In UpdateFiling API, the action is sent as ’REJECT’ instead of ‘WITHDRAW’.

Similarly, in Smart Dispute for Acquirers application, if the Acquirer withdraws the case filing, UpdateFiling API action is sent as ’REJECT’ instead of ‘WITHDRAW’.

Smart Dispute ImplementationIn all case filing flows, the data transform SetActiontoWithdraw is invoked before withdrawing the case filing to set the property .CaseFilingResponse as ‘WITHDRAW’.

In GetClaim data transform, step 4 is added to set CaseFilingType.

How to test the functionality
  1. Create an inbound MCOM Acquirer case.
  2. Select ‘Reject’ on ‘Review inbound chargeback’ screen.
  3. Process the case till inbound Arbitration and in ‘Review inbound Arbitration’ screen, select ‘Reject’ as response.
  4. Verify the case lands on ‘Awaiting association review’.
  5. Select ‘Withdraw Case Final Ruling’ option from Actions.
  6. Verify Acquirer is able to successfully withdraw the case filing. Action is sent as ‘WITHDRAW’ in UpdateFiling API request.
  7. Verify case moves to Process liability after the case filing is withdrawn.

MCOM – Case Filing API fixes

ApplicationSmart Dispute for Issuers
Scheme ImpactMCOM
Dispute ReasonAll
Functional CategoryCase Filing
Reported IssueIn CreateFiling MCOM API Request, filedAgainstIcafield is mapped to acquiringInstitutionIdCode from GetAuth API but acquiringInstitutionIdCode can be blank in certain scenarios. In such cases, CreateFiling API is failing because of empty value in filedAgainstIcafield. Error: 'Unable to validate Chargeback Reference data' .

As per confirmation from Mastercard, acquirerId from GetClaim API must be passed to filedAgainstIcafield instead of acquiringInstitutionIdCode from GetAuth API.

Smart Dispute ImplementationIn PreArbDetailsScreen, removed default value of FiledAgnstICA and updated with MCOM_GetClaim.acquirerId. In InitiatePreComplianceForMCOMSection, removed default value of FiledAgnstICA and updated with MCOM_GetClaim.acquirerId. In InitiateComplianceForMCOM section, removed default value of FiledAgnstICA and updated with MCOM_GetClaim.acquirerId.
How to test the functionality
  1. Create a MCOM dispute and select any dispute reason in Qualify dispute screen.
  2. ProcessDispute questionnaire screen and submit the dispute to MCOM.
  3. At Review second presentment screen, select ‘Initiate Pre-Arbitration’ and proceed further.
  4. At Initiate Pre-Arbitration screen , verify 'Filed against ICA' value is pre-populated (MCOM_GetClaim.acquirerId).

MCOM – EBDR fixes

ApplicationSmart Dispute for Issuers
Scheme ImpactMCOM
Dispute ReasonAll
Functional CategoryEBDR
Reported IssueIf the reason code is updated in the Answer Ancillary Questionnaire screen from 4853 to 4834, and questionnaire is answered, the updated comments are not populated in the EBDR form.
Smart Dispute ImplementationIn SetRCByDisputeReasondata transform, the property MCOMQualifyQuestionnaire.CBKDispDetails is removed. In ClearConditionCodes data transform, the property FirstCBRCInfo.CBKDispDetails is removed. In SetRCByDisputeReasonNoParam data transform, the property FirstCBRCInfo.CBKDispDetails is removed. In ClearAllConditionCodePropsdata transform, the property PreArbRCInfo.CBKDispDetails is removed. In SetMComRCQuestionnairedata transform, the property PreArbRCInfo.CBKDispDetails is removed.
How to test the functionality
  1. Create a MCOM dispute and select any dispute reason in Qualify dispute screen.
  2. In Answer Ancillary Questions screen,update the reason code and give comments in Describe the Cardholder's complaint in detailfield.
  3. Observe that the generated EBDR document contains the latest comments.

MCOM – New cases are created when Pre-Compliance is received for existing dispute

ApplicationSmart Dispute for Acquirers
Scheme ImpactMCOM
Dispute ReasonAll
Functional CategoryInbound Pre-Compliance
Reported IssueAs an Acquirer, when Pre-Compliance is received,
  1. If a dispute exists, system should attach the PreCompliance details and route the case to Review inbound pre-compliancedetails assignment.
  2. If there are no existing disputes, a new case should be created and case should be routed to Review inbound pre-compliance details assignment.
Smart Dispute ImplementationIn Smart Dispute for Acquirers, the agent Inbound PreComp - Receiver Case Filing is used to retrieve all inbound pre-compliances and create cases for those items that do not have existing disputes. CaseCreationFromQueue activity is used for this purpose. The logic to identify existing dispute cases must use standardclaimsproperty, especially for prefiling and filing scenarios. However, the activity was using claimId property in steps 11 and 14 resulting in errors.

This has been corrected to use standardclaims property.

How to test the functionality
  1. Acquirer receives a chargeback, and a dispute is created.
  2. Acquirer declines the chargeback by submitting second representment.
  3. As a response, acquirer receives an inbound precompliance.
  4. When the agent Inbound PreComp - Receiver Case Filing runs, no new case should be created, and the queue item should not be updated.
    Note: The inbound pre-compliance queue items for existing cases will eventually be processed by the agent Inbound case filing - Receiver Case Filing or Inbound Pre-Comp Post CB. These agents will attach the pre-compliance details to the existing dispute and resume the case for further user action.

MCOM – Addition of Mastercard Fraud Types 55 and 56

ApplicationSmart Dispute for Issuers
Scheme ImpactMCOM
Scheme ReferenceAN 6917 Revised Standards for Global Expansion of Fraud Types 55 and 56 and Guidance Update
Dispute ReasonFraud
Functional CategoryFraud questionnaire
Effective DateNovember 2022
Reported IssueAs per Mastercard article AN 6917, Issuer can report fraud transaction with fraud types ‘Modification of Payment Order - 55’ and ‘Manipulation of Cardholder - 56’.

In Smart Dispute for Issuers application, the new fraud types must be available in the Qualify fraud questionnaire screen.

Smart Dispute ImplementationAs per Mastercard article AN 6917, Issuer can report fraud transaction with fraud types ‘Modification of Payment Order - 55’ and ‘Manipulation of Cardholder - 56’. In Smart Dispute for Issuers application, the new fraud types must be available in the Qualify fraud questionnaire screen.
How to test the functionality
  1. Create a MCOM fraud dispute
  2. In Qualify fraud disputes screen, observe the new fraud types are available.
  3. Complete the questionnaire by selecting fraud type as ‘Modification of Payment Order’.
  4. Process Answer ancillary questions and submit the screen.
  5. Verify application reports the fraud by triggering createFraud API with reason code as 55.

Visa – Process Liability amount in Audit history

ApplicationSmart Dispute for Issuers
Scheme ImpactVISA
Scheme ReferenceNA
Dispute ReasonNA
Functional CategoryProcess Liability
Reported IssueIn the Dispute Questionnaire screen, when Process Liability action is performed through ‘Other Actions’ and Write-off is selected, then Cardholder Liable amount is displayed as blank (--) instead of 0.00/<Currency>.
Smart Dispute ImplementationIn the activity PostProcessliabilityatDQScreen, steps 12 and 13 are modified.

“.VCRDQMPWriteoffAmt = @If(.VCRDQMPWriteoffAmt=="",0,.VCRDQMPWriteoffAmt)”

“.VCRDQMPCHAmt = @If(.VCRDQMPCHAmt=="",0,.VCRDQMPCHAmt)”

How to test the functionality
  1. Create a VCR dispute.
  2. Process Qualify dispute screen by selecting any dispute reason.
  3. In Dispute Questionnaire screen, select ‘Process Liability’ option from ‘Other Actions’ tab.
  4. Select “Write Off” and submit.
  5. Verify the below audit message is displayed in AuditHistory tab

    “Dispute amount processed using multi-pronged options. Write-off amount : 849.50/USD Cardholder liable amount : 0.00/USD Dispute amount : 849.50/USD”

Visa – Cancelled Merchandise/Services Questionnaire

ApplicationSmart Dispute for Issuers
Scheme ImpactVISA
Scheme ReferenceNA
Dispute ReasonCancelled Merchandise/Services
Functional CategoryDispute Questionnaire
Reported IssueIn Cancelled Merchandise/Services questionnaire screen, when the operator answers, ‘What was purchased’ as ‘Services’, ‘Type of service’ as ‘Time share’ and enters a future date in ‘Date of the timeshare, or the date the contract or related documents were received’ field, then application is displaying property level error message that future value is not allowed but is accepting future date when the questionnaire is submitted. There is no future date post validation on the time share date after questionnaire submission.
Smart Dispute ImplementationIn the activity ValidateCSQuestionnaire/ ValidateCSRCustomerCancelled, step 2 is added to invoke Obj-validate rule ValidateTimeShareDate.
How to test the functionality
  1. Create a VCR dispute.
  2. In Qualify dispute screen, select the dispute reason as ‘I cancelled the merchandise/service’.
  3. Select What was purchased as ‘Services’.
  4. Select Type of Service as ‘Timeshare’.
  5. Enter future date in the field ‘Date of the timeshare, or the date the contract or related documents were received.
  6. Submit the screen and verify the error message “TimeShareDate: This date cannot be a future date” is displayed.

Visa – Audit history update

ApplicationSmart Dispute for Issuers
Scheme ImpactVISA
Scheme ReferenceNA
Dispute ReasonNA
Functional CategoryAudit history
Reported IssueIn the audit tab, when the timeframes are executed, the audit history is displayed as “validating the dispute time limit check.”’ instead of “Validating the dispute time limit check.”.
Smart Dispute ImplementationIn InvokeVCRProcessing Flow, audit note "validating the dispute time limit check" on TimeFrameCheck Utility shape is replaced with ValidatingDisputeTimeLimitCheck field value.
How to test the functionality
  1. Create a VCR non-fraud dispute.
  2. In Qualify dispute screen, select any dispute reason, and complete the questionnaire.
  3. In the audit tab, verify the note “Validating the dispute time limit check.”

Visa – Fraud Report

ApplicationSmart Dispute for Issuers
Scheme ImpactVISA
Scheme ReferenceNA
Dispute ReasonFraud : Application Fraud (FRAPP)
Functional CategoryFraud Report
Reported IssueIn Qualify fraud dispute questionnaire screen, if the Issuer selects fraud type as ‘Application Fraud (FRAPP)’, then application is trying to submit fraud report by triggering RTSI SubmitFraudReportwith blank fraud type and hence Visa is throwing an error. ‘Application Fraud (FRAPP)’ is not a Visa defined Fraud type but is used for internal investigation by the Issuers and hence fraud report should not be submitted to Visa.
Smart Dispute ImplementationIn PegaCard-Sd-Dispute-Visa- SubmitFraudReportAndEFL flow, before invoking SubmitFraudReport sub flow, condition is updated to check if .FraudTypeVisa exists and has a value(using when rule IsFraudTypeVisaAvailable).
How to test the functionality
  1. Create a VCR Fraud dispute.
  2. In Qualify fraud dispute screen, select fraud type as Application Fraud(FRAPP), answer the questionnaire and submit.
  3. Verify RTSI SubmitFraudReportis not triggered as Application Fraud(FRAPP) is used for internal investigation purposesonly.

Visa – Appeal case filing amount

ApplicationSmart Dispute for Acquirers
Scheme ImpactVISA
Scheme ReferenceNA
Dispute ReasonNA
Functional CategoryAppeal Case filing
Reported IssueAs an Acquiring dispute operator, when I submit appeal for full or partial case filing amount, the case filing amount must be properly mapped in the request of RTSI SubmitDisputeFilingOperation.
Smart Dispute ImplementationIn the data transform, SubmitDisputeFilingRequest, under Compliance page, if .AppealInd=="true",the mapping of .CaseFilingAmount.value is replaced from .CompAppealInitiationAmount to .AssociationData.FilingAmount and a step is added to map .CaseFilingAmount.currency to .AccountTransaction.PostedCurrency.
How to test the functionalityAcquirer Inbound Compliance Flow:

Inbound Pre-Compliance caseDecline Pre-ComplianceIssuer Initiates Compliance Review Inbound Compliance DetailsProcessComplianceRuling .

  1. If an Acquirer gets an inbound Pre-Compliance case, in Process pre-compliance response screen, select response as ‘Decline’ and submit.
  2. In Pre-compliance response screen, answer the question “Why are you declining Pre-compliance?” and submit the screen.
  3. Submit Awaiting process Pre-compliance response screen.
  4. Submit Review Inbound Compliance details screen.
  5. In Process Compliance ruling screen, select ‘Both’ for the question “Liable party as per Association ruling”. Enter Acquirer liable amount and select Acquirer action as Appeal Final Ruling and provide exchange rate(in USD) and submit the screen.
  6. In Initiate compliance appeal screen, provide Compliance Appeal reason and submit the screen.
  7. Open "SubmitDisputeFilingOperation" from Audit→ Third party tab and verify CaseFilingAmountis proper.

Similarly, verify case filing amount for Acquirer Outbound Compliance:

Collaboration caseProcess Inbound Dispute Initiate Pre-ComplianceAwaiting Pre-Compliance ResponseIssuer declines Pre-complianceProcess Pre-Compliance Response Initiate ComplianceAwaiting Compliance AcknowledgementAwaiting Final Decision by VisaProcess Compliance Ruling.

Claim level Pulse Gadget

ApplicationSmart Dispute for Issuers
Scheme ImpactAll
Scheme ReferenceNA
Dispute ReasonNA
Functional CategoryPulse gadget
Reported IssueIn Smart Dispute for Issuers application, when a claim case is created, issuing operators are unable to attach documents in the pulse gadget.
Smart Dispute ImplementationRemoved pxPulseGadgetfrom pyCaseAssets section and added pyCaseFeed to pyCaseBody section.
How to test the functionality
  1. Create a claim.
  2. Process Qualify dispute screen by selecting any dispute reason.
  3. Verify pulse gadget is displayed at claim level below case overview details. Also, verify the operator is able to attach documents using pulse.

Regulation-E fixes

ApplicationSmart Dispute for Issuers
Scheme ImpactAll
Scheme ReferenceNA
Dispute ReasonNA
Functional CategoryRegulation E
Reported IssueWhen a dispute is created on a non-US deposit account transaction, application is throwing runtime exception of incorrect date format after Qualify dispute stage. In Reg-E dateevaluations, billing cycle value is used to calculateNoRegECreditDate in the data transform rule SetNoRegECreditDate.If the billing cycle value is blank , then application is throwing date format error. Clients who do not have Billing Cycle value in their system of records are facing this issue.
Smart Dispute ImplementationIn PegaCard-Sd-DebitREGEFlowFlow, ‘Is US Deposit Account’decision shape is added before ‘RegE Eligible’ Decision shape. .IsRegEEligible flag is set as ‘false’ if when rule IsUSDepAccount evaluates to false. In the activities InvokeRegEforDST, PostInvokeReturnCodeAdvisor, CheckCSRDisputeReasonsValidation, when condition IsUsDepAccountis added before invoking SetNoRegECreditDatedata transform. Updated IsUsDepAccount when rule in PegaCard-SdDebit class and created IsUsDepAccount rule in PegaCard-Sd-to validate account type and country code in both pyWorkpage.AccountDetails and pyWorkCover.AccountDetails.
How to test the functionality
  1. Create debit dispute for non-US account and select any dispute reason in Qualify dispute screen.
  2. Submit ‘Select charge fees’ & ‘Verbal attestation’ screens .
  3. Verify IsRegEEligible flag is set to false in the pyWorkPageof dispute.

Timeframe expiry fixes

ApplicationSmart Dispute for Issuers
Scheme ImpactAll
Scheme ReferenceNA
Dispute ReasonNA
Functional CategoryTimeframe expiry in CSR channel
Reported IssueAs a CSR operator, when I create a dispute with a dispute reason requiring supporting documentation and if the transaction eventually goes to timeframe expiry, application displays below two confirmation messages when Cardholder liable option is selected in the timeframe expiry screen.

“Thank you for your inquiry. Your reference number is DXXXX.

We will hold this case until below required documents are received and then we will process the dispute and attempt to get your money back. If we dont receive the documents with in 30 days will resolve the dispute and notify that we have taken no action.”

“Thank you for your inquiry. This case, D-XXXX, is resolved.”

As a back-office operator,when I open the dispute, the case should be resolved with no open assignments but the case is having open assignments with case status as Resolved-Cardholder Liable.
Smart Dispute ImplementationIn the section ConfirmMessage, added when condition to the dynamic layout 1 to display appropriate confirm message.

In the flow rules ReviewCustomerInitiatedDispute, added decision shape after TimeFrameExpiry sub process to verify whether the case status is resolved or not.

How to test the functionality
  1. As a CSR operator, create a VCR dispute on an older transaction that does not have dispute rights.
  2. Process Qualify disputeby selecting the dispute reason I have not received the expected credit.
  3. Answer the questionnaire and observe that Transaction Receiptis displayed as mandatory document in the Supporting documents section. Submit the questionnaire.
  4. As the dispute timeframes are expired, verify application displays Process liability screen.
  5. Select cardholder as liable and proceed further.
  6. Verify application displays confirmation message that the dispute is resolved: “Thank you for your inquiry. This case, D-XXXX, is resolved.”
  7. As a back-office operator, verify the dispute is resolved with no open assignments.

MCOM – AN 7077 Revised Chargeback Standards for Currency Errors

ApplicationSmart Dispute for Issuers
Scheme ImpactMCOM
Scheme ReferenceAN 7077 Revised Chargeback Standards for Currency Errors
Dispute ReasonPoint of Interaction Error – Currency Errors (4834-6)
Functional CategoryAnswer Ancillary Questionnaire
Effective DateApril 15th 2023
Reported IssueAs per article AN 7077, Issuers can initiate a chargeback with reason code Point of Interaction Error4834 only for the difference between the transaction amount and the transaction amount claimed by the cardholder, excluding any amount related to the Issuer's conversion of the transaction.

The currency exchange rate in effect on the date of the transaction must be used to calculate the partial amount.

Smart Dispute ImplementationAs per the revised standards, dispute questionnaire is updated for the dispute reason code – Point of Interaction Error (4834). These changes apply to the condition code – 6, for which condition code label is updated to Currency Errors.

Labels for the options in the drop down Select the condition for chargeback are updated to follows.

  • POI Currency Conversion (Dynamic Currency Conversation) was performed, and the cardholder did not consent to the POI Currency Conversion
  • Currency conversion was performed incorrectly

New question to capture the correct amount in posted currency is added.

How to test the functionality
  1. Create a MCOM for a cross-currency transaction.
  2. In the Qualify dispute screen, select I have another issue with the transaction as dispute reason and proceed further.
  3. In Answer Ancillary Questions screen, select Reason code as Point of Interaction Error-4834 and Condition code as Currency Errors-6.
  4. Observe application displays the updated labels for drop-down Select the condition for chargeback.
  5. Dispute displays the question “What should be the amount (in posted currency)?”
  6. When user enters a valid amount, system displays the message “Chargeback amount will be updated to <AMT / CUR>”. Chargeback amount is calculated as Posted Amount – (Write-off amount + Cardholder liable amount + Amount entered in step 5).
  7. Upon submission, dispute amount is updated to the chargeback amount.

MCOM – Case filing batch queue fixes

ApplicationSmart Dispute for Issuers and Acquirers
Scheme ImpactMCOM
Scheme ReferenceNA
Dispute ReasonNA
Functional CategoryBatch Queue Processing
Reported IssueAfter Issuer files a Pre-Arbitration, a queue item appears in Sender Case Filing queue immediately within next few hours although Acquirer did not respond to the Pre-Arbitration. For such queue items, in GetClaim API response, latest case filing action is “createcase” and so the batch queue processing agent does not update isProcessed flag to “Y”.

The case filing action remains as “createcase” until the Acquirer accepts/rejects the pre-arbitration.

Above two circumstances resulted in the same items to be processed by the Batch queue agent multiple number of times until Acquirer accepted or rejected the Pre-Arbitration.

In addition, by default OOTB settings, the batch queue agents will process “newest” 500 queue items per execution. When queue items of the above-described nature accumulate more than 500, older records are not processed in a timely manner.

Smart Dispute Implementation
  1. Logically, older queue items have more probability of getting an acquirer response than the newer queue items. In accordance with that, default sorting is changed in such a way that batch queue agents will process oldest 500 items first.
  2. If latest case filing action for Sender Case Filing queue items is “createcase”, Smart Dispute will update the isProcessed flag value to ‘Y’. This ensures that the same queue items are not repeatedly processed until acquirer responds. Based on MasterCom confirmation, when acquirer responds to the Pre-Arbitration, lastModifiedDateof the corresponding queue item is updated. The batch queue reading agent (Invoke Queue Summary) will read the updated items and initialize isProcessed flag value to ‘N’ again. This allows the response to be processed.
How to test the functionality
  1. Create a MCOM dispute and submit the chargeback to the acquirer.
  2. After acquirer rejects the chargeback, review the representment details and initiate Pre-Arbitration.
  3. Dispute should now be routed to Awaiting prearbitration response assignment.
  4. Observe that Sender Case Filing queue item appears for this chargeback within next few hours in the batch queue.
  5. After the agent Outbound Prearb - Fetch Prearb Resp processes this queue item in the next execution, observe that
    1. The dispute case remains at Awaiting prearbitration response assignment.
    2. The latest case filing action is “createcase”. Latest case filing action can be reviewed in the audit history of the dispute case.
    3. The value of isProcessed flag is “Y” for the queue itemin sd_mcom_queuesummary table.
  6. When the acquirer accepts or rejects the prearbitration, observe that the value of isProcessed is updated to “N”.
  7. After the agent Outbound Prearb - Fetch Prearb Resp processes this queue item in the next execution, observe that
    1. The dispute case has progressed forward based on accept / reject response.
  8. The value of isProcessed is “Y” for the queue item

Visa – Cancelled Recurring TransactionQuestionnaire

ApplicationSmart Dispute for Issuers and Acquirers
Scheme ImpactVISA
Scheme ReferenceIES for Release 23.1_Pub 12.16.22
Dispute ReasonCancelled Recurring Transaction
Functional CategoryDispute Questionnaire
Reported IssueIssue 1:

As part of 23.1 Compliance, a new checkbox labelled Contact method with merchant was introduced. During MTE2 testing, it was observed that Visa returned the following error when user did not check the checkbox.

E-200100002 : One or more required fields are missing. Please correct the following errors:ContactMethodWithMerchantInd

In SubmitDisputeQuestionnaireOperation, it was observed that the value passed to the ContactMethodWithMerchantIndattribute is false.

It is inferred from the error that Visa expects this value to be true always

Issue 2:

As part of 23.1 Compliance, contact method related 23.1 questionnaire is applicable for all regions other than Europe regional or domestic. For Europe inter-regional transactions where the Issuer is in Europe and the merchant is not in Europe, the new questionnaire is not displayed.

Smart Dispute ImplementationValidations for Web Self Service (WSS) and Questionnaire screens are updated to ensure that the value of ContactMethodWithMerchantInd is true. Updated visibility condition for 2.4 Dynamic layout in CustomerDisputeQuestionnaireCR section.
How to test the functionality
  1. Create a VCR disputeon a Europe inter regional transactions (Card issued in Europe but the transaction is performed outside of Europe).
  2. In Qualify dispute questionnaire screen, select I cancelled the recurring transaction as the dispute reason.
  3. Enter a date for Date cardholder withdrew permission to charge the Payment Credential.
  4. Verify System displays Contact method with merchant check box.
  5. Enter Contact merchant details and Cancellation reason.
  6. Leave the Contact method with merchant check box unchecked and click Submit.
  7. System should throw an error that Contact method with merchant is mandatory.
    Note: In WSS, when ContactMethodWithMerchantInd is false, dispute will not be eligible for straight through processing (STP) and will be routed to Qualify dispute screen.

Visa – Other Fraud – Card Absent Environment (10.4) dispute validation for fully authenticated U.S. domestic token transactions

ApplicationSmart Dispute for Issuers
Scheme ImpactVISA
Scheme ReferenceU.S. Domestic Token Transactions in High-Risk MCCs Will Continue to Have Issuer Fraud Dispute Rights, Regardless of ECI Classification
Dispute ReasonOther Fraud – Card Absent Environment (10.4)
Functional CategoryDispute Validations
Effective DateApril 15th 2023
Reported IssueAs per Visa guidelines, Issuers will have dispute rights under Other Fraud – Card Absent Environment (10.4) dispute sub-category for fully authenticated U.S. domestic token transactions irrespective of the electronic commerce indicator value in case of highrisk merchants.

The below merchant category codes (MCCs) are considered as high-risk merchants: 4829, 5967, 6051, 6540, 7801, 7802, 7995

Smart Dispute ImplementationEval_104_7when rule is modified to include when rules WhenUSDomesticTxnand CheckHighRiskMCCsForUS.
How to test the functionality
  1. Create a VCR fraud disputeon a U.S. domestic fully authenticated token transaction (Electronic commerce indicator value – 05) performed at a high-risk merchant (MCC 4829).
  2. In Qualify fraud dispute screen, answer the questionnaire, and submit the fraud dispute.
  3. In Dispute Questionnaire screen, click on submit.
  4. For Other Fraud – Card Absent Environment(10.4) disputes, in the VCR tabDispute details: Dispute validations, observe the outcome of the below dispute validation as Pass:

“A Secure Electronic Commerce Transaction processed with Electronic Commerce Indicator value 5 in the Authorization Request with exception of U.S domestic transactions conducted with high risk merchants (MCC-4829, 5967, 6051, 6540, 7801, 7802, 7995)”

Visa – Pre-Arbitration: Remedy – Prior Undisputed Non-Fraud Transactions questionnaire UI fixes

ApplicationSmart Dispute for Acquirers
Scheme ImpactVISA
Scheme ReferenceIES for Release 23.1_Pub 12.16.22
Dispute ReasonOther Fraud – Card Absent Environment (10.4)
Functional CategoryPre-Arbitration Questionnaire
Effective DateApril 15, 2023
Reported IssueIn Pre-Arbitration questionnaire, when ‘Add undisputed transactions’ is selected, Filter by merchant checkbox is displayed above Search button although it is not used to perform transaction inquiry. This is misleading and might result in users performing multiple transaction search to filter or not filter by merchant.
Smart Dispute ImplementationFilter by merchant checkbox is moved below Search button and is conditionally displayed only when the transaction search has yielded results.
How to test the functionality
  1. Open an inbound Visa 10.4 (Other Fraud – Card Absent Environment) dispute.
  2. Select Initiate Pre-Arbitration and submit.
  3. In the next assignment, select Remedy – Prior Undisputed Non-Fraud transactions as the prearbitration reason.
  4. Click Add/Edit undisputed historical transactions.
  5. In the pop-up, under Find by Visa transaction inquiry tab, observe that Filter by merchant checkbox is not visible by default.
  6. Enter Start date and End date and click Search.
  7. After transaction search returns results, observe that Filter by merchant checkbox is displayed.

Visa – Minimum dispute amount dispute validation for Travel and Entertainment transactions

ApplicationSmart Dispute for Issuers
Scheme ImpactVISA
Scheme ReferenceVisa Core Rules and Visa Product and Service Rules, 15th October 2022
Dispute ReasonNA
Functional CategoryDispute Validations
Effective DateNA
Reported IssueAs an Issuing bank operator, if a dispute is raised on a travel and entertainment transaction and the transaction amount is less than 25 USD (or equivalent local currency), then application should consider the dispute as invalid for all dispute conditions except for (10.1, 10.5, 13.3, 13.8 and 13.9).

Merchant category codes (MCCs) for travel and entertainment transactions: 4112, 4411, 4722, 4511, 7011, 7512, 7513

Smart Dispute ImplementationThe dispute validation ‘Minimum dispute amount validation for TE transaction’must be manually deleted by accessing Smart Dispute ConfigurationsVCR ConfigurationsVCR Dispute Validations. Filter the dispute validations as:

Dispute category: Consumer Disputes

Dispute SubCategory: Not as Described / Damaged or Defective / Quality

Validation Details: Minimum dispute amount validation for TE transaction

The above dispute validation can alternatively be removed by deleting the pzinskey ‘PEGACARDINTERFACE-ADMIN-DISPUTEVALIDATIONS NOT AS DESCRIBED / DAMAGED OR DEFECTIVE / QUALITY!CONSDISP! ISTETXNWITHAMNTLESSTHANMINDISPUTEAMNT’ from the instances of PegaCard-Interface-Admin-Dispute Validations class.

In TETransactionFilter_DV when rule, 4722 merchant category code is added.

How to test the functionality
  1. Create a VCR dispute.
  2. In Qualify dispute screen, select the dispute reason as ‘I have an issue with the merchandise/services’ and dispute sub-reason as ‘The merchandise/service was not as described’ and complete the questionnaire.
  3. Proceed with dispute submission to Visa.
  4. In the VCR tabDispute details: Dispute validations, observe the dispute validation Minimum dispute amount validation for TE transaction is not displayed.

Visa – Refine Transaction Selection Criteria

ApplicationSmart Dispute for Issuers
Scheme ImpactVISA
Scheme ReferenceNA
Dispute ReasonNA
Functional CategoryTransaction Inquiry
Effective DateNA
Reported IssueIssue 1:

After a user performs Qualify Dispute, Smart dispute uses the RTSI API SubmitTransactionInquiryOperation to retrieve details of the disputed transaction from VROL (Visa Resolve Online) system. This API uses the following search criteria to find the matching transaction: Start Date, End Date and ARN or Transaction ID.

If no transactions are found, Smart Dispute routes the dispute to Transaction selection assignment with an action for the user to manually refine the criteria and then search the transaction. If user does not perform a refined search, Smart Dispute will automatically perform a retry on every third day or timeframe expiry day, whichever is earlier, to find the matching transaction. If no transactions are found during retry, system routes the case again to Transaction selection assignment and the cycle continues until a matching transaction is found.

If the timeframe expires for a dispute in Transaction selection assignment, system retries the transaction search on the timeframe expiry date. If still no transactions are found, it is routed back to Transaction selection. Since timeframe expiry date is in the past, the dispute becomes eligible for a retry immediately. System again retries, finds no matching transactions, and routes the dispute to Transaction selection. This results in an endless loop of transaction search retries.

Issue 2:

If Visa responds to the transaction search with a TIEventID, then the transaction search follows an asynchronous flow. This means Visa cannot fulfil the search request immediately, but the results can be retrieved using the TIEventID later using GetTransInquiryResultsOperation API. In this scenario, Smart Dispute employs an automated mechanism to retrieve the results. Smart Dispute invokes the API every 1 minute until the results are ready for 1 entire day. The frequency of 1 minute for this automated job is deemed impractical due to high usage of resources.

Smart Dispute ImplementationFix 1:

Given that SubmitTransactionInquiryOperation API is chargeable, Smart Dispute has strategically decided that the system will perform an automated retry only once on the third day or timeframe expiry day, whichever is earlier. When the dispute waits in Transaction selection indefinitely and timeframe expires, system will route the dispute to Process Liability assignment. Clients must train operators to proactively refine the search criteria manually and submit the assignment to find the matching transaction and continue with the dispute. Failing to do so will result in timeframe expiry and loss of dispute rights

Fix 2:

The frequency to invoke GetTransInquiryResultsOperation API is configured in the DSS setting PegaCardInt • AsyncTIWaitTimeInMinutes. The DSS value is updated from “1” to “30” minutes.

How to test the functionality
  1. Create a VCR dispute for a transaction that has a timeframe expiry date after 3 days.
  2. Qualify the dispute and submit.
  3. When no transactions are found using default transaction search criteria, verify that the dispute is routed to Transaction selection assignment.
  4. Verify that the system retries SubmitTransactionInquiryOperation only once after 3 days.
  5. If no transactions are found during retry, then verify that the dispute is routed to Transaction selection assignment again.
  6. When timeframe expiry date is reached, verify that the dispute is automatically routed to Process liability assignment.

Visa – Cancelled Merchandise/Services Questionnaire

ApplicationSmart Dispute for Issuers and Acquirers
Scheme ImpactVISA
Scheme ReferenceIES for Release 23.1_Pub 12.16.22
Dispute ReasonCancelled Merchandise/Services (13.7)
Functional CategoryDispute Questionnaire
Effective DateApril 15, 2023
Reported IssueFor a VCR dispute, at the Qualify dispute screen, when an Issuing operator selects dispute reason as ‘I cancelled the merchandise/service’ and answers the below questions as indicated below :
  • Did the cardholder attempt to resolve the dispute with the merchant? – No
  • Is attempt to resolve prohibited by local law or regulations? – Yes
  • What was purchased? – Services

Visa throws the below error message after submitting the dispute:

One or more required fields are missing. Please correct the following errors:AttemptToResolveProhLocalLaw’

Smart Dispute ImplementationAdded step 5.1.3 in the data transform SubmitDisputeQuestionnaireOperationReq_CD_CS:

When: .CardholderAttemptToResolve=="N"

Set : .AttemptToResolveProhLocalLaw== .AttemptToResolveProhLocalLaw

How to test the functionality
  1. Create a VCR dispute.
  2. Process the case until Qualify dispute screen.
  3. Select the dispute reason as ‘I cancelled the merchandise/service’.
  4. Answer the questionnaire as: a. Did the cardholder attempt to resolve the dispute with the merchant?’ – ‘No’ b. ‘Is attempt to resolve prohibited by local law or regulations?’ – ‘Yes’ c. ‘What was purchased?’ – ‘Services’.
  5. Complete the questionnaire and submit the dispute.
  6. Verify Dispute Questionnaire screen is displayed with the questionnaire as pre-populated.
  7. Review the questionnaire and submit the dispute.
  8. Observe the dispute is successfully submitted to Visa.

Visa – Supporting documentation for Incorrect Amount disputes

ApplicationSmart Dispute for Issuers
Scheme ImpactVISA
Scheme ReferenceAI12852 12.5 Incorrect Amount Delay
Dispute ReasonIncorrect Amount (12.5)
Functional CategoryDispute Validations
Effective DateApril 15, 2023
Reported IssueAs part of the 23.1 Compliance requirement, Copy of Transaction Receipt or other record with the correct Transaction amount is required as a supporting document for disputes submitted with condition code Incorrect Amount (12.5).

As per the recent mandate published by Visa in the article AI12852, the supporting document requirement for 12.5 disputes is postponed to 23.2 Compliance. Copy of Transaction Receipt or other record with the correct Transaction amount is not required as supporting document for Incorrect Amount disputes.

Smart Dispute ImplementationIn Dev StudioSmart Dispute ConfigurationsVCR Document Configurations, the below supporting document, must be manually deleted:

Select Dispute category as Consumer Disputes, Dispute stage as Submit Questionnaire and remove row with Condition as VCRCONFIG_ISSUER_PE_IA.

The decision table doComplianceChangeImpactDisputeCategory is updated such that dispute condition codes having mandatory updates in 23.1 Compliance (CS and CR) are set as true and other dispute condition codes are set as false.

How to test the functionality
  1. Create a VCR dispute.
  2. In Qualify dispute screen, select dispute reason as “I was charged/credited incorrectly”.
  3. Select the Sub Reason as “I was charged wrong amount”.
  4. Verify Transaction Receipt is not displayed as mandatory document in the ‘Supporting Document’ section.

Regulation-E eligibility criteria

ApplicationSmart Dispute for Issuers
Scheme ImpactVISA
Scheme ReferenceNA
Dispute ReasonNA
Functional CategoryRegulation E
Effective DateNA
Reported IssueFor a dispute to be eligible for Regulation E (Reg E), the disputed transaction must be within 60 days from the date of the statement containing the disputed transaction.

Disputes for transactions which are more than 60 days old from the statement date are evaluated as eligible for Reg E which is incorrect.

Smart Dispute ImplementationEvaluateNoRegECreditDate data transform uses Billing Cycle to calculate the statement date and the Reg-E cutoff date.

Billing Cycle value is not passed on to EvaluateNoRegECreditDate from SetNoRegECreditDate data transform. This resulted in empty statement date and consequently, Reg-E cut-off date always being 60 days after current date.

SetNoRegECreditDate has been updated to pass Billing Cycle parameter value to EvaluateNoRegECreditDate.

How to test the functionality
  1. As a back-office operator, create a dispute on a U.S checking account transaction.
  2. Select any dispute reason in Qualify dispute screen and submit the questionnaire.
  3. Verify application determines Regulation E criteria as defined in the below table:
    Bill CycleTransaction DateStatement DateDispute Request DateReg E eligible?
    2510-Mar-2325-Mar-23<= 60th day 24-May-23Y
    2510-Mar-2325-Mar-23> 60th day 24-May-23N
    2529-Mar-2325-Apr-23 <= 60th day 24-Jun-23Y
    2529-Mar-2325-Apr-23 > 60th day 24-Jun-23N
  4. If the dispute is eligible for Reg E, the dates Reg E PC Date and Reg E Final date will be visible in the Overview footer tab of the dispute.

Fix for dispute amount rounding off issue

ApplicationSmart Dispute for Issuers amd Acquirers
Scheme ImpactAll
Scheme ReferenceNA
Dispute ReasonNA
Functional CategoryDispute Creation
Effective DateNA
Reported IssueAs an Issuer, create a new claim and search for transactions. Select transaction(s) in non-ISK currency and create the claim. It is observed that for some of the clients, the dispute amount having decimal digits is rounded off in the dispute(s) created.
Note: The reported issue is not reproducible in OOTB Smart Dispute for Issuers application.
Smart Dispute ImplementationValue in PostedCurrencyExponent property is used to round of the dispute amounts. This property is initialized in GetTransactionDetails OOTB activity.

However, in the custom implementation layer of clients, GetTransactionDetails activity may be customized or replaced with another custom activity to retrieve the transactions list. In such cases, clients are expected to initialize PostedCurrencyExponent by invoking the OOTB map value GetCurrencyExponent at an appropriate step in the customized activity.

However, as a pre-cautionary measure, Smart Dispute now initializes the PostedCurrencyExponent property wherever rounding off is performed. PostedCurrencyExponent is initialized by calling the map value GetCurrencyExponent.

Also, if PostedCurrencyExponent is blank, rounding off will not be performed.

How to test the functionality
  1. Create a new claim.
  2. Enter an account number and click Search.
  3. Select any transaction(s) having a dispute amount with decimal places (E.g.: 100.50 GBP, 95.75 ISK etc) and click Create Claim.
  4. If the currency is not ISK, then the dispute amount should not be rounded. For instance, in the above example, the dispute amount should remain as 100.50 GBP.
  5. If the currency is ISK, then the dispute amount should be rounded to zero decimal places. For instance, in the example, the dispute amount 95.75 ISK should be rounded to 96.00 ISK

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