INC-B12903

INC-B11078

INC-B14843

INC-B10201

INC-A23653

INC-B7655

• .CaseInformation page is prefixed on the step 6.4 existing when condition as follows:

  .CaseInformation.FraudClassification==”F”

1. Login to Smart Disputes for Issuers application.
2. Create a Visa fraud claim.
3. Process the applicable early resolution stages (if any).
4. Process the Qualify fraud dispute screen.
5. On the Dispute questionnaire/ Dispute validation screen, perform Actions->Edit Fraud report.
6. On the Edit Fraud report. screen, select Modify and select any Fraud type classification value from the drop-down list.
7. Submit the chargeback.
8. Go to the Audit->Third party tab and open the InitiateDisputeFromTransactionOrCaseOperation service page.
9. Verify whether the FraudTypeClassification field is present and has a value in the request header.

• The InternalId field is added under the External mapping tab for the class PegaCard-Int-Visa-QueueItemLog as follows:

  InternalIdà.InternalId.Id

1. Connect to the Database of the respective server.
2. Run this query to check whether there are queue records and check whether the merchantname column should not exist as a separate column: “select * from pegadata.sd_vcr_QueueItemLog;”
3. On the dev studio, on the App explorer search this class: PegaCard-Int-Visa-QueueItemLog.
4. Expand the Data modelPropertyMerchantName. Right click and proceed with Optimize for reporting.
5. On the wizard completion, switch over to ConfigureSystemDatabaseColumn Population Jobs.
6. Check for the job which includes MerchantName in the ForProperty(s) column.
7. The job should run with 100% processed items and with status as Completed.
8. Run the query below and check whether the MerchantName column is created with data values populated in the rows.

   select * from pegadata.sd_vcr_QueueItemLog

• Data transform RegEEligibleReversePCPreProcessingWrapperClass:PegaCard-Sd-Debit : Wrapper rule to set the PCReversal date and the pre-process RegEEligibleReversePCPreProcessing data transform for Reg E.
• Flow rule ReversePCOrderInsight Class: PegaCard-Sd-Debit : Updated the above data transform rule in the outgoing connector of Notify assignment.

1. Create a Visa claim case with multiple debit card disputes (only Reg E eligible).
2. Perform bulk action going forward for all the stages such as Process potential duplicates, Qualify dispute, Verbal attestation etc. in the claim till the Provisional Credit screen.
3. Provide Provisional credit to all the disputes.
4. In the Resolve Order details assignment, bulk process and answer Yes to the question: Do the order details help to resolve the dispute?.
5. Verify is the Reverse provisional credit assignment is displayed.
6. Navigate to the Claim summary tab of the claim case and verify whether the Reverse PC flag is marked as true.

• Flow rule InvokeRDRProcessing: Status parameter is set to Resolved-RDRCredit in the outgoing connector of correspondence utility. Additionally, status (Pending - Visa RDR Credit) is added at Awaiting Visa RDR Credit assignment.
• Flow rule UpdateDisputeStatus : The confirmation note is modified to get the localized field value.

1. Login to Smart Disputes for Issuers application.
2. Create a Visa dispute case.
3. Process the applicable early resolution stages (if any).
4. Process the Qualify dispute screen.
5. Complete the assignments until Awaiting Visa RDR credit by resolving all the assignments through the case life cycle (Qualify disputeView transaction & order detailsDispute questionnaireDispute validationsAwaiting Visa RDR credit).
6. After resolving Awaiting Visa RDR credit assignment at dispute level, the dispute will get resolved with status "Resolved - Visa RDR Credit" and the Claim also gets resolved with same status.
7. Verify the claim level view and observe that the "Actions" Navigation menu is not coming on the top right corner.

• Activity FindAuthTransactionMatch: Updated step 4 to map the original dispute amount to posted amount.
• Activity GetDisputeCaseDetailsList: Updated step 8.8 to map dispute amount and original dispute amount from dispute to claim level.

1. Login to Smart Disputes for Issuers application.
2. Create a dispute case for a pending transaction for which the transaction and posted amount are different with same currency.
3. Process the Qualify dispute screen.
4. Process the dispute questionnaire screen after the matching posted transaction record is found.
5. Submit the chargeback.
6. Verify if the SubmitDisputeQuestionnaireOperation service call request should hold the posted amount.

• Data transform SetAccountingAmount: Disabled step 1.3 and 2.3.
• Flow rule PreArbResponseAcctng: After Process Issuer liability assignment, removed the decision shape (.AssociatedTranAmount>0 ) and the corresponding connectors.

