What the verifier actually checks
A referral credit is not a single decision. It is the output of three sequential gates plus a cross-account check that runs at payout time. A reader who treats the invite as a one-step event reads the screen the wrong way. The screen shows three gates, each with its own status indicator, and the credit only moves from pending to available after every gate is green.
Gate one: the signup-screen code field
Gate one is the signup screen itself. The verifier reads the code field at the moment the account is created. If the field is empty, no code is registered and the credit cannot be retroactively attached to a later Refer & Earn screen. If the field contains a string, the verifier compares the string against the live referral database. A match routes the invitee into the referral ledger. A non-match leaves the invitee in the standard signup path. There is no fuzzy match, no second-chance prompt, and no "did you mean" warning. The verifier either accepts the string or it does not.
The signup screen contains two visually similar fields: a refer code field and a bonus code field. The two fields are wired to different ledgers. The refer code field registers the referral. The bonus code field registers a separate welcome offer route. A reader who pastes a friend's code into the bonus code field sees the welcome offer applied and the referral never registers. There is no automated rerouting. The reader's screen shows the bonus offer landing, and the absence of a referral is invisible until the Refer & Earn screen is opened separately.
Gate two: KYC verification
Gate two is KYC. The verifier asks for a PAN, a selfie, and a fresh mobile re-verification. Each document returns a clean or contested result, and contested results restart the gate. A reader whose PAN is already linked to another Player11 account hits the matched document check, which is a separate signal from the shared-device check. The two are independent. A reader can pass the shared-device check and fail the matched document check on the same KYC submission.
KYC is the slowest of the three gates to close. A clean PAN with a clear selfie and a freshly re-verified mobile number closes KYC in one pass. A contested PAN, a blurry selfie, or a mobile number that fails the re-verification SMS opens a review queue that takes hours to days. The referral credit does not advance during the review window. The credit sits in pending state while the verifier works the queue.
Gate three: the first paid contest
Gate three is the first paid contest. The verifier watches for a contest entry that locks against a real entry fee, not against a bonus balance. A reader who enters a free practice contest with zero entry fee does not advance the gate. A reader who enters a paid contest paid for with a bonus balance also does not advance the gate. The verifier wants a contest paid for with cash that the operator can confirm settled on the payment processor.
The first paid contest is also the gate most sensitive to state eligibility. A reader who signs up in an eligible state and moves to a restricted state before locking the first paid contest will find the gate open again. The verifier can also reclassify paid contests in mid-flight. A format that was eligible at signup can become read-only if the state regulator issues a fresh notice in the days between signup and lock-in. The reader's only signal is the eligibility list inside the in-app Legal screen, which is the source of truth the verifier reads from.
The cross-account check
The cross-account check is not a gate. It runs once at payout, after all three gates are green, and it verifies that the inviter's qualifying chain is still intact. The inviter must still hold an active Player11 account, the inviter must not have a payment reversal or chargeback on a recent contest, and the inviter must not have hit a separate verification check that closed the inviter's own wallet. If any of those conditions fail, the matching credit on the invitee's side does not post either. The invitee's qualifying work on gates one through three is preserved, but the credit cannot post without the matching inviter.
The cross-account check is the one the invitee has the least control over. Gates one through three are all decisions the invitee can affect directly. The cross-account check is a decision the inviter makes on the inviter's side, often without knowing that the invitee is watching the wallet for the credit to land.
Edge case one: the code in the wrong field
The most common cause of a forfeited credit is also the simplest to prevent. A reader pastes a friend's alphanumeric code into the field labelled "Bonus code" because the two fields sit one above the other on a small phone screen and the labels read similarly in the in-app font. The bonus offer applies, the welcome offer ledger lights up, and the referral ledger never registers the invite.
The verifier does not warn the reader at paste time. The verifier reads the field at account creation, applies the bonus route, and discards the string from the referral route. The reader who opens the Refer & Earn screen later in the week sees a clean state with no record of the invite. There is no support ticket the reader can file to "reroute" the code. The verifier does not have a reroute function, and the gate has already moved on.
The recovery path is prevention. The signup screen contains a refer code field with a separate label. Paste the code into that field, not the field above or below it. If the reader has already created the account with the code in the wrong field, the only recovery is to delete the account, reinstall the app, and create a new account with the code in the correct field. The delete-and-resignup path costs the reader the welcome bonus on the original account, so a reader who values the welcome bonus over the referral credit can leave the account as it is.
Edge case two: shared device, shared PAN, shared number
The second cause of a forfeited credit is the shared-device check. The verifier matches three signals at signup: the device fingerprint, the mobile number, and the PAN. Two or more accounts that share any two of those three signals trigger the flag. The flag is silent. Signup succeeds, KYC succeeds, and the first paid contest joins. The credit never moves out of pending state, however, and the inviter never sees the matching credit on the inviter's wallet.
The shared-device check is calibrated for fraud. The verifier is looking for a reader who opens a second account to claim the invite credit on the second account, leaving the operator with a duplicated incentive. A family household with two readers who happen to use the same phone or share a mobile plan can hit the flag accidentally. A reader who reinstalls the app on a second phone but keeps the same mobile number and PAN can also hit the flag.
The recovery path is asymmetric. A genuine family household can route around the flag by separating the signals across the two readers: a separate device for each, a separate mobile number for each, and a separate PAN for each. A reader who is reinstalling on a second phone can keep the second phone and the same mobile number only if the PAN on the second account is different. The verifier does not publish a self-service appeal for the flag. Customer care on the in-app support queue is the only surface that returns a ruling from the verification team.
Edge case three: a state change between signup and first contest
The third cause of a forfeited credit is a state change between signup and the first paid contest. The verifier reads the eligibility list on the day the gate closes, not the day the account is created. A reader who signs up in an eligible state and crosses into a restricted state before locking the first paid contest will find the gate open again. The verifier also re-reads the list when a state regulator publishes a fresh notice in the days between signup and the first contest.
The state change edge case is the one most readers misread. The state the reader signs up in is not the state the credit settles against. The state the credit settles against is the state the reader is in on the day the first paid contest locks. A reader who travels between states with the same app, or who moves between an eligible state and a restricted state during a long qualifying window, should not assume the credit will land just because the original signup was in an eligible state.
The recovery path is to wait for the gate to re-open with a fresh eligibility status. A reader who travels back into an eligible state can complete the first paid contest on the next eligible fixture and the gate will close on the original qualifying chain. A reader who moves permanently to a restricted state cannot advance the gate inside the restricted state and cannot advance it across state lines. The credit is forfeit in the permanent-move case because the eligibility check has no positive path forward.
Edge case four: the inviter's chain breaks first
The fourth cause of a forfeited credit is the cross-account check. The inviter's wallet must be active and in good standing at the moment the invitee's gate three closes. An inviter who deletes the account, hits a payment reversal on a recent contest, fails a separate verification check on the inviter's wallet, or simply lets the inviter's account sit dormant past the usage window cancels the matching credit on the invitee's side as well.
The cross-account edge case is the one the invitee has the least control over. The invitee can clear gates one through three on the invitee's side and still lose the credit because the inviter closed the inviter's account the night before. The reader's screen shows a successful gate three and a pending credit, and the credit never moves out of pending because the inviter's wallet is gone. The invitee has no recourse inside the app because the missing piece is on the inviter's side, not the invitee's.
The recovery path is to invite through a fresh inviter. A reader who has a strong relationship with the original inviter can wait for the inviter to reopen the inviter's account, reinstall the app, and re-run the qualifying chain, at which point the verifier can reattempt the cross-account check. A reader who does not have a strong relationship with the original inviter can request a fresh invite from a different inviter and run the qualifying chain against the new invite. The new invite starts gates one through three from scratch and the old invite's qualifying work is preserved on the wallet but not posted to the ledger.
The seven-row decision matrix
Each edge case maps to a specific gate and a specific recovery path. The table is built from the in-app Refer & Earn screen and the support queue's typical response pattern.
| Edge case | Gate it breaks | What the screen shows | Recovery path |
|---|---|---|---|
| Code pasted into bonus field | Gate one (signup code) | Bonus offer applied, Refer & Earn empty | Delete account and resignup with code in correct field |
| Shared device, PAN or number | Gate one (silent flag) plus gate two (KYC) | All gates appear green, credit stuck pending | Separate the signals across the two accounts, or escalate to support |
| Code field empty at signup | Gate one (no code registered) | Refer & Earn empty | Cannot be retroactively attached; delete and resignup with the code |
| Contested KYC document | Gate two (KYC review) | Gate two flagged open | Resubmit a clean PAN, clear selfie and re-verify the mobile |
| Practice or bonus-funded first contest | Gate three (first paid contest) | Gate three flagged open | Enter a cash-paid contest to settle gate three |
| State change to restricted jurisdiction | Gate three (eligibility re-check) | Gate three flagged open with state note | Travel back to eligible state, or accept the forfeit |
| Inviter account closed or reversed | Cross-account check at payout | All gates green, credit stuck pending | Wait for inviter to reopen and re-run, or invite a fresh inviter |
The two right-hand columns are the parts of the table that are not on the screen. The screen names the gate. The screen does not name the recovery path. A reader who reads the table before signing up can run the four edge cases against the signup plan and close each one before it triggers. A reader who reads the table after a failed credit has to walk the recovery path instead.
What a reader can do inside the app today
Five actions sit between a refer code arriving in a text message and a credit that lands inside the published usage window. The order is the order in which the verifier reads the gates, not the order in which a new reader usually does them.
Action one: open the signup screen and read the labels. The refer code field is the lower of the two code fields. Paste the friend's alphanumeric string into that field and leave the bonus code field empty. Action two: confirm the device, mobile number and PAN are not already linked to a Player11 account. A reader who reinstalls the app on a new phone but keeps the same mobile number and PAN will trigger the shared-device check at signup. Action three: keep the KYC document set clean. A fresh PAN, a clear selfie in good light, and a mobile number that receives the re-verification SMS in one pass closes KYC in one attempt. Action four: plan the first paid contest before locking it. A practice contest does not advance gate three, and a bonus-funded contest does not advance gate three. Only a cash-paid contest settles the gate. Action five: confirm the inviter's wallet is active on the day of the first contest. The cross-account check runs at payout, and an inviter who closed the inviter's account the night before cancels the credit.
The five actions are conservative on purpose. Each one mirrors a gate the verifier runs after signup. A reader who runs all five before locking the first contest will avoid the four edge cases above and reduce the support queue to the cases where the verifier's signal returns a contested result the reader cannot fix on the device.
The audit trail inside the app
The Refer & Earn screen shows the three gates with a status indicator per gate. A reader who has a failed credit can read the gate status to identify which check is the open one. The screen does not name the underlying edge case directly. A reader who sees gate two open can infer a KYC issue. A reader who sees gate three open can infer a contest, eligibility or state issue. A reader who sees all gates green and the credit still pending has inferred a cross-account issue or a silent shared-device flag.
The audit trail is partial by design. The screen is built for the typical reader who follows the standard path and watches the credit land in the first week. The screen is not built for the reader who has hit one of the four edge cases and needs a named ruling. Customer care on the in-app support queue is the surface that returns the named edge case from the verification team. The queue reads the same gates the screen reads and returns a specific reason for the failure, which is the answer the reader needs to decide between the recovery path and the forfeit path.
What the audit trail does not show is the timestamp on each gate closure. A reader who wants to know how long a contested KYC document has been sitting in the review queue cannot read that from the screen. The reader can read it from the support queue. The support queue returns a timestamped status that names the contested document and the resubmit window. The resubmit window is the one piece of information that decides whether the credit lands inside the published usage window or runs past it.
Where to read next
The four edge cases above are the parts of the refer code mechanic that look like ordinary decisions at signup but turn out to be gate-killing choices. Open the refer code page for the standard mechanic. Open the bonus code page for the welcome offer route that the wrong-field paste accidentally activates. Open the wallet and KYC page for the documents the KYC gate will request and the resubmit windows the verifier publishes. The three pages cover the standard path and the four edge cases that fork off it.
What to watch next
The cross-account check is the part of the refer code mechanic most likely to evolve in the next season. The verifier has been adjusting the gate definitions and the silent flag thresholds between seasons for the past three cycles, and the cross-account check is the gate where the verifier has the least public documentation. A reader who plans to invite a friend through the credit should treat the cross-account check as a per-season contract and re-check the relevant in-app screen at the start of each season.
A practical signal to watch: the order in which the verifier opens the gates when a credit fails. A reader who sees gate three fail before gate two closes is hitting an eligibility or contest issue. A reader who sees gate two fail on a clean document set is hitting a silent shared-device flag. A reader who sees all gates green and the credit stuck pending is hitting the cross-account check. The order is the same; the verifier's tuning is the variable.
The next verified check is the gate status displayed on the Refer & Earn screen at the moment the first paid contest locks. A reader who opens the screen on the day of the first contest will see exactly which gate is open and can decide between the recovery path and the forfeit path before the usage window closes. The mechanic is the same; the gate status is the signal.