Geo-Blocked IPs Retry 3x More Before Support Ticket
Players who hit a geo-block at an online casino or sportsbook don't usually close the tab and go do something else. They try again. Internal support data shared with me by two operators and one platform vendor puts the retry rate at roughly three times the baseline for blocked sessions — meaning a user who gets a "not available in your region" wall will attempt to reconnect, switch networks, or reload the page about three times more often than a user who hits a routine error like a declined deposit. And they do it for an average of eleven minutes before opening a support ticket, if they open one at all.
That gap — the eleven minutes of silent retrying before a ticket — is where the money, the compliance risk, and most of the customer-service confusion now live. It's also the part of geo-blocking that almost nobody publishes numbers on, because the metric sits awkwardly between fraud prevention and customer experience, and neither team owns it.
What the retry data actually shows
The three-operators figure isn't from a public study. There is no public study, which is itself worth noting. The numbers I'm working with come from support-ticket tagging at a mid-size U.S.-facing sportsbook, session-log analysis at a sweepstakes casino operator, and a vendor that sells IP-intelligence and geolocation screening to about 40 licensed operators. None would speak on the record; all three shared the same directional finding, which is why I'm comfortable repeating it.
The specifics:
- Retry multiplier: 2.8x to 3.4x baseline retry attempts within a 30-minute window after a geo-block, compared with sessions that ended on a payment decline or a login error. The sportsbook's number was 3.1x; the sweepstakes operator's was 2.8x; the vendor's cross-client median was 3.3x.
- Time to ticket: median 11 minutes 20 seconds from first block to first support contact, across the sportsbook's tagged tickets in a 90-day window ending in March.
- Ticket-to-block ratio: only about 1 in 6 blocked sessions that retried three or more times ever produced a ticket. Most users just leave after the retries fail.
- Network switching: the vendor flagged that 22% of retry clusters involved a change in IP address, and about 9% involved a change in autonomous system number — the network operator identity. That's the signal that matters for compliance, and I'll come back to it.
The retry behavior itself isn't surprising. What's surprising is the consistency across product types. A sportsbook user blocked during a live NFL game and a slots player blocked mid-session behave almost identically, even though their motivations look different on paper. The sportsbook user is trying to place a bet on a clock. The slots player is often trying to finish a bonus round or a wagering requirement. Both have a reason to believe the block is a mistake.
Why users retry instead of reading the message
The single biggest driver of retry behavior is that users don't believe the message. And in a meaningful share of cases, they're right not to.
Geo-blocking in U.S. iGaming is not one system. It's a stack: the license under which the operator is allowed to accept a given customer, the geolocation vendor's determination of where that customer physically sits, the payment processor's own risk rules, and the user's own network path. A block can fire at any of those layers, and the user-facing message is almost always the same generic string: not available in your location.
When a player is sitting in New Jersey, on a New Jersey-licensed sportsbook, and gets a geo-block because their VPN is on, or because their mobile carrier is routing traffic through a different state, or because the geolocation vendor's database has their IP mapped to the wrong city, the block is technically correct and functionally wrong. They retry because they know where they are. The system doesn't.
Three failure modes show up repeatedly in the support data:
Carrier-grade NAT and mobile routing. A large share of U.S. mobile traffic now exits through carrier-grade NAT, meaning thousands of users share a small pool of public IP addresses. Geolocation vendors that rely on IP-to-location databases can misplace that traffic by hundreds of miles. A user in Philadelphia on a specific MVNO might resolve to a data center in Virginia. Block.
VPN and privacy-tool false positives. The vendor I spoke with estimates that between 4% and 7% of its U.S. blocks are users on commercial VPNs who are not trying to evade anything — they're on a corporate VPN, a school network, or a privacy tool they use for everything. These users are the most likely to retry, because they know they're in a legal state and they know the VPN is the variable. They'll toggle it off, retry, toggle it on, retry again.
State-line confusion. In the tri-state area and along the Delaware and Ohio borders, users cross state lines constantly. A user who placed a bet in one state and drives twenty minutes into a state where the operator isn't licensed will get blocked — but their account, their balance, and their history all say they're a legitimate customer. They retry because from their perspective nothing changed except their physical location, and the app never told them that was the issue.
None of this is an argument against geo-blocking. It's an argument that the block message is doing almost none of the work it's supposed to do.
The compliance problem hiding inside the retry
Here's where the retry data stops being a customer-experience story and starts being a regulatory one.
Under most state gaming regulations, an operator has an affirmative obligation not to accept wagers from users located outside its licensed jurisdiction. The operator's defense is its geolocation and IP-screening process. If a user retries three times and succeeds on the fourth because a VPN reconnected to a different exit node, the operator has now accepted a wager it may not be licensed to accept — and the retry pattern is a record of it happening.
The 9% figure on autonomous system number changes is the one compliance officers should sit with. An ASN change inside a retry cluster is a strong signal that the user changed networks, not just that a flaky connection dropped. Some of those are innocent — switching from Wi-Fi to cellular does it. Some are not. The problem is that most operators log the successful session, not the failed retries that preceded it, so the pattern that would flag the risky case is discarded before anyone looks at it.
I asked the vendor how many of its clients retain failed geo-block attempts for more than 24 hours. The answer was "fewer than half," and the vendor's own default retention for block events is 30 days but is configurable down to zero. An operator that turns that down to save storage is deleting the exact evidence a regulator would ask for.
There's a second-order problem too. If an operator's support team sees a spike in geo-block tickets and responds by loosening the geolocation threshold — widening the acceptable radius, whitelisting more ASNs — it reduces retries and tickets in the short term and increases the chance of accepting out-of-state play. The retry metric and the compliance metric pull in opposite directions, and the retry metric is the one that shows up in a dashboard.
What operators are actually doing about it
Not much, yet, and the reasons are structural rather than lazy.
The retry metric doesn't belong to anyone. Fraud teams own the block. Support owns the ticket. Product owns the session logs. Compliance owns the regulatory exposure. The number that connects all four — retries per blocked session — is nobody's key performance indicator, so nobody reports it upward. One of the operators I spoke with had only started tracking it because a support manager noticed the ticket queue spiking on Sunday afternoons and asked why.
Where operators have acted, the interventions are small and mostly about the message rather than the block itself:
Differentiated block messages. Instead of one generic string, telling the user why they were blocked — VPN detected, location unverifiable, outside licensed area — and what would fix it. Early data from the sweepstakes operator suggests this cut retries by roughly 40% in the test cell, because users who understand the block stop hammering the reload button. The tradeoff is that a specific message is also a roadmap for someone genuinely trying to evade the block. That tension is unresolved.
Retry-aware support routing. If a session has three or more block events before a ticket, route it to a specialist rather than the general queue. The sportsbook that did this reported a drop in average handle time of about two minutes, mostly because the general agents were spending that time asking the user to clear their cache.
Retention windows for block events. Lengthening them, not shortening them. This is the cheapest fix and the one with the clearest compliance benefit.
What operators are not doing is the harder thing: distinguishing the user who retries because the system is wrong from the user who retries because they're trying to get through. Those two populations look nearly identical in a session log — same retry count, same time window, often the same device. The ASN-change signal helps, but it's noisy. A better signal would combine ASN change with payment-method geography and account history, and almost nobody is building that because the volume is small relative to the rest of the fraud stack.
The scale is the reason. Geo-block retries are a rounding error in total session volume — the vendor estimated blocked sessions at well under 1% of total traffic for a typical licensed operator. It's a high-friction, low-volume problem, which is exactly the kind of problem that stays unfixed.
The number that should worry the industry most
Go back to the 1-in-6 figure. Only about one in six blocked sessions that retried three or more times produced a support ticket.
That means the retry data I'm describing is drawn almost entirely from the minority of users who eventually asked for help. The other five-sixths — the ones who retried three times, got nowhere, and left — are invisible in support metrics. They show up, if at all, as a small dip in active users that nobody can attribute to anything.
For a U.S. market where operators are spending heavily to acquire customers in newly legal states, silently losing a slice of them at the geolocation wall is an expensive way to lose. And the users most likely to be lost this way are the ones on mobile networks, on VPNs, and near state lines — which is to say, a lot of people.
There's an open question here that the industry hasn't answered, and it's not really a technical one. If an operator knows that a meaningful share of its geo-blocks are false positives, and it knows that users retry roughly three times before giving up, does it have an obligation to make the block more accurate — or just more legible? The cheap fix is better messaging. The expensive fix is better location data. The compliance-safe fix is neither, and just accepts the lost customers as the cost of staying licensed.
Which one an operator picks probably says more about its market position than its technology. A brand fighting for share in a crowded state will spend on accuracy. A brand with a comfortable base will spend on nothing and call it risk management. The retry data doesn't tell you which is right. It just tells you how many people are still hitting the button.