1. Login to Smart Disputes for Issuers application.
2. Create a Visa fraud dispute.
3. Process the applicable early resolution stages (if any).
4. Process the Qualify fraud dispute screen.
5. Process theassociated transactions screen by choosing a transaction.
6. Process the submit dispute questionnaire screen.
7. Process the Inbound Pre-Arbitration assignment by accepting it fully/partially.
8. Verify that the suspense accounting is opened for the unsettled part of transaction post associating a transaction.

• For the 10.4 other card absent environment the count of 35 fraud disputes is currently being calculated based on account number.
• The logic should be based on card number

• Report definition PegaCard-Sd-Dispute-Visa-GetPastDisputesForOtherCardAbsentDisputes : Changed the filter conditions to calculate based on CardNumber.
• Data transform PegaCard-Sd-Dispute-Visa- SetFlagsBasedOnPastDisputes : Added step 5.3 to set card number is added and in step 5.5 card number param is passed in the Data page.
• Data page D_GetpastDisputes: Card number param is passed

1. As a prerequisite, 35 fraud disputes should be existing under the same card number submitted under 10.4 card absent category.
2. Login to Smart Disputes for Issuers application.
3. Create the 36th fraud dispute under the 10.4 card absent category.
4. Process the applicable early resolution stages (if any).
5. Process the Qualify fraud dispute screen.
6. Process the submit dispute questionnaire screen.
7. The dispute case should be navigated to the Dispute validations screen.
8. Verify the Dispute validations fail under the footer tab (VCR -> Dispute details -> Dispute validations) with below validation message:

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

• Data transform PegaCard-Sd-Debit SetWrapperReverseProvisionalCreditDate : The SetReversePCDate Data transform is called only on the .ResolveAfterTAOD=="True".
• Section ReviewOrderInsightWrapper : Added the new Data transform created in dynamic layout 3.

1. Login to Smart Disputes for Issuers application.
2. Create a Visa fraud dispute.
3. Process the applicable early resolution stages (if any).
4. Process the Qualify fraud dispute assignment.
5. Verify if the case waiting at View transaction order details screen.
6. Now select No to the question Do the order details help to resolve the dispute? and submit the assignment.
7. Verify if the Reverse PC flag in the claim summary tab should not be checked.

• Post activity of the dispute questionnaire assignment has a sub activity “ValidateAuthErrors” to validate authorization response code on both AssociationData and “.AssociationData.AuthorizationData”. If the valid authorization response code “00” is received then, system sets error on the page and stops the case to advance.
• To fix the issue, added .IsRelatedToLP!="Y" condition to check if the dispute is related to Late presentment and if yes, skips the step to set error message

1. Login to Smart Disputes for Issuers application.
2. Create a dispute on visa transaction which is a valid transaction (authorization response code is 00) and valid for late presentment.
3. Process the applicable early resolution stages (if any).
4. Process the Qualify dispute screen by selecting the I was charged a long time after the transaction occurred dispute reason.
5. In the dispute questionnaire screen, if the answer to Is the dispute related to late presentment? is selected as Yes then case should be advanced, and the dispute should get submitted.
6. If the answer for the above-mentioned question is selected as No then it means that issue is not related to late presentment and as the transaction authorization is success, system should throw error with message as below :

   There appear to be no issues with the transaction authorization. Please consider filing the dispute using a different dispute category.

• When a dispute is received by the Acquirer, and it is later recalled by Issuer then the case gets resolved in Acquirer application.
• If the Issuer resubmits the dispute with same visa case number, then the new case is not getting created in Acquirer application.

• Activity ProcessBatchQueueRecords : Added step 7 specific to AWAITING_ACTION_BQ_DISPUTE and removed the reference of the same queue in 8th step.
• Report definition GetDisputeUsingVisaCaseNumber : Updated the report definition to add pxCreateDateTime field to sort the cases from latest to old. Also checked the check box Use null if empty for the visacasenumber filter.
• Decision table CheckIfQueueCanBeProcessedInSDForAcquirer : Removed recalled status entry for the queue AWAITING_ACTION_BQ_DISPUTE as they get processed through INCOMING_BQ_RECALLS queue.

