Customer care

How to reach a human, and what to expect from each channel.

Most platform issues resolve quickly through the right channel. This page lists every channel we have seen, what each is good for, and the median response time we have measured across our reviews sample.

Channels

Pick the channel that matches the ticket.

Four channels, four different use cases. The right one depends on what you need done.

AIn-app supportFastest → BEmailBest for KYC → CLive chatBest for tables → DPhoneEscalation only →

In-app support

A close-up of an adult hand holding a smartphone showing a customer-care chat window, on a wooden tabletop. — Editorial photograph — in-app support as the format most readers use.

In-app support is the fastest channel for most tickets. Open the app, tap the help icon (usually in the settings or account menu), choose the category that matches your issue, and a chat window opens. The window is staffed during business hours and is the right channel for table issues, deposit issues and most account issues.

The median response time across our reviews sample is 1 to 4 hours depending on the platform. The fastest platforms answer within 30 minutes; the slowest take up to 8 hours.

Email

Email is the right channel for KYC tickets (where you need to attach documents), withdrawal tickets (where you need to attach transaction references), and any ticket where the response will be a written decision you need to keep. The median response time is 4 to 24 hours; the slowest platforms take up to 48 hours.

Use the platform's published support email — usually support@ or help@ on the operator domain. Avoid generic webmail addresses (gmail, yahoo) when contacting a platform; legitimate platforms always publish an address on their own domain.

What to include

Account email, account ID (if separate), the table ID or transaction ID, the timestamp of the issue, and a clear one-sentence description of the resolution you are looking for. Attach documents as PDFs, not as phone-camera JPEGs.

Live chat (web)

Live chat on the platform's website is the same staffing as in-app support but accessible without installing the app. The median response time is identical (1 to 4 hours), and the use case is identical (table issues, deposit issues, account issues). Live chat is the right channel for readers who do not want to install the app yet but need to reach support.

Phone

Phone support is the right channel for escalations — when a ticket has been open for more than 7 days, when the ticket involves a significant balance, or when the response from email or chat has been unsatisfactory. Most platforms publish a phone number only on the responsible-play or complaints page, not in the main support area; that placement is intentional, because phone support is the highest-cost channel and reserved for the cases that need it.

Before you call

Have your account ID, the ticket ID (from email or chat), the table ID or transaction ID, and a one-sentence description of the resolution you are looking for. Phone support will ask for all of these; having them ready shortens the call.

Status page

Reading the platform's status page.

The first check before opening any ticket is the platform's own status page — a public feed of incidents, scheduled maintenance and component health.

A status page is a public, timestamped feed the platform publishes about the health of its own services. It is separate from support, separate from marketing, and is intended to be read before you open a ticket. Most platforms publish it at a stable URL such as status.example.com or status.example.io, and most publish it through third-party services (Statuspage, Status.io, Better Uptime) that maintain a 90-day incident history. The page lists the platform's components individually — login, deposit processing, withdrawal processing, tables, KYC verification, RNG — and shows the current state of each as an operational status (typically green, yellow or red) with a short incident summary.

Reading the page means scanning the component list for the system your issue touches. A withdrawal that has not arrived means you scan for the withdrawal processing component, not the RNG component. A table that will not open means you scan for the tables component, not the KYC component. The page is structured so that each component's state is independent — the platform can be running normally on every other component while a single component is in degraded mode. The incident summary below the component list names the affected component, the start time, the current state, and the expected resolution time or the last update timestamp.

The first use of the status page is to determine whether your issue is local to your setup. If every component on the status page is green and your last update timestamp is within the last few minutes, the issue is almost certainly local — your network, your device, your cached session, your payment method, your KYC document. The standard troubleshooting ladder (refresh, clear cache, switch browser or device, wait 24 hours, check with a friend on a different network) applies. You do not need to open a support ticket for a local issue; the platform cannot help with a problem that is not on its side.

The second use of the status page is to determine whether an issue is platform-wide and therefore something a support ticket can act on. If the component your issue touches is yellow or red, the platform has acknowledged the issue, the incident summary names the affected systems, and the page gives an expected resolution window — your ticket would be a duplicate of an incident the platform is already working on. In that case the right action is to wait for the incident to resolve (subscribe to the page for email or SMS notifications), then verify the change once the status returns to green, and only open a ticket if the change has not actually landed on your account. Tickets opened during a known incident are routed to a holding queue and answered with a template, which is a slower path than waiting for the incident to resolve.

Want to know what response time to expect from your platform?

The reviews ledger scores five platforms on support response time.

Read the reviews Verify safety

Ticket craft

How to write a support ticket that gets resolved.

Five details that turn a vague complaint into a ticket support can act on.

The first detail is the account ID. Most platforms have an account ID separate from your email — a string of digits or alphanumeric characters visible on the account page. Quote it in the first line of the ticket. Support cannot look up your account by email alone if you have multiple accounts or have changed your email.

The second detail is the timestamp in the platform's local timezone. "I tried to withdraw at 11pm" is less useful than "I tried to withdraw at 23:04 IST on 04 Aug 2026". The timestamp lets support locate the exact server log entry.

The third detail is the transaction ID or table ID. Most platforms embed these in the receipt email or the table lobby. Quote it. Support cannot reconstruct a transaction by description alone.

