iPhone POS API returns location_id_mismatch despite matching location settings

Questions
1

I’m testing a production web integration with Square’s Point of Sale API on an iPhone using Chrome. My Square account has two active locations: an older main location (Location B) and my current shop (Location A).

When the integration sends Location A’s explicit location_id and the Square app is set to Location A, Square briefly opens at the $0.00 keypad and immediately returns to the browser. The callback reports location_id_mismatch.

Switching the Square app to Location B allowed the $1.00 checkout screen to open. After selecting Location B in the web integration, I completed a $1.00 payment. Our backend verified that the Square payment and order both belonged to Location B, although I believed the Square app was displaying Location A.

We need payments to use Location A consistently.

What could cause Square POS to reject Location A despite matching settings? Could the app retain a previous location internally, and how can we verify its actual active location and ensure the checkout uses the requested location_id?

I can provide exact IDs, timestamps, and sanitized request/callback details privately if needed.

3

location_id is a location check, not an instruction to switch locations. The Square POS app must already be signed in to the location supplied in the request. If they don’t match, POS rejects the request before checkout. POS API mobile web reference see location_id description there.

Your completed payment and order confirm that the successful test was processed at Location B. Combined with the mismatch when requesting A, this suggests that POS was using B during those requests, or that the actual launch payload contained a different ID than expected. It doesn’t yet establish that the app retained a previous location incorrectly.

Verify the ID-to-location mapping. Use production ListLocations with the integration’s seller credentials to confirm A and B’s IDs, names, and account ownership. This verifies the integration’s mapping; it doesn’t report which location the iPhone POS app is currently using. List locations

4

Thanks for clarifying. We understand that location_id checks the location already signed in to POS and does not switch it.

We completed the production ListLocations check using the integration’s seller credentials. Locations A and B have distinct IDs, their names map correctly, and both belong to the same connected seller account.

We repeated the test on October 6 with the integration explicitly saved to A. Server diagnostics decoded the generated POS launch URL and confirmed location_id was A’s verified ID, amount_money.amount was 125, currency_code was USD, and version was 1.3. Square returned status=error and error_code=location_id_mismatch.

I normally use A in the iPhone POS app and processed a regular shop payment there today. I did not deliberately switch locations before this test. However, we understand this does not independently establish the native POS session’s location ID at launch.

We also identified a separate callback-parsing failure in our integration that prevented the returned checkout from reopening. The mismatch above was read directly from the incoming callback in gateway logs, not inferred from that UI error.

What is the supported way to verify the exact location ID of the current iPhone POS session and, if necessary, explicitly reselect A? Are there additional checks you recommend given the verified mapping and generated payload?

For privacy, I have omitted account/location IDs, full URLs, and logs. Please let me know how to share sanitized diagnostics privately with Square staff.

5

I sent you a DM, can you send me your app id and some recent IDs and timestamps so I can investigate

7

Hi Zac,

I wanted to clarify the actual issue we’re trying to investigate with our Square integration for TintBay.

The $1.00 test transaction processed successfully and was automatically refunded because we canceled the sale. That part worked as expected.

The issue is a location ID mismatch during payment processing.

Our Square merchant account has two locations:

  1. Shop (Mobile) — Intended Location
    Location ID: L1DVF6Z5GPDW6

  2. Tint Scapes / Flat Glass (Physical) — Alternate Location
    Location ID: L2VXQ5D3QPDY0

During testing, our TintBay application explicitly requested the Shop location, but our backend returned a location_id_mismatch error.

When we switched the integration to the Flat Glass location, the $1.00 checkout was able to open successfully.

What we’re trying to determine is:

Why is Square rejecting the Shop location when it belongs to the same merchant account?

Is there a location-specific restriction, configuration issue, or authorization problem?

Is there something in our API integration that needs to be corrected to ensure payments are routed to the intended location?

Our goal is to make sure TintBay consistently processes payments through the correct Square location without requiring workarounds.

The $1.00 test transaction occurred on October 4, 2026, at approximately 9:39 PM, with the cancellation/refund recorded at 9:47 PM.

TintBay checkout reference:
97c1deef-4174-4f34-9ce6-4c0812c44ded

I appreciate your willingness to investigate this. Please let me know if you need anything further.

Thank you,

Tracy Hilt
TintBay

Tint Scapes