INC-A17594

INC-A17699

INC-A21008

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

1. Updated when rule WhenOtherViolationSource to include check for Send OI so that the case does not route to the Process Liability screen when Pre-Compliance is initiated with Send OI violation type.
2. Updated data transform LoadPreComplianceViolationType so that Send OI violation type is not visible for Issuers.
3. Updated data transform LoadPreComplianceViolationType on the Acquirer side so that the TypeOfVoilation drop down does not show Send RI/Payment for Acquirer.

1. Create a MCOM dispute in Smart Dispute for Issuers application.
2. Process Qualify dispute and proceed till the Answer Ancillary questionnaire screen.
3. Select Initiate Pre-compliance from Other Actions and observe that Send OI violation type is not available in the violation type dropdown.

Acquirer:

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

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

• PegaCard-Sd-Debit-MC-International
• PegaCard-Sd-Dispute-MC-International-Wk

1. In Smart Dispute Application, two dispute validations are created for transaction where the authorization date is on or before Nov 6, 2023 and transaction where the authorization date is on or after Nov 7, 2023.
2. The data transform PegaCard-Sd-Dispute-SetFailToFNSCounter changes the outcome of the disputevalidations where when conditions are “FNSCounterCheck_DV”, “FNSCounterGT15” to fail for stale disputes checking the latest value of FNS counter from database. Added logic to check Authorization Date after cutoff or before cutoff and change the output for the respective dispute validation.
3. In the PegaCard-Sd-Dispute CheckFraudFNSCounter existing when condition, logic is added/changed to check authdate and FNS counter for the dispute validations related to FNS counter.

1. Create a Master Card fraud case
2. Proceed till the Answer ancillary questions screen and submit chargeback
3. The outcome of the dispute validation applicable when authorization date is before Nov 6, 2023, will be determined depending on the below criteria.
   • If the number of Fraud-Related Chargebacks on the account is less than 15, dispute validation outcome will be "Pass”.

   Or

   • If the number of Fraud-Related Chargebacks on the account is less than 15, dispute validation outcome will be "Pass”.

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

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

  Or

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

1. In the Report definition PegaCard-Sd-Dispute-MC- GetMasterCardExcessiveCBS_GetCBCount the filter condition of account number is changed to Param.AccountNumber.
2. In the section PegaCard-Sd-Dispute-MC-ReasonCodeListForMCom in the dynamic layout the visibility condition is changed from expression to when condition DataIntegrityEdit1Check.

1. Create a MCOM dispute and proceed till the Answer Ancillary Questionnaire screen.
2. If 20 chargebacks are submitted each in the current month and in the previous month, then observe that Edit 1 information message is displayed.

1. Create a MCOM non-fraud dispute and proceed till the Answer Ancillary Questionnaire screen.
2. If 15 fraud chargebacks and 5 non-fraud chargebacks are already submitted on the account number in the month, then observe that Edit 2 information message is displayed.

1. Added “unavailable” document status in the when condition CheckDocumentRejectedbyMCOM to handle the CreateCB failure scenario.
2. Added “unavailable” document status in the when condition IsMCOMDocumentStatusFailed to handle the Pending doc queue scenario.

1. Create an MCOM dispute case.
2. Submit answer ancillary questions screen to submit the chargeback.
3. Make the CreateCB service fail because of the document status as Unavailable which comes from GetClaim service.
4. Observe that case lands Awaiting document assignment.
5. Attach the document and submit.
6. Verify that the UpdateCB service is invoked.

1. Create a Mastercard dispute case.
2. Check if already 40 or more chargebacks are submitted in previous month and 40 or more chargebacks are submitted in Current month.
3. Verify the Edit 1 message displayed in Answer ancillary screen for the 41st dispute.

Scenario 2: Edit 2 message

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

1. HealthCheck API call step has been added to both CreateCB and CreateFiling connectors in HandleServiceSpecificErrors flow.
2. From the connection problem flow, the subsequent call to GetClaim will happen only when the HealthCheck is successful to ensure the services are up and running.

1. Create a MCOM dispute case.
2. Submit Answer ancillary questions screen to submit the chargeback.
3. Make the CreateCB and healthcheck service fail with outage.
4. Observe that case lands on retry service error assignment and in the audit HealthCheck API is called after createCB failure and Getclaim is not invoked.
5. Remove the outage failure and case resumes with GetClaim API call and CreateCB API call.
6. Verify the dispute case lands on Awaiting Acquirer response screen.

1. Create a MCOM dispute case from Smart Dispute Issuers application.
2. Submit Qualify dispute screen.
3. Initiate Pre-Compliance.
4. Select “ATM Dynamic Currency Conversion” Violation type and submit the Pre-Compliance Screen.
5. Verify if the value of the “Type of violation” field is displayed as “ATM Dynamic Currency Conversion” in the read-only section in the MasterCom tab.

