When automatic matching fails: matching a pre-chargeback alert by hand

Most pre-chargeback alerts find their transaction on their own. Some do not. The alert says €52.90, the payment was taken in Israeli shekels. The alert carries no acquirer reference number. The authorization happened just before midnight in one time zone and after it in another. Automatic matching rightly refuses to guess, and the alert waits with no transaction attached, while its response window keeps running.

An unmatched alert is the most expensive kind. Nobody can refund it, because nobody knows which payment to refund, and if the window closes the claim becomes a chargeback anyway. NORBr now lets the person handling alerts match it by hand, in a few clicks, with the candidates already narrowed down and the decision recorded for whoever reads the alert next.

Here is why some alerts cannot be matched automatically, how manual matching works on NORBr, and what PayFacs, PSPs, ISOs and ISVs should expect from it.

Why does automatic matching sometimes fail?

Automatic matching fails when the data in the alert does not point to exactly one transaction. That is a feature, not a flaw: a matcher that picks the closest payment on a guess would refund the wrong customer.

The alert is built from the issuer's view of the payment, and the issuer's view drifts from the processor's in predictable ways. Mastercard's transaction matching guidance for Ethoca lists the usual suspects implicitly in its tolerances: a transaction date that can differ by up to two days, an amount that can vary by 5% once converted into the transaction's currency, a reference number that is not always present, and card numbers that the merchant may hold only in tokenized form. Each condition in its cascade returns a transaction only when exactly one matches.

So the alerts that fail are the ones at the edges: cross-currency payments, partial captures, a customer who bought twice the same day with the same card, a payment authorized on one day and settled on the next. They are a small share of alerts, and they are the ones that end up as chargebacks when nobody looks at them.

As explained in our article on automatic transaction matching, NORBr first tries the PSP transaction ID, the acquirer reference number and the card data. When none of them leads to a single payment, the alert is marked as not matched instead of being attached to a guess.

How do you find the alerts nobody has matched yet?

They have their own view. In the pre-chargeback alerts table, the "Not matched" view lists every alert still waiting for its transaction, with the time left before its response deadline. Sorting on time left puts the most urgent at the top. The table also shows, for every alert, its source, the card's first six and last four digits, the match status and the matching type, automatic or manual, so a team lead can see at a glance how many alerts needed a human.

Opening an unmatched alert shows a banner above everything else: the time left to respond, and the instruction that goes with it, match the transaction, then refund.

How does manual matching work on NORBr?

The alert does most of the narrowing for you. Candidate transactions are filtered on the card the alert was raised against: only payments made with the same first six and last four digits are listed, because the alert sets that constraint and nobody should override it.

The candidates are shown day by day, starting with the authorization date carried by the alert. If the payment is not there, one click goes back a day, another goes forward. For each candidate, the list shows the transaction ID, the authorization date and time, the amount and currency, the payment status and the partner that processed it.

By default, only amounts within 5% of the alert amount after currency conversion are listed, the same tolerance Mastercard recommends for automated matching. A shekel payment of ₪ 214.90 appears next to a euro alert because, once converted, it falls inside that band. When the gap is wider, for example after a partial refund or a shipping fee added later, the amount filter can be switched off to show every payment on that card that day.

Pick the transaction, click Match, confirm. The candidate table disappears, the alert now points to its payment, and two fields record what happened: matched by, with the name of the person, and matched at, with the time.

Why record who matched the alert, and why?

Because a manual match is a judgment, and judgments get questioned later. The issuer may come back, the merchant may ask why a refund went to that order, an auditor may sample alerts handled by hand. Matched by and matched at answer the first two questions. The optional comment answers the third: before confirming, the person matching can write why this transaction, for the next person reading the alert. "Same card, same day, only captured payment; the other one was voided" takes ten seconds to type and saves a conversation three weeks later.

The matching type stays visible in the table and on the alert, so a manual match is never mistaken for an automatic one.

What happens after the alert is matched?

The clock changes meaning. The banner that said time left to respond now says time left to refund, and offers a direct link to the transaction. From the payment, the Refund button opens with a mandatory reason, and "Pre chargeback alert" is already selected. Once the refund is issued, the banner disappears from the alert and a refund card takes its place, with the status, the reason, the amount, the date and the person who refunded.

The transaction tells the same story from the other side. Its refund and refund reason columns show it was refunded because of a pre-chargeback alert, and its history shows the alert, the match and the refund in order. For RDR alerts, where Visa issues the refund itself, the payment shows a network refund by Visa instead.

What should operators expect from manual matching?

Three things. First, that it is rare: automatic matching should handle the large majority of alerts, and manual matching exists for the edges. If a large share of your alerts end up in the "Not matched" view, the issue is upstream, in the data your connectors pass with each payment. Second, that it is fast: a search narrowed to one card and one day, with a sensible amount tolerance, takes less time than reading the alert. Third, that it is traceable: every manual match carries a name, a time and, ideally, a reason.

The €52.90 alert that started this article gets matched in under a minute to the ₪ 214.90 payment it was about, refunded with the right reason, and closed well inside its window. Without manual matching, it would have become a chargeback that nobody could explain.

What else do operators ask about manual matching?

How often does an alert need manual matching?

Rarely. Automatic matching handles most alerts through the PSP transaction ID, the acquirer reference number or the card data. Manual matching covers the edge cases: cross-currency payments, partial captures, two purchases with the same card on the same day, or dates that differ between the issuer and the processor.

Can someone match an alert to any transaction?

No. Candidates are limited to payments made with the card the alert was raised against, using its first six and last four digits. By default, only amounts within 5% of the alert after currency conversion are shown, and the amount filter can be switched off when the gap is wider.

Who can see that an alert was matched by hand?

Everyone who opens the alert. The matching type stays visible as manual, with the name of the person who matched it, the time and an optional comment explaining the choice, so support, risk and audit teams can follow the decision later.

What happens after an alert is matched?

The banner changes from time left to respond to time left to refund, with a link to the transaction. The refund is issued on the original payment with the reason "Pre chargeback alert", and both the alert and the transaction record it.

NORBr Pre-chargeback Alerts gives PayFacs, PSPs, ISOs and ISVs Verifi and Ethoca alerts matched to their transactions, automatically when the data allows and by hand when it does not, under their own brand. Talk to us about resolving your merchants' claims before they become chargebacks.