Fetching the alert ID and merchant outcome for the Smart Dispute for Issuers application can be performed by using either of the following methods:

• Manual polling – By manually submitting the Awaiting AlertID assignment, the system calls the /transactions/batch/{batchId} URL initially and waits for the Ethoca system’s response. Calling /alerts/batch/{batchId} on a periodic basis allows you to check the alert status and outcome for changes.
  The process for callback or Manual polling is configured in the PerformEthocaDisputeResolution flow.
• Event notification callback – If you provide a callback endpoint to the Ethoca system, it sends you notifications of an event. The following events can be raised:
  • Batch processed – Confirms that the transactions sent from the dispute system are successfully forwarded to the respective merchant and the dispute system can query for the alert ID to take the processing further.
  • Alert outcome updated – Confirms that the merchant has responded to the dispute raised and the dispute system can query Ethoca to fetch the merchant response.

Manual polling

Manual polling is used in the following scenarios:

• The callback feature is disabled
• The callback feature is enabled, but a user invoked the manual flow from the Actions tab for proceeding manually

Alert ID

Once the transaction is posted to Ethoca and the case is in waiting status during the Callback flow, the user can continue to fetch the Alert ID manually by selecting Invoke Ethoca Manual Polling from the Other Actions menu. This calls the GetManualEthocaOutcome flow. If the callback functionality is disabled, the case is routed to the GetManualEthocaOutcome manual polling flow. The assignment is displayed after launching the Invoke Ethoca Manual Polling action, which is configured in the InvokeEthocaCallbackService section.

Once the disputes operator submits the assignment, the GetAlertID activity is called to fetch the Alert ID. If the case is processed and delivered, the flow is resumed and fetches the merchant outcome. If the transaction is not yet processed by the Ethoca system, the dispute waits at the Awaiting Ethoca AlertID assignment. The system continues trying to fetch the alert ID for 5 minutes, but if the transaction is still not processed and delivered once that time has elapsed, the interaction with Ethoca is ended and the case reverts back to the normal flow. This configuration occurs in the SetEthocaResolutionSLA flow.

Merchant outcome

After successfully fetching the alert details and once the transaction has been delivered to Ethoca successfully, a GetMerchantOutcome flow is called to fetch the merchant response. The timeline for the merchant to provide the outcome is 24 hours, which is specified by the Ethoca team.

In manual polling, four attempts are made to fetch the merchant outcome at an interval of 8 hours. At every attempt, if the merchant has not provided an outcome, the dispute waits at the Awaiting merchant response assignment for 8 hours. After 8 hours, the flow resumes and the dispute tries to fetch the outcome again. This process is performed automatically every 8 hours.

If the time limit of 24 hours and grace period of 8 hours is exceeded, the interaction with the Ethoca system is ended and the dispute reverts back to the Chargeback flow.

Callback processing

The callback service enables the dispute system to receive the notifications for alert IDs and merchant outcome processing.

Alert ID

The callback service can be enabled or disabled through the EnableThirdPartyCallbackService dynamic system setting. When the callback functionality is enabled, after posting the transaction to Ethoca, the case waits at the Awaiting Ethoca Response assignment by default. The user can choose to continue the callback functionality or manual polling by clicking the Actions tab. While the case is waiting at the Callback flow (at the Awaiting Ethoca response assignment), a service REST, EthocaServicePackage.v1.EventNotificationCallback checks for any notifications from Ethoca.

If you receive any notifications from Ethoca (for example, “Alert outcome updated” or “Batch processed”), the service REST maps the response to a property and calls the InvokeEthocaCallbackService activity. This activity maps the response. Based on the event type received, corresponding activities are called for either the “Batch Processed” or “Alert Outcome Updated” notifications.

The first notification after posting a transaction to Ethoca is the “Batch Processed” event type. Based on this event type, the EthocaEventTypeBatchProcessed activity is called from InvokeEthocaCallbackService. This activity, which is based on the data received in the notification, identifies the corresponding work object by calling an OpenDisputeCaseByEthocaID report definition that sends the ID received in the notification event as a parameter. The activity then resumes the flow for that work object.

Once the PerformEthocaDisputeResolution flow is resumed, a check is performed on the event type and is routed to the GetEthocaAlertId flow.

An initial check is performed at the start of the flow if AlertId already exists and proceeds based on the result. If AlertId is not available yet, a GetEthocaAlertId activity is called, which is used to fetch the case details and AlertId through a GetAlertID REST connector that is called from the D_GetAlertID data page by passing BatchID as a parameter. The endpoint URL for all service connections is configured in the D_InitializeEthocaData data page.

After a successful interaction with Ethoca, the data received is stored on to the EthocaInformation clipboard page. The corresponding audits and logs are added to the logger list to display the same in the footer tab.

Merchant outcome

If the delivered count in the response is greater than 0, the interaction continues with Ethoca and the AlertId of the delivered transactions would be the AlertID used to fetch the merchant outcome.

If the interaction with Ethoca fails, or if the transaction is not delivered to Ethoca (either undelivered or failed or ignored by the Ethoca system), the interaction with the Ethoca system is suspended and the dispute reverts back to the normal flow. The case continues to wait at the same assignment, and the footer is updated with the alert details.

After the merchant provides the outcome, the Ethoca system sends a callback notification using an Alert Outcome Updated event type. Based on this event type, the EthocaEventTypeAlertOutcomeUpdated activity is called from the InvokeEthocaCallbackService activity. This activity first uses the resource URL provided in the notification to fetch the alert details (in this scenario, BatchID) and determines the work object to be resumed based on the BatchID obtained from the output of the resource URL. Once the work object is determined, the activity checks if the work object is currently waiting at the PerformEthocaDisputeResolution callback flow and then resumes the callback flow.

Once the flow is resumed with the Alert Outcome Updated event type, the GetMerchantOutcome flow is called, which is used to fetch the merchant outcome and process the dispute based on the outcome.

The GetEthocaMerchantOutcome activity fetches the merchant outcome by calling the GetMerchantOutcome REST connector from the D_GetMerchantOutcome data page.

If the interaction with the Ethoca system for fetching the merchant outcome is successful, the retrieved outcome is mapped to the EthocaInformation page on the clipboard and the corresponding audit and logs are built to display the same in the footer.

A row is added to the Third Party tab in the footer after a successful interaction with Ethoca and the merchant outcome is received.