The launch is ready when a deposit reaches the report

A player can reach the brand, finish registration and still leave without a completed deposit. Or the money can arrive while the source disappears from the report. Before the test, walk that route with the brand’s approved test account and find out which parts actually work. That puts the broken step on the table before anybody starts arguing about audience quality.

Follow the source past the landing page

The route is simple to draw: creator link, landing page, registration, account, cashier, payment confirmation, report. Use the route players will take, including redirects and any pages between those steps. A landing page opened from an internal bookmark tells you little about the tracking link.

The check should end with a matched deposit row: the completed transaction can be traced back to the player account and the source that brought it. The link opening correctly clears one step. It leaves the rest of the route to check.

A source can survive the first page and disappear at registration. Check where it is stored on the player account and how the deposit picks it up later. The link, promo code and postback checks cover that chain, including what happens when a link and a code point to different sources.

Use account and transaction references that the brand team can trace. There is no need to pass a player’s personal details around to show that a source field went missing. The working record should make the broken step clear enough for its owner to repeat it.

The rehearsal also needs to check the FTD field. Its definition belongs in the deposit report. Readiness means checking that the brand’s agreed field reaches the output unchanged. A green click count cannot stand in for that final row.

The cashier must work on the route players will use

Open the cashier with the target geo and account settings. See which payment methods appear for that player, which currency is shown and what amounts the method accepts. A method on a general product page may be absent from this account’s cashier.

Let the brand team approve the account and payment method for the check, and agree how the resulting transaction will be treated. Start with the route needed for launch. Where another route needs a separate check, make that explicit. There is no reason to create a crowd of test accounts to find out whether one payment can reach the report.

Follow the payment beyond the cashier. A player may leave the site to confirm it and then return. Inspect the final transaction status and account balance. A friendly return screen can appear while the payment is still pending. An error on that screen can also hide a payment that completed.

A failed payment and a completed payment missing from the source report need different repairs. Payments owns the failed transaction. Tracking or reporting owns the lost connection to the source. One team finding a missing report row does not solve the other team’s decline.

The readiness check should finish with a completed transaction on the approved route and the same transaction in the report. If the method cannot be checked yet, keep it open. The launch contact needs to know exactly which route has passed before players arrive.

Limits, language and support are part of the deposit path

The amount shown to the player must agree with what the selected method accepts. A general account minimum may differ from that method’s minimum. Check the amounts at the allowed boundaries under the brand’s test procedure, then check the error when an amount falls outside them.

A rejection needs to tell the player what to change. Inspect the currency next to the amount, the limit message and the route back to the cashier. If the player only learns about a limit after leaving the site to pay, the problem sits inside the deposit path.

Then read the route in the language the audience uses: registration, account confirmation, cashier instructions, payment errors and any message required to continue. Translation of the landing page alone leaves too much unchecked. The geo page gives the product and support languages alongside local currencies. The actual check belongs inside the brand’s product.

Support needs to handle the same route in that language. Ask what happens when a player says, “I paid and my balance is missing.” Which reference does support request? Who sees it next? The player should not need to post sensitive payment details in an ordinary chat to move the case forward.

Support is part of our launch check because a payment problem can reach them before it reaches the test team. A reachable contact and a clear handoff help the brand find the transaction while the player is still asking about it.

The language and support check is complete when required screens make sense in the target language and support can get a payment case to its owner. That is a product check the brand controls.

Put each blocker in someone’s hands

Name a brand contact who can reach the people responsible for the player path. The contact doesn’t have to repair every problem personally. They should get a missing source to tracking, a decline to payments and an untranslated error to product, with enough detail for each team to act.

Give the problem a precise name. For a method that stays pending after confirmation, send payments the route used and the transaction reference. For a completed transaction with no source in the export, ask reporting to trace that record. That directs each issue to someone who can repeat the failed step.

Assign those jobs to actual people and include a backup. Find out when they can respond during the test and how an urgent payment issue reaches them. A name without a way to reach that person leaves the launch team waiting at the same broken step.

A reply saying “deployed” doesn’t close a blocker.

Repeat the failed route after the repair. If the source survives or the payment completes, keep the matched record with the issue. If it still fails, the blocker stays open. The question is whether the player can now finish that step.

Keep rehearsal deposits out of the live result

The brand’s approved test accounts need to remain visible in the readiness checks and excluded from the campaign result. Agree how they are marked and removed. Otherwise a rehearsal deposit can end up in the first weekly result, or disappear from the export needed to check tracking.

Inspect the same completed payment in the cashier and the report. Its transaction reference, amount, currency, completion time and source should agree. Check the export cutoff and timezone too. A payment completed after that cutoff belongs in a later export. The test row should make that easy to confirm.

Keep the test-account references and approved payment paths in a small readiness sheet. When a blocker is repaired, the launch contact can return to the exact account, method and step that failed. Leave the original result beside the recheck so the team can see which part now passes and which is still open.

Use that sheet to check the brand’s inputs for the test. A working link, a completed payment and its source in the export give the launch contact a route they can approve.

A rehearsal proves that the checked route can produce a deposit row. It leaves the audience result for the live test.

Approve the checked route and watch what changes

The launch contact needs a clear view of what passed, what is blocked and what was left outside the check. A required payment method that cannot complete is a blocker. Another method outside the chosen route can remain on a separate list. Success through one method cannot clear all the others.

Keep the checked configuration close to that decision: geo, account language, payment methods, deposit limits and tracking rule. If registration or the cashier changes during the test, repeat the affected route. Otherwise a fall in reg-to-FTD rate gets discussed as an audience problem while the product has changed underneath it.

That split tells the brand where to send the problem. The traffic checks in the brand’s data help when the deposit path works but the incoming players still look wrong. First clear the broken route; then judge the live test on the result it actually produced.