The fourth detail is what you have already tried. "I tried refreshing, clearing the cache, switching browsers, and waiting 24 hours" tells support the issue is not local to your setup. "I tried refreshing" leaves them wondering if the issue is local to your setup.

The fifth detail is the resolution you are looking for. "I would like the withdrawal to be processed or the funds to be returned to my playable balance with a clear explanation of why the withdrawal was held" is a resolution request. "Please fix this" is not.

Five details, all in the first paragraph of the ticket. Tickets that include them are typically resolved in a single exchange; tickets that omit them typically require three or four exchanges before resolution.

When to escalate

Three signs a ticket needs to be escalated.

Three patterns that mean the standard support path is not enough.

The first pattern is silence after 7 business days. A ticket that has not received any reply within a week is not in the standard queue. Re-send the ticket with the original ticket ID in the subject line; this routes it back to a supervisor who can investigate the original ticket's status.

The second pattern is a recurring complaint. If the same issue happens twice within a 30-day window — the same withdrawal held twice, the same KYC document rejected twice — the underlying problem has not been fixed even if the individual ticket was "resolved". Escalate with the prior ticket IDs in the new ticket.

The third pattern is a dispute about the platform's published terms. If the platform's action contradicts its own published policy, the dispute is no longer about the individual ticket — it is about whether the policy applies at all. Escalate with the policy text quoted alongside the action being disputed.

Escalation is not aggression. It is the standard process for cases that the first-line queue cannot resolve. Platforms that treat escalation as adversarial are platforms that have not built a serious support operation; the reviews ledger tracks this as a usability deduction.

What support can and cannot do

Five things support can resolve and five things it cannot.

Setting expectations on both ends so the ticket reaches a resolution faster.

Support can resolve: deposit holds within the published threshold verification rule; KYC document rejections where the document is the issue (not the identity); withdrawal processing delays within the published SLA; bonus application errors where the bonus was applied to the wrong account; and session login issues where the credentials are confirmed correct.

Support cannot resolve: jurisdictional disputes about whether play is legal in your state (support is not a legal adviser); bonus disputes where the published terms clearly cover the situation but you disagree with the terms (the terms govern); complaints about the platform's published RNG fairness (the audit certificate is the answer); refund requests for winnings lost in a hand you believe was unfair (the hand was played under the platform's rules); and any request that requires the platform to violate its own published terms.

Knowing what support can and cannot resolve lets you write a ticket that lands in the right queue on the first try. Tickets that ask for something support cannot do are routed to the legal or compliance team, which adds days to the resolution.

Outside the support queue

When to skip support and contact the operator directly.

Three cases where the right escalation path is not through the support ticket queue.

The first case is when a withdrawal has been held for more than 7 business days with no ticket acknowledgement. The right escalation is to send a written complaint (email with read-receipt) to the operator's published complaints email, copying the support ticket ID. The complaints email is read by a different team and has its own SLA.

The second case is when a platform's published terms have been changed mid-session in a way that affects your active play. The right escalation is to file a complaint with the relevant regulatory body in your state — usually the state police's cyber cell or the consumer forum — with the operator's published terms (dated) and the change notification attached.

The third case is when you suspect fraud — your account has been accessed from a location you have not visited, your password has been changed without your action, or your wallet balance has changed without a transaction you initiated. The right escalation is the platform's security email (usually security@ or fraud@), and the parallel escalation is to your bank's fraud team if your payment method is attached to the wallet.

Want to know what response time to expect from your platform?

The reviews ledger scores five platforms on support response time.

Read the reviews Verify safety

After the ticket

What to do once the issue is resolved.

Three short steps to close the loop on a resolved support ticket.

The first step is to confirm the resolution. Open your account on a fresh page and verify the change the support ticket promised is actually in place. Withdrawal unblocked? Balance correct? Setting applied? The confirmation step is the only way to know the resolution landed, because support tickets occasionally close without the underlying change being made.

The second step is to record the resolution. Open your session log (the paper score pad we recommend on the responsible-play page) and write down the ticket ID, the resolution summary, and the date. The record is useful if the issue recurs — you have a paper trail of what was supposed to have been fixed, which makes the next ticket easier to resolve.

The third step is to file the platform-side feedback form, if the platform offers one. Most platforms publish a satisfaction survey after a ticket is closed. The feedback goes to the support supervisor, who uses it to identify patterns. If your resolution was excellent, say so; if it was poor, say so. The feedback loop is what makes support better for the next reader.

Self-help resources

What to try before you open a ticket.

Four resources that resolve the issue faster than a ticket does, when they apply.

The first resource is the help centre search. Most platform help centres have a search box that returns relevant articles for the most common issues. Searching for "withdrawal pending" or "KYC rejected" returns a step-by-step guide in most cases. The guide is faster than a ticket because it does not require a human to read and respond.

The second resource is the FAQ block. Most platforms publish a FAQ block on the responsible-play or safety page that addresses the most common responsible-play and security questions. If your question is on the FAQ, the answer is the FAQ — no ticket needed.

The third resource is the community forum, where the platform has one. Some platforms run a community forum where players help each other with common questions. The forum is moderated by the platform, so the answers are usually reliable. Treat the forum as a complement to support, not a replacement.

The fourth resource is the operator reference page on this site. We publish a summary of each platform's support channels and what to expect from each. The summary is current as of the publication date; the platform's own help pages are more current, but the operator reference gives you the structure faster.