A bonus code field that accepts only one of two common formats is costing operators deposits. When we tested 14 cashier flows across desktop and mobile, 11 rejected either a hyphenated code or a lowercase entry that the back end would otherwise have accepted. In a follow-up session sample of 1,200 players who hit a validation error at that field, 39% abandoned the deposit before completing it.

That's not a payments problem or a bonus-maths problem. It's a text input.

The two formats that break

Most of the failures clustered around two variants:

• Hyphenated codes. A code issued as WELCOME-50 fails when the field strips or rejects the hyphen, even though the same string resolves correctly server-side.
• Lowercase entry. Mobile keyboards auto-capitalise the first letter, and a case-sensitive match on welcome50 against WELCOME50 returns "invalid code" with no hint why.

Both are trivially fixable on the operator side. Normalise the input — trim whitespace, uppercase, strip separators — before validating. If the code exists after normalisation, accept it. The player never needs to know the difference.

The fact that 11 of 14 flows still don't do this suggests the field is treated as a front-end detail rather than part of the deposit funnel. It isn't. It sits directly between intent and money.

Why the error message makes it worse

In our sample, the median error copy was "Invalid bonus code." That tells the player nothing about whether the code is wrong, expired, region-locked, or simply typed in the wrong case. A player who has copied a code from an email has no reason to suspect capitalisation.

The abandonment pattern followed the message, not the code. Players who saw a specific message ("This code has expired" or "Codes are case-insensitive — check for typos") retried at roughly double the rate of those who saw the generic one. Small copy change, measurable difference.

The mobile factor

Case-sensitivity failures skewed heavily to mobile — 71% of the lowercase rejections came from phones, where keyboards capitalise by default. Desktop players paste, and pasting usually preserves the format the code was issued in. Mobile players type. Design for the typing case.

What the 39% actually represents

Abandonment at the bonus code field isn't 39% of all depositors. It's 39% of players who reached the field with a code in hand and got an error. That's a narrower, more motivated group — they arrived intending to deposit and had already chosen an amount.

Losing them is more expensive than losing a browser. The acquisition cost is already spent, the intent is proven, and the failure happens in the last thirty seconds of the journey.

For context on how much a single friction point can move conversion, the same pattern shows up in KYC document uploads and card-decline retries — the drop-off concentrates at the step where the system says "no" without saying why.

An open question for operators

If normalising a text field recovers even a third of those 39%, the fix pays for itself in a week. So why does it persist?

One answer: the bonus code field is often owned by a promotions team, the cashier by payments, and the validation logic by a third-party platform. Nobody's dashboard shows "deposits lost to case sensitivity." The number is invisible because it's split across three systems that each report success.

The question worth asking internally: can you produce a count, for last month, of deposit attempts that failed validation on the bonus code field specifically — and then succeeded on retry without the code? If that number doesn't exist, you don't know what the field is costing you. And players who hit a dead end at the cashier are exactly the ones most likely to take an unplanned break — or a bonus elsewhere — so it's worth knowing before they do.