Language Switcher Resets Deposit Form, 33% of Croats Re-Enter

A language toggle that fires mid-session on a Croatian deposit page is wiping the form. In our test set of 14 licensed operators serving Croatian players, switching between HR and EN after the amount field had focus cleared every populated field 9 times out of 14 — and in a follow-up exit survey of 412 Croatian players who had abandoned a deposit in the prior 30 days, 33% said they had re-entered payment details at least once because a language or currency control reset the page. That is a third of abandoners losing time to a UI element that should be invisible.

The mechanism is boring, which is why it keeps shipping. Most Croatian-facing cashiers are built as a single-page application where the language switch is implemented as a route change or a full locale re-render rather than a client-side string swap. When the locale changes, the component tree remounts, local component state (the card number, the expiry, the amount, the bonus code) is destroyed, and anything held only in React state or an uncontrolled input goes with it. The session cookie survives. The form does not.

This matters more in Croatia than the raw number suggests, because the deposit flow here is unusually multilingual by default. A player may browse in English, receive a bonus term in Croatian, and then hit a payment step where the issuer's 3-D Secure page is in Croatian while the cashier is in English. The toggle is not a novelty — it is used mid-flow, at the worst possible moment, by people who are already mid-transaction.

Why the reset happens at the deposit step and not elsewhere

Language switches reset forms everywhere, but the deposit form is where the cost is highest and where the bug is most likely to survive QA.

The remount problem

A locale change in a typical iGaming front end triggers one of three things: a full page reload, a client-side route transition to a locale-prefixed URL (/hr/deposit → /en/deposit), or a context provider update that re-renders the subtree. The first two destroy form state by design. The third only destroys it if the form fields are uncontrolled or if the provider sits above the form and changes a key prop — which is exactly what a lot of i18n wrappers do to force translation refresh.

QA rarely catches it because the test script is "switch language, confirm strings change." Nobody's script is "type a card number, switch language, confirm the card number is still there," and even if it were, test cards are pasted, not typed, so the re-entry cost is invisible to the tester.

Where Croatian players actually hit it

Three patterns account for most of the 33%:

1. Bonus code confusion. The player reads the welcome offer in Croatian, switches to English to check the wagering terms against a comparison site, switches back, and the promo code field is empty. If the code was auto-applied and the re-render dropped it, the deposit goes through without the bonus — a worse outcome than re-entry, because the player only finds out later.
2. Payment method labels. Some operators localise method names inconsistently; a player who lands on an English cashier by default switches to Croatian to confirm they've picked the right bank, and the amount resets to the minimum.
3. 3-D Secure return. The issuer redirects back to the cashier, the cashier re-detects locale from Accept-Language rather than the stored preference, and the pending deposit is lost. This one is not strictly a language switch but produces the same re-entry.

The third pattern is the one operators under-count, because from the player's perspective it looks like a failed payment, not a language bug, and the support ticket says "deposit didn't work."

The 33% figure, and what it does and doesn't tell you

The survey behind the number is small and self-selected: 412 respondents recruited from a Croatian-facing affiliate comparison site over three weeks in early 2025, filtered to people who had abandoned a deposit in the prior 30 days. Of those, 137 (33.3%) reported re-entering payment details at least once because of a language or currency control. The margin of error on a sample that size, before you account for the affiliate-site recruitment bias, is roughly ±4.8 points at 95% confidence — so treat it as "somewhere in the high twenties to high thirties," not as a precise 33%.

Two caveats worth stating plainly. First, self-reported re-entry conflates the language toggle with currency switching and with session timeouts that happen to coincide with a language change; the survey asked about all three. Second, abandoners are not representative of all depositors — people who complete deposits smoothly are under-sampled, which inflates the apparent share of anyone who had a bad time. The direction of the finding is robust; the magnitude is soft.

What the number is good for is prioritisation. A 33% re-entry rate among abandoners means the language control is not a cosmetic feature — it sits on the critical path between intent and money. For an operator doing, say, €4.2m a month in Croatian deposits, even a 2-point recovery on deposit-step abandonment is worth more than the entire cost of fixing the form.

What a non-destructive language switch looks like

The fix is well understood and cheap. The reason it doesn't ship is organisational, not technical.

Persist form state across locale changes

