Keno Number Pad Swaps 1 and 7, and 19% Tap Wrong
A keno interface used across several US-facing online casino lobbies renders the numbers 1 and 7 in swapped positions on its on-screen pad, and internal usability testing supplied to me puts the mis-tap rate for those two cells at 19% among first-time players. The swap is a layout bug, not a design choice: the pad reads left-to-right in rows of ten, except that the first row begins 7, 2, 3, 4, 5, 6, 1, 8, 9, 10. Players aiming for 7 hit 1, and players aiming for 1 hit 7, roughly one time in five during the first session.
The vendor's name is not the point here, and I'm not going to pretend the identity of the studio is the story. The story is that a defect this visible survived a release, passed through at least two operator integration reviews, and sat in production long enough for a testing contractor to document it in a slide deck dated March 14. Keno is a low-stakes game with a simple interface, which is exactly why nobody caught it: the people who build and approve these pads do not play them with their own money.
What the swap actually does to a ticket
Keno is a lottery-style draw game. You pick between one and ten (sometimes up to fifteen, depending on the variant) numbers from a pool of 80, the house draws 20, and you're paid according to how many of your picks land. The pick step is the whole game. There is no strategy layer, no dealer decision, no card to read. You choose numbers and you wait.
That makes the pad the game. A sportsbook can have a clumsy bet slip and still function, because the bet slip is downstream of a decision you already made. A keno pad is the decision. When two adjacent cells in the top row are transposed, the player's intent and the ticket diverge at the moment of commitment, and nothing downstream corrects it.
Consider the practical case. A player who always plays 7 — a birthday, a lucky number, the same number they've played at a tribal casino for twenty years — opens the game, taps the cell in the position where 7 has always been, and gets a 1. They don't notice, because keno players scan the grid for their numbers after tapping, and the selected cells are highlighted with a filled circle that reads "1" in small type. On a phone, at arm's length, in a dim room, a filled circle containing a single digit is not a legible confirmation. The player submits, the draw runs, and their 7 either hits or doesn't. If it hits and they didn't pick it, they lose a bet they thought they'd won. If it misses and they didn't pick it, they never know.
The 19% figure comes from a moderated test of 240 participants with no prior exposure to the interface, each asked to build a five-spot ticket using three specified numbers and two of their own choosing. Nineteen percent of the resulting tickets contained a 1 or a 7 that the participant had not intended to select, as confirmed by post-task interview. Among participants over 55, the rate was 27%. Among participants who completed the task on a phone rather than a desktop, 24%.
Those are not catastrophic numbers in the way a payment failure is catastrophic. They are worse in a quieter way. A payment failure generates a support ticket. A mis-tapped keno number generates nothing — the player assumes they misread the grid, or that they typed the wrong thing, or that they're getting old. The defect is absorbed by the player's own self-doubt.
The near-miss problem
There's a second-order effect that the test didn't measure but that anyone who has run a keno product will recognize. Keno players track near-misses. If you pick seven numbers and six of them come up, you notice. The payout table rewards that attention — a six-of-seven pays meaningfully more than a five-of-seven, and the gap is where the game's emotional texture lives.
Now put a silent substitution in the middle of that. A player who intended to play 7 and got 1 will, over a session, accumulate a set of results that don't match their memory of their own tickets. They'll remember picking 7. The ticket says 1. When the draw comes up with a 7 in it and their ticket shows a 1, the experience registers as a near-miss that they cannot explain, because from their perspective they did pick the 7. The result is a low-grade, hard-to-articulate sense that the game is not quite honest — which, from the player's side, is indistinguishable from the game not being honest.
That's the part that should worry operators more than the 19%. A layout bug is fixable in an afternoon. Erosion of trust in the draw itself is not, and keno has no dealer, no shuffle, no physical ball machine to point at as evidence of fairness. The only thing separating regulated online keno from a random number generator with a coat of paint is the player's belief that the numbers they chose are the numbers that were played. Break that and you've broken the product.
How a transposition gets into production
The most likely explanation, according to two developers I spoke with who have shipped keno titles for US-facing operators, is a data-entry error in a configuration array rather than a rendering bug. Keno pads are typically built from a list of 80 values mapped to grid positions, and that list is often hand-maintained because the pool size varies by variant — 80-number keno, 40-number keno, 20-number "mini" keno. A copy-paste or a sort operation applied to the wrong slice produces exactly this: a mostly correct sequence with a localized transposition.
Neither developer would speak on the record about a competitor's product, and I'm not naming the studio because the same pattern almost certainly exists elsewhere and the specific culprit is less instructive than the process failure. But both described the same gap.
The first gap is in automated testing. A keno pad is trivially testable: render the grid, read the values, assert they equal 1 through 80 in order. That test is maybe six lines of code. It is also the kind of test that gets written once during initial development and then never run again, because the pad "doesn't change." Except it does change — every time a variant is added, every time the grid is reskinned for a new operator's white-label, every time someone adjusts the responsive breakpoints and reflows the rows.
The second gap is in the integration review. Operators licensing a third-party keno game typically review the math, the RTP certification, the jurisdiction compliance, and the visual fit with their lobby. They do not, as a rule, sit down and play a five-spot ticket while checking each number against the grid. Why would they? The game is certified. The RTP is documented. The pad is a pad.
The third gap is the one that matters: nobody plays keno for money during QA. Test accounts use play credits. A tester who mis-taps 7 for 1 with fake money loses nothing and has no reason to notice. The 19% mis-tap rate is invisible to anyone who isn't personally invested in the outcome of the ticket.
Where the responsibility legally sits
This is genuinely unsettled, and operators should not assume the vendor carries it. Under most US state gaming regulations, the licensed operator — not the vendor — is responsible for what appears in front of the player. A game that misrepresents the player's selection, even through a layout error, sits uncomfortably close to the language states use around "accurate representation of the wager." I've seen no enforcement action on anything like this, and I doubt one is coming for a transposition bug. But the exposure exists on paper, and it grows if the operator knew about the defect and left it live.
That last clause is doing a lot of work. The testing deck is dated March 14. I asked the studio when the fix shipped and did not receive an answer by publication. If the answer is "it hasn't," then every day since March 14 is a day the operator's legal team would rather not have to explain.
What players can actually do about it
Not much, and I want to be honest about that rather than write a listicle of tips.
The single useful habit is to read back your ticket before you submit. Most keno interfaces show a summary line — "Your picks: 3, 7, 12, 19, 44" — separate from the grid. That summary is generated from the actual selected values, not from the grid positions, so it will show the 1 you didn't mean to pick. It's the only reliable confirmation in the flow. Players who check it will catch the swap on the first ticket. Players who don't will keep losing bets to a bug.
The second habit is to slow down on the top row specifically. Transposition errors in numeric grids cluster at the edges and in the first row, because that's where reading order is most automatic and least scrutinized. If you're playing a number in the 1–10 range, look at it twice.
Beyond that, the remedies are institutional. If you believe a ticket was placed with a number you didn't select, screenshot the confirmation screen and the ticket history and take it to the operator's support channel the same day. Some operators will void and refund a disputed ticket as a goodwill gesture; most will not, because from their side the log shows you tapped the cell you tapped. Whether the cell was labeled correctly is a separate question, and it's the one worth asking in writing. A support transcript that says "our keno pad displays 1 and 7 in swapped positions" is a document. Keep it.
And the usual applies: keno's house edge runs from roughly 4% on a two-spot up past 25% on some ten-spot pay tables, which means the game is already expensive before a layout bug takes another bite. Set a session limit before you open the game, not after. If you're playing to chase a ticket you think you mis-tapped, stop — that's the exact frame of mind the game is worst for.
The question nobody has asked
Here's what I keep coming back to. The 19% figure measures mis-taps among new players. What it doesn't measure is how many experienced players have quietly adapted to the bug without ever registering it as a bug — building a mental map of the pad that routes around the top-left corner, avoiding 1 and 7 entirely because "those two are weird," and never once filing a complaint because they assumed the problem was them.
That population is invisible in every metric an operator tracks. It doesn't show up in support tickets, because they didn't complain. It doesn't show up in churn analysis, because they didn't leave. It shows up only as a slow, unremarked drift in which numbers get played, and nobody is running that report.
Which raises the question worth putting to every operator carrying a third-party keno title right now: when did you last open your own game, with your own money, and check that the numbers on the pad are the numbers on the pad? Not the RTP certificate. Not the compliance sheet. The pad. Because somewhere in a configuration array, a 1 and a 7 are still in each other's seats, and the only person who was ever going to notice is a player who has already decided the mistake was theirs.