18+ only. Fantasy cricket involves financial risk. Play responsibly and within your means. The PROG Act 2025 governs online real-money gaming in India.
CrickBet Referral Code: How Referrals Settle and What to Verify
A referral is a two-sided transaction. Both people should know the qualification steps, tracking window, reward type and disclosure before anyone registers.
Related desk files
bonus terms note · wallet and KYC checklist · verification review
No referral string is certified here
The desk has not verified a live CrickBet referral code, reward amount, tracking link, eligibility period, or operator programme. Do not copy a plausible-looking string into editorial copy. A genuine programme should appear in the authenticated account or on a verified operator domain with dated terms. The record must distinguish the referrer, who sends the invitation, from the referee, who creates or activates the new account. Both should read the conditions. A code shared by a stranger can carry undisclosed commercial benefit and may send the new user through an impersonation page.
Referrer conditions need their own checklist
The referrer may need a verified account, completed KYC, eligible state residence, minimum activity, and no account restrictions. Programmes can exclude self-referral, same-device registrations, shared payment instruments, employees, household members, or previously registered users. A reward can be capped per month or cancelled for duplicate accounts. Before sharing, record the referral screen, programme version, code or link, and date. Do not promise another person that settlement is certain; their eligibility and subsequent actions may be outside the referrer’s knowledge.
Referee conditions can extend beyond registration
A referee may need to be a genuinely new user, enter the code at a particular step, verify identity, make a qualifying deposit, join a named contest, or complete settlement before the invitation counts. Each condition should have a deadline. If the code field appears only during registration, adding it later may be impossible. That is why the new user should pause before account creation and inspect the written terms. Funding should never happen solely to release a referral reward. The referee’s loss limit and legal eligibility come before the referrer’s benefit.
Why tracking fails
Common causes include opening the invitation in one browser and registering in another, blocking cookies or attribution parameters, using an old app build, entering a code after account creation, mistyping the code, or being recognised as an existing user. Device switching and private browsing can also break attribution. None of these should be “fixed” by opening duplicate accounts. Capture the invitation URL without exposing personal tokens, the code-entry screen, registration timestamp, account identifier, app version, and confirmation message. Those details let support inspect the event rather than guessing.
Reward timing and status language
Referral dashboards may use invited, registered, verified, qualified, pending, credited, expired, or rejected. Each status should map to a written event. “Pending” may mean KYC review, contest settlement, fraud screening, or an ordinary waiting period; support should identify which. Record the stated settlement window in business days or calendar days and the relevant timezone. If the reward is bonus credit, check expiry and contest-use rules after it arrives. A credited headline amount can still be restricted, which is why the bonus-code note belongs beside the referral ledger.
Disclosure is part of a fair invitation
Tell the invited person that the referrer may receive a benefit and name its verified type if known. Do not describe the link as neutral help while hiding the incentive. Share the risks, state restrictions, age rule, and any qualifying spend. Avoid group spam or contact-list uploads. A responsible message gives the recipient room to decline and links to operator terms rather than making performance claims. The editorial board treats disclosure as a trust test: if a programme cannot be described plainly without pressure, it should not be promoted.
Evidence and escalation
Keep the programme terms, invitation source, timestamps, account identifiers, KYC completion status, qualifying transaction record, contest settlement, dashboard status, and prior support ticket. Redact PAN, Aadhaar, bank numbers, and OTPs from routine screenshots. An escalation message should state the expected event, actual status, elapsed time, and requested remedy. Ask for a ticket number and written reason. Do not pay an agent to “manually map” the code, and do not share a screen or OTP. If the operator cannot identify the programme under its own terms, treat the reward as disputed rather than guaranteed income.
Closing field note
A referral ledger should be closed after the stated campaign window. Remove public links when terms expire, tell prior recipients that conditions may have changed, and do not recycle an old screenshot as evidence of a current reward.
Questions in the desk ledger
Has the desk verified a current CrickBet referral code?
No. No string, reward, or campaign period is certified here.
Can the code usually be added after registration?
Not always. Inspect the written flow before creating the account.
Should a tracking failure lead to another account?
No. Duplicate accounts may violate terms and make attribution harder.
What should a referrer disclose?
That a benefit may be earned, plus any verified qualification and spend conditions.
Which evidence helps support most?
Terms, invitation record, timestamps, account ID, status, qualifying event, and ticket number.
Field-notes appendix
Treat the referral as a campaign record rather than a permanent arrangement. Save the programme version, the date, the invitee identity, the qualification steps, the reward type, the timing, and the dispute route. When the programme ends, archive the record. A future reader of the ledger should be able to identify what the referrer was promised, what the referee completed, and how the settlement was made. The desk would rather the record end with a clear “settled in full” entry than drift on with stale screenshots. If the operator changes the programme mid-campaign without notice, raise the change with verified support and reference the prior terms, and be ready to revoke the invitation if misleading messaging is observed.
Field-notes appendix
A useful referral ledger does not end with the settlement. After the settlement, archive the programme version, the date, the invitee identifier, the qualification steps, the reward type, and the operator case. If the operator changes the programme later, the archived record protects the previous invitation. If the same campaign opens a second time, the archived record becomes the basis for a second invitation. The desk recommends the same archive for every referral programme the reader uses, even ones that look simple. Simple programmes often change. The archive is the reader's defence against a silent change. It also helps a reader who wants to compare programmes across operators and decide which referral arrangement actually rewards the reader fairly.
Editorial appendix
The desk also recommends that the reader treat the referral campaign as a marketing offer that needs the same scrutiny as a bonus code. The scrutiny includes the programme version, the reward type, the reward timing, the reward expiry, the contest-use rule, the KYC interaction, the tax interaction, the regional availability, the disqualified programme types, the cancellation rule, the dispute route, the data retention period, the privacy policy reference, the responsible-play control reference, and the date. The referral programme may look simple, but a programme that pays a rupee today may pay a different rupee tomorrow. The reader should not assume a programme is the same as the previous one. A reader who keeps the programme version, the date, and the operator's terms can compare the current programme to the previous one and ask a precise question if the comparison shows a change. The comparison is also the basis for a more informed decision: the reader can decide whether the new programme is worth the same effort as the old one, and the reader can revoke the invitation link if the programme is not. A withdrawn invitation is a small action, but it is also a sign of a reader who is in charge of the invitation rather than the other way around. A small sign, repeated, is the same habit. A reader who maintains the habit can build a referral record that is more useful than the loudest invitation in the group chat. The record belongs to the reader. The record, kept, is the reader's defence against a silent change.
What to retain at each step
The referral mechanic is one of the most-likely-to-fail flows in any real-money gaming app. The desk's retention protocol covers each step in the flow, with the screenshots that protect the referrer when the operator's tracking silently drops the referral.
Step 1 — share the code
Retain a screenshot of the message you sent to the referee with the code. The screenshot should include the date, the platform (SMS, WhatsApp, Telegram), and the exact code text. The desk's note: the screenshot is the proof that you shared a specific code at a specific time.
Step 2 — referee signs up
Retain the referee's confirmation screenshot showing the code applied to their account. The screenshot should include the referee's username or account ID and the timestamp of the code application. The desk's note: this is the moment the tracking is committed; everything after this is operational.
Step 3 — referee deposits
Retain the referee's first deposit receipt, including the amount, the date, and the deposit method. The desk's note: this is the qualifying action for most operators; without it, the referral does not credit.
Step 4 — bonus credits
Retain the bonus wallet credit notification, including the credited amount, the date, and the operator's transaction ID. The desk's note: the credit notification is the moment the operator's system recognised the referral; before this moment, the referral is pending.
Step 5 — escalation, if needed
If the bonus does not credit within the operator's published window, contact support with all four prior screenshots. The escalation message template: ticket ID, expected bonus amount, screenshot of each step, request for written confirmation of the next step. Retain the operator's response; if the response is unsatisfactory, escalate to the state regulator.
Disclaimer. CrickBet is an editorial notebook about fantasy cricket. The site does not operate a real-money gaming platform and does not process deposits or withdrawals. References to fantasy contests describe publicly known contest formats from licensed operators. Fantasy cricket involves financial risk; only individuals aged 18+ and resident in eligible Indian states should participate. Please refer to the Public Online Gaming Act 2025 and your state's rules for current eligibility.