JP Sandbox: JCB 3DS challenge with OTP 000000 still results in COMPLETED payment

Questions
1

Hello Square Developer Support,

Square Japan support directed us to this forum for a Web Payments SDK / Sandbox question. We are testing 3D Secure in a Japanese ticketing application, using Sandbox only (no real charges).

Environment

  • Sandbox seller country JP, currency JPY; amount JPY 10,000.
  • Web Payments SDK 1.87.0 as observed during the tests on October 19, 2026.
  • Square API version 2026-09-16.
  • Desktop Chrome on Windows.

Reproduction steps

  1. Start a new, unpaid test purchase.
  2. Enter the Sandbox JCB challenge card 3569 9900 0000 0009, expiration 12/28, CVV 111.
  3. Click Pay. Our application calls card.tokenize() with the verification details below.
  4. In the displayed Square Challenge Form, enter OTP 000000 and click Authenticate once.
  5. When tokenization returns status OK, send the returned token to our backend as CreatePayment.source_id.
  6. Check the resulting payment using GetPayment, rather than relying only on the application’s displayed status.

Client flow (buyer email omitted):

const result = await card.tokenize({
  amount: '10000',
  currencyCode: 'JPY',
  intent: 'CHARGE',
  customerInitiated: true,
  sellerKeyedIn: false,
  billingContact: { email: '<buyer email>', countryCode: 'JP' }
});
if (result.status !== 'OK') {
  throw new Error('Tokenization or verification did not complete');
}
// Send result.token to our backend; do not create a payment on non-OK results.

The backend calls CreatePayment with source_id set to that token, amount_money {amount: 10000, currency: 'JPY'}, an idempotency key, order_id, location_id, autocomplete: true, and reference_id. We use the integrated tokenize(verificationDetails) flow, not a separate verifyBuyer call.

Actual results

  • The tester reported entering 000000 on multiple separate purchases. Subsequent GetPayment responses showed payment.status: COMPLETED and card_details.status: CAPTURED for JCB ending 0009, without errors. The application then marked each purchase paid and issued one valid ticket.
  • One recorded completion was 2026-10-19 02:01:32 UTC.
  • The tester later reported that an earlier attempt might have involved an offline connection. We therefore do not regard that earlier attempt as conclusive evidence of how the submitted OTP was handled.
  • We repeated the test with a new unpaid purchase after the tester confirmed stable connectivity. The tester again reported entering 000000 and seeing payment success. GetPayment confirmed COMPLETED / CAPTURED at 2026-10-19 02:12:15 UTC (11:12:15 JST), JCB ending 0009, without errors. Connectivity was confirmed by the tester; we do not have a network trace proving the exact ACS request contents or timing.
  • Sandbox payment IDs are available to Square staff through a private channel if needed. We have omitted account identifiers and buyer information from this public post.

Comparison tests

  • With the same JCB test card and OTP 123456, payment completed and a ticket was issued.
  • Canceling the challenge returned the application to an unpaid, retryable state.
  • With the documented failed-verification Visa test card 4811 1100 0000 0008, the payment failed with CARD_DECLINED_VERIFICATION_REQUIRED. The purchase remained unpaid, no ticket was issued, and retry was possible.

Questions

  1. For this JCB challenge card in JP Sandbox, is 000000 supposed to fail authentication? Is it a reserved test value, an expected simulator limitation, or an issue that needs investigation?
  2. Can payment approval after an unsuccessful challenge be expected for this JP Sandbox scenario? Which documented behavior applies?
  3. What card, OTP, and verification parameters should we use to reliably test a rejected challenge/incorrect OTP and verify that the payment is not completed?
  4. Which response fields or diagnostics should we capture to distinguish 3DS authentication results from payment authorization results with the integrated tokenization flow?
  5. What differences should we expect between this Sandbox behavior and JP production, and what additional implementation or validation is required before launch?

We have not added an application-side OTP comparison or a bypass. We would appreciate clarification before treating this negative 3DS test as complete. Thank you.

3

Welcome to the Developer Forum!

Thanks for the detailed write-up.

  1. For the JCB challenge card, the docs give 123456 as the only verification code. They don’t say what any other OTP does, 000000 included. It’s possible that other combinations can result in successful payment.
  2. Again, the key gap is that entering 000000 does not establish that the simulator actually returned an unsuccessful authentication.
  3. You already ran both scenarios of failed-verification and canceled challenge. Try using 4310 0000 0020 1019 with verification code 1111 (N) and 2222 (R) and see if they simulate the scenarios.
  4. Your flow is correct. With the Web Payments SDK, verification is carried inside the token returned by tokenize(verificationDetails), and there’s no separate verification token. The amount and currencyCode in verificationDetails must match the amounts you send to CreatePayment.
  5. In production most 3DS authentications are frictionless, so you usually won’t see a challenge. Make sure your checkout page’s Content Security Policy allows the challenge iframe (frame-src). If it doesn’t, the challenge can fail to display without any error.
4

Thank you for your reply and the detailed explanation. We understand that our implementation flow is correct, and that entering 000000 in the Sandbox does not necessarily mean that authentication failed.

We have now adopted Square-hosted checkout and have successfully tested a small payment and refund in production. We will keep the additional test scenarios you suggested in mind for future validation.

Thank you again for your help!