1. Login to Smart Disputes for Acquirer application.
2. Process the dispute response for visa transaction in using a batch queue record from AWAITING_ACTION_BQ_DISPUTE queue.
3. Process the recall record for the same visa case number from INCOMING_BQ_RECALLS queue and observe the case is resolved as “Resolved-DisputeRecalled”.
4. Create one more entry to the d queue table for incoming dispute in the queue AWAITING_ACTION_BQ_DISPUTE with the same visa case number.
5. Verify if a new case gets created with same visa case number considering the scenario where Issuer reinitiated the dispute with same visa case number.
   Note: The same scenario can be tested in live by connecting visa mte2 server.

• Flow rule InitiatePrearbitrationAccounting Class: PegaCard-Sd-Dispute-Visa- : Updated to set .AccountingAmount to AmountOutstandingPreArbRes in the connector for the scenario where cardholder is held liable, and Visa FX Accounting is not involved.

1. Login to Smart Disputes for Issuers application.
2. Create a Visa dispute case.
3. Process the applicable early resolution stages (if any).
4. Process the Qualify dispute screen.
5. Process the Submit dispute questionnaire screen and submit the dispute to Visa.
6. Dispute is declined by Acquirer.
7. Process the dispute response by initiating a Pre-Arbitration.
8. Pre-Arbitration is accepted partially by Acquirer.
9. Make the cardholder liable for the remaining amount.
10. This cardholder re-debit accounting should be updated with correct value.
11. The card holder should be debited, and Receivable Account should be credited. The final outstanding amount should become zero.

• Data transform GetAssociatedTransactionListOperationResponse : The mapping of the CustomerName property is updated from (Param.FirstName+ +Param.LastName) to CustomerName in step 8.1.6 to avoid the failure when the CustomerName property has more than 50 characters.

1. Login to Smart Disputes for Issuers application.
2. Create a Visa dispute case for a fraud or non-fraud transaction.
3. Process the applicable early resolution stages (if any).
4. Process the Qualify dispute screen or Qualify fraud dispute screen by selecting a dispute reason and corresponding questionnaire.
5. Verify if the service GetAssociatedTransactionListOperation service is invoked and the CustomerName is populating under the PurchaseInquiryInformationDetail page if page is available.

Once liable party is modified, the Acquirer liable amount is getting updated to the respective value.

• Activity GetFinalDecision: Updated with step 11 to invoke ClearVCRLiableResolution to update the AcquirerLiableAmount.

1. Login to Smart Disputes for Issuers application.
2. Create a Visa dispute case.
3. Process the applicable early resolution stages (if any).
4. Process the Qualify dispute screen.
5. Process the Submit dispute questionnaire screen and submit the dispute to Visa.
6. Dispute is declined by Acquirer.
7. Process the dispute response by initiating a Pre-Arbitration.
8. Pre-Arbitration is declined by Acquirer.
9. Process the Pre-Arbitration response by initiating Arbitration.
10. Review Inbound Arbitration details assignment gets created on receiving the Arbitration response.
11. On submit the Review Inbound Arbitration details screen, the Process Arbitration ruling assignment gets created.
12. Select Both as the liable party and split the Issuer liable amount and Acquirer liable amount. (Ensure the Issuer liable amount is greater than 5000 USD or equivalent to appeal for final ruling.)
13. Awaiting final decision by Visa assignment gets created. (This assignment must be submitted by SLA agent when VISA response is received).
14. When the VISA response is received (Response comes with liable party as "Both") SLA agent moves the dispute to the Process Arbitration Appeal Ruling assignment.
15. Verify the Acquirer liable amount is equal to the case filing amount if the liable party as per association rule is Both upon the initial page load in this assignment.

• Flow action RouteToDisputeQuestionnaire: Created flow action to route back to Dispute questionnaire screen by using the post activity as SetTicket with parameter as ResumeDisputeQuestionnaire.
• Flow rule PendDocAttach: Updated flow by adding local action as RouteToDisputeQuestionnaire on Awaiting supporting document assignment.
• Section RouteToDisputeQuestionnaire: Created section to route back to Dispute questionnaire and plug it in the RouteToDisputeQuestionnaire flow action.
• Field value Route_disputequestionnaire: Createdfield value to show the content to route back to Dispute questionnaire and plug it in the section RouteToDisputeQuestionnaire.

