The Early Warning File: Turning Pre-Dispute Alerts into Evidence of Control

The alert is not the answer; the process is

For a UK merchant processing through an offshore acquirer, a chargeback is rarely just a refund that arrived late. It is a data point in the acquirer's risk model, a cost against the merchant's reserve, and a signal that the relationship may need re-pricing or review. Pre-dispute alerts, offered through services such as Ethoca, Verifi Order Insight and Visa's Rapid Dispute Resolution, arrive before a formal dispute is raised. They give the merchant a short window to refund, clarify or challenge. That window is valuable, but it is not self-executing.

Offshore underwriters have seen too many merchants buy an alert service and treat it as a box-ticking exercise. The question they ask is not whether alerts are switched on. It is whether the merchant has built a repeatable control loop that captures the alert, reaches a documented decision, executes it promptly and can prove what happened. This article sets out how to construct that loop and what to put in the file.

What the alert actually represents

A pre-dispute alert is generated when a cardholder contacts their issuer about a transaction. The issuer or network intercepts the query and sends the merchant a notification containing transaction data and, often, a reason category. The merchant can then refund, provide evidence that the transaction was legitimate, or take no action. If the cardholder later escalates to a formal chargeback, the alert record becomes part of the chronology.

For cross-border merchants, the alert is also a timing instrument. UK cardholders may raise queries at hours when an offshore operations team is asleep. An alert that sits unread for three days is not a control; it is a liability. The acquirer will look at response times, not just response rates.

Designing intake that survives audit

The first failure point is fragmentation. Alerts arriving in a shared inbox, a spreadsheet and a payment gateway dashboard are difficult to reconcile and easy to miss. A defensible programme routes every alert into a single queue with a unique identifier, a timestamp and the order reference attached.

Where the alert provider supports API or secure file transfer, use it. Manual download introduces delay and transcription risk. The queue should be owned by a named function, not by whoever happens to check the inbox. Set a service level that reflects the acquirer's expectations and the merchant's operating hours. For many UK merchants, a 24-hour weekday target is realistic; for digital goods with instant delivery, shorter windows may be appropriate. Publish the target internally and record performance against it.

Routing rules should be explicit. High-value alerts, repeat customers, regulated products and alerts linked to a specific fulfilment failure may need different handling from a low-value first-time query. The acquirer does not need a complex decision tree, but it does need to see that decisions are not arbitrary.

The refund decision is a risk decision

The temptation with pre-dispute alerts is to refund everything. It reduces immediate chargeback volume, but it also trains friendly fraud, erodes margin and can look to an underwriter like capitulation rather than control. A blanket refund policy is not a risk programme.

A better approach is a documented decision matrix. For physical goods, check delivery status and carrier evidence. For digital goods, check access logs, download records and licence activation. For services, check booking records and cancellation history. If the evidence supports the transaction, respond with information rather than a refund. If the evidence is ambiguous or the cost of dispute exceeds the refund, refund and record why. The key is that the reason is written down at the time, not reconstructed later.

This is where alert handling meets chargeback defence. The same evidence that justifies a refund decision may later be needed if the cardholder disputes a different transaction. Retain it in a consistent format.

Fitting alerts into helpdesk and fulfilment systems

Most UK merchants already run a helpdesk such as Zendesk, Freshdesk or Gorgias, and a commerce platform such as Shopify, WooCommerce or BigCommerce. The alert process should not sit outside those systems. Create a ticket for each alert, link it to the order, and sync the outcome back. If a refund is issued in the gateway, the ticket should record the refund reference. If the alert is rejected, the ticket should record the evidence relied on.

Fulfilment data is particularly important. An alert on an order that has not yet shipped is a different risk from an alert on an order delivered three weeks ago. Where possible, pull tracking status and delivery confirmation into the ticket automatically. For subscription businesses, include renewal notices and cancellation records.

Spreadsheets are not forbidden, but they are fragile. If a spreadsheet is used for reporting, it should be generated from the ticket system rather than maintained by hand.

The data trail an offshore underwriter expects

An offshore acquirer reviewing a pre-dispute programme will typically want four things: a policy, a record of operation, a reconciliation and an outcome measure.

The policy should state scope, ownership, service levels, decision rules, escalation paths and retention periods. It need not be long, but it should be approved and dated.

The record of operation should show alerts received, alerts actioned within service level, refunds issued, information responses and cases where no action was taken. A monthly pack is sufficient if it is consistent.

The reconciliation should connect alert identifiers to refund identifiers and, where relevant, to subsequent chargebacks. This is the evidence that the programme is not a paper exercise. If an alert was refunded but a chargeback still arrived, the merchant should be able to explain why.

The outcome measure should be honest. Alert-to-chargeback conversion, refund rate and estimated chargeback avoidance are useful, but they should be presented with caveats. Overstating savings damages credibility.

Retention periods should align with scheme rules and the acquirer's contract. Twelve to eighteen months is a common baseline; longer may be needed for high-risk sectors.

Costs, limits and the case for realism

Pre-dispute alerts are not free. Providers charge per alert, and the merchant bears the refund cost and staff time. For illustration, an alert fee of a few pounds may be cheaper than a chargeback fee plus lost goods, but the arithmetic depends on the merchant's average order value and dispute rate. A programme that refunds every alert can cost more than the chargebacks it avoids.

Coverage is also uneven. Alerts depend on the issuer and network participating, and not every cardholder query generates one. UK-issued cards are generally well covered, but merchants should not assume universal reach. Alerts can also be triggered by genuine confusion or friendly fraud, so a refund is not always the right answer.

The programme should therefore be presented as a risk-reduction control with measurable but bounded benefits, not as a chargeback elimination tool.

Making the programme legible

Finally, name the programme and put it in the onboarding pack and annual review. A one-page summary with the policy, the service levels and the latest monthly pack does more for an underwriter's confidence than a verbal assurance. If the merchant has a risk committee or board reporting line, say so. Offshore acquirers are assessing whether the merchant can operate a control when no one is watching. The pre-dispute file is one of the clearest pieces of evidence available.

Alerts are early warnings. The file is the defence.