1. Create MCOM Fraud/Non-Fraud dispute case.
2. Proceed till Answer ancillary questions assignment.
3. Click on Other Actions and click Initiate Pre-Compliance.
4. Observe FilingagainstICA value populating on Pre-Compliance screen.
5. Close the dispute and reopen it.
6. Click on Other Actions and click Initiate Pre-Compliance again.
7. FilingagainstICA value should be populating on Pre-Compliance screen.

1. Create a dispute for a pending transaction.
2. Process the Answer ancillary questions stage after the matching posted transaction is found.
3. Submit the chargeback.
4. The CreateCB service call parameter page should hold the posted amount.

1. Created a data transform rule SetReversePCDateWrapper to call SetReversePCDate only if the cardholder is liable.
2. Updated dispute validation option’s action set to call SetReversePCDateWrapper in ProcessDispValidationsForVCR section.

1. Create a Visa claim case by disputing multiple transactions those are eligible Reg E.
2. Submit Qualify dispute screen.
3. Provisional Credit should be given to Cardholder after attestation.
4. Submit the dispute questionnaire screen.
5. Bulk process the Process dispute validation and perform write-off.
6. Validate if the Reverse PC flag is not updated in claim summary tab.

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

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

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

1. In Step 6.1.2, added wait period of 15 days when merchandise is cancelled and returned.
2. In Step 6.1.3, added wait period of 15 days when merchandise is returned.
3. In step 6.1.4, added wait period of 15 days when merchandise is cancelled.

1. Create a Visa dispute case.
2. Perform Qualify dispute screen by selecting the dispute reason as “I cancelled the Merchandise/Services".
3. Select “Did the cardholder cancel “-Yes and enter Cancellation date.
4. Select “Did the cardholder return the merchandise”-Yes and enter the return date.
5. Submit the Qualify Dispute screen.
6. Observe that the dispute should wait for 15 days from the recent date compared between the two given dates.

1. Create a Visa dispute case.
2. Perform Qualify dispute screen by selecting the dispute reason as “I cancelled the Merchandise/Services".
3. Select “Did the cardholder cancel “-No.
4. Select “Did the cardholder return the merchandise”. -Yes and enter return date.
5. Submit the Qualify Dispute screen.
6. Observe the dispute should wait for 15 days from the given returned date.

1. Create a Visa dispute case.
2. Perform Qualify dispute screen by selecting the dispute reason as “I cancelled the Merchandise/Services".
3. Select “Did the cardholder cancel “-Yes and enter Cancellation date.
4. Select “Did the cardholder return the merchandise”. -No
5. Submit the Qualify Dispute screen.
6. Observe the dispute should wait for 15 days from the given cancellation date.

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

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

1. Created properties which acts as a flag upon deadline expiry-AwaitingDisputeResponseFromIssuerSLAFlag,AwaitingPreCompIssuerResponseSLAFlag and PreArbitrationIssuerResponseSlaFlag.
2. Created data transform rule which checks if the properties are true- SetSlaFlagForAwaitingIssuerResponse,SetSLAFlagForPreArb, SetSLAFlagForPreComp.
3. Updated the SLA deadline escalation to call the data transform- AwaitingDisputeResponseFromIssuerSLA,PreArbitrationIssuerResponseSLA,PreCompIssuerRespSLA,AwaitingissuerPreArbResponseSLA.
4. Updated when rules to check if the deadline has expired- IsDispIssuerResSLAExpired,IsIssuerPrearbResSlaExpired, IsIssuerPreCompResSlaExpired.

1. Create a VISA collaboration case from the Issuer application.
2. Process the dispute screen by declining the Acquirer response and submit from the Acquirer application.
3. The case is at Awaiting Issuer response. Upon 30 days, if no response is received and the deadline expires, the case should be resolved as Issuer liable.

1. Initiate a Pre-Arbitration for VISA collaboration case from the Issuer application.
2. Process the dispute screen by partially accepting the Acquirer response and submit from the Acquirer application.
3. The case will be at Awaiting Issuer response. Upon 30 days, if no response is received and the deadline expires, the case should be resolved as Issuer liable.

1. Create a VISA allocation case from the Issuer application.
2. Process the dispute response by initiating Pre-Arbitration.
3. The case is at awaiting issuer response. Upon 30 days, if no response is received and the deadline expires, the case should be resolved as Issuer liable.

1. Create a VISA allocation case from the Issuer application.
2. Process the dispute screen by choosing Accept and Initiate Pre-Compliance and submit the Acquirer application.
3. Process the Initiate Compliance
4. The case is at Awaiting Issuer response. Upon 30 days, if no response is received and the deadline expires, the case should be resolved as Issuer liable.