1. Login to Smart Disputes for Issuers application.
2. Create a Visa dispute case.
3. Process the applicable early resolution stages (if any).
4. Process the Qualify dispute screen by selecting a dispute reason and corresponding questionnaire.
5. Process the Dispute Questionnaire screen by keeping one of the mandatory documents need to be attached (without attaching the documents in the Dispute questionnaire screen).
6. The dispute case will land on the Awaiting supporting documents screen.
7. Attach a document and submit the dispute to Visa.
8. When the dispute is rejected by Visa in case of any exceptions, the dispute case lands on the Awaiting supporting documents screen.
9. Verify if there is a local action as Review dispute questionnaire (Other actions -> Review dispute questionnaire) that could be used to route back to Dispute questionnaire screen.
10. On click of Review dispute questionnaire local action, the dispute case will land on the Review dispute questionnaire screen.
11. On submit, the dispute case will route back to Dispute questionnaire screen.

• When condition DisplayInterviewTab: When rule updated to show the interview tab on the dispute case based on the CardPossessionFraud property.
• Section pyCaseContent: Updated thesection to show the Qualification details tab at the claim case based on the condition (.IsRecentClaim != '' || .CardPossessionFraud != '' || .RegIIQuestionnaire.FraudOccured!='')

1. Login to Smart Disputes for Issuers application.
2. Create a Visa fraud dispute.
3. Process the applicable early resolution stages (if any).
4. Process the claim level Qualify fraud dispute screen by answering the question Are you in possession of your card? and click on save.
5. Verify if the Qualification details tab is visible in the footer tab for the claim case.

• Dispute cases are looping to call GetTransInquiryResultsOperation API every 30 mins when RolTransactionId is not received indefinitely.
• This should stop after the wait limit is reached which is not happening.

• Data transform SetAsyncTIWaitDateTime: Steps 3 and 4 were removed, to only set the waiting time in minutes.
• Data transform SetAsyncTIWaitTimeAndRetry: Created to call the SetAsyncTIWaitTimeAndRetry data transform and set retry time limit in days.
• Flow TranInquiryFlow: Updated the data transform from SetAsyncTIWaitDateTime to SetAsyncTIWaitTimeAndRetry. on the async connector from the visa response decision shape (after the submitTranInquiry sub flow).

1. Login to Smart Disputes for Issuers application.
2. Create a live Visa dispute case.
3. Process the applicable early resolution stages (if any).
4. Process the Qualify dispute screen.
5. On submit of Qualify dispute screen, GetTransInquiryResultsOperation API is invoked to fetch Transaction Inquiry results.
6. The GetTransInquiryResultsOperation service is invoked again upon receiving null value for RolTransactionId in the service response.
7. This service gets invoked repeatedly after every 30 minutes.
8. Verify if the service invocation stops after the specified wait limit is reached.
9. Validate the service response at: Audit->History-> GetTransInquiryResultsOperation view response

• Data transform CalculateReceiptAmount: New extensible data transform created. The receipt amount is set to cardholder receipt amount divided by the currency conversion rate.
• Data transform SetReceiptAmount: Step 2.1 in the Data transform is updated to call data transform CalculateReceiptAmount.

1. Login to Smart Disputes for Issuers application.
2. Create a Visa dispute case.
3. Process the applicable early resolution stages (if any).
4. Process the Qualify dispute screen with dispute reason as
5. Charged incorrectly and sub reason as Charged wrong amount.
6. Enter the amount in cardholder’s receipt and select the currency as the transaction currency.
7. After submitting the Dispute Questionnaire screen, the dispute amount should be calculated correctly with respect to the currency conversion rates.

• When condition IsEditFraudReportNotSubmitted: A period (.) was added before the IsEditFraudReportProcessing property name.

1. Login to Smart Disputes for Issuers application.
2. Create a Visa fraud dispute case.
3. Process the applicable early resolution stages (if any).
4. Submit the Qualify fraud dispute screen of dispute case while failing the Visa API or creating a business exception to get an RTSI error message.
5. Submit the Qualify Fraud Dispute again by activating the Visa API or discarding the changes that caused the business exception.
6. Verify if the previously generated error message has now disappeared.

• The error message for error code E-900003544 is not being parsed correctly.
• Invalid characters – " is being displayed multiple times with the error message upon submitting the dispute questionnaire.

1. Activity SetVCRRESTServiceAudit:
   • New step added after step 10 to remove all invalid characters.
   • Pre-condition is added to the same step to check the service name, operation status and error code.
2. Activity HandleBusinessException:
   • New step added after step 12 to remove all invalid characters and for string formatting.
   • Pre-condition is added to the same step to check the service name and error code.

