3D Secure (Cardinal Songbird) VCDI device‑fingerprint iframe crashes iOS Safari on braintree-web 3.138 — regression from 3.117

[hwhovo]

Environment: Sandbox + Production (reproduced on both)
Cardinal OrgUnitId (from logs): 55ef3f7cf723aa431c99e180
Sample Cardinal ReferenceId: 0_a7328358-5c08-48fc-b16d-922cf7814c1f

Summary

After upgrading braintree-web from 3.117.1 → 3.138.0, iOS Safari tabs crash (WebKit content process terminated) during the 3‑D Secure
step when verifying a new credit card. The crash occurs at the VCDI (Visa Cardholder Device Intelligence) device‑fingerprint iframe
(secure-devicefp.visa.com, sandbox/CTE: secure-devicefp-cte.visa.com). This profiler is new in the Songbird version delivered by 3.138
and did not run on 3.117.1, which never crashed.

Environment / versions

• braintree-web: 3.138.0 (regression introduced somewhere after 3.117.1; note 3.121.0 "Retrieve Cardinal Songbird script URL and
  integrity hash from the gateway configuration").
• 3DS integration: threeDSecure.create({ version: 2 }), hosted fields, verifyCard.
• Device: iPhone, Mobile Safari, iOS 26.5 (crash is iOS‑Safari‑specific; Chrome/desktop unaffected).
• Merchant page sends Permissions-Policy: payment=* on the top‑level document.

Steps to reproduce

1. On an iPhone (Safari/Chrome), at the first time (recommended every time try in incognito with new session) go to checkout and enter a new credit card with 3D secure support.
2. Submit to trigger 3‑D Secure (verifyCard), which starts Cardinal Songbird device profiling.
3. Songbird runs two profilers: CardinalData (succeeds) and VCDI (loads the secure-devicefp iframe).
4. The Safari tab crashes/reloads at the VCDI iframe; the user never completes payment.

Expected vs actual

• Expected: 3‑D Secure device profiling completes and the challenge/verification proceeds without terminating the browser tab.
• Actual: The VCDI iframe fails the payment permission policy, times out, and the iOS Safari tab is killed. The last console output
  before the crash is the secure-devicefp(-cte).visa.com iframe.

Console evidence (verbatim, Safari Web Inspector)

Primary profiler succeeds:
CardinalDataCollection - Fingerprinter completed, creating data object taking [168]ms
CardinalDataCollection - SaveBrowserData completed [380]ms after starting profiling
Profiling - Profiling completed. Final results: [{"DataSource":"CardinalData","Status":true,"ElapsedTime":380}]
Profiling - Fingerprinting completed.
VCDI iframe is sandboxed, then fails and times out (immediately before the tab crash):
VcdiProfiling - VCDI iframe: applied allow attribute (Flag A)
VcdiProfiling - VCDI iframe: applied sandbox attribute (Flag B)
[Error] Permission policy 'Payment' check failed for document with origin 'https://secure-devicefp-cte.visa.com'.
VcdiProfiling - VCDI profiling timed out.

What we already tried (and why it isn't enough)

• We set Permissions-Policy: payment=* (which missing in your documentation) on the top‑level checkout document. This fixed the primary CardinalData profiler (now completes
  in ~380 ms instead of the previous 4 s Base.DF: Device profiling did not complete in [4000]ms timeout).
• It does not fix VCDI, because Songbird creates the VCDI iframe with a sandbox attribute (log "Flag B"). A sandboxed iframe cannot
  use the Payment API via a top‑level Permissions-Policy alone — it also requires the allow-payment-request sandbox token on the iframe
  element. That iframe and its sandbox/allow attributes are generated by Cardinal Songbird, not by the merchant, so we cannot grant the
  permission from our side.

Analysis

• CardinalData already returns a successful device‑data result, so VCDI appears redundant for our integration — yet it runs, fails the
  payment‑permission check, times out, and crashes iOS Safari.
• The braintree-web threeDSecure.create() API exposes only cardinalSDKConfig (logging, timeout, maxRequestRetries, payment) — there is
  no client option to disable VCDI / device fingerprinting, so we cannot turn it off from the SDK.

What we're asking

Any one of these would resolve it; please advise which is possible:

1. Disable VCDI (Visa Cardholder Device Intelligence) for our Cardinal org unit 55ef3f7cf723aa431c99e180, since CardinalData already
   provides device data. (Preferred — zero merchant‑side risk.)
2. Fix the VCDI iframe Songbird generates so the sandboxed iframe includes allow-payment-request (and/or allow="payment") so it
   doesn't fail the payment permission and time out.
3. Investigate why the VCDI iframe crashes the iOS Safari (WebKit) content process rather than failing gracefully.
4. If none of the above, provide a client‑side threeDSecure.create() option to disable VCDI.

Business impact

iOS‑Safari mobile shoppers cannot complete new‑card checkout (tab crashes at 3DS). We measured roughly a 15–25 percentage‑point drop
in mobile‑Safari checkout payment‑step completion coinciding with the 3.138 rollout.

[lvandenboom]

Thanks for reporting this issue. We're investigating.

1. In the meantime would you mind sharing your Braintree merchant ID?
2. Would you be able to share the (test) credit card data used to reproduce the issue in sandbox?
3. Could you confirm the exact iOS versions where you see this issue? Is it limited to 26.5.2 or do you see issues with earlier versions too?

[hwhovo]

Thanks for picking this up. Answers below, plus an important reproduction detail we've since isolated.

1. Braintree merchant ID

126952463

2. Sandbox test card

4000000000001091 (challenge-required 3DS test card).

3. Affected iOS versions — not limited to 26.5.2

From our production RUM over the last 45 days, isolating the crash signature: the checkout tab's last recorded event with no $pageleave (i.e. the WebKit content process was terminated rather than the user navigating away), followed by a fresh page load in a new window.

iOS version	Checkout sessions	Crash-signature sessions	Rate
18.7.0	794	43	5.4%
26.5.0	19	1	5.3%
26.5.2	7	1	14.3%
18.6.0	11	1	9.1%

It spans both the iOS 18.x and iOS 26.x lines. The large majority of occurrences are on iOS 18.7.0 (43 / 794 = 5.4%), simply our most common iOS version. The 26.5.2 and 18.6.0 figures are very small samples and shouldn't be read as version-specific severity — the consistent ~5% rate on the two versions with meaningful volume (18.7.0 and 26.5.0) is the reliable signal. Other iOS versions had too few checkout sessions (1–11) to draw conclusions, so we can't call them unaffected.

4. Most important: the crash does not require a card at all

We've narrowed the trigger precisely, and it should make this much easier for you to reproduce:

• With eager initialization — calling threeDSecure.create({ version: 2 }) when our payment step mounts — the iOS Safari tab crashes immediately, before any card is entered and without ever calling verifyCard. No card data, no lookup, no challenge.
• As a mitigation we deferred threeDSecure.create() until card submission. The tab then survives the payment step, but still crashes when submitting any 3DS-required card (e.g. 4000000000001091).

So the crash is in Songbird initialization + device profiling, not in the challenge or anything card-specific. The last output before the tab dies is consistently the VCDI device-fingerprint iframe:

CardinalDataCollection - Fingerprinter completed, creating data object taking [168]ms
CardinalDataCollection - SaveBrowserData completed [380]ms after starting profiling
Profiling - Profiling completed. Final results: [{"DataSource":"CardinalData","Status":true,"ElapsedTime":380}]
VcdiProfiling - VCDI iframe: applied allow attribute (Flag A)
VcdiProfiling - VCDI iframe: applied sandbox attribute (Flag B)
[Error] Permission policy 'Payment' check failed for document with origin 'https://secure-devicefp-cte.visa.com'
VcdiProfiling - VCDI profiling timed out.
  -> iOS Safari tab terminated here (last output before the crash)

Minimal repro for your side: on a physical iPhone in Safari, load a page that simply calls threeDSecure.create({ version: 2 }) against our sandbox merchant (126952463) and let device profiling run. The tab should terminate during profiling — no card, no verifyCard.

Note that CardinalData profiling succeeds (Status: true, 380 ms), so the device data 3DS needs is already collected; VCDI appears to be additive and is what kills the tab.

Our ask while you investigate

Can VCDI be disabled for our Cardinal org unit 55ef3f7cf723aa431c99e180? Since CardinalData already returns successfully, disabling VCDI should be functionally neutral for us and would immediately stop customer-facing crashes on iOS Safari, rather than waiting on a Songbird fix. If that's possible, we'd like it applied to sandbox first so we can verify, then production.

[lvandenboom]

Thanks for providing these details, we appreciate it. Unfortunately we are not able to disable VCDI on our end. We're contacting our 3DS partner Cardinal with your findings.

Would you be able to share a HAR file demonstrating the issue? If so, please send it to us through Braintree support: https://developer.paypal.com/braintree/help/3DS2Help.

[hwhovo]

I can't provide a HAR file: the page crash terminates the tab before the capture completes, so the exported HAR is 0 KB.