Quick answer: Test iGaming affiliate software with a small set of known player events, not a vendor-led dashboard tour. In a 14-day proof of concept (POC), follow a test click-through registration, first-time deposit (FTD), commission calculation, fraud review, and payout export. Include duplicates, reversals and delayed events. The platform passes only when your marketing and finance teams can explain every result from the underlying records.
A polished demo tells you what a platform is designed to do. It does not tell you what happens when your casino sends an FTD twice, a sportsbook bet is voided, or an affiliate disputes an NGR deduction.
Those questions belong in a proof of concept. Give each shortlisted vendor the same scenarios and ask for the same evidence. You are buying a system that will decide which partner receives credit and how much that partner is owed. Both decisions need to survive inspection.
The 14 days below are a test window after access and event mapping are ready, not a promise that a full casino integration can be implemented in two weeks. Use a sandbox and synthetic player records. Do not put real player data or live-money transactions into a sales evaluation without the appropriate internal approvals.
What should you prepare before testing affiliate software?
Start with your program rules. If each vendor has to guess what “a qualified FTD” means, their results will not be comparable.
Prepare one short evaluation brief containing:
- Your casino and sportsbook brands, markets and currencies.
- The events your gaming platform can send: registration, deposit, qualified FTD, wager, revenue adjustment and reversal.
- Your attribution rule, including what happens when a player returns directly after an affiliate click.
- A sample CPA deal and a sample RevShare or hybrid deal.
- Your NGR formula, including which deductions your affiliate agreement permits.
- Your negative-carryover and chargeback rules.
- The reports and exports marketing, risk and finance must receive.
Use invented player IDs and amounts. Give every vendor the same file of expected outcomes. The exercise is not to see whether a vendor can make a dashboard display a number; it is to see whether the recorded number agrees with your rules.
If you are still deciding which vendors to test, use the broader iGaming affiliate software decision matrix to build a shortlist first. The POC begins once you have candidates, not while you are still collecting names.
How should a 14-day iGaming affiliate software POC run?
| Period | Operator task | Evidence to retain |
|---|---|---|
| Days 1–2 | Map event names, player IDs, click IDs, currencies and commission rules. Agree on expected outcomes before sending events. | Signed-off event map and test-case sheet |
| Days 3–6 | Test tracking from affiliate click to registration and qualified FTD, including a returning visitor and a delayed deposit. | Click record, incoming event, attribution decision and affiliate-facing result |
| Days 7–10 | Test CPA, RevShare, duplicates, reversals, negative revenue and fraud-review states. | Raw event log and itemized commission ledger |
| Days 11–14 | Test brand permissions, reporting, support, exports and finance reconciliation. Review unresolved failures. | Role screenshots, export files, issue log and final pass/fail record |
Do not change the expected result halfway through a test because a vendor’s default configuration behaves differently. Record the difference, decide whether your rule can be configured, and rerun the case. A configurable exception is different from an unexplained discrepancy.
Which test cases reveal the most about an affiliate platform?
The following pack is deliberately small. It covers the points where an apparently correct click count can still produce the wrong partner credit or payout.
| Test case | Send or simulate | What must be visible |
|---|---|---|
| Basic attribution | One affiliate click, one registration and one qualified FTD | The same click or attribution ID connects the three records and credits the intended affiliate |
| Returning player | Click the affiliate link, leave, then return directly to register or deposit within your agreed window | The result follows your written attribution rule, with a reason visible to the operator |
| Duplicate FTD | Send the same qualifying event twice | One payable FTD, with the duplicate identifiable in the event history |
| Delayed or out-of-order event | Send the deposit event before a delayed registration event reaches the platform | A documented outcome that can be reconciled; no silent second commission |
| CPA and RevShare | Apply two different commission plans to known player records | Itemized calculations that match the signed-off deal terms |
| Reversal | Reverse a previously approved FTD or revenue event | An adjustment trail showing the original event and the reversal, not a number that simply disappears |
| Fraud review | Mark a synthetic event for review under a configured rule | The reason, status, reviewer action and effect on the payable balance |
| Multi-brand player | Use one synthetic player across two brands | Attribution and commission treatment follow your cross-brand policy |
| Finance export | Export the test period’s events, adjustments and balances | Export totals reconcile with the operator report and affiliate statement |
The pass condition is not “the vendor supports all nine features.” The pass condition is that every test record has the expected status and an explainable path to the final balance. An unresolved difference remains a failed test, even if the dashboard total looks close.
For a closer look at failure patterns in the conversion chain, see Scaleo’s postback troubleshooting guide. For suspicious traffic scenarios, use the affiliate fraud pattern library to choose realistic review cases.
How do you test CPA and RevShare calculations?
Use arithmetic simple enough that both teams can check it without software.
For CPA, create one player who meets your written FTD qualification rule. If the test deal pays $200 per approved FTD, the expected commission is $200. Send that event a second time with the same event ID. The expected payable commission remains $200, not $400. Then reverse the qualification and check how the ledger shows the adjustment.
For RevShare, use an illustrative test case:
- Gross gaming revenue: $1,000
- Bonus deduction allowed by the test agreement: $150
- Payment-fee deduction allowed by the test agreement: $50
- Test NGR: $800
- RevShare rate: 30%
- Expected commission: $240
This is not a universal NGR formula. Your agreement determines which deductions are permitted and when they apply. The vendor should show the $1,000 starting figure, each $150 and $50 deduction, the $800 commission base and the resulting $240. A single “commission: $240” line is not enough evidence for a finance sign-off.
Run a second period with negative NGR. State your negative-carryover rule in advance, then check whether the platform applies that rule rather than its own default. Scaleo’s commission-model guide explains the deal structures; the POC tests whether your chosen structure calculates correctly.
What should count as a failed POC?
A failure is a result the vendor cannot explain or correct against the agreed test case. Some failures are configuration work. Others should stop procurement.
Treat these as no-go issues until resolved and retested:
- A qualifying conversion cannot be traced back to its attribution record.
- Sending a duplicate event creates a second payable commission.
- Finance cannot reproduce the commission from the underlying events and deal terms.
- A reversed event leaves no visible adjustment history.
- A fraud hold or rejection cannot be explained to the operator.
- The operator cannot export the records needed to reconcile or leave the platform.
- Brand or role permissions expose data that the wrong team or partner should not see.
A vendor may need time to configure your particular FTD definition or NGR formula. That is reasonable. What is not reasonable is marking a case “passed” on the promise that someone will build or explain the behavior after you sign.
Keep a simple issue log: test ID, expected result, actual result, owner, proposed fix, retest date and final status. Screenshots help, but raw logs and exports are stronger evidence.
What if the vendor does not offer a self-service sandbox?
A self-service sandbox is useful, but it is not the only way to run a fair evaluation. Ask for an assisted session in which your team chooses the test cases and watches the vendor execute them. Request the resulting event logs, commission statements and exports afterward.
The distinction is control. A vendor-led demonstration uses the vendor’s preferred examples. An operator-led POC uses your attribution rules, commission terms and failure cases. If a vendor cannot offer either a sandbox or a controlled test with inspectable output, record that limitation in the buying decision.
Also separate POC access from production readiness. A successful synthetic test does not prove that your gaming platform, payment systems and affiliate team are ready to migrate. Integration ownership, data protection, service levels and exit terms still need contract review.
How should you compare the vendors at the end?
Score only demonstrated outcomes. Use the same criteria for Scaleo and every other shortlisted platform:
- Tracking integrity: Can the team trace the click-to-FTD path and explain exceptions?
- Commission accuracy: Do CPA, RevShare and adjustments match the agreed examples?
- Risk controls: Are suspicious events reviewable without silently changing payable balances?
- Operational visibility: Can marketing, risk, affiliates and finance each see the records appropriate to their role?
- Data portability: Can you export the event and commission history needed for reconciliation or a future move?
- Implementation effort: Which test cases worked through configuration, and which require custom work?
Keep price separate until these results are clear. A lower license fee does not compensate for a payout process your finance team cannot audit. Once the technical shortlist is settled, compare the full commercial terms using the iGaming affiliate software pricing guide.
Frequently asked questions
How long should an iGaming affiliate software POC take?
A 14-day test window is enough for a focused set of synthetic cases once access, event mapping and expected results are ready. A custom integration or migration may take longer. Do not compress the test by removing duplicates, reversals or reconciliation; reduce the number of vendors or test records instead.
Should a new casino operator test software before it has live affiliates?
Yes. A new operator can use one synthetic affiliate and a few synthetic players. Testing before launch is often simpler because there is no existing commission history to migrate. The operator still needs to define FTD qualification, attribution and payout rules before judging the results.
Should a POC use real player data?
Use synthetic or appropriately anonymized records by default. Real player data introduces privacy, security and regulatory questions that a sales POC does not need to answer. Your compliance and security teams should approve any exception.
What matters more: a feature checklist or a working test?
A feature checklist helps create the shortlist. A working test decides whether a feature handles your rules. “Supports RevShare” is a starting claim; an itemized calculation from your own test events is evidence.
What should I ask the vendor to send after the POC?
Request the event map, configuration notes, raw or inspectable event logs, commission ledger, sample affiliate statement, finance export and an issue list showing any failed or untested cases. Keep these with the procurement record so that implementation can be checked against what was demonstrated.
The buying decision
Choose the platform whose results your team can reproduce, not the one with the longest feature page. Apply the same test pack to Scaleo and every competing vendor. A good POC should leave marketing confident about attribution, risk confident about review decisions and finance able to reach the payable total without asking the vendor to explain a black box.