1. Login to Smart Disputes for Issuers application.
2. Create a Visa dispute case for a fraud or non-fraud transaction.
3. Process the applicable early resolution stages (if any).
4. Process the Qualify dispute screen or Qualify fraud dispute screen by selecting a dispute reason and corresponding questionnaire.
5. Submit the dispute questionnaire.
6. Verify if the validation error message displayed should not have " characters.

• Flow AcquirerVCRAllocationFlow: The data transform in the connectors for Recall Precompliance and Recall Pre-arbitration were updated to UpdatePreCompRecallProperties and UpdatePreArbRecallProperties data transforms respectively.
• In both the data transforms the DisputePreArbId and DisputePreCompId were removed respectively from both the work page and the association data.

1. Login to Smart Disputes for Acquirers application.
2. Process an Inbound fraud dispute by initiating a Pre-Arbitration or Pre-Compliance by providing all the required responses.
3. Check the CreateDisputePreArbOperation or CreateDisputePreCompOperation service response and verify the DisputePreArbId or DisputePreCompId property has value respectively for both the scenarios.
4. Initiate recall for the dispute case.
5. Repeat step 2.
6. Verify if the DisputePreArbId or DisputePreCompId property should not be present in the service request.

• The below mentioned validation rules are updated to validate the properties conditionally.
  • Validate rule ValDoNotRecognize.
  • Validate rule ValDoNotRecognizeData.

1. Create a dispute case through Web Self Service with details as below:
   • DisputeReason: DoNotRecognize,
   • ATRInd: "Y",
   • RecognizeMerchant: "True",
   • OtherMemHaveCardAccess: "",
   • GaveAcctNbrToMerch:"",
   • CardOrAcctNbrLostOrStolen: "",
   • ContinueAsFraud: "",
   • Comments: "Test"
2. Verify the dispute is case is created and resolved by the STP agent or STP queue processor.

• Visacasenumber is added in the external mapping of the following classes:
• • PegaCard-Sd-Debit-Visa-International-LAC
  • PegaCard-Sd-Dispute-Visa-International-US-Wk
  • PegaCard-Sd-Debit-Visa-International-CEMEA
  • PegaCard-Sd-Debit-Visa-International-Canada
  • PegaCard-Sd-Debit-Visa-International-AP
  • PegaCard-Sd-Dispute-Visa-International-Wk

1. Login to Smart Disputes for Issuers application.
2. Create a Visa dispute case in live environment.
3. Process the applicable early resolution stages (if any).
4. Process the Qualify dispute screen.
5. Proceed with the questionnaire assignments and submit the chargeback.
6. Now pick this case from Awaiting_Action_BQ_Dispute queue for Acquirer member role.
7. Read and process this case in Acquirer application. Open the Process inbound dispute and respond.
8. When a queue response is available from Acquirer, run the Job scheduler from the Issuer application.
9. While processing the record, there should not be any error encountered at GetVCRIssuerCase report definition and user should be able to proceed with further processing.

Alternate approach (not Live Testing)

1. In the Dev studio, search and open the report definition GetVCRIssuerCase.
2. Run the report by passing any valid/invalid case number.
3. The report should run successfully without throwing any error.

• When a Visa dispute case is created in the Issuer application with Rest as service and a document is attached in the Dispute questionnaire screen, the dispute is submitted to Visa and the dispute case is at the Awaiting acquirer response screen.
• Batch queue reads and processes this dispute case in Acquirer application.
• When the user expands the list of received documents section in the Process Inbound dispute screen, documents attached from Issuer are not displayed.

• Rest connector rule GetVCRAttachment: New rule created.
• When rule EnableConnectHttpForImageDownload: Created which checks the DSS “EnableConnectHttpForImageDownload.
• DSS EnableConnectHttpForImageDownload: Created.
• Activity RESTDownloadImage: Updated to add step to call Connect-Rest when EnableConnectHttpForImageDownload is false, and calls Connect-HTTP when it is true.

1. Login to Smart Disputes for Issuers application.
2. Create a Visa dispute case.
3. Make sure that case is being created with Rest as service.
4. Process the applicable early resolution stages (if any).
5. Process the Qualify dispute screen.
6. Process the Submit dispute questionnaire screen along with attaching a supporting document.
7. The dispute is submitted to Visa and dispute case is at the Awaiting acquirer response screen.
8. Batch queue reads and processes this dispute case in Acquirer application.
9. Open the Process Inbound dispute assignment.
10. Expand the list of received documents section on the screen.
11. Verify the supporting documents displayed those were attached from Issuer.

