Alert Webhook helps merchants reconcile transactions by processing alert outcomes and responses. The process ensures accurate matching of alerts to transactions, supporting dispute resolution.
- Update response outcome
API
Update alert outcomes by alert universally unique identifier (UUID). - Get alert by ID
API
Retrieve detailed information about a specific alert using its UUID. - Retrieve alerts list
API
Fetch alert lists filtered by type, outcome, provider, product, transaction, or merchant, with pagination. - Receive alert
Webhook
Receive notifications on alert events to automate responses.
Alert flow
Chargebackhit delivers chargeback
Chargeback notifications are messages informing the merchant that a chargeback has occurred or is about to occur.
alerts
to the merchant before a claim is made, giving them a chance to avoid it. The alerts inform the merchant that a chargeback is pending but not yet filed. In this case, the merchant can take independent actions to avoid the chargeback, such as a voluntary refund, and pass this information to the issuer.
Alerts are issued either by issuers or card schemes and originate from customers who have initiated a chargeback. Here is a simplified overview of the process for all types of alerts:

- Cardholder contacts the issuing bank to dispute a purchase.
- Issuer returns notifications to the providers directly or through card schemes.
- Providers notify Chargebackhit of the upcoming dispute.
- Chargebackhit sends a request to the merchant and notifies the merchant of the incoming chargeback. Depending on the alert type, the merchant then decides to refund the customer, stop order fulfillment, update order details, or dispute the transaction.
- Merchant takes the necessary actions, such as matching the alert to a database transaction or issuing a refund.
- Merchant communicates the action taken to Chargebackhit.
- Once Chargebackhit receives the response, it responds to the issuer according to the alert type. Assuming the merchant wants to avoid a chargeback, they refund the purchase and stop order fulfillment.
- Issuer receives the information and under certain conditions, can stop the chargeback process.
- Cardholder gets information or a response from the issuing bank indicating that the money can be returned shortly, or they receive additional real-time information about the transaction. This information can also help stop the chargeback process.
Alert products
Chargebackhit provides alert Webhook notifications. Its products include:
Cardholder Dispute Resolution Network’s (CDRN) patented closed-loop process integrates directly with issuers. It helps merchants and issuers resolve disputed payments while minimizing chargebacks and cardholder dissatisfaction. CDRN receives immediate notifications from issuing banks about cardholder issues.
Verifi CDRN alerts freeze the chargeback process for 72 hours.
Before a dispute can be registered, Visa requires issuing banks to make an Order Insight inquiry into the transaction. Order Insight sends the transaction data from the merchant as it is gathered in real time. This data contains delivery confirmations, purchasing device IDs, and even customer support interactions that link a cardholder to the purchase. Order Insight prevents disputes and
</span>
<span>
<span class="tooltip_title">Glossary</span>
<br />
<span class="tooltip_text__boldGrey">Friendly fraud occurs when a cardholder disputes a legitimate transaction with their bank instead of contacting the merchant directly.</span>
</span>
</span>
</span>friendly fraud</span>
by aiding cardholder recognition.
Alert types
Alert types represent the notifications merchants receive when a potential chargeback is detected but not yet filed. They help proactively address the issue and avoid the formal chargeback process. Each alert type serves a specific purpose, whether providing detailed transaction information to cardholders, facilitating voluntary refunds, or reconciling disputes.
| Alert type | Description | Outcome |
|---|---|---|
| inquiry | Provides order information to help cardholders identify purchases and build trust and transparency in the ecosystem. | Default outcome
acknowledged order
,
customer
,
transactions
,
products
,
merchant
information in the alert webhook |
| init-refund | Matches the alert to the original transaction and updates its status, typically resulting in a refund. | Enum outcome
reversed
,
previously-reversed
,
decline
,
reverse-error
,
not-found
,
acknowledged
,
pending
,
shipped order
information in the alert webhook If this alert type includes an Acquirer Reference Number (ARN), the decline outcome is not applicable. |
| fraud-notification dispute-notification resolved prevented | Reconcile to the original transaction. | Default outcome
acknowledged order
information in the alert webhook and
order_id
is important for reconciliation alert to the original transaction |
Outcome types
There are several outcome types associated with alerts. Each outcome type provides a status update about the related transaction, allowing merchants to track the progress and resolution of disputes.
| Outcome type | Description |
|---|---|
| reversed | The transaction has a refund following the alert. This outcome occurs when Chargebackhit successfully matches an alert with a successful sale transaction, resulting in a refund of the transaction. |
| previously-reversed | The transaction has a refund from before the alert. This outcome occurs when the transaction already has a refund prior to the alert. |
| duplicate | The transaction has a refund due to a duplicate alert. This outcome occurs when the alert matches a transaction that a previous alert already refunded. |
| decline | The related transaction is not successful. This occurs when the bank declines the transaction before the alert. For init-refund alerts that include ARNs, the decline action is not applicable.
The ARN signals that the transaction has already settled, so declining a refund at this stage is not a valid step. In such cases, there is the following message to the decline action attempt:
“Alert with ARN refers to a settled transaction. Please verify the outcome flag.” |
| error | A processing error occurs, requiring additional communication. |
| reverse-error | Unable to process a refund. This outcome occurs when the bank declines an attempt to refund. |
| not-found | Chargebackhit cannot find the transaction. This outcome occurs when an alert cannot be matched with any existing transaction. |
| acknowledged | The default response for the alert is that the transaction requires no action. |
| pending | A temporary status that allows for a response at a later time, recommended within 24 hours, through the update outcome API method. |
| shipped | This outcome applies to physical goods that have already shipped. |
Interaction
| Type | Products | Actions |
|---|---|---|
| inquiry |
Alerts that require a response and transmission of additional data. |
|
| prevented |
Successful prevention of disputes. |
|
| init-refund |
Alerts that require a response and refund. |
|
| resolved |
Post-factum notification about the pre-dispute. |
|
| fraud-notification |
Notifies about the confirmed fraud cases. |
|
| dispute-notification |
Notifies about disputes. |
|
| Use the Understand how Chargebackhit matches prevention alerts to transactions in real-time using prioritized algorithms and transaction data. matching algorithm to match alerts to transactions. It applies prioritized identifiers and flexible criteria for real-time accuracy. | ||