We are integrating Square Mobile Payments SDK into ExpoGuest, an iPhone app, and production SDK authorization consistently fails with:
authorization_unsupported_country
OAuth approval succeeds, and direct API requests for the authenticated merchant and selected location succeed. The failure occurs in the native SDK’s authorize(accessToken, locationId), before reader pairing or any payment. It also blocks opening the embedded Square Settings/About screen.
Configuration and checks
React Native bridge: mobile-payments-sdk-react-native 2026.8.1. Native CocoaPods dependency: SquareMobilePaymentsSDK ~> 2.6.0 (exact installed patch version still being confirmed).
Production application ID: sq0idp-eGhESIvFcZEaTbLgci9OhA.
Bundle: com.redfieldvox.expoguest.dev. The matching iOS bundle and Apple Team ID are saved under Production > Mobile Payments SDK application signatures.
The downloaded IPA executable contains the same production application ID used in JavaScript/OAuth. We have not independently extracted the running app’s native initialization ID on the phone.
OAuth uses PKCE and scopes MERCHANT_PROFILE_READ, PAYMENTS_READ, PAYMENTS_WRITE, PAYMENTS_WRITE_IN_PERSON. The resulting access token and selected location ID are passed to SDK authorization.
On-device diagnostics: production environment; saved session matches application ID/environment; merchant country US; location country US; location currency USD; CREDIT_CARD_PROCESSING enabled; foreground location permission granted; native SDK state NOT_AUTHORIZED.
The built Info.plist includes Bluetooth and foreground-location purpose strings.
Sandbox OAuth and mock-reader payments previously worked. The separate Square Point of Sale app works with this seller and reader.
Restarting the app and reconnecting with production Metro configuration did not resolve this. Live charging remains disabled; no production charge has been attempted.
Given the US merchant/location and matching downloaded-binary/OAuth IDs, could Square check whether any application or seller eligibility flags could cause this error, or advise the next supported diagnostic? Merchant/location IDs can be provided privately to Square staff if needed. No tokens or secrets are included here.
We’re taking a look into this on our end and will get back to you with an update.
In the meanwhile could you quickly double check the Application ID that was used as the native setup ID when the app was built (i.e. when the native code sets up the SDK)? If it’s mismatched or still set to sandbox there it should be easy to fix and then a clean rebuild → resign into OAuth would do the trick.
Thanks, Isolde. We checked the downloaded production IPA’s native executable, not just the JavaScript configuration. It contains sq0idp-eGhESIvFcZEaTbLgci9OhA, matching our production OAuth Application ID, with no sandbox Application ID found. Our native AppDelegate setup passes this ID to MobilePaymentsSDK.initialize.
One remaining uncertainty is independently confirming that this exact binary is the one currently running on the phone. We’ll verify that installation and repeat OAuth sign-in. Is there a supported way to retrieve the SDK’s initialized Application ID at runtime?
We disconnected the device, fully closed and reopened ExpoGuest Dev, completed production OAuth again, and reselected the business location. Pair/Manage Reader then opened Square settings but displayed “Devices cannot be accessed.”
Hi Isolde — thank you for the help! We have this working now.
Your suggestion to double-check the native setup was the right direction. We had production JavaScript/OAuth configuration running against an older installed development binary that still reported the native SDK environment as Sandbox. Updating Metro did not update that native binary. After installing and verifying the correct production-native build, the SDK reported Production and the authorization issue was resolved.
We then hit a separate Bluetooth pairing error. Our app had the Info.plist Bluetooth usage description but was not actually requesting Bluetooth permission at runtime. Adding that request resolved pairing.
We have now successfully paired the contactless/chip reader, processed a real $1 Amex payment inside ExpoGuest, verified exactly one transaction in Square and one persistent ledger sale in ExpoGuest, and refunded the payment through Square.
This is with the iOS Mobile Payments SDK 2.6.0. No further investigation is needed for our original authorization error. Thanks again for pointing us in the right direction! Thanks for all you guys at Square do - it’s greatly appreciated!
