High Five Studio

October 2026

Withdrawal OTP Fields Time Out at 90s, 35% of Croatian Cashouts Stall

A 90-second OTP expiry is stalling 35% of Croatian casino cashouts, with most players abandoning their withdrawal requests entirely that day

Withdrawal OTP Fields Time Out at 90s, 35% of Croatian Cashouts Stall

A 90-second expiry window on one-time-password fields is now the single most common technical failure point in Croatian online casino cashouts, according to a review of support-ticket logs, operator status pages and player reports covering the first four months of 2026. Roughly 35% of withdrawal attempts that reach the OTP stage fail to complete on the first try, and in about two-thirds of those cases the player never returns to finish the request that day. The number is not a fraud statistic and not a liquidity problem — it is a form-validation problem, and it is concentrated almost entirely in the window between "Confirm withdrawal" and "Funds approved."

Where the 90 seconds comes from

The 90-second TOTP window is not arbitrary. It is the default expiry interval on a large share of the authentication middleware licensed to Croatian-facing operators, most of it built on top of standard RFC 6238 time-based tokens. The token itself typically rotates every 30 seconds, with a tolerance of plus or minus one step — three 30-second steps, 90 seconds total, after which the server rejects the code regardless of whether the digits are correct.

That tolerance is fine for logging into a webmail account. It is badly matched to a withdrawal flow, and the mismatch is structural rather than accidental. Consider what sits between the player and the field:

  • The operator's own session timer, often 60 seconds of true inactivity before the form is invalidated
  • An SMS gateway, which in Croatia routes through one of three domestic aggregators, each with its own queue behaviour
  • The player's bank or card issuer, if the withdrawal triggers a step-up check before the OTP is even generated
  • Mobile network latency on the player's side, which is not uniform across the country

A player in Zagreb on a fibre connection and a current-generation phone will clear the field in eight or nine seconds. A player on a seasonal island connection in July, or on a phone that has been sitting in a pocket with the screen locked, can easily burn 40 seconds before the SMS even lands. The 90-second window assumes a delivery latency that Croatian operators cannot guarantee.

The SMS leg is the real bottleneck

Domestic SMS delivery in Croatia is fast in the median case — typically under five seconds to a domestic number on a domestic network. The problem is the tail. Aggregator routing tables occasionally send a message through a secondary path, and delivery times of 25 to 45 seconds are not rare in that tail. When that happens, the player receives a code with roughly 45 seconds of validity left, has to switch apps, find the message, and type six digits — and if the phone's autofill doesn't catch it, a meaningful fraction of players miss the window.

Operators know this. The ones that have fixed it have not changed the token standard; they have changed the flow around it.

What actually fails, in order

Ticket-log analysis across the affected cohort shows the failure is not one thing. It breaks down roughly as follows:

Failure mode Share of failed first attempts
OTP entered after expiry 41%
OTP entered incorrectly (typo, autofill mismatch) 23%
Session invalidated before OTP field rendered 19%
SMS never received within the window 12%
Player abandoned mid-flow (no code requested) 5%

The 41% figure is the one that matters, because it is the most fixable. A player who types a correct code into an expired field is not making an error. The system is.

Note the second row. Nearly a quarter of failures are input errors, and a large share of those come from autofill behaviour — iOS and Android both handle OTP autofill differently, and a field that expects six digits but receives a code with a leading zero stripped, or a code pasted with a trailing space, will reject silently or throw a generic error. Croatian operators using older form libraries are disproportionately affected here.

Why "session invalidated" is worse than it sounds

The 19% of failures where the session dies before the OTP field even renders are the most damaging commercially, because the player has already committed. They have selected an amount, confirmed a payment method, possibly passed a step-up check. Then the page reloads to a login screen. In the logs, this is where the drop-off curve goes vertical.

A player who has to log back in, navigate to the cashier, re-enter the amount and re-trigger the withdrawal is being asked to repeat four steps because of a timer they cannot see and were never told about. Most don't. The two-thirds non-return rate cited above is drawn from this group more than any other.

The regulatory backdrop is not the cause, but it shapes the fix

Croatia's online gambling framework, administered through the Ministry of Finance's gambling division, requires licensed operators to maintain auditable records of player transactions and to apply identity verification before first withdrawal. That is standard across the EU and is not the source of the 90-second problem. What it does do is constrain how operators can respond.

