Getting Started With AlertBridge™ Dispute Alerts

A dispute alert is an early signal that a cardholder has raised a problem with a transaction. AlertBridge™ helps connect eligible alert information with the merchant and transaction context needed to act on it. This guide walks through the complete review sequence: from alert received, to transaction confirmed, context reviewed, prior credits checked, action selected, and outcome documented.

What AlertBridge™ Helps You Review

AlertBridge™ is not an alert provider or a card network. Alerts originate from programs operated across the payments ecosystem — for background on the programs themselves, read how dispute-alert programs work. What AlertBridge™ helps you do is bring an incoming pre-dispute alert together with the merchant and payment context that should shape your response: the merchant account involved, the underlying transaction, related order records, and any refund or dispute activity already connected to the case.

Alert sources can include programs such as the Cardholder Dispute Resolution Network, Rapid Dispute Resolution, and Ethoca Alert coverage. Alert eligibility and timing can vary by provider, issuer, network, geography, merchant enrollment, and the individual case.

Before You Review an Alert

Alert review works best when the merchant has already decided, in advance, how it generally wants to treat common situations — for example, how it handles an alert on an order that has not shipped versus one delivered weeks ago. You do not need a rule for every case, but a shared baseline keeps individual reviewers consistent.

Step 1: Confirm the Merchant and Transaction

Start by confirming that the alert belongs to the merchant account or MID you expect, and locate the transaction it references. Review the available information such as:

• Merchant account or MID
• Transaction amount and transaction date
• Customer information on the order
• Order information, including what was purchased

If the transaction cannot be confidently matched to an order, resolve that question first. Acting on the wrong transaction is one of the most damaging alert-handling mistakes.

Step 2: Review the Alert Type and Timing

Review the alert source and when the alert arrived relative to the transaction. Different programs carry different implications, and the time available to act is not the same in every case. Timing can vary by provider, issuer, network, and geography, so treat the timing information attached to the specific alert as the operative guide rather than a general rule.

Step 3: Check the Payment and Order Context

With the transaction confirmed, look at the surrounding context:

• Fulfillment status — shipped, delivered, in progress, or not yet fulfilled
• Cancellation activity on the order or subscription
• Prior customer communication, such as a complaint or a refund request
• Existing dispute or chargeback activity on the same transaction

This context is what separates an alert that calls for a refund from one that calls for a different response. An alert on an unfulfilled order is a very different situation from an alert on an order the customer has already used or received.

Step 4: Check for an Existing Refund or Credit

Before issuing any credit, confirm whether one already exists. A prior refund or credit should always be checked before another credit is issued — issuing a second credit on top of an existing one turns a recoverable situation into a direct loss. Use Refund Guard™ to check refund and credit history connected to the transaction, including partial credits and credits issued through other channels.

Step 5: Determine the Appropriate Action

Not every alert requires the same action, and not every alert should automatically result in a refund. Depending on the case, the appropriate response may be to issue a refund, let an already-processed refund stand, stop fulfillment on an unshipped order, or prepare for a potential dispute where the transaction appears legitimate and the merchant intends to stand behind it.

Weigh the transaction amount, the cost of the goods or services, fulfillment status, and the customer relationship when selecting the action.

Step 6: Record the Outcome

Document what was decided and why: the action taken, who took it, when, and the key facts that drove the decision. A recorded outcome protects the merchant if the same transaction resurfaces later as a dispute, and it builds the internal history that makes future alert decisions faster and more consistent.

Common Alert-Review Mistakes

• Refunding automatically without checking fulfillment status or prior credits
• Acting on a transaction that was never confidently matched to the alert
• Ignoring alert timing and responding after the practical window has passed
• Treating every alert source as if it behaves the same way
• Leaving the outcome undocumented, so the history is lost when a dispute follows

When to Escalate the Alert

Escalate rather than guess when the alert cannot be matched to a transaction, when the referenced merchant account looks wrong, when refund history appears inconsistent with your records, or when the same customer or card generates repeated alerts. For help with any of these situations, contact Payment Defender Support with the alert details and what you have confirmed so far.

Related Payment Defender Resources

The related guides below continue the workflow from the point where an alert has been reviewed and a decision recorded.