1. Create a fraud dispute for the Visa transaction.
2. Complete the pre-dispute stages and raise a dispute to Visa.
3. As part of dispute response initiate a Pre-Arbitration from Acquirer application.
4. As part of the dispute Select ‘Accept partially’ in the Inbound pre-arbitration screen from Issuer application.
5. Verify the case status is "Pending-Closure" when SLA expires on 'Awaiting Acquirer Pre-arb' assignment.
6. Verify the case status is "Resolved-AcquirerLiable" after completing 'Process Issuer Liability' assignment.

1. Create dispute for the Visa cross currency transaction.
2. Process Qualify dispute screen with reason ‘I was charged the wrong amount’.
3. Enter amount on the cardholder's receipt & confirm the currency on the receipt as transaction currency.
4. Verify the Dispute amount is calculated correctly.

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

1. Updated SLA goal and deadline to 10 days and added offset days to goal and deadline from DSS in SetPreArbIssuerResSLA Data transform.
2. Updated SLA property in section AwaitProcessPrearbResponse.

1. Create a VISA collaboration case from the Issuer application.
2. Process the dispute screen by declining the Acquirer response and submit from the Acquirer application.
3. Initiate the Pre-Arbitration from the Issuer application.
4. Process Inbound Pre-Arbitration in Acquirers application.
5. Case moves to ‘Awaiting Issuer Response'. Verify that the SLA deadline should be 10days+ offset days from DSS.

1. Create Visa debit dispute case by selecting a transaction that is eligible for Reg E.
2. Submit Qualify dispute screen.
3. Provisional Credit is given to Cardholder after attestation.
4. Dispute case navigates to Review order insight details, choose process liability from Other Actions.
5. Proceed with partial write-off/cardholder liable option.
6. Resolve the case by answering Yes to the question ‘Do the order details help to resolve the dispute?’.
7. As cardholder is liable for remaining amount, PC should be reversed i.e liable amount should be debited from cardholder.

1. Create a Visa claim case by disputing multiple transactions with at least one transaction having a merchant credit.
2. Submit Qualify dispute screen.
3. Select a transaction in associated transactions screen and perform partial merchant credit.
4. Process till Dispute validation.
5. Select Continue dispute option and submit.
6. Navigate to Risk summary tab and verify Total chargeback amount and Total recovered amount.

1. Create a dispute case.
2. Process the Qualify dispute screen.
3. Process provisional credit to the dispute.
4. Click on accounting tab.
5. Click on suspense details table. Verify that the table should not elongate beyond the row contents.

Updated below Activities –

• ValidateAndProceedWithManualCase (Class:PegaCard-Sd-Dispute-),
• ValidateAndProceedWithManualCase (Class:PegaCard-Interface-Transaction-ACH),
• AttachTransaction (Class:PegaCard-Interface-Transaction-ACH )

Scenario 1:

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

Scenario 2:

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

Scenario 3:

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

1. Create a claim case with more than one REG E eligible transactions.
2. Process the disputes till Dispute validation screen.
3. At the claim level notice that we have dispute validations tab, and it is also present under Claim summary.
4. Select all the disputes and perform Claim level action “Process Dispute Validations”.
5. Resolve the disputes as write-off.
6. Verify the claim level “Dispute Validations” tab is displayed and is also available under Claim Summary.

• Shortcut rule: McomDisputesListWithStatus- Updated and applies to class PegaCard-Sd-Dispute-MC-International-Wki.
• Report Definition: VCRDisputesByStage- Updated to Select "Include Implementation class only" under "Report on descendant class instances" under Data Access tab.

1. Launch the Disputes manager portal in the Smart Disputes Issuer application.
2. Click Reports on the left panel.
3. Select MCom Reports->” Mcom Disputes List With Status”.
4. Verify the report runs successfully with correct data.
5. Select VCR Reports->” Display report for disputes by dispute stage”.
6. Verify the report runs successfully with correct data.

1. Create Visa/MCOM fraud dispute claim with multiple transactions.
2. Proceed till Qualify fraud dispute assignment.
3. Answer the questionnaire, choose the option as “No” for the questions “Do you want to continue as fraud?” and "Do you want to continue to Dispute?” and submit.
4. The claim case gets resolved with status as “Resolved-NoAction”. Verify if the fraud questionnaire is not displayed under Qualification details tab.

1. Create Visa/MCOM dispute case.
2. Proceed till Qualify dispute screen.
3. In the Attachments section, click on “Attach new” hyperlink and choose URL.
4. In subject field, give any text and in the URL field, give a long URL and submit.
5. Verify the URL should not overflow the table in the History tab.