Mobile Payments SDK 2.6.0 (iOS) — reader pairs, then "Unable to establish a secure connection to Square"

Questions
1

Setup: Flutter plugin 2026.7.4 → native iOS SDK 2.6.0. iPhone 16 Pro, iOS
18.7.8, debug build. Production application ID + production access token,
AU merchant.

The reader pairs over Bluetooth, then immediately reports “Reader
Unavailable. Unable to establish a secure connection to Square” and never
reaches Ready. Reproducible across forget/re-pair cycles and app restarts.

4

Can you ensure you are on the latest version of the SDK? We just shipped a fix for this a few days ago. Mobile SDKs: 2026-07-27 Changelog

5

Our Square Reader (2nd gen contactless, serial 426LS22205000747, firmware 416099) pairs over Bluetooth and responds to “Identify reader,” but sits at “Reader unavailable — Unable to establish a secure connection to Square.”

Everything on our side is verified:

  • Production application sq0idp-pFqYyU6grRdDvu92-gOdPw, production OAuth grant with MERCHANT_PROFILE_READ, PAYMENTS_WRITE, PAYMENTS_WRITE_IN_PERSON.
  • Mobile Payments SDK signature registered under that application: Bundle ID com.thecanvasnailstudio.admin, Team ID XSMG7W3WMM — confirmed against the .ipa’s embedded provisioning profile.
  • SDK: mobile-payments-sdk-react-native 2026.7.1 → native iOS SDK 2.6.0. iOS release-signed internal-distribution build (Expo/EAS).
  • The same reader on the same phone connects and takes payments fine in the Square POS app, so hardware, network, and the merchant account are all healthy.

Can you check the server-side rejection reason for our reader’s secure-session attempts? Merchant timezone America/New_York; most recent attempts Aug 19–20, 2026.

7

Hi @thecanvasnailstudio - The reader and account configuration appear healthy, but the secure connection is being rejected during iOS app-attestation. We recommend reviewing the app’s Apple signing, provisioning, App Attest capability, and Expo config. It may also help to test a fresh TestFlight build to determine whether the issue is specific to internal distribution. If the same error occurs with a correctly provisioned TestFlight build, please let us know so we can escalate it to the Mobile Payments SDK team.

8

Resolved — thank you, the app-attestation pointer was exactly right.

Root cause: our staff app is distributed internally (EAS ad-hoc build), not through TestFlight/App Store. Apple’s App Attest uses the sandbox attestation environment whenever the com.apple.developer.devicecheck.appattest-environment entitlement is absent and the build
isn’t TestFlight / App Store / Enterprise. Our build had no such entitlement, so since the Aug 17 change (MPSDK ≥ 2.5.0 using App Attest for device integrity) every secure-session attempt attested against Apple’s sandbox and was rejected — hence “Unable to establish a secure connection to Square” on a reader that paired fine and worked in Square POS.

Fix: added the entitlement com.apple.developer.devicecheck.appattest-environment = production to the app (Expo ios.entitlements), enabled
the App Attest capability on the App ID, rebuilt with a fresh provisioning profile. Same bundle ID / Team ID registration as before, no other changes. The Square Reader (2nd gen contactless+chip) now connects and takes payments.

Two suggestions for the docs, since nothing in the “App Attest (MPSDK 2.5.0+)” section mentions setup:
(1) state that internally distributed / ad-hoc iOS builds must set the appattest-environment entitlement to production (TestFlight and App Store builds are forced to production by iOS and don’t need it);
(2) note that a missing/sandbox attestation surfaces as the generic “Unable to establish a
secure connection to Square” reader error, which currently points people at signature/Team ID registration instead.