Operator guideEN

Affiliates / Affiliates Config

Configure PID-targeted payment-setting records and affiliate event sending windows.

How to use this guide

Start with the main guide

Follow the explanation and examples first. Extra definitions and formulas are available below when you need them.

What this section is for

Use Affiliates / Affiliates Config to maintain two independent PID-targeted configuration sets:

  • Payment Settings stores a named minimum-deposit value in EUR for one or more PIDs.
  • Sending Window limits how long affiliate events remain eligible after a player's first deposit.

These settings matter only when the project uses affiliate PID attribution. Limit write access to affiliate, marketing-operations, payments, or senior administrators.

Payment Settings

Each row contains:

  • Name
  • one or more PIDs
  • Min Deposit EUR
  • Active

The CRUD persistence and visible fields are verified. Live enforcement of Min Deposit EUR in the player deposit flow is not verified. Treat the value as stored configuration, not as proven payment enforcement, until the target brand's payment flow is tested and the runtime consumer is confirmed.

The model also supports Affiliate Keys, but the current form does not expose that field.

Sending Window

Each active rule targets one or more PIDs and can define:

SettingRuntime meaning
Standard LimitDay limit used for a regular player after first deposit.
CPA LimitOverride used only when the player has a successful CPA-qualified FTD.
empty limitNo configured time limit for that branch.
ActiveInactive rows are ignored.

The window uses exact elapsed duration from the first recorded deposit timestamp. A limit of N days expires when at least N x 24 hours has elapsed; there is no calendar-day truncation or timezone boundary in this comparison.

If the sending-window check itself fails, the verified tracking flow fails open and continues rather than blocking the affiliate event. If multiple active records match the same PID, the current lookup has no deterministic order. Avoid duplicate active PID coverage.

How to configure safely

  1. Confirm the exact PID value used by the campaign.
  2. Decide whether the task belongs to Payment Settings or Sending Window.
  3. Use a unique name that identifies the partner or campaign.
  4. Avoid overlapping active records for the same PID.
  5. Save the rule and test with a controlled attributed player.
  6. For Payment Settings, verify the live deposit minimum independently because runtime enforcement is not yet source-proven.
  7. For Sending Window, test both an ordinary player and a successful CPA-qualified FTD when both limits are populated.

Access and troubleshooting

Payment Settings uses the Affiliates permission family. Sending Window uses cpaQualification. Menu visibility alone does not prove that a user can save changes, so verify the target role before editing these rules.

If a rule appears ineffective, check active state, exact PID spelling, first-deposit timestamp, CPA qualification outcome, duplicate matching records, and whether the relevant runtime consumer is actually enabled.

More help

Related pages

Affiliate Payment Settings / Detail

Detail/edit shell for one saved affiliate payment-setting record.

Affiliate Payment Settings / Form

Create and edit form for one affiliate payment-setting record, with visible PID targeting, minimum deposit threshold, and active-state control.

Affiliate Payment Settings / List

Affiliate payment settings inventory page for reviewing configured rows and opening saved records.

Affiliate Deals / Dashboard

Affiliate deal cohort report that period-bounds registrations, then combines the selected players with cumulative deposit and linked-event values.

Affiliate Deals / Form

Create and edit form for affiliate deals, including PID, date window, commercial terms, and responsible person.

Affiliate Deals / List

Searchable table of affiliate deal rows with PID filter, create action, dashboard shortcut, and edit/delete row actions.