Deposit buttons fail 3x more on Android — the fix is one line

Payment failures on Android devices run at roughly three times the rate of iOS across a sample of Australian-facing casino and sportsbook apps — 4.7% of deposit attempts versus 1.6%. The cause is rarely the payment processor, and it's almost never the player's bank. It's a single missing attribute in the button markup, and fixing it takes one line.

That number comes from a mid-2024 audit of 14 AU-licensed operators, covering about 610,000 deposit attempts across both platforms. The pattern held across every operator in the sample, which is the part that should make anyone running product in this market sit up: this isn't one badly built app. It's an industry-wide default.

Why Android breaks what iOS doesn't

The short version: Android WebView and Chrome handle a click event differently from Safari when the user's finger moves even slightly between touchstart and touchend.

On iOS, a tap that drifts 8–10 pixels still fires a clean click on the button. On Android, if the finger moves past the browser's slop threshold — often around 8px on a 3x-density screen, which is about 2.7mm of real movement — the browser fires touchcancel instead of click. No click, no deposit. The button looks pressed. The spinner never appears. The player taps again, and sometimes a third time.

You've seen this in the wild. The punter who says "the app's broken, I tried three times." Support logs it as a user error or a bank decline. It's neither.

There's a second, related failure. Android's default 300ms tap delay — the legacy double-tap-to-zoom wait — means fast tappers can register the first tap as the start of a zoom gesture and the second tap as the actual click. On a deposit button sitting inside a scrollable container, that delay plus a scroll gesture is a compound failure: the browser decides the user is scrolling, kills the tap, and the deposit never fires. iOS removed this delay years ago for viewports with width=device-width.

Both problems have the same root: the button is listening for click when it should be listening for pointerup with a fallback, or — more practically for most teams — using touch-action and pointer-events correctly so the browser stops guessing.

The one line

The fix that cleared up the majority of the gap in the audit:

.deposit-btn { touch-action: manipulation; }

That's it. touch-action: manipulation tells the browser to skip the 300ms double-tap-zoom delay and disables double-tap-to-zoom on that element specifically. It doesn't disable pinch-zoom for the page, so you're not breaking accessibility guidelines, and it doesn't interfere with scrolling.

On its own, touch-action: manipulation closed about 60% of the Android/iOS gap in the operators who applied it — deposit failures dropped from 4.7% to around 2.9%. That's still worse than iOS, which points to the second issue.

For the touchcancel problem, the companion fix is to bind the deposit handler to pointerup rather than click, and to add pointercancel handling that re-enables the button if the gesture is aborted:

btn.addEventListener('pointerup', submitDeposit);
btn.addEventListener('pointercancel', resetButtonState);

Between the two, the operators in the follow-up sample landed at 1.9% Android failure versus 1.6% iOS. The remaining 0.3 points is noise, or close enough that chasing it isn't worth the engineering hours.

The 300ms delay is a deposit tax you're already paying

Here's the part that doesn't show up in a failure-rate dashboard. The 300ms delay doesn't just cause failures — it causes perceived failures. A player taps, nothing happens for a third of a second, they tap again. Now you've got a double-submit risk, and depending on how your idempotency keys are set up, either a duplicate deposit attempt (which the bank may decline as suspicious) or a race condition in your ledger.

In the audit sample, 11% of Android deposit attempts involved two or more taps within 800ms. On iOS, that figure was 4%. Some of those double-taps resolved cleanly because the second tap landed after the button disabled itself. Some didn't.

If you're running a sportsbook and this happens during the last two minutes before a big race jump, the player doesn't blame the button. They blame the book. Retention damage from a failed deposit at a high-intent moment is worth more than the deposit itself.

Where the audit found the failures concentrated

Not evenly distributed. Three patterns stood out:

• Deposit buttons inside modals or slide-ups: 6.1% failure on Android, versus 3.4% for inline buttons. Modals add a focus-management layer that interacts badly with touchcancel.
• Buttons under 44px tall: 5.8% failure. The tap target is too small for the slop threshold to forgive any drift. Apple's 44pt guideline exists for a reason; Android's Material spec says 48dp, and plenty of AU operators are shipping 36px buttons because they look tidier.
• Apple Pay and Google Pay buttons: Google Pay failed at 2.2% versus Apple Pay at 0.9%, but most of that gap traced to the same touch-action issue in the surrounding container, not the wallet SDK itself.

The modal finding is the one worth flagging to your front-end lead. If your deposit flow opens a sheet, check whether the sheet's container has touch-action set anywhere. Most don't.

What this means for conversion maths

If you're doing 50,000 deposit attempts a month on Android — reasonable for a mid-tier AU operator — a 3.1-point failure gap is about 1,550 lost deposits monthly. At an average first-deposit or top-up value of $85, that's roughly $131,000 in monthly handle you're not seeing. Some of those players retry successfully. Most don't, at least not in that session.

The frustrating part is that this isn't a payments problem, so it never gets escalated to the payments team. It surfaces in customer support as "app issues," gets bucketed with generic complaints, and never reaches the sprint board. Meanwhile the fix is a CSS property and a listener swap — maybe two hours of work including QA across device matrix.

There's a reasonable argument that operators haven't fixed this because the failure rate is low enough in absolute terms that it doesn't trip any alerting threshold. 4.7% sounds like a rounding error until you multiply it by handle. Nobody sets a pager for "deposit button slightly worse on one platform."

The uncomfortable question

The audit didn't test whether the same pattern shows up in withdrawal flows, KYC document uploads, or live-betting bet slips. There's no obvious reason it wouldn't — same buttons, same WebView, same touch handling. If deposit buttons fail 3x more on Android, the button that confirms a $2,000 withdrawal probably does too, and a failed withdrawal is a much angrier support ticket than a failed deposit.

So the open question for anyone running product in this market: if you fixed the deposit button and never checked the other touch targets in the app, what else is quietly failing on Android at three times the iOS rate? The one-line fix is easy. Finding out how many buttons need it is the actual work — and it starts with pulling your failure rates by platform and device, not by payment method, which is how most operators currently slice the data.

If you're going to spend the afternoon on it, start with the deposit button, then the withdrawal button, then anything inside a modal. And if you're a player reading this and your deposit button occasionally does nothing on Android — it's not you, and it's not your bank. It's a missing line of CSS that nobody's sprint has room for.