Japan Production Web Payments SDK: card.tokenize() throws UnexpectedError before 3DS; pci-connect verification request returns 400

Questions
1

Hi Square team,

We are seeing a reproducible issue with the Web Payments SDK in Production in Japan.

Environment

  • Square Web Payments SDK

  • Production

  • Japan / JPY

  • Safari on macOS

  • Test amount: JPY 100

  • customerInitiated: true

  • sellerKeyedIn: false

The failure occurs during:

card.tokenize(verificationDetails)

The SDK throws:

SQUARE_TOKENIZE_EXCEPTION [status=UNKNOWN; type=UNKNOWN; code=UNKNOWN; name=UnexpectedError; count=0]

No server-side payment request is made after this failure, and no transaction is created in Square Dashboard.

No 3DS challenge screen appears.

What we tested

  1. We separated the actual cardholder name from the reservation/customer name and supplied the actual cardholder name in billingContact.

Result: same UnexpectedError.

  1. We ran tokenization-only tests with both:

  • intent: "CHARGE"

  • intent: "CHARGE_AND_STORE"

Both independently returned the same UnexpectedError.

These diagnostic tests blocked all payment POST requests, so no CreatePayment request or card storage operation occurred.

  1. In Safari Web Inspector Console, during the failed tokenization, we observed this Square request returning HTTP 400:

https://pci-connect.squareup.com/v2/analytics/verifications

We understand that this analytics request alone may not necessarily be the root cause, but it occurs during the same failed verification flow.

Question

Could the Square team please check the internal buyer verification / 3DS logs for this Production verification flow and determine why card.tokenize() throws UnexpectedError before any 3DS challenge is shown?

We can provide privately, if needed:

  • Production Application ID

  • Production Location ID

  • exact JST timestamps of the failed attempts

We have also seen a recent Japan Production report involving verification/3DS failures returning HTTP 400 before the challenge step, although that report involves the In-App Payments SDK rather than Web Payments SDK:

For security reasons, we will not post PAN, CVC, expiration date, access tokens, or payment tokens.

Thank you.

3

Additional diagnostic result:

I tested the same Web Payments SDK tokenization flow in the Square Sandbox environment.

Sandbox result:

  • card.tokenize(verificationDetails) successfully entered the buyer verification / 3DS flow.

  • The 3DS Challenge Form was displayed correctly.

  • After completing the Sandbox challenge, tokenization returned status=OK.

  • No CreatePayment request was made. This was tokenization-only.

Production result remains different:

  • card.tokenize(verificationDetails) immediately returns UnexpectedError.

  • The 3DS challenge does not appear.

  • The failure occurs before CreatePayment.

  • This remains reproducible after correcting the Production Location ID and after testing with the required Square CSP configuration.

This comparison suggests that the client-side tokenization and 3DS implementation itself is functioning, while the failure appears specific to the Production buyer-verification/3DS path.

Could Square please check the internal Production verification/3DS logs for this Application/Location and confirm whether there is any merchant, application, account, or verification configuration preventing the Production challenge from starting?

4

Thanks for the additional testing. The Sandbox comparison is helpful, especially since production still returns UnexpectedError after correcting the Location ID and testing the required CSP.

The issue occurs before CreatePayment, so the next step is to trace the production tokenization/verification attempts. Send Square Developer Support the following privately (I’ll send you a DM to open the thread):

  • Production Application ID and Location ID.
  • Exact timestamps for 2–3 recent attempts, including the time zone.
  • The 400 response body and any request, correlation, or verification ID exposed in the response, with sensitive information removed.
  • The non-personal fields passed to tokenize: amount, currencyCode, intent, customerInitiated, and sellerKeyedIn.

Can you also confirm whether the same production flow reproduces in Chrome? Keep the tests tokenization-only, as you’ve been doing.

The HTTP 400 alone doesn’t identify the underlying cause. We also can’t yet confirm a connection to the earlier iOS incident.

Don’t share card details, access tokens, payment tokens, or buyer personal information.