• When a Visa dispute case is created in the Issuer application with Rest as service and a document is attached in the Dispute questionnaire screen, the dispute is submitted to Visa and the dispute case is at the Awaiting acquirer response screen.
• Batch queue reads and processes this dispute case in Acquirer application.
• When the user expands the list of received documents section in the Process Inbound dispute screen, documents attached from Issuer are not displayed.
• The document name under list of received documents from issuer are always displayed as other.

• Data transform GetImageOperationResponse : Updated to set the Document name coming in comment element of GetImage Operation to a parameter Param.DocName.
• Activity GetImageOperationResponse : Updated to modify step 3 to set the Document name onto the NewAttachment page.( NewAttachment.pxAttachName). This document name is coming as param value from the data transform GetImageOperationResponse.

1. Login to Smart Disputes for Issuers application.
2. Create a Visa dispute case.
3. Make sure that case is being created with Rest as service.
4. Process the applicable early resolution stages (if any).
5. Process the Qualify dispute screen.
6. Process the Submit dispute questionnaire screen along with attaching a supporting document.
7. The dispute is submitted to Visa and dispute case is at the Awaiting acquirer response screen.
8. Batch queue reads and processes this dispute case in Acquirer application.
9. Open the Process Inbound dispute assignment.
10. Expand the list of received documents section on the screen.
11. Verify the supporting documents displayed with a valid name those were attached from Issuer.

• Correspondence rule EBDRForm1221: Updated as highlighted:

  {when pyWorkPage.ReqNewEBDRAtPreARb=="true"}

  <tr><td>

  </br><b>Additional

  Comments</b>:{pyWorkPage.PreArbMemo} </td></tr> {/when}

1. Login to Smart Dispute for Issuers application.
2. Create a Mastercard dispute.
3. Process the applicable early resolution stages (if any).
4. Process the Qualify dispute screen.
5. Process the Answer ancillary questions screen by selecting Reason code as CardHolder Dispute - 4853 and condition code as Goods or Services Not Provided – 2, Addendum Dispute – 9 and submit the dispute case.
6. Process Awaiting Acquirer response.
7. On the Review Second Presentment, select Initiate Pre-Arbitration and proceed.
8. On the Initiate Pre-Arbitration screen, select the options as below and submit the dispute case:
   1. Do you want to change the reason code ?* as No”
   2. Arbitration reason* - Cardholder Reasserts their Claim and
   3. Pre-Arbitration memo* pre-populates.
9. Verify the EBDRForm1221PreArb in attachments and check that Additional comments section is properly coming on the form.

• GetCBStatus API fails due to SSL error for the first time and an MCOM Service Error task gets created and when subsequent service gets retried, and it is opening a new thread in each retry.
• As result DisputeListByMComCaseStatus page list does not get set with the request parameters (chargebackId, claimId), which it got through data transform rule PreparePageforGetCBStatus.

• Data transform GetCBStatus Class: PegaCard-Sd-Dispute-MC- :Added step 2 to call the PreparePageforGetCBStatus data transform.

1. Login to Smart Dispute for Issuers application.
2. Create a Mastercard dispute.
3. Process the applicable early resolution stages (if any).
4. Process the Qualify dispute screen.
5. Process the Answer ancillary screen by responding to the questions.
6. Submit for chargeback.
7. Case is now at “Awaiting Acquirer response”.
8. Ensure Acquirer Representments the case.
9. Ensure GetCBStatus API fails due to SSL error.
10. Retry the MCOM service error assignment.
11. Validate that the service is passed and assignment lands on the Review Second Representment.

• Decision tree SetMMTMessageFor4855 : In the decision tree rule, added the code for representment 2713 to set RepreMemberMessageText property.

1. Login to Smart Dispute for Issuers application.
2. Create a Mastercard dispute case.
3. Process the applicable early resolution stages (if any).
4. Process Qualify dispute or Qualify fraud dispute screen.
5. Process the Answer ancillary questions screen and submit the chargeback.
6. Login to Smart Dispute for Acquirers application.
7. Process the chargeback response for above created Mastercard dispute case.
8. Process the representment for reason code 4855 and Representment Code 2713.
9. In the third-party tab, verify the request for CreateCB to find the messageText populated.

• When condition IsPaymentTxnNotEligibleForLP:
• When ruleupdated condition A to .MCOM_GetAuthDetail.processingCode

