We’re seeing a recurring production failure when creating a card form with the Web Payments SDK. Square.payments(applicationId, locationId) returns, but await payments.card() rejects before the card fields appear:
UnexpectedError: An unexpected error occurred while initializing the payment method.
We recorded nine failures in one browser trace on September 16, 2026, between 16:00 and 19:10 UTC, and four more in a later trace for the same buyer on September 22, between 16:35 and 17:50 UTC. The failure persisted across fresh page loads. The browser reported Windows/Chrome 152 on the first date and Windows/Chrome 153 on the second. Other sessions reporting Windows/Chrome 153 loaded the card form successfully.
The affected attempts did not reach card tokenization or payment submission. The error stack points into web.squarecdn.com/v1/square.js, but we have no Network capture from the affected browser and cannot see the underlying cause.
What could cause payments.card() to fail this way for a particular browser or connection? What safe diagnostics would help distinguish an SDK or configuration issue from a browser or network issue? If Square can investigate its internal logs, please let us know how to provide the page URL, precise timestamps, and application and location IDs securely.
The failure is at payments.card(), not Square.payments() — so the script loaded and the SDK object constructed, and things broke when it tried to create its cross-origin iframes and call Square.
Worth knowing before you dig in: UnexpectedError at card() has at least two causes that look identical from the error object. During card() the SDK issues a GET to https://pci-connect.squareup.com/payments/hydrate. That error appears both when the request is blocked and when it completes but returns 400/401 (bad application ID, environment mismatch). The error carries no detail to tell them apart — its errors array is empty.
So the one thing worth getting from the affected buyer is a DevTools → Network capture of the hydrate row. No response at all points to client-side blocking — ad blocker, privacy extension, enterprise proxy, DNS/TLS filtering. A 401/400 points at credentials or environment instead.
Given other Chrome 153 sessions succeed and it follows one buyer across reloads, blocking is the better bet. Quick test: have them retry in a clean profile with extensions disabled, and on a different network.
Also worth confirming your CSP matches the documented requirements and that production loads https://web.squarecdn.com/v1/square.js.
Thanks—knowing which request is failing is helpful. We can’t reasonably ask this customer to collect a DevTools capture, so we’re looking for a way to investigate from our integration or through Square support.
Given that hydration happens inside Square’s cross-origin iframe, does the Web Payments SDK expose any supported diagnostics that would distinguish a blocked request from a 400/401 response when payments.card() throws UnexpectedError? We currently receive no useful detail in the error’s errors array. Is there a request or correlation ID we can capture for investigation?
If those details aren’t exposed to our application, can Square trace the attempts using our application ID and incident time ranges, supplied privately? Please let us know what information would help and the appropriate support channel.