A tracking gap needs a transaction reference

A tracking check follows a deposit all the way through: source link or promo code, player account, successful payment, postback and report. If the brand and agency show different totals, that path tells you where to look. Start with a transaction reference from the cashier. Then find which step lost it or assigned it somewhere else.

The link has to survive registration

A source code in the landing URL identifies the visit. It tells you how that visit arrived. The report needs more: the code has to reach registration and remain attached to the account that later pays. A working first page can still lead into an untracked player account.

Follow the path through redirects, the registration form and the cashier. A new session should not wipe the stored source. A later visit can have a clean URL while the account still carries the original attribution under the agreed rule. Checking the URL alone misses that distinction.

The pre-launch checks explain how to arrange a controlled check with the brand. The result should be a chain you can follow: source code, player reference, transaction reference, successful status and completion time.

Use stable source codes behind the report’s readable headings. Renaming a creator type or changing a display name should not break the join to an earlier account. The brand can group the result by geo and creator type while the people checking a disputed payment use the underlying references.

A link and a promo code can point in different directions

A player can follow one link and later use a promo code tied to another source. That needs a rule. Does an accepted code change the credited source? Does the earlier link keep priority? Is there a reason to leave the case unresolved until the brand checks it?

Agree that rule before the test. A rule chosen after seeing which source looks stronger turns a technical question into an argument about credit. The cashier amount can stay unchanged while the source report shifts, so the rule matters even when nobody disputes that the payment happened.

Code entry and code acceptance are different steps. The player may type a code that the brand rejects. Check that the accepted code was stored against the right account and belonged to that source at the time. A screenshot of the input box can’t answer that.

The rule should also say which payments it covers and how it handles existing accounts. Keep the original link and accepted code available beside the final source assignment. Then a disputed row can be explained with both signals still visible.

When the link and accepted code disagree, the payment row should show which source got credit and the rule that decided it.

A late postback can move a payment into the wrong period

A payment completes at one time; its postback can arrive later. The report needs both timestamps. If the receiving system groups deposits by message arrival while the brand groups them by payment completion, the same payment can land in different reporting periods.

The cutoff and timezone need to match before anybody compares totals. A deposit completed just before the cutoff may reach the other report after it. The correction belongs with the period selected by the agreed reporting rule, with a note explaining the late arrival.

There is another clock: the attribution window. It says how long a link or code can qualify a later event for source credit. State its starting event and the event it governs. A window ending at registration answers a different question from one ending at deposit completion.

For a player’s elapsed time after FTD, use the cohort windows. When tracing a payment between systems, check that its completion timestamp and source treatment remain unchanged.

A retry should find the original payment

A postback is a message about an agreed event. It might report a reg, a payment attempt or a completed deposit. The receiver has to know which. Successful delivery of a message about a pending attempt cannot turn the attempt into money in the cashier.

The transaction reference is what joins a completed payment to its messages. If that reference is unique only inside one brand or payment system, include that scope when matching it. Amount and arrival time are weak substitutes: two real payments can share an amount, while two messages about one payment can arrive far apart.

Status updates should find the same payment too. A pending record that becomes successful changes status on the original transaction. If updates arrive out of order, the current cashier record decides which status is valid. A reversal needs a visible correction tied to the original reference.

These are payment checks. The distinction between payments and FTDs lives in the deposit report. Matching messages is only the step that makes the payment records usable.

Find the missing rows before arguing about the total

A lower brand total can come from a missing source join, late delivery or extra rows at the receiver. Start with a short list of missing or extra transaction references, then trace the point where the records diverge.

Some gaps are money missing from a report. Others are the same money credited to a different source. Treating both as a missing deposit sends the team down the wrong path. Compare the underlying records before changing either the amount or the source assignment.

The cashier total needs a bridge to the reported total

A bridge is simply an explanation of the difference. Which successful payments reached the report, which have no source attached and which are waiting for delivery? Every amount in the gap should have a reason you can check.

Don’t push the €60 into the test merely to make the headline agree. It belongs there only if the agreed source rule supports that assignment. Equally, leaving it out of the attributed report does not mean the payments failed.

A mixed-currency report needs a bridge by currency or an agreed conversion rule. The export used for a recheck also needs the original cutoff. Otherwise late payments and new payments can get mixed into the repair, and nobody can say what actually changed.

A blank cell has no verdict in it

A blank can mean the export is late, the field was never supplied or the source join failed. Check which happened before anyone reads it as zero.

A zero says the agreed records were checked and no matching successful payment was found. If the payment data hasn’t arrived, write “Export pending”. If the payment exists but its attribution is unresolved, write “Source missing”. Plain words beside the cell save a pointless argument about performance.

We would rather leave a gap explained than publish a tidy zero nobody checked. If the data later arrives, show the revised amount and the reason for the change. The earlier report then remains understandable instead of looking as though the players changed their behaviour overnight.

A correction closes when the next export agrees

Passing a screenshot back is easy. Closing the gap takes the same references, dates, currency and status rules in the next comparable export. The payment should appear once, with the source supported by the agreed rule. If a delay remains, say which rows are still waiting.

Access to deposit statistics or a regular export is one of the brand’s inputs for the test. Use the matching export for this recheck, keeping the same period so new payments don’t get mistaken for recovered ones.

Run this check early enough to repair the path while the test is still useful. Keep the transaction references inside the working check. Player credentials and payment details do not belong in a screenshot passed around between teams.

Keep the confirmed transaction reference with the attribution rule used for the report. When someone returns to the earlier gap, they should be able to find that payment in the fresh export.

“Corrected” needs a row someone can actually find.