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.

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.

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.

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

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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

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”

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

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

• 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

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

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.

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.

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.

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

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.

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

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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

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.

• Find by Visa transaction inquiry
• Enter transaction details manually

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.

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.

• Disputes raised for partial amount
• Disputes with reason Incorrect Amount
• FX Gain / Loss in cross-currency disputes etc

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.

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.

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

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

EnterCancelOrAcctClosureDateForVE – Message

CancelDateWhenVEDomestic – Field value

CancelOrAcctClosureDateForVEDomestic – Field value

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.

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

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

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.

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

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.

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

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

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.

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.

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

What was purchased? - Merchandise

Did the cardholder receive the merchandise? - Yes

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

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

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

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.

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

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.

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.

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

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.

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.

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.

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.

Step 2: To capture Dispute Stage into a Param

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

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: ********”

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.

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

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.

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.

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

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.

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

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.

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.

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.

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.

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

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

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

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.

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

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

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.

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

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.

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.

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.

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

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.

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.

The data transform has been corrected to PreVCRConfigurations.

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

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

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

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

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

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.

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

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

1. Create a dispute on a Europe transaction.
2. Verify the currency is displayed as EUR throughout the dispute case lifecycle.

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

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

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

1. Create a MCOM Claim.
2. Proceed till pre-arbitration stage and verify the label updated for Due date.

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.

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.

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.

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.

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.

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

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.

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.

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.

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

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

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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

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.

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 .

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.

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

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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

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 are getting set for all cases created from CSR even if the case does not fall under RegE conditions.

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.

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.

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.

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

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.

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

1. Create a HND Claim.
2. Verify the case status is Open once the disputes are created.

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

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.

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.

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.

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

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

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.

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.

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.

1. Login to CSFS application.
2. Enter an account number and perform the search.
3. Verify the transactions are returned.

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.

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.

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.

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.

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?

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.

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.

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.

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

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

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.

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

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

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.

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.

This has been corrected to use standardclaims property.

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.

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

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.

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

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

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”

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.

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

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.

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.

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.

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.

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

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

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

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.

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

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.

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.

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.

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.

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

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.

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.

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.

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

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

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.

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

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.

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.

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.

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.

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.

• 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’

When: .CardholderAttemptToResolve=="N"

Set : .AttemptToResolveProhLocalLaw== .AttemptToResolveProhLocalLaw

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.

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.

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.

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.

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

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.

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 Cycle	Transaction Date	Statement Date	Dispute Request Date	Reg E eligible?
   25	10-Mar-23	25-Mar-23	<= 60th day 24-May-23	Y
   25	10-Mar-23	25-Mar-23	> 60th day 24-May-23	N
   25	29-Mar-23	25-Apr-23	<= 60th day 24-Jun-23	Y
   25	29-Mar-23	25-Apr-23	> 60th day 24-Jun-23	N

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.

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.

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