1. Login to Smart Dispute for Issuers application.
2. Create a dispute for a Mastercard transaction.
3. Process the applicable early resolution stages (if any).
4. In Qualify dispute screen, select the reason code “Authorization-related Chargeback-4808” and Condition Code “Expired Chargeback Protection Period-2” and submit the dispute case.
5. Process and submit the Answer ancillary question screen.
6. Verify if the transaction authorization date and central processing date has the difference more than the defined time frames as mentioned below when condition, then Dispute validations will Pass else Dispute Validations will Fail and user will land on to the Dispute Validation Screen to review the conditions before submitting the chargeback.

   When Condition : IsPaymentTxnNotEligibleForLP : The authorization was identified as a Payment Transaction and the transaction was presented in clearing more than one-calendar day after the authorization approval date.

• TransactionInformation Mail
• EBDRForm1221Footer Mail
• EBDRForm1221ForRC4841Footer Mail
• EBDRForm1221ForRC4841Header Mail
• EBDRForm1221ForRC4855Footer Mail
• EBDRForm1221ForRC4855Header Mail
• EBDRForm1221ForRC4860Footer Mail
• EBDRForm1221ForRC4860Header Mail
• EBDRForm1221Header Mail
• EBDRForm1240Footer Mail

1. Login to Smart Dispute for Issuers application.
2. Create a dispute for a Mastercard transaction.
3. Process the applicable early resolution stages (if any).
4. Process the Qualify dispute screen.
5. In Answer ancillary questions screen, select 4853 reason code, answer the relevant questions, and submit the assignment.
6. The chargeback should be submitted to Mastercard, and the dispute case should be waiting in “Awaiting Acquirer response “
7. Validate the EBDR generated in new template.
8. Repeat above steps 2 to 6 for reason code 4834.

When did the merchant agree to refund the transaction to the cardholder?

• Section RC4808CC2 : Updated to add label DateMerchantAgreedToRefundIsRequired and updated required condition for When did the merchant agree to refund the transaction to the cardholder? field.
• pyCaption – DateMerchantAgreedToRefundIsRequired : Created that will display information message Date merchant agreed to refund is required for all refund transactions.
• When condition : IsDateMerchantAgreedToRefundBlank : New when rule added to check if When did the merchant agree to refund the transaction to the cardholder? field is blank for refund transactions.
• Flow rule EvaluatePreDispValidations : Added new rule to check When did the merchant agree to refund the transaction to the cardholder? field is blank for refund transactions, before checking the validations.
• Flow rule DisplayDisputeValidations : Updated to include a new flow created EvaluatePreDispValidations, which is used for evaluating the conditions before checking the dispute validations.

1. Login to Smart Dispute for Issuers application.
2. Create a dispute for a Mastercard transaction.
3. Process the applicable early resolution stages (if any).
4. Process the Qualify dispute screen.
5. In the Answer ancillary questions screen select Reason code – Authorization-related Chargeback-4808 and Condition code as Expired Chargeback Protection Period-2.
6. The below question is displayed as optional, irrespective of transaction types:

   When did the merchant agree to refund the transaction to the cardholder?

7. When the Answer ancillary questions screen is submitted – GetAuthdetails service gets invoked and based on few response parameters system can determine, what type of transaction it is.
8. If the transaction type is refund and the field When did the merchant agree to refund the transaction to the cardholder? is blank, then user will be routed back to Answer ancillary questions screen displayed with an informational message:

   Date merchant agreed to refund is required for all refund transactions.

9. The below field is now displayed as mandatory:

   When did the merchant agree to refund the transaction to the cardholder?

• The existing logic for checking the invalid CVV2 and reason code was moved from FetchAuthAndClearingDataFlow flow to EvaluatePreDispValidations inside DisplayDisputeValidations flow just after the ‘Auth and Clearing Data’ subprocess.

1. Login to Smart Dispute for Issuers application.
2. Create a Mastercard fraud dispute.
3. Process the applicable early resolution stages (if any).
4. Process Qualify fraud dispute screen.
5. Process the Answer ancillary questions screen with fraud reason code 4837 and submit the chargeback.
6. Verify if the flow returns to Answer ancillary questions screen as the CVV2 is invalid.
   Note: The case should have invalid CVV2 conditions.

• Activity ProcessBulkAction: Post jump condition of call ValidateDetermineReasonCode activity updated to @PageExists(tmpSelectedDispute) && @hasMessages(tmpSelectedDispute).

