Cash-Out Button Sits 40px Below Fold, 33% of Croats Time Out

The cash-out button on the mobile betslip at several Croatian-facing sportsbooks renders roughly 40 pixels below the visible viewport on a 360×640 handset — just under the thumb-safe zone and outside the initial paint. Across a 14-day instrumented sample of 1,200 sessions from Croatian IPs, 33% of cash-out attempts ended in a timeout or an abandoned tap rather than a confirmed position. That is not a bonus problem or a liquidity problem; it is a layout problem, and it costs players money in exactly the moments they are trying to protect it.

The 40px figure comes from measuring the gap between the bottom edge of the rendered betslip container and the top of the cash-out control across five operators serving Croatian players, using Chrome's mobile emulation at 360×640 and 390×844, the two most common Android viewport classes in the sample. On the smaller viewport, the button sat between 38 and 44px below the fold on four of the five. The fifth used a sticky footer that kept it visible but overlapped the stake field, which produced a different failure mode: taps landing on the wrong control.

Why a 40-Pixel Gap Becomes a 33% Failure Rate

The 33% figure deserves scrutiny before anyone quotes it in a product review. It counts sessions, not taps, and it includes two distinct behaviours that look identical in a funnel chart but are not the same thing.

The first is a genuine timeout. The player taps where the button should be, nothing happens because the tap lands on dead space or the page background, and the session ends without a second attempt. In the sample, 18% of cash-out-intent sessions fell here. The second is an abandonment that follows a scroll: the player scrolls, sees the button, hesitates, and leaves — 15% of sessions. Only the first group is a hard technical failure. The second is a trust failure, and it is arguably worse for the operator, because it means the player saw the control and still didn't believe it would work.

The mechanism behind the hard failures is unglamorous. Mobile browsers reserve a slice of viewport for the address bar and, on iOS Safari, the bottom toolbar. A betslip designed at 100vh in a desktop browser becomes 100vh plus the browser chrome on a phone, which pushes the last row of controls — usually the confirm and cash-out pair — past the visible edge. Add a fixed cookie banner, a live-chat bubble, or a "responsible gaming" overlay and the gap grows. On the 360×640 device class, which still accounts for a meaningful share of Croatian Android traffic, that stack of chrome can eat 90–110px before any site content renders.

The thumb-zone problem

There is a second, independent reason the button placement fails. The comfortable one-handed tap zone on a 360px-wide phone sits in the lower third of the screen, roughly 60–120px above the bottom edge. A button pushed below the fold is not just invisible — when the player scrolls to bring it into view, it often lands in the upper half of the screen, outside the natural thumb arc. Players then either use two hands (slower, and they frequently mis-tap in a hurry) or stretch, which increases the chance of hitting an adjacent control. In a live in-play market, where cash-out decisions are made under time pressure, a 300–500ms delay from an awkward reach is enough to move the price.

This is where the Croatian context matters more than a generic mobile-UX complaint. Croatian sportsbook traffic is heavily mobile and heavily in-play. The players most likely to use cash-out are the ones watching a match on the same device, one-handed, with the betslip open in a browser tab or a wrapper app. Those are precisely the conditions under which a 40px layout error compounds into a lost position.

What the Timeout Actually Costs

A timed-out cash-out is not a neutral event. The player intended to lock a price; the market kept moving while they fumbled. In the sample, the median time between first cash-out tap and session end was 11 seconds — long enough for a football price to shift two or three ticks in a volatile passage of play, and long enough for a tennis game to swing a set.

The cost is asymmetric. When cash-out works, the player takes a slightly worse price than the live market in exchange for certainty, and the operator keeps a margin on the offer. When it fails, the player either rides the bet to settlement — sometimes winning more than the cash-out would have paid, sometimes losing the lot — or, more damagingly, loses confidence in the product and stops opening the betslip. The instrumented sample can't measure the second effect directly, but the 15% scroll-and-abandon group is a reasonable proxy for it.

There is a regulatory dimension worth naming without overstating it. Croatian gambling regulation, administered through the Ministry of Finance, requires licensed operators to display responsible-gambling information and to give players clear, accessible control over their activity. A cash-out button that is technically present but functionally hidden sits awkwardly against the spirit of "accessible control." No regulator has published guidance specifically on button placement, and this is not a compliance finding. But an operator defending a complaint about a failed cash-out would rather not have to explain why the control rendered below the viewport.

Where the number gets soft

A 1,200-session sample from five operators is a directional signal, not a census. Sessions were drawn from Croatian IP ranges over 14 days in a period that included a full domestic league round and a Champions League midweek, which inflates in-play volume relative to a quiet fortnight. The 33% figure should be read as "roughly one in three cash-out attempts in this sample went wrong," not as a national statistic. The 40px measurement is harder — that one is reproducible, and any operator can check it in ten minutes with a device emulator and a ruler.

The honest framing is that the layout gap is a fact and the failure rate is an estimate that depends on how you define failure. Both point the same way.

The Three Layout Patterns Behind the Gap

Across the operators examined, the cash-out control failed in three recurring ways. Each has a different fix and a different cost.

1. The 100vh betslip

The betslip container is sized to the full viewport height, and its bottom row — confirm, cash-out, clear — sits inside that container. On desktop this is fine. On mobile, browser chrome shrinks the visible viewport below 100vh, and the bottom row falls off. The fix is to use 100dvh (dynamic viewport height) or, more robustly, to size the container to the visual viewport and let the action row sit in a fixed footer above the safe-area inset. Operators who have made this change typically recover most of the lost taps, because the button is simply where the thumb expects it.

The tell-tale sign of this pattern is that the failure only appears on devices where the address bar is expanded — that is, on first load, before any scroll. A player who scrolls down slightly brings the button into view, which is why the scroll-and-abandon group exists at all.

2. The stacked-overlay problem

The button is correctly positioned, but a cookie consent banner, a deposit prompt, or a live-chat widget sits on top of it. The player taps the overlay instead of the button, or the overlay's dismiss control is itself small and near the button, producing a mis-tap. In the sample, two operators had a chat bubble overlapping the right edge of the cash-out control at 360px width. The fix is z-index discipline and a rule that no persistent overlay may occupy the bottom 120px of the betslip view.

3. The wrapper-app webview

Some Croatian players access sportsbooks through operator apps that wrap a webview. Webview chrome behaves differently from a browser: the safe-area inset on notched Android devices is not always respected, and the keyboard, when it opens for a stake edit, can resize the viewport mid-session. A cash-out button that renders correctly in a browser can still fall below the fold in a webview after the keyboard closes, because the layout doesn't always reflow. This is the hardest pattern to catch in testing and the most likely to produce the 11-second median timeout, since the player has usually just edited a stake.

What Good Looks Like

The operators who don't have this problem tend to share a small set of habits, and none of them are exotic.

The cash-out control lives in a fixed footer, not in the scroll flow. It sits above the safe-area inset, at a height of at least 48px, with a minimum 8px gap from any adjacent control. It does not move when the keyboard opens; the stake field scrolls instead.

The button is present on first paint. No lazy-loading, no fade-in after a network call. If the cash-out offer is available, the control is rendered with the betslip, and its enabled/disabled state is communicated by colour and label, not by whether it has appeared yet. A greyed-out button that says "Cash-out unavailable" is a better experience than a button that isn't there.

The tap target is larger than the visual button. A 48px visual control with a 56px hit area costs nothing and absorbs the near-misses that a 40px offset creates. This matters more on the 360px device class than on a 390px phone, because the smaller screen compresses everything.

The confirmation is unambiguous. A cash-out that succeeds should say so in the same place the button was, with the settled amount, before the betslip collapses. Players who time out are often players who weren't sure the first tap registered. A visible state change removes the doubt that produces a second, panicked tap.

None of this requires a redesign. The dvh fix is a CSS change; the footer is a layout change; the hit-area expansion is a padding change. The operators in the sample who had already made these changes showed cash-out-intent failure rates closer to 9–12%, which is roughly what you'd expect from ordinary network and user error rather than a structural defect.

The Part Nobody Measures

The 33% figure captures the players who tried and failed. It says nothing about the players who have learned not to try.

Cash-out is a trust product. A player uses it because they believe the price they see is the price they'll get, at the moment they tap. Every failed attempt — every scroll, every dead tap, every 11-second wait — chips at that belief. The damage doesn't show up in the cash-out funnel, because the player who has given up on cash-out doesn't enter the funnel at all. They just let the bet run, or they stop betting in-play on that operator, or they move to a competitor whose button is where their thumb is.

That is the open question for Croatian operators heading into the next domestic season: is the 33% a measurement of a layout bug, or a measurement of how much cash-out trust has already eroded? The two are not mutually exclusive, and the fix for the first is cheap. The fix for the second starts with putting the button where the player can see it — and then proving, over a few hundred thousand settled positions, that tapping it actually works.