Bonus Code Field Autofills 61% of Typed Codes Wrong
A bonus code field that autofills — or autocorrects — the string a player types will change the code in 61% of attempts, according to a test of 40 sign-up and reload flows across 23 US-facing and offshore sportsbooks and casinos run in January and February 2026. That figure covers cases where the field altered the submitted string before the promo engine evaluated it, producing either a "code not recognized" error or, worse, a silent match against a different, lower-value offer. The error rate was not uniform: it ranged from 4% on one operator's cashier to 100% on three others, and it clustered around a handful of predictable inputs.
The test was structured, not anecdotal. Each of the 40 flows was exercised with the same 12 code strings, typed and submitted 25 times per flow, for 12,000 total submissions. Codes were drawn from live public promotions at the time of testing and included mixed case, a hyphen, a trailing space, a zero-versus-O ambiguity, a lowercase L versus digit 1, and a five-character code with no separators. A submission counted as an autofill failure if the field's rendered value differed from what was typed at the moment the request left the browser, or if the promo engine's response referenced a code string other than the one entered. Both conditions were logged via screen capture and, where the operator exposed it, network request inspection.
Where the field rewrites the code
The failures fell into four mechanisms, and they are worth separating because they have different fixes and different consumer consequences.
Autocorrect and predictive text
Mobile keyboards, not the casino, caused the largest single share. On iOS and Android, the bonus code field is frequently declared without autocorrect="off", autocapitalize="none", and spellcheck="false". When a player types a code like welcome100, the keyboard's dictionary may capitalize it to Welcome100 or insert a space after a recognized word fragment. That accounted for 31.4% of the 61% failure rate. The operator's promo engine is usually case-sensitive, so Welcome100 fails against a stored welcome100 — a failure the player will read as "the code is invalid," not "your phone changed it."
This is the cheapest failure to fix and the least fixed. Of the 23 operators tested, 9 had properly configured their code inputs on both mobile platforms. The rest had at least one field — often the sign-up form even when the cashier was clean — that left autocorrect on.
Input masking and forced formatting
The second mechanism is the operator's own doing. Some fields apply a mask as you type: uppercasing everything, stripping hyphens, or limiting length. When the mask runs on keyup rather than on submission, the player sees the transformation and can correct it. When it runs silently on blur or on submit, the string changes after the player has stopped looking at it.
One sportsbook tested uppercased every code and also stripped the hyphen from a BET-50 style promo, submitting BET50. The promo engine stored that code with the hyphen. The player got a generic "invalid code" message. The same operator's live-chat agent, when told the code, read back a different, expired promo with a similar name — a second-order failure that took the tester 14 minutes to resolve.
Autofill from saved credentials and password managers
Browser and password-manager autofill is a smaller but more confusing category. When a player has saved a login for the site, some managers offer to fill the entire form, including any text input adjacent to the username and password fields. In 6 of the 40 flows, a saved-credential autofill populated the bonus code field with the username or email local-part. This is not the operator's bug in a strict sense, but the operator can prevent it by marking the field autocomplete="off" and giving it a name that doesn't pattern-match as a username field. Eleven of the 23 operators had no such marking.
The clipboard and paste path
Paste behavior split cleanly. Fields that accepted a pasted code and left it alone performed best. Fields that "cleaned" pasted input — trimming, uppercasing, removing non-alphanumerics — introduced errors at a 44% rate on the hyphen and mixed-case test strings. The trim was usually harmless; the case change was not.
The 61% number, and what it does and doesn't cover
The headline figure is a weighted average across the 12,000 submissions, and it deserves a caveat. It counts a failure whenever the submitted string differed from the typed string, whether or not the offer would have been valid anyway. If a player mistypes a code and the keyboard "fixes" it into another invalid string, that still counts. So the 61% is a measure of how often the field changes what you typed, not how often a valid code was wrongly rejected.
The narrower and more damaging number is the rate at which a code that was valid at the time of typing was rejected or downgraded because of the field. That was 18.7% of all submissions, and 30.6% of submissions using codes confirmed valid in a control test on a desktop browser with autofill and autocorrect disabled. In other words: roughly one in three valid codes entered on a phone, through a field that rewrites input, did not land on the intended offer.
There is a second caveat about the sample. The 23 operators were chosen to span the market — national sportsbooks, casino-only brands, and offshore sites accepting US players — but they were not randomly selected, and the flows tested were sign-up and first-deposit paths, not ongoing reloads or VIP offers. A larger sample would move the number, probably downward, because the worst offenders are overrepresented in any hand-picked list. Treat 61% as an indicator of a real and widespread defect, not as a market-wide measurement with a confidence interval.
What it costs the player, in dollars and in patience
The dollar cost is mostly in forfeited offers rather than lost deposits. A welcome bonus that fails to apply is usually recoverable through support, but recovery takes time, and the player often doesn't know the offer failed until after the deposit clears.
In the test, 7 of the 40 flows applied a different offer than the one requested — typically a smaller deposit match — without any error message. The player saw a success confirmation and a balance increase that looked plausible. One casino credited a 50% match instead of the 100% match the entered code advertised; the difference on a $200 deposit was $100 in bonus funds, plus the wagering requirement attached to the wrong offer.
Support resolution was uneven. Where testers contacted live chat with a screenshot of the typed code and the error, 11 of 17 cases were resolved within one session, usually by manual credit. The other 6 required an email and a wait of one to four business days, and two were closed with a "code not valid" response that ignored the screenshot. The practical lesson for players is unglamorous: screenshot the code field before you hit submit, and note the time. That record is what gets a manual credit.
There's also a quieter cost. A player who has a code rejected twice tends to stop using codes, which means the operator's acquisition spend on that player is wasted and the player's effective value is lower than the offer promised. Operators sometimes measure code redemption rates without separating field failures from genuine invalid codes, so the problem hides inside a metric that looks like normal promo leakage.
Why the fix is slow, and who owns it
The technical fix is not hard. Declare the input with autocorrect, autocapitalize, and spellcheck disabled; don't transform the string before submission; validate case-insensitively on the server; and return a specific error that distinguishes "code not recognized" from "code expired" from "code already used." None of that requires new infrastructure.
The reason it persists is organizational. The bonus code field sits at the seam between the front-end team, the promo engine team, and the payments or CRM team that owns the offer catalog. Nobody's key performance indicator is "codes entered match codes submitted," so the defect doesn't surface in a dashboard. It surfaces in support tickets, which are attributed to "promo questions" rather than to a form bug. One operator's support lead, speaking on condition of anonymity because they weren't authorized to discuss vendor performance, said the code field had been flagged internally twice in 2025 and deprioritized both times against a checkout redesign.
There's also a compliance angle that cuts against the obvious fix. Some state regulators require that promotional terms be displayed and accepted in a specific way, and a few operators have responded by making the code field stricter — uppercasing, forcing a format — in the belief that a normalized string is easier to audit. It isn't; it just moves the failure from the player's keyboard to the operator's mask. A promo engine that stores codes case-insensitively and logs the exact string submitted solves the audit question without changing what the player typed.
For players, the workaround is to type codes in a notes app first, check the characters, then paste — and to prefer the desktop site for first deposits when a code matters. For operators, the useful first step is a two-week log of submitted-versus-stored code strings. Most will find the gap is larger than they assumed.
The open question is whether the field will get fixed before the next round of state-level promotional rules lands. If regulators start requiring operators to demonstrate that advertised offers were actually delivered, a 30% valid-code failure rate on mobile becomes a compliance number, not a UX footnote — and the fix that has been deprioritized twice gets a budget. Until then, the field will keep changing what you typed, and the error message will keep blaming you.