Hi Square team,
We’re running a custom ordering kiosk at our restaurant using the Mobile Payments SDK, and we’ve now had an intermittent payment issue occur twice in production.
The frustrating part is that everything looks healthy in Square’s settings, but when the customer gets to payment, the reader doesn’t activate.
Environment
-
Android tablets running a production release build
-
Square Mobile Payments SDK: 2.6.1, confirmed in the SDK settings
-
React Native package: mobile-payments-sdk-react-native 2026.8.1
-
Physical Square Contactless & Chip reader connected over Bluetooth
-
Reader firmware: 418098
-
Production environment
-
Square’s default payment UI, using ONLINE_ONLY processing
-
Only one reader connected to the affected tablet
What happens
When the issue occurs:
-
Our kiosk opens Square’s payment screen, which prompts the customer to tap or insert a card.
-
The reader’s green payment lights never come on.
-
Tapping a card does nothing.
-
During the first occurrence, inserting a card changed the screen to “Do not remove card” / “Preparing payment,” where it remained without completing.
We haven’t found a reliable way to reproduce this on demand.
What Square’s settings show
During the latest occurrence, I checked the reader in Square’s settings and opened its detail screen. It explicitly showed:
Despite that, returning to checkout did not activate the reader. There was no visible warning explaining why it couldn’t take payment.
I have screenshots of the reader details and SDK information.
History and workaround
The first occurrence was September 14, 2026. Payments worked in our debug setup, and a second production tablet also worked. Disconnecting and reconnecting the reader on the affected tablet restored payments.
The issue occurred again on September 24, 2026. The latest associated production ticket was created at approximately 9:44 AM MDT / 15:44 UTC. That is an order timestamp we can use for correlation, rather than an exact SDK failure timestamp.
Reconnecting the reader is our current workaround based on the first occurrence, but we need to understand why a reader can appear ready while failing at checkout.
Questions
-
Is this a known issue with Android SDK 2.6.1 or reader firmware 418098?
-
Is there an additional readiness check we should use beyond the reader’s READY status? Would checking available card-entry methods help, and is that supported through the React Native package?
-
What is the recommended recovery when checkout has opened but the reader never activates or remains at “Preparing payment”?
-
Can your team investigate using SDK logs around the September 24 occurrence? Please let me know which identifiers you need and how to provide them privately.
I’m open to this being something in our integration. I would just like to understand what signal we’re missing and how we can catch this before a customer is standing at a payment screen that won’t work.
Thanks,
Bobisback
A follow-up: I checked our other production tablet, and it is now in the same state. So this has affected both tablets.
It seems like leaving the reader connected for an extended period may be a factor, but I haven’t confirmed the trigger or how long it takes to happen.
I created a test order named Reader Test 2, and it is currently stuck on “Preparing payment.” I’ve left my card inserted for about 10 minutes with no change. During that time, there has been no visible timeout or error.
The attached images show the sequence:
-
Settings.jpg: Reader settings opened from within Square’s payment screen show that the reader is ready to take payments.
-
IdentifyReader.jpg: Using Identify reader makes the physical reader flash correctly. It is responding to commands even while payment activation is failing.
-
NoGreanLight.jpg: The payment screen is open, but the reader’s green payment lights are not on.
-
PreparingPayment.jpg: Inserting a card moves the screen to “Preparing payment,” but it stays there without progressing. Taping the card has no response at all from the reader or the payment screen.
The part I’m trying to understand is how the reader can report ready and respond to the identify command, yet fail to activate for payment. The Bluetooth connection appears to be functioning, but something in the payment flow is getting stuck.
Does this help narrow down the issue? Could a reader or payment session become unusable after an extended connection without its reported readiness changing? Also, is there an expected timeout for this “Preparing payment” state, or a supported way for our app to detect and recover from it?
Thanks,
Bobisback
P.S. I’m going to leave this reader in its current state so we have the issue available to investigate. If someone from Square’s development team would like to reach out, please do. I’d be happy to work through hands-on troubleshooting and gather whatever information would help track this down. This is a pretty significant issue for us moving forward.
A small update: I’ve narrowed down a consistent pattern. This happens after the tablets have been off for an extended period, rather than simply leaving the readers connected.
Our tablets automatically shut down at 3:30 PM on Tuesday and turn back on at 6:30 AM on Thursday, about 39 hours later. The reader issue consistently occurs when they come back on after that scheduled downtime.
My guess is that being off for around 24 hours or longer may trigger it, but I haven’t tested the exact threshold yet.
One more update: the tablet that was previously stuck recovered on its own today. It also shuts down and turns back on automatically, so I’m wondering if restarting the tablet clears the issue.
I haven’t confirmed that the restart caused the recovery, but it seems like another useful clue.
Thanks for the detailed writeup!
Since you still have a tablet in the failed state, could you capture this before reconnecting?
const readers = await getReaders();console.log(JSON.stringify({ authState: await getAuthorizationState(), readers}, null, 2));
That one dump should give us the whole ReaderInfo (state, status.status, readerUnavailableReason, connectionInfo.failureInfo, isConnectionRetryable, firmwareInfo, model, and serialNumber.).
Also, what tablet model are you using?
Thanks! The tablet is a Teclast P30T running Android 16.
Unfortunately, it went through its scheduled restart last night, and the reader is working again. So I’ll need to reproduce the issue before capturing the failed state.
This is a production release, so I’m planning to add a diagnostic capture for the output you requested and then repeat the extended shutdown test.
Just to confirm, you want that dump while the reader is in the broken state, before reconnecting or restarting anything, correct? Does the payment screen need to remain open and stuck, or can I cancel out to access our Diagnostics screen?
Thanks,
Bobisback
Yes, the dump is most useful while the reader is still in the broken state, before reconnecting or restarting anything. A reconnect or restart rebuilds the reader session and we lose the state we’re after.
You can cancel out of the payment screen. getReaders() reads from the SDK’s reader manager rather than the payment flow, so it isn’t tied to an active checkout and your Diagnostics screen will work fine. The things to avoid are restarting the app, toggling Bluetooth, forgetting or re-pairing the reader, or letting the tablet restart. One thing to double-check: if your Diagnostics screen re-initializes or re-authorizes the SDK when it mounts, that could reset the state before you capture it.
Before you spend a release on this, Android 16 / API 36 wasn’t supported until MPSDK 2.6.0 (July 2026). If you’re on an earlier version, that alone could explain the behavior. Could you confirm which version you’re on?
Thanks for clarifying. We’re on MPSDK 2.6.1, confirmed in Square’s settings and the screenshot posted above, so we’re past the Android 16 support threshold.
I checked our Diagnostics screen: opening it does not reinitialize or reauthorize the SDK. The new capture action just reads the authorization and reader state.
I’m preparing the diagnostic build now, then I’ll repeat the approximately 39-hour shutdown that has preceded the issue. If it reproduces, I’ll cancel out of payment and capture the dump before changing anything else, making sure the tablet doesn’t automatically restart again first. Additionally we are grabing a bunch more information during the payment processing screen just in case we need more data for this bug. That way I can do only one build.
What’s the best way to share the diagnostic file privately with your team as there may be sensitive information in the logs?
Thanks,
Bobisback
Sounds like a great plan! I will send you a DM on here now so you will have a thread to correspond privately.
