Apple Pay on our site opens the payment sheet and self-dismisses in about a second, before Face ID. tokenize() throws UnexpectedError: An unexpected error occurred while using Apple Pay.
We instrumented ApplePaySession and captured the handshake: the session constructs (v3), begin() runs, onvalidatemerchant fires with the apple-pay-gateway.apple.com/paymentservices/startSession validationURL, and the SDK then calls session.abort() without ever calling completeMerchantValidation. The SDK’s merchant-session request to Square’s backend is failing.
Everything on our side is verified:
Application: Verified Correct
Location: Verified Correct
Domain www.*****.com registered under this application, status Verified (2026-08-22); the association file serves HTTP 200 (9,098 bytes)
Minimal paymentRequest (US / USD / positive fixed total; no contact requests); tokenize() called synchronously in the click handler
Production access token renewed 2026-08-23 after the console’s Locations page reported “Access token is missing” — the abort is unchanged after renewal
Card payments through the same application and location work: live production charges completed before and after the token renewal (most recent 2026-08-23, 14:33 UTC)
Reproduced on iOS 26 (Safari and Chrome), fresh sessions, across 2026-08-22 and 2026-08-23
it appears Apple Pay on the web is not fully provisioned for this seller account despite the Verified domain.
I’d like to see if I can reproduce this and track some of the internal API logs. Could you post your AppID and a timestamp (date time + timezone) I can use to trace it?
It would also help if you had some sample code showing how you are setting up the web payments SDK and any error messages reported to the browser’s devtools
Solved, and it was on our end — posting the details in case it helps the next person.
Root cause: our page was initializing the SDK with a location ID that doesn’t belong to our Square account. NEXT_PUBLIC_SQUARE_LOCATION_ID in our production environment still held the location from our sandbox setup, left over from when the page was built against sandbox. The app ID and the server-side access token were both correct and belonged to the right merchant — only the client-side location was foreign.
Why it was so hard to see:
Card payments worked perfectly, including live charges. Card tokenization is client-side and doesn’t validate the location, and our server charges with its own (correct) SQUARE_LOCATION_ID, so every non-wallet payment succeeded end to end.
Apple Pay is the only flow that must prove merchant + location + domain together, at merchant validation. With a location outside the account, that check can’t pass, so the SDK called session.abort() without completeMerchantValidation — the exact journal I posted above.
Everything we kept re-verifying (domain Verified, association file serving 200, freshly rotated access token, seller-level Apple Pay toggle, sample-identical paymentRequest) was genuinely fine and had nothing to do with it.
Corrected the variable, redeployed, and Apple Pay completed a live payment on the first try.
One suggestion, offered kindly: UnexpectedError is doing a lot of work here. If the SDK could surface something like “location not found for this application” when merchant validation fails on an invalid location, this would have been a two-minute fix rather than a ten-day hunt across your forum and Apple’s docs. A note in the Apple Pay guide — “the locationId passed to payments() must belong to the same merchant as the application; a mismatch fails at merchant validation while card payments continue to work” — would probably save others the same trip.
Thanks for engaging with it, and for pointing me at the internal-log angle — chasing what your backend saw is what got me looking at what we were sending it.
Sorry for the late reply, but I am glad you were able to troubleshoot it on your own. I’ll see if I can get a little note added to the docs, getting the sdk updated will be harder though.
I worked with the dev team and we updated the documentation to be more explicit about the location required when initializing the web payments sdk. We are hoping to also add better error handling so these errors surface more intuitively, but I don’t have an eta on that. Thank you for posting!