# Receive Alerts by Push and Submit Outcomes
source: https://developer.mastercard.com/ethoca-alerts-for-merchants/documentation/use-cases/push-alert-processing/index.md

## Context {#context}

This use case applies when a direct merchant or partner wants Ethoca to deliver alerts directly to an HTTPS endpoint instead of polling for them. It is best suited to integrations that need near real-time delivery into an internal fraud, operations, or case-management workflow.

## Goal {#goal}

Receive an alert from Ethoca, confirm that it was accepted by your endpoint, investigate the underlying transaction, and send the final outcome back to Ethoca so the issuer can decide whether a chargeback is still necessary.

## Actors {#actors}

* Issuer
* Ethoca Alerts platform
* Direct merchant or partner webhook service
* Merchant operations or fraud systems

## Outcome {#outcome}

The merchant receives the alert, confirms delivery, investigates the transaction, and submits an outcome such as `STOPPED`, `RESOLVED`, or `NOT_FOUND` through the Outcome API.

## Preconditions {#preconditions}

* Your organization is onboarded to Ethoca Alerts.
* A Push integration is configured for your account.
* Your HTTPS webhook endpoint is registered with Ethoca.
* Your webhook trust store accepts the required Mastercard certificate chain.
* Your system can call the Outcome API with OAuth 1.0a.

## Flow {#flow}

Diagram push-alert-processing

### Step 1: Receive the alert delivery {#step-1-receive-the-alert-delivery}

Ethoca sends the alert to the webhook endpoint that you registered during onboarding. This is the event that starts the merchant-side workflow. Use this endpoint when you want Ethoca to push alert data into your system instead of requiring your platform to poll for available alerts.

API Reference: `POST /api/push/alerts`

Your webhook must return a successful acknowledgement response to confirm that the alert reached your destination. Without that acknowledgement, Ethoca cannot treat the delivery as complete.

This acknowledgement is part of the same `POST /api/push/alerts` interaction shown above, so the same endpoint contract governs both the incoming payload and the response body.

API Reference: `POST /api/push/alerts`

### Step 2: Submit the merchant outcome {#step-2-submit-the-merchant-outcome}

After your internal systems review the transaction, submit the final action taken through the Outcome API. This is the endpoint that closes the merchant side of the alert lifecycle and forwards your response to the issuer.

Use `POST /outcomes` when you need to report whether the transaction was stopped, refunded, unresolved, not found, or otherwise handled. The API accepts batches of outcomes, which is useful when your review workflow processes alerts asynchronously.

API Reference: `POST /outcomes`

## Why These Endpoints {#why-these-endpoints}

* `POST /api/push/alerts` is the correct Push endpoint because it is the webhook contract Ethoca uses to deliver alert data to the merchant.
* `POST /outcomes` is required to report the merchant decision back to Ethoca and ultimately to the issuer.
* No Pull endpoints are used in this flow because alert retrieval is initiated by Ethoca, not by the merchant.