iOS In-App Payments SDK 1.6.7: 3DS challenges fail with buyer_verification_unexpected since Oct 17, 2026 (three-ds-authentication returns 400)

Questions
1

Hi Square team,

Since around 2026-10-17 07:16 UTC, card-on-file registration with 3DS has been failing on iOS for most cards that require a challenge. We’d like help finding out why Square rejects these verifications.

Environment

  • SquareInAppPaymentsSDK / SquareBuyerVerificationSDK 1.6.7 (latest on CocoaPods)
  • react-native-square-in-app-payments 2.1.1
  • Production, Japan
  • Flow: startCardEntryFlow to get a nonce, then startBuyerVerificationFlow with buyerAction Store

What happens

  • startBuyerVerificationFlow returns buyer_verification_unexpected 2–6 seconds after it starts. No challenge screen is shown.
  • Frictionless cards still succeed. Some challenge cards also still succeed, so it depends on the card.
  • Android (same application) is not affected.
  • We did not change the native part of our iOS app during this period.

Where it fails
In the failing cases, this request returns 400, and the SDK then returns buyer_verification_unexpected:

PUT https://pci-connect.squareup.com/v2/analytics/verifications/{verification_id}/three-ds-authentication

In the successful cases, the same request returns 200 and the SDK continues to the issuer’s challenge (ACS).

We can’t see the 400 response body from the app. Could you check why these verifications were rejected? We can share example verification IDs and timestamps privately with the Square team.

Related observation
At the same time, this request from the bundled Netcetera 3DS SDK started returning 404 on every call:

POST https://api.support-server.prod.netcetera-cloud-payment.ch/sdk-data
  • 200 (about 51 KB) until 2026-10-17 05:28 UTC; 404 (19 bytes) on every call since 07:16:41 UTC
  • Our first failure happened 3 seconds after the first 404

However, the devices whose challenges still succeed also get 404, so we are not sure the 404 alone is the cause. We also noticed that NetceteraSDK-License-Prod.lic bundled in SquareBuyerVerificationSDK 1.6.7 has valid-until: 2024-08-31.

Questions

  1. Why does three-ds-authentication return 400 for these verifications?
  2. Is the /sdk-data 404 related, and is it expected?
  3. Is a fixed iOS SDK or a workaround planned?

Thanks!

3

Hi,

Thank you for the detailed report. The timing and iOS behavior you describe match a 3DS incident that affected card verification, including saving cards, from October 17 until approximately October 19, 2026, at 11:30 UTC.

  1. Why does three-ds-authentication return 400?

In this incident, the card networks’ directory servers rejected encrypted device data from the iOS 3DS SDK with code 302, “data decryption failure.” The verification stopped before the issuer’s challenge screen, and the SDK surfaced a generic buyer_verification_unexpected response.

The affected iOS SDK contained outdated fallback encryption certificates. When it could not retrieve current certificates from Netcetera, it used those fallback certificates, which the affected card networks no longer accepted.

  1. Is the Netcetera /sdk-data issue related?

Netcetera confirmed an outage of its SDK Support Server following a scheduled TLS certificate renewal problem. That server supplies the current certificates used by the SDK.

This also explains why an unsuccessful Support Server request did not prevent every verification: devices that had already cached current certificates could continue working.

  1. Is there a fix or workaround?

Netcetera restored the Support Server around 11:30 UTC on October 19. Verifications recovered without an app or SDK update. Restarting the app allows the SDK to initialize again and retrieve current configuration.

Could you retest on an affected device? If the issue continues, share example verification IDs and UTC timestamps privately, ideally including one successful attempt for comparison. These will help us trace the specific rejection.