Five Checkout Failure Patterns Every Mobile Product Team Encounters
Mobile checkout failures are not evenly distributed. Published mobile commerce research consistently identifies the same five technical patterns as the dominant causes of checkout failure across ecommerce and fintech apps. This article documents each pattern, explains the underlying mechanism, and describes the test coverage required to catch it before release.
Pattern 1: Android keyboard overlay
The most prevalent checkout failure pattern on Android. On Samsung Galaxy devices running One UI 5.0+, the soft keyboard defaults to overlay mode in certain screen configurations rather than resizing the view. When the user focuses on the CVV or postcode field, the keyboard overlays the field rather than pushing the view up. The field appears to be visible but the submit button is obscured. Users submit without completing the field and receive a validation error with no visible error message — the error is rendered below the keyboard.
- Primary cause: windowSoftInputMode not set to adjustResize in the Activity or Fragment
- Affected devices: Samsung Galaxy S and A series on One UI 5.0+, covering a significant share of Android sessions in most markets
- Test coverage required: payment form test on Samsung Galaxy device with physical keyboard interaction, verify all form fields and CTA visible with keyboard open
- Fix: set android:windowSoftInputMode="adjustResize" in AndroidManifest.xml for the checkout Activity
Pattern 2: Decimal separator locale mismatch
Payment form fields that accept currency amounts must handle both period (.) and comma (,) as decimal separators depending on locale. In Germany, France, and most of continental Europe, the decimal separator is a comma and the thousands separator is a period — the opposite of US convention. An input field that validates for /^\d+\.\d{2}$/ will reject all European card payments, silently or with a confusing error message.
- Primary cause: payment amount validation regex or parsing logic assumes US decimal convention
- Affected users: all users with device locale set to a European or Latin American regional setting
- Test coverage required: payment form entry with device locale set to de-DE, fr-FR, and pt-BR; verify amount fields accept comma as decimal separator
- Fix: use locale-aware number parsing (NumberFormat with user locale); do not parse payment amounts with a fixed-locale formatter
Pattern 3: SCA / 3D Secure redirect handling
Strong Customer Authentication (SCA) under PSD2 requires a redirect to the issuing bank for authentication on European transactions. The redirect opens a browser (Safari View Controller on iOS, Custom Chrome Tab on Android) for the bank's authentication challenge. The app must handle the return from that browser via a deep link or URL scheme. Failures in this handoff — deep link not registered, session state lost during background/foreground transition, timeout handling absent — cause silent payment failures where the bank authentication succeeds but the order is never confirmed.
- Failure mode A: deep link scheme not registered for the return URL, app never receives confirmation
- Failure mode B: session timeout during the bank challenge (challenges can take >5 minutes), payment SDK's session has expired when user returns
- Failure mode C: app backgrounded during challenge, iOS or Android terminates the app to reclaim memory, returning to a dead session
- Test coverage required: test full 3DS2 challenge flow with simulated timeout; test 3DS1 redirect to external browser; test challenge with app backgrounded mid-challenge
Pattern 4: Wallet payment session race condition
Apple Pay and Google Pay both involve a biometric authentication step before the payment intent is captured. The payment SDK fires a callback after biometric success, but if the app calls the capture API before the PaymentIntent has been created server-side (due to a race condition in the payment initialisation flow), the capture fails silently. The user has authenticated and considers the payment complete; the app has no completed transaction.
- Primary cause: payment initialisation (PaymentIntent creation) and wallet sheet presentation are started concurrently rather than sequentially
- Affected scenarios: high-latency API calls (slow backend or poor network) where the PaymentIntent creation has not completed when the user completes biometric authentication
- Test coverage required: wallet payment test under network latency simulation (packet delay 300–1000ms); verify order confirmation is received before success screen is shown
- Fix: PaymentIntent must be fully created before presenting the wallet sheet; do not present the sheet optimistically
Pattern 5: Order confirmation crash on degraded network
The order confirmation step — the final API call after payment capture — is a frequent source of crashes on poor network conditions. A force-unwrap on an optional API response field, an incorrect assumption that the network request will complete within the app's active lifecycle, or a failure to handle HTTP 429 or 503 responses gracefully can crash the app precisely at the moment the user believes the order is confirmed. The user has been charged; the app has crashed; support volume increases.
- Primary cause: force-unwrap (!) on optional fields in the order confirmation API response model
- Contributing cause: network timeout not handled, app crashes when the confirmation request exceeds the timeout threshold
- Test coverage required: order confirmation API call under 3G network simulation; test with malformed / partial API response; test with HTTP 503 response
- Fix: all API response fields should be optional with defined fallback behaviour; network errors should surface a recoverable error state, not a crash
Frequently asked questions
The fastest diagnostic approach is to combine payment gateway failure data with session replay (Sentry, Datadog RUM, or FullStory for mobile) and device-specific crash monitoring (Crashlytics). Payment gateway failure data tells you which step fails; session replay shows the user interaction; crash monitoring identifies technical root causes. If you don't have session replay, MAT's checkout diagnostic sprint runs structured test execution against these five patterns on your app within 5 business days.
Patterns 1 and 2 (keyboard overlay, decimal separator) are independent of payment gateway. Pattern 3 (SCA) is specific to European transactions processed through PSD2-regulated payment flows. Pattern 4 (wallet race condition) applies to all wallets but severity varies by SDK — some payment SDK versions have addressed this, others have not. Pattern 5 (confirmation crash) is independent of payment gateway and applies to any app that assumes its API layer will behave correctly under degraded conditions.
Need more detail?
Our team can provide vertical-specific data, custom analysis, or a live walkthrough of any resource on this page.