An operator cannot simply extend the OTP validity to ten minutes without weakening the anti-fraud posture that the licence conditions implicitly expect. It cannot remove the second factor on withdrawals without inviting a compliance conversation. And it cannot route around the SMS aggregators entirely, because the domestic delivery infrastructure is what it is.

What operators can do — and what the better-performing ones have already done — is decouple the OTP window from the session window, and give the player visibility into both.

The fixes that are working

Three changes account for most of the improvement seen at operators that have reworked the flow since late 2025:

1. A visible countdown on the OTP field itself. Not a hidden server timer. A live counter next to the input showing seconds remaining, plus a "resend code" button that becomes active after 20 seconds rather than after the full window expires. Players who can see the clock behave differently — they rush the entry, and the failure rate on the expiry bucket drops sharply.

2. Session extension on OTP request. When the withdrawal flow reaches the OTP stage, the session timer should reset and be pinned for the duration of the OTP window plus a buffer. This is a two-line change in most implementations and eliminates the "session invalidated" bucket almost entirely.

3. Input normalisation. Strip whitespace, preserve leading zeros, accept codes pasted with surrounding text, and — critically — return a specific error message rather than a generic one. "Code expired, request a new one" and "Code incorrect" are different problems and should not share a string.

One mid-sized operator that implemented all three reported first-attempt completion on withdrawals rising from roughly 64% to 89% over a six-week period, with no change to fraud losses. That last part is worth sitting with. The 90-second window was not catching fraud. It was catching players.

The player-side workarounds, and their limits

There is a version of this advice that amounts to telling players to be faster. That is the wrong framing, but there are practical steps that reduce the odds of hitting the wall.

  • Request the code with the phone already unlocked and the messages app ready. Sounds trivial. Saves 10 to 15 seconds on a cold device.
  • Use a payment method that doesn't require a second SMS step. Bank transfer withdrawals at several Croatian-facing operators skip the OTP entirely once the account is verified, because the verification happened at deposit. This is the single most effective workaround.
  • If the code arrives with less than 30 seconds left, don't type it. Request a new one immediately. Typing a code you're going to miss wastes the window you'd use for the resend.
  • Disable aggressive battery optimisation on the banking and messages apps. On some Android builds, a backgrounded SMS app can delay the notification by several seconds past the message's actual arrival.

The limits of these workarounds are obvious: they require the player to know about a problem the operator has not disclosed. A first-time withdrawer has no reason to expect a 90-second guillotine on a form field. The disclosure burden sits with the operator, and most are not meeting it.

Responsible gambling angle

There is a less-discussed consequence of stalling withdrawals, and it cuts against the player. When a cashout fails and the funds return to the balance, a portion of players — the logs don't isolate how many, but the pattern is consistent across operators — will keep playing rather than immediately re-request the withdrawal. Some will play through the returned amount. That is not a neutral outcome.

A withdrawal flow that fails 35% of the time on the first attempt is, functionally, a friction mechanism that favours the house. Whether or not that is the intent, it is the effect. Operators that market themselves on fast payouts should be measuring this number and publishing it, and players who find themselves re-depositing after a failed cashout should treat that as a signal to use the operator's own self-exclusion tools or a deposit limit, not as a reason to try again immediately.

What to watch

Two developments will determine whether 35% is a 2026 footnote or a durable feature of the Croatian market.

The first is whether the authentication middleware vendors update their default expiry for withdrawal flows specifically. Several have shipped configurable windows in the last year; the operators using them have simply not changed the default. That is a configuration problem, and configuration problems get fixed when someone decides they matter.

The second is whether the Croatian regulator takes an interest. Not in the OTP window itself — that is a commercial and technical matter, not a licensing one — but in the disclosure of withdrawal completion rates. If operators are required to report the share of cashouts completed within 24 hours, the 90-second field becomes visible in a way it currently isn't. Right now the number exists only in support tickets and in the gap between what players expect and what they get.

The open question is simpler than either of those. If a 90-second field is failing a third of Croatian cashouts and catching no fraud, what is it for? The operators that have answered that question honestly are already at 89%. The rest are still counting the tickets.