[Bug] Authorize.net AcceptUI.js payment form broken by privacy protections despite being allowed

Describe the bug

The DuckDuckGo Android browser's privacy protections break Authorize.net's AcceptUI.js hosted payment form, even though the script is shown as "loaded" in the shield panel under "Third-Party Requests Loaded."

Authorize.net is one of the largest payment processors in the US, and AcceptUI is their standard/recommended integration for accepting credit card payments on e-commerce sites. The script loads from js.authorize.net, creates an iframe-based payment modal when the user clicks a payment button, and communicates back to the merchant page via postMessage.

In the DuckDuckGo browser, the script downloads successfully (confirmed via the shield panel), but it never initializes at runtime. window.AcceptUI remains undefined and the payment button becomes non-functional. The user sees a "Proceed to Payment" button but clicking it does nothing. There is no error shown to the user, making this a silent failure.

This likely affects every e-commerce site using Authorize.net's AcceptUI integration, which is a significant number of small-to-medium online retailers.

Additional observations:

• Tapping the shield icon shows js.authorize.net listed under "Third-Party Requests Loaded", confirming the network request is allowed
• The shield panel also states "though our other web tracking protections still apply"
• Adding detection code to the page confirms window.AcceptUI is undefined after the script loads, meaning the script downloads but DDG's runtime protections prevent it from executing or initializing properly
• The same checkout flow works correctly in Chrome, Firefox, and Safari on the same device

How AcceptUI.js works (technical context):

• The merchant page includes a <script> tag loading https://js.authorize.net/v3/AcceptUI.js
• AcceptUI.js scans the DOM for buttons with the CSS class AcceptUI and attaches click handlers
• When clicked, it creates a cross-origin iframe to Authorize.net's hosted payment form
• After the user submits payment info in the iframe, it communicates the tokenized payment nonce back to the merchant page via postMessage
• The runtime protections appear to be breaking either the script initialization, the iframe creation, or the postMessage communication

How to Reproduce

1. Open the DuckDuckGo browser on Android
2. Visit any e-commerce site that uses Authorize.net's AcceptUI for payment (for example: https://victoryseeds.com)
3. Add an item to the cart and proceed to checkout
4. Fill out all required fields (name, email, address, shipping method) so the payment button becomes active
5. Click the "Proceed to Payment" button
6. Nothing happens - the Authorize.net payment modal/lightbox never appears

Expected behavior

Since js.authorize.net is already allowed to load (shown in the shield panel), the script should also be allowed to execute and function at runtime. AcceptUI.js is a payment processing script, not a tracker. It tokenizes credit card data so that the merchant never handles raw card numbers. Blocking its runtime behavior prevents users from completing purchases.

Ideally, js.authorize.net (and jstest.authorize.net for sandbox/testing) should be added to an allowlist that exempts them from the runtime web tracking protections, similar to how other critical third-party services are handled.

Environment

- DDG App Version: Latest (Downloaded 2026-02-24 from Google Play Store)
- Device: Pixel 8
- OS: Android 16

No source files or tests are named. Start by reproducing the checkout flow on Android with DuckDuckGo privacy protections enabled, then trace the runtime protection handling for js.authorize.net, iframe creation, and postMessage behavior. Done means AcceptUI initializes and the payment modal opens without weakening unrelated protections.