3DS rule still disabled after a successful $1 production payment — can someone trace it?

Hi, we’re trying to enable 3DS for a US Square account. Risk Manager still shows “Update your APIs to enable 3D Secure rules,” and the 3DS action is disabled.

We use the production Web Payments SDK and API version 2026-09-16. Our card flow is:

card.tokenize({
  amount: "1.00",
  currencyCode: "USD",
  intent: "CHARGE",
  customerInitiated: true,
  sellerKeyedIn: false,
  billingContact: {
    givenName, familyName, email,
    addressLines, city, state, countryCode
  }
})

The billingContact entries above are variable names, not customer data. The resulting token goes to CreatePayment as source_id, with the matching amount/currency and production location.

Our sandbox 3DS challenge works. A real $1 production payment also completed and was captured, with CVV_ACCEPTED, AVS_ACCEPTED, and NORMAL risk. No bank verification popup appeared, and verification_method/verification_results were absent from the Payment response. Refreshing Risk Manager afterward still left the 3DS action disabled.

Could someone from developer support trace that production attempt and confirm:

  1. Was 3DS authentication initiated? If so, what was its result? If not, why was it skipped?
  2. What exact application/location eligibility check is preventing us from enabling a 3DS rule?
  3. What specific code or configuration change is required, or does Square need to correct something on the account?
  4. How can we confirm whether this payment received 3DS authentication and any applicable fraud liability shift?

General support referred us here. We can provide the payment ID, application/location IDs, timestamp, and support case number privately to verified Square staff. Please let us know the appropriate private channel; we don’t want to post those identifiers or customer information publicly.

Thanks.

Welcome to the Developer Forum!

Thanks for the detail, and for keeping identifiers off the public thread.

The US doesn’t mandate SCA, so Square doesn’t run 3DS on US payments by default. In production most authentications are frictionless, so not seeing a challenge popup doesn’t tell you whether 3DS ran.

CVV/AVS acceptance and NORMAL risk also do not prove 3DS. verification_method and verification_results describe EMV cardholder verification, not online 3DS. Their absence is not evidence that 3DS was skipped.

Ultimately, it depends on the issuing bank whether to prompt a 3DS challenge. For example, Square can request a 3DS challenge, but the bank can look at the requested payment and choose to approve it without 3DS.

If the bank successfully authenticated the payment through 3DS (including ones without a challenge), fraud liability generally shifts to the issuing bank.