The Web Payments SDK v1.84.0 fails to initialize in production. Card fields never render.
The failing request is GET pci-connect.squareup.com/payments/hydrate returning 401 Unauthorized.
Application ID: sq0idp-BWBCTTVO9cW9hZ2flfN2Yw
Location ID: 29SQ5416Y0V4N (BOOGIETEK LLC, main location)
It fails identically on our production domain boogietek.com and on a Vercel preview host, so it is not domain-specific. Credentials were copied directly from the Developer Console Production tab, and the access token has been regenerated. The application’s use case is set to Accept payments (online, in-app, in-person).
Sandbox works correctly: five successful POST /v2/payments on 2026-08-06. Production API Logs show zero entries, which is consistent with the SDK never getting past initialization.
This Square account has processed card-present payments since 2023 but has never taken a card-not-present payment. Please confirm whether card-not-present or online processing is enabled on this account, and whether this application is authorized for the Web Payments SDK.
Hi @boogietek! If your Square account is registered and has successfully received card-present payments, then card-not-present payments is also enabled and active. Since your app is working on Sandbox, the likely issue is related to an error in switching from sandbox to production.
Please check the URL for SDK initialization - for sandbox, it should look like this:
Thanks for confirming CNP is active. The script URL is already correct: the SDK is loaded from https://web.squarecdn.com/v1/square.js, and the network tab confirms square.js, main-iframe.html and card-wrapper.css all load 200/304 from that host before the failure. The SDK is initializing, it’s the hydrate call that returns 401:
Note the applicationId and locationId in that request are the exact production values from the Console, so the sandbox/production switch is complete. Could you check your logs for that request against my application ID? That’s how similar 401s have been resolved in past threads.
Hi @boogietek - please double check that the App ID is exactly as it appears in the developer console. I was able to check our logs and it appears that all of the requests associated with the location ID that you provided are with an incorrectly typed App ID.
Thank you, that’s extremely helpful. Could you tell me the correct App ID as it appears in our Console, or point to which characters differ from what’s being sent? I’ve been copying it by button rather than typing, so I’d like to know where the corruption is happening.
Solved, thank you jseok. Two separate issues stacked on top of each other, posting both in case it helps someone else.
1. The 401 on hydrate — a mistyped App ID. Exactly as you found in the logs. Our production App ID contains a lowercase l that had been transcribed as the digit 1 when the environment variable was set. The two are visually identical in most UI fonts. Square returns a plain 401 from pci-connect.squareup.com/payments/hydrate rather than “unknown application”, so there is nothing in the error pointing at the ID itself.
Lesson: never retype an App ID, always use the copy button in the Developer Console and paste it. And if you are debugging this, note that the hydrate request carries no access token at all, only applicationId, locationId and hostname, so the token and its permissions can be ruled out immediately.
2. After that, an InvalidStylesError. With the correct App ID, hydrate returned 200 but the card fields still would not render. The cause was our CARD_STYLE object passed to payments.card({ style }). We had set backgroundColor on .input-container, which Square rejects, and it throws InvalidStylesError: One or more style selectors and/or CSS properties are invalid. Moving the fill to the input selector, which does support backgroundColor, fixed it.
Worth flagging for others: if your init is wrapped in a try/catch without logging the error, both of these surface as the same generic failure message. Adding console.error inside the catch is what finally made the InvalidStylesError visible and named the invalid property outright.
Appreciate you checking the logs, that was the step that unlocked it.