Transaction ID: The Field That Makes a Refund Fixable

The Short Definition

Transaction ID (txid): a value unique to a single conversion event, passed alongside the click ID in a postback so that the tracker can tell one money event apart from another money event belonging to the same visitor.

In Voluum's postback the two parameters sit next to each other and are documented very differently. cid is headed "cid Parameter (Required)" and described as dedicated to passing the click ID: "The parameter is required to track the registered event." txid is headed "txid Parameter (Optional)" and described as being "used to pass a unique transaction ID for each conversion," specifically "when you want to record secondary conversion steps, upsells, per visitor following the primary conversion."

Required and optional. That asymmetry is the whole problem, because optional parameters are the ones people leave out of a setup at eleven at night and never revisit.

Why the Click ID Is Not Enough

A click ID is issued once, when the visitor passes through your redirect. Everything that visitor ever does downstream carries the same click ID.

So on a subscription offer, the initial sale, rebill one, rebill two, rebill three, the refund of rebill two and the eventual cancellation all arrive at your tracker wearing the same cid. If that is the only key in the postback, your tracker is being asked to hold six distinct financial facts in one row.

Voluum is explicit about what its click-ID requirement is protecting. From its documentation: "To maintain data consistency, Voluum typically allows for conversions with click ID information only. This prevents conversions from being falsely reported." That is a deliberate refusal, and it is the right instinct.

But it is a refusal about attribution, not about identity. A postback with a valid cid and no txid is accepted. It just cannot be individually addressed later.

What Happens When the Key Is Missing

Voluum publishes a fallback for conversions arriving with no click ID at all, using attribution=cid-caid to attribute the conversion to a campaign instead of a visit. The documentation lists the costs of that fallback in the same section, and one line in that list is the one to memorise:

Each postback is unique, there is no option to filter out duplicates

Read that as a statement about identity rather than about deduplication. Without a key, every message is a new fact. Nothing can be recognised as a repeat of something you already hold, which also means nothing can be recognised as a correction to something you already hold. A refund is just another unique postback.

The same document spells out the client-side version of this: with the pixel fallback, "if a visitor refreshes the 'Thank you' page where the pixel is located, the conversion will be counted twice." One customer, one sale, two rows, no way to tell which is the real one.

The ClickBank Case, Which Is Worse Than People Realise

ClickBank is the network most affiliates meet this problem on, because ClickBank has a genuine, unique, permanent transaction identifier and does not show most of it to affiliates.

From ClickBank's own transaction reporting documentation, on the Receipt Number field:

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.

Three characters out of eight. As a join key, three characters is not a key at all. If you promote at any volume, collisions are not a risk, they are a certainty.

The same paragraph adds the part that matters for subscriptions:

Rebill transactions have the same receipt number as the initial order, followed by a dash and four-digit number that indicates its place in a cadence of rebill transactions.

So the rebill numbering is a suffix on a number you cannot see in full.

ClickBank does give affiliates two identifiers that are not redacted. The Order Number is documented as "a ClickBank-generated ID that links all transactions within an order," visible to affiliates and sellers, linking the initial sale to order bumps and upsells. And the Tracking ID is "the tracking ID on the HopLink that facilitated the transaction," a field ClickBank's documentation marks as "only visible to the affiliates."

Which is the practical answer, and it is the same answer as always: the identifier you can rely on is the one you issued yourself.

What a Good Transaction ID Looks Like

Unique for the event, not for the visitor. If two rows can share it, it is not doing the job.
Issued by whichever party will still exist when the correction arrives. The network's internal ID is ideal if the network sends it to you in full. If it does not, generate your own on the HopLink or offer URL and store the mapping.
Passed on every event type, not just the sale. A refund postback with no txid cannot say which sale it refunds.
Stable across the whole lifecycle. A rebill that reuses the parent's ID collapses the cadence. A rebill with a completely unrelated ID orphans it from the parent. The ClickBank pattern, parent plus dash plus sequence, is actually the right shape.
Stored, not just accepted. Plenty of trackers accept a txid and surface it only in a conversion log you cannot group by. Voluum notes of its additional parameters that "these are only values, therefore you cannot use them as a grouping option." Check what you can actually query on before you rely on it.

The Three Statuses Problem

Having a key is necessary and not sufficient. You also need somewhere to put the outcome.

ClickBank fires a distinct transaction type for each thing that can happen: SALE for the initial purchase, BILL for a rebill, RFND for a refund, CGBK for a chargeback, INSF for an eCheck chargeback, CANCEL-REBILL for a cancellation, and UNCANCEL-REBILL for the reversal of one. Their documentation also notes that a refund on a recurring product fires two events, because products "that are refunded also result in a 'CANCEL-REBILL' transaction."

Most trackers have far fewer states than that. PeerClick is unusual in shipping named presets: its Subscription preset adds Start, Rebill, Buyout and Stop as first-class columns, and its E-commerce preset adds Hold, Sale and Reject. Voluum's equivalent is Custom conversions, more flexible and starting from nothing.

If your tracker has one conversion state and the network has seven, five of those seven are being thrown away at the door, whatever your transaction ID says.

The Check to Run This Week

Pull one conversion from a recurring offer and answer three questions.

Does the postback you configured include a txid, and is the value unique per event rather than per visitor?
If the same customer bought twice, can you point at one of those purchases in your tracker without pointing at the other?
When a refund fires, does your tracker change the original row, or add a new one?

If the answer to the third is "adds a new one," your revenue column is a sum of everything that ever happened rather than a statement of what is true now. That is fixable, and it starts with the parameter marked optional.

Click ID: the identifier that names the visitor
Postback URL: the channel a transaction ID travels on
Event deduplication: the same identity problem, on the ad platform side
Conversion hold period: why the status on that row is not final

Transaction ID (txid): What It Is and Why Corrections Need It