1. Login to Smart Dispute for Issuers application.
2. Create a multiple dispute claim for Maestro transactions.
3. Process the applicable early resolution stages (if any) at claim level using bulk action.
4. Process Qualify dispute screen at claim level using bulk action.
5. Process Select charge fees screen at claim level using bulk action.
6. Process the Verbal attestation screen at claim level using bulk action.
7. Process the determine reason code screen using the bulk action without any error.

• Activity QFDCheck: The first when condition expression was updated in the steps 1 and 2 as specified below.
• The existing logic for the following combination of Reason code and Condition code – (4834, 4 & 2) and (4831, 1) respectively was removed & similar logic was added for Reason code 71 and Condition code 1.

1. Login to Smart Dispute for Issuers application.
2. Create a dispute case for a Maestro transaction.
3. Process the applicable early resolution stages (if any).
4. Process Qualify dispute screen with dispute reason as charged wrong amount.
5. Select the reason code as 71(Maestro - Transaction Amount Differs) and the condition code as 1(Transaction amount is different).
6. Post submitting the qualify dispute assignment, the dispute amount should be updated to the difference between Original Dispute Amount and Authorized Amount.

• Data transform Simulate_GetAuthDetail: Updated the banknetDate property to set the date as 30 days before the current date.

1. Login to Smart Dispute for Issuers application.
2. Create a Mastercard fraud dispute.
3. Process the applicable early resolution stages (if any).
4. Process Qualify fraud dispute screen.
5. Process the Answer ancillary questions screen.
6. User should navigate to the dispute validations screen.
7. Verify the ‘after Nov 7’ FNS counter in the Dispute validations screen.
   Note: There should already be at least 35 chargebacks for the merchant.

• Activity PrivilegeBasedRouting Class: PegaCard-Sd-Dispute- : Added additional check in step 7 pre-condition for Param.Worklist == “false”
• Activity PrivilegeBasedRouting Class: PegaCard-Sd-Debit : Added additional check in step 7 pre-condition for Param.Worklist” == “false”
• Activity PrivilegeBasedRoutingForCaseFromAPI Class: PegaCard-Sd-Dispute- : Added step 4 for setting route to Worklist and removed jump from step 3.

1. Create either a Fraud or Non-Fraud case through WSS API (applicable for Mastercard/Visa).
2. The dispute case will land on Qualify dispute/Qualify fraud dispute/ Process potential duplicates screen.
3. The dispute case will be routed to Fraud/Customer Claim workqueue.
4. The user fetches the dispute case from the workqueue, processes it and submits the assignment.
5. The subsequent assignment should also get routed to the same operator’s worklist who initially picked the case for processing it.
6. This flow is applicable until the chargeback submission.

• Section AdjustmentDetails Class : PegaAcct-Step- : Deleted the blank column under Txn amount base label.

1. Login to Smart Dispute for Issuers application.
2. Create a dispute for a Visa, Mastercard or AMEX transaction.
3. Process the applicable early resolution stages (if any).
4. Process the Qualify dispute screen.
5. Process Dispute questionnaire or Answer Ancillary questions screen.
6. Process Dispute validations screen if applicable and proceed to submit the chargeback.
7. Verify under the accounting tab for the adjustment details in the tax amount base field if there should not be any blank column getting visible.

• Rule overrides utility is provided to find the rule overrides in the implementation layer which needs retrofit as the same rule has got updates in the smart dispute latest version.
• The utility is not working for the upgrades from one of the 8.x version to 8.y version.
• Example : Upgrade from SD 8.7 to SD 23.

• Property UpgradeFrom – Updated to include SD87, SD88 and SD23 in the local list to get them displayed on the utility landing page in Select version from which base application was upgraded/ compared from drop down.
• Decision table BaseAppUpgradeFromVersionRange : Updated to add entries for the Smart Dispute 8.7, Smart Dispute 8.8 and Smart Dispute 23 to get the range of the ruleset versions to be considered to identify overrides
• Section LauchSection – Updated to the source of the Select application auto complete to use the data page instead of the report definition

1. Add the compare rules ruleset to the implementation layer application.
2. Run the rule changes utility first to identify the rules that are changed / updated as part of the latest Smart Dispute version (Upgrade To)
3. Run the overrides utility to identify the overrides that needs retrofit and ensure that we see Smart Dispute 8.7, Smart Dispute 8.8 and Smart Dispute 23 versions are available to select in Select version from which base application was upgraded/ compared from drop down.