Chargebackhit API helps merchants reconcile transactions by processing complex outcomes and responses. It ensures accurate matching of alerts to transactions, simplifying dispute resolution.
-
Update response outcome
API
Efficiently update alert outcomes by alert UUID. -
Get alert by ID
API
Retrieve detailed information about a specific alert using its UUID. -
Retrieve alerts list
API
Fetch tailored alert lists with flexible filters (types, outcomes, providers, products, transactions, merchants) and pagination. -
Webhooks
API
Receive instant notifications on alert events to automate responses.
Alert flow
Chargeback
Chargeback notifications are messages that the merchant receives informing them that a chargeback has occurred or will soon occur.
alerts
are delivered 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 has not yet been filed. In this case, the merchant may 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 via card schemes.
- Providers notify Chargebackhit of the upcoming dispute.
- Chargebackhit sends a request to the merchant and notifies the merchant of the incoming chargeback. Then the merchant decides either to refund the customer, stop order fulfillment, update order details, or dispute the transaction, depending on the alert type received.
- 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 the response is received by Chargebackhit, Chargebackhit 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 will be returned shortly, or they receive additional real-time information about the transaction. Obtaining information can also help to stop the chargeback process.
Chargebackhit API provides alert webhook notifications. Currently, its products include:
Cardholder Dispute Resolution Network’s (CDRN) unique and patented, closed-loop process directly integrates with top issuers and provides unmatched service quality and accuracy for merchants and issuers to resolve disputed payments, dramatically minimizing chargebacks and cardholder dissatisfaction. CDRN receives immediate notifications from issuing banks about cardholder issues.
Verifi CDRN alerts lead to the freezing of the chargeback process for 72 hours.
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 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 webhook
|
fraud-notification
dispute-notification resolved prevented |
Reconcile to the original transaction. | Default outcome
acknowledged
order
information in the 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 been refunded following the alert. This outcome occurs when an alert is successfully matched with a successful sale transaction, leading to a refund of the transaction. |
previously-reversed | The transaction has been refunded before the alert. This outcome is determined when the transaction has already been refunded prior to the alert. |
duplicate | The transaction has been refunded due to a duplicate alert. This outcome occurs when the alert is matched with a previously refunded transaction due to an alert received earlier. |
decline | The related transaction was not successful. This occurs when the transaction was declined before the alert. |
error | The processing error has occurred requiring additional communication. |
reverse-error | Unable to process a refund. This outcome occurs when an attempt to refund has failed due to a decline by the bank. |
not-found | The transaction has not been found. This outcome occurs when an alert cannot be matched with any existing transaction. |
acknowledged | The default response for the alert is that no action is required with the transaction. |
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 been 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 a
Internal logic for quick matching of alert data by the system in real-time. matching algorithm to quickly match alerts to transactions using prioritized identifiers and flexible criteria to ensure real-time accuracy. |