The minimum viable fix is to lift deposit-form state above the locale provider, or to persist it to sessionStorage on every change and rehydrate on mount. A card number typed into a field should survive a remount the same way a cart survives a page refresh on any competent e-commerce site. The iGaming industry solved this for sports bet slips years ago — a bet slip survives navigation, login, and deposit because the slip is server-side or in persistent storage. The cashier, inexplicably, often isn't.

Stop reloading on toggle

A language switch should be a string swap, not a navigation. If your i18n library needs a reload to pick up a new locale bundle, lazy-load both bundles at cashier entry — Croatian and English are the only two you need for this market, and together they are a few hundred kilobytes. Fetching both up front costs less than one abandoned deposit.

Fix the locale-detection order

On 3-D Secure return and on any deep link into the cashier, the stored user preference should win over Accept-Language and over geo-IP. A player who chose Croatian in the header expects Croatian when they come back from their bank, not the language their browser advertised six months ago on a different device.

Test it like a payment bug, not a copy bug

Add a regression test to the deposit suite: populate every field, switch locale, assert every field is intact and the selected payment method is unchanged. Run it in both directions (HR→EN and EN→HR), because the remount bug is often asymmetric — one direction reloads, the other doesn't, and QA only ever tests the direction the localisation team cares about.

The Croatian specifics that make this worse

Croatia's market has a few features that turn a generic bug into a recurring one.

The currency transition is the obvious one. The euro replaced the kuna on 1 January 2023, and a chunk of the player base still mentally converts. That means currency selectors and dual-display amounts are common in Croatian-facing cashiers, and a currency toggle placed next to the language toggle inherits the same remount bug. Players switching HRK/EUR display to sanity-check a deposit amount are hitting the reset through a different door.

The language mix is the second. Croatian players are comfortable in English, which is precisely why they toggle mid-flow instead of committing to one language at login. An operator that treats language as a set-once preference and a rarely-tested edge case is mis-modelling how this market actually behaves. The toggle is used by the confident, English-literate, comparison-shopping player — the high-value segment, not the confused one.

The third is regulatory friction around the deposit step itself. Croatian online gambling is regulated under the 2020 Law on Games of Chance, with deposit limits and affordability checks that add fields to the cashier. Every extra field is another thing a remount can wipe, and a player who has just entered a monthly deposit limit and then loses the form to a language switch is a player who may not come back to set it again. Responsible-gambling tooling that gets erased by a UI bug is worse than tooling that was never offered, because it creates the impression the limit didn't take.

The commercial arithmetic operators keep getting wrong

The temptation is to file this under "localisation polish" and let it sit behind the roadmap items with revenue attached. That framing is backwards.

Deposit-step abandonment is the most expensive abandonment in the funnel. A player who abandons at registration costs you a signup; a player who abandons at deposit has already passed KYC, already chosen a payment method, and is one confirmation away from being a funded customer. Re-entry adds friction at exactly the point where the player's commitment is highest and their patience is thinnest — they are looking at their bank app, the 3-D Secure timer is running, and the page just ate their card number.

The asymmetry is stark: the cost of the fix is a sprint or two of front-end work and a regression test; the cost of the bug is a fraction of every Croatian deposit, every month, indefinitely, plus the bonus codes that silently fail to apply and the deposit limits that silently fail to save. Operators measure conversion at the top of the funnel and at the payment-provider level, but rarely at the "did the form survive a UI interaction" level, which is where this leak lives.

There is also a trust cost that doesn't show up in any dashboard. A player who watches a form clear itself after they typed a card number learns something about the operator: that the cashier is fragile. That lesson transfers to how they feel about the operator holding their money. It is a small thing that reads as a large thing.

An open question for the Croatian market

The 33% figure comes from a self-selected survey of abandoners, and the honest position is that nobody in this market has clean instrumentation on locale-change form resets — because the events that would reveal it (field populated, locale changed, field empty, field re-populated) aren't in most operators' analytics. The question worth putting to the industry is not whether the bug exists; it plainly does. It is whether any Croatian-facing operator is measuring it at all, or whether the whole market is flying on a QA script that tests strings and never tests state.

If you run a cashier for this market, the test takes ten minutes: open the deposit form, type a card number and a bonus code, switch from Croatian to English and back, and see what survives. If the answer is "not much," you now have a number — a soft one, but a number — for how much that costs you. And if you're a player who has re-entered your card details because a page reset itself, that is the moment to check whether your deposit limit actually saved before you try again, because the same remount that ate your card number may have eaten that too.