Roughly 18% of UK mobile casino deposits never make it from the payment screen to the wallet intact. The money leaves the player's bank, the operator's cashier marks the transaction as pending, and then the session dies — usually because the handset has dropped from Wi-Fi to 4G, or from 4G to a dead spot, at the exact moment the PSP is waiting on a callback. The deposit is not lost. It is stranded, and it sits stranded for anywhere between four minutes and three days.

That figure comes from a 2024 analysis of 2.4 million UK deposit attempts across 11 operators, and it is the single most under-discussed number in the mobile gambling stack. The industry spends enormous energy on onboarding funnels, bonus mechanics and CRM. Almost nobody publishes on what happens in the 4.2 seconds between "Confirm" and "Balance updated."

The mechanics of a dropped deposit

A card deposit on a mobile casino is not one transaction. It is a chain of at least five.

1. The app or mobile browser sends a tokenised card request to the operator's cashier.
2. The cashier forwards it to an acquirer or directly to the PSP.
3. The PSP contacts the issuing bank for authorisation.
4. The issuing bank returns an auth code, and the PSP confirms back to the cashier.
5. The cashier credits the player wallet and fires a push notification.

Steps 1 through 4 are typically done inside 2 to 4 seconds on a stable connection. Step 5 is where it goes wrong on mobile, because step 5 depends on the client still being reachable. If the player's phone has switched networks, backgrounded the app, or dropped to a 2G fallback in a basement, the operator has the money but the client never hears about it.

The player, meanwhile, sees a spinner, then an error, then — quite reasonably — assumes the deposit failed and tries again. This is where duplicate authorisations originate. A meaningful share of the "double charge" complaints that reach UK casino support desks are not double charges at all; they are one successful deposit the player never saw confirmed, plus one genuine retry.

Why mobile is worse than desktop

Desktop browsers hold a TCP session open across the whole flow. Mobile apps do not. iOS aggressively suspends background network activity, and Android's Doze and App Standby modes will throttle a socket within seconds of the screen locking. A player who taps "Deposit" and immediately locks their phone — which is common, because people deposit in queues, on trains, in lifts — is asking the operating system to finish a financial transaction it has no intention of finishing.

Operators have partly worked around this with server-to-server webhooks and reconciliation jobs that run every 5 to 15 minutes. That fixes the ledger. It does not fix the player's experience, because the player has already opened a live chat ticket, or worse, opened a second casino account to deposit again.

What the 18% actually breaks down into

The headline figure flatters nobody, but it is worth splitting.

• Roughly 11% are recoverable in under 15 minutes. The webhook lands, the wallet credits, and the player sees a delayed confirmation. Annoying, not damaging.
• About 5% take between 1 and 24 hours, usually because the reconciliation job caught the transaction but flagged it for manual review — common when the deposit is the player's third in an hour, or when the IP geolocation does not match the card's registered address.
• The remaining 2% are the problem. These are deposits where the auth succeeded, the PSP settled, and the operator's cashier never received a matching reference. Resolving these requires a manual trace between the operator's finance team and the PSP, and it can take up to three working days.

Two percent sounds trivial until you apply it to scale. A mid-sized UK-facing operator processing £40m in monthly mobile deposits is looking at roughly £800,000 a month in transactions that require manual reconciliation. At a fully loaded support cost of £6 to £9 per ticket, that is not a rounding error.

The regulatory edge nobody wants to touch

Under the Gambling Commission's licence conditions, customer funds must be protected and transactions must be accurately recorded. A deposit that has left the player's bank but not arrived in the wallet sits in an awkward category: the operator holds the funds, but has not credited them, and the player has no visibility of where the money is.

This is not technically a licence breach. It is, however, exactly the kind of thing that generates a formal complaint, and formal complaints to the Commission about deposit handling have been rising. The Commission's own guidance on fair and transparent terms pushes operators toward clear communication when a transaction is delayed — but "clear communication" in practice often means a generic email two hours later, by which point the player has already disputed the charge with their bank.

That is the real cost. A chargeback costs the operator the deposit, a £15 to £25 dispute fee, and a mark against their acquirer ratio. And a player who files a chargeback over a £20 deposit that was simply slow is a player who is not coming back.

Where the fixes are landing

Three approaches are showing measurable results.

Open Banking payments. Pay-by-bank rails skip the card networks entirely and settle through a redirect flow that is more resilient to app suspension, because the bank's own app handles the authorisation. Drop-off rates on these rails are running 6 to 9 percentage points lower than card on mobile specifically, though they introduce their own friction: the player has to leave the casino app, authenticate with their bank, and come back.

Wallet-first deposits. Apple Pay and Google Pay reduce the number of steps and, more importantly, keep the authentication inside a native OS sheet that survives app backgrounding. The trade-off is that operators lose some card data they would otherwise use for CRM and fraud scoring.

Idempotency keys on the client side. This is the unglamorous fix. If the app generates a unique key for each deposit attempt and the cashier rejects any duplicate key, retries cannot create double authorisations. Several tier-one operators have implemented this since 2023, and their duplicate-deposit tickets have dropped by more than half.

None of these solve the underlying problem, which is that mobile operating systems are designed to kill background network activity and financial transactions are designed to need it.

The question operators have not answered

The 18% figure is uncomfortable because it implies that a meaningful slice of UK mobile deposit friction is not a payments problem, not a UX problem, and not a compliance problem — it is an operating system problem that the gambling industry has no control over and has largely chosen not to measure.

The obvious question is whether the true figure is higher. The 2.4 million attempts in that analysis only cover deposits where the operator could match a client-side event to a server-side event. Deposits where the app crashed before logging anything are invisible in the data. So is the player who gave up, closed the app, and never tried again — and that player never generates a ticket, never files a complaint, and never appears in any churn model, because from the operator's perspective they simply never deposited in the first place.

If you are running payments or CRM at a UK operator and you cannot state your own mid-session drop rate to one decimal place, the 18% is not the number you should be worried about. It is the number you have not yet looked for.