Your Refund Notice Names a Sale You Cannot Find

Mechanism One: The Identifier Is Redacted

ClickBank's transaction report has a field called Receipt Number, and the documentation describes it like this:

This field refers to the unique ClickBank receipt number for the transaction. For sellers, this number will appear as all eight character in the receipt number. Affiliates can see the first three characters--the remain characters are redacted.

I have read that sentence perhaps thirty times and it still lands the same way. The record has a unique identifier. If you are the seller you get all of it. If you are the affiliate you get three characters.

I want to be careful about how far I push this, because ClickBank does not publish the character set its receipt numbers are drawn from, and it does not publish whether prefixes are evenly distributed. So here is the most generous possible version of the arithmetic, which is also an upper bound on how much that prefix can be worth to you.

If those three characters were drawn uniformly from the thirty-six alphanumerics, there would be 46,656 distinct prefixes. By the standard birthday bound, you cross a fifty percent chance that two of your transactions share a prefix at 255 transactions.

Two hundred and fifty five transactions is a modest month. And that is the best case. If the alphabet is smaller, or if prefixes cluster by date or by vendor the way sequential identifiers usually do, the number is lower and possibly much lower.

So when the refund notice arrives naming receipt 7KQ and you have two sales beginning 7KQ, the honest answer is that you do not know which one refunded. You have a fifty-fifty and a revenue column to correct.

I want to say clearly that I do not think this is malice. Redacting most of a transaction identifier from a party who is not the merchant of record is a defensible privacy posture, and ClickBank redacts the customer's name and email from affiliates for the same reason. I have no argument with the policy. I have an argument with building a reconciliation workflow on top of it and calling the result accurate.

Mechanism Two: The Record Expires Before the Money Settles

Every cloud tracker on the market publishes a data retention window, and almost nobody compares it against the windows that actually govern their revenue.

Two entry plans, both current as of this week:

Now put that against what a refund or a chargeback actually does. A digital offer commonly runs a 30 or 60 day refund guarantee. A cardholder disputing a charge is working to a card network's timetable, not the merchant's, and those timetables run months rather than weeks. A subscription offer stretches it further, because a rebill in month four can be refunded in month five.

On a three month plan, a chargeback arriving on day 118 does not produce a difficult reconciliation. It produces an impossible one. The click it refers to was deleted four weeks ago.

This is the mechanism I find most avoidable and most common, because it is entirely a purchasing decision. Nobody chooses a tracker by reading the retention row. It sits under the event count and the campaign limit and it looks like a storage detail. It is not a storage detail. It is the statute of limitations on your own books.

A refund on day 47 is recoverable on a 3-month plan. A chargeback on day 118 is not, and both are ordinary.

Mechanism Three: The Message Is Delivered Once, Or Never

This is the one almost nobody knows about, and it is written down in plain language on ClickBank's own support site.

ClickBank's Instant Notification Service has a delivery policy. Here it is verbatim:

When we send an instant notification, we monitor the response code from your URL. If we receive a response code in the 200 range within 3 seconds, the notification delivery is considered successful.

Three seconds. If your endpoint is slow, it did not happen.

Then:

If the response code is not in the 200 range, we attempt to resend the notification once every four hours. After a max of five failed attempts, it will no longer attempt to deliver the information. There is no way to resend the instant notification once it has reached the max attempts.

Five attempts, four hours apart. Do the arithmetic and your entire margin for error is about twenty hours from the first failure. After that the information is not delayed, queued, or recoverable. ClickBank says it in a sentence: there is no way to resend it.

Twenty hours sounds generous until you list the ordinary things that consume it. A DNS change propagating. A certificate expiring on a Saturday. A migration that returns 502 for an afternoon. A tracker whose free plan rate-limits you after an event cap. A firewall rule somebody added on Friday.

And here is the part that makes it an orphan reversal rather than a missed sale: the notifications you lose are not randomly distributed across event types. A SALE that never arrives is visible, because you can see in the network dashboard that you earned money your tracker does not show. An RFND that never arrives is invisible, because the absence of a correction looks exactly like the absence of a problem. Your tracker keeps showing revenue you no longer have, and nothing in the interface will ever tell you.

Missing sales get noticed within a day. Missing refunds get noticed at tax time.

What This Costs, Concretely

I am not going to invent a study. Here is the arithmetic you can run on your own numbers in about five minutes, which is more useful than a statistic I made up.

Take last quarter. Write down three figures:

1. Gross commissions your tracker reported.
2. What the network actually paid you, from the payment record, not the dashboard.
3. The number of refunds and chargebacks the network reported in that period.

Figure one minus figure two is the total value of corrections that never landed in your tracker. Divide by figure three and you have the average cost of one orphan reversal in your business.

The reason this is worth doing rather than reading about is that the gap is not the real damage. The real damage is that every one of those uncorrected conversions was also reported to Meta, Google or TikTok as a successful purchase, and those platforms build their audience models out of exactly that. An uncorrected refunder is not a rounding error in your revenue column. It is a training example telling the algorithm to go find more people like that.

That compounds. Your revenue column does not.

Can You Apply the Correction? A Diagnostic

Reversing a conversion needs three things to be true at once, and none of them is about the refund itself.

Why This Is Getting Worse, Not Better

Two things changed in the last two years and they pull in opposite directions.

Networks got better at telling affiliates when a conversion goes bad. Reversal postbacks are standard now, the documentation is better than it was, and the major platforms fire distinct event types rather than silently adjusting a number. That is real progress and the people who did that work deserve the credit.

At the same time, ad platforms got stricter about how late a correction may arrive, and trackers moved decisively to metered cloud plans where retention is a pricing lever. Those two trends together mean the message now arrives more reliably into a system that is less able to act on it.

There is also a structural point worth saying out loud. Voluum's own documentation, explaining why it normally insists on a click ID, says it "prevents conversions from being falsely reported," and lists among the costs of its fallback mode that "each postback is unique, there is no option to filter out duplicates." I quote that approvingly. It is a vendor being straight about a trade-off. But notice what it implies: identity is the feature. Everything downstream, deduplication, correction, reversal, reconciliation, is built on being able to name one row. Lose the name and you lose all of it at once.

What Good Looks Like

If you are evaluating tooling, or arguing with a vendor, these are the four properties that decide whether a reversal ever lands.

Retention longer than your longest correction window. Not longer than your refund window. Longer than the chargeback window, which is not set by you or your network.

A transaction identifier on every event, issued by you. The network's identifier is better when you get all of it. On ClickBank you do not, so the Tracking ID on your own HopLink is the key you actually control, and ClickBank's documentation notes that field is visible only to affiliates.

An endpoint that answers fast and never goes quiet. Three seconds is the published bar on ClickBank. Twenty hours is the whole retry budget. Whatever receives your postbacks should be the most boring, most available thing you own.

A reversal that leaves the building. Changing a row in your own dashboard corrects your bookkeeping and changes nothing about what Meta, Google and TikTok believe. The correction has to be forwarded to the platforms that are spending your money, or it is a private act of tidiness.

So What Do You Do About It

Go and find out which of the three mechanisms you are exposed to. Look up your tracker's retention window and write it next to the longest chargeback window on your offers. Send one test postback and time how long your endpoint takes to return a 200. Pull a refund from last quarter and see whether you can point at the exact sale it reversed.

If you want the fourth property handled for you, ClickerVolt keeps unlimited data retention on every plan including the free one, parses ClickBank's transaction types natively rather than making you map them, and forwards a reversal to Google, Meta and TikTok instead of stopping at the dashboard. You can read the full breakdown here.

But the part that matters works regardless of what you use. A correction you cannot apply is worse than one you never received, because you will spend the quarter believing your numbers. Find the three windows, write them on the same page, and pick the shortest one. That is your real reconciliation deadline, and it is almost certainly earlier than you think.