Superseded by #1012

[claude]

Requested by oisín, Alexander Reyes-Wainwright · Slack thread

Why

Before: A page that constructs two ui.applePay() instances gets "unsupported" from the second one, permanently. Each instance loaded the Apple Pay SDK itself, and an instance that found a <script> tag already in the DOM marked the script loaded without checking whether it had run — so the second instance sailed past the load wait while Apple's script was still in flight, found no ApplePaySession, and returned "unsupported". availability() cached that answer for the life of the instance and cleared it only on a thrown probe, so no later call and no remount recovered. The express-checkout button never appeared. This only shows up where ApplePaySession comes from Apple's injected SDK rather than the browser: Chrome and Edge on macOS and iOS, in-app browsers, older Safari. Native Safari 17+ defines applePayCapabilities itself, so it never reproduced.

After: Every ApplePayButton on the page shares one SDK load, and the second instance waits for the same script the first one injected, so both resolve "available" and the express-checkout button mounts. A "unsupported" result is no longer cached, so a call made before the SDK is ready no longer poisons every call after it. A tag the merchant injected themselves — the workaround the reporting customer is running — is now handled whether or not it finished loading before the SDK was constructed. Browsers that genuinely have no Apple Pay still get "unsupported", not an error.

How

Script loading moves from per-instance #injectScript() to a single module-level loadApplePaySDK() promise: it resolves immediately when a tag exists and ApplePaySession.applePayCapabilities is already a function, otherwise listens for load on the one tag and applies the existing 10s timeout — rejecting for a tag we injected, resolving for one we did not, since a tag that already ran will never fire load again. availability() keeps memoizing "available" and "unavailable" and drops "unsupported" so the next call re-probes.

Where it came from

Introduced by e6891313a42fee08ebf86894b257d4190989a334; shipped in @evervault/browser@2.62.1 (Aug 10) but only reached prod when 2.63.0 deployed 2026-09-02, which is why it surfaced in September.

Two calls worth a reviewer's attention

The resolve-immediately fast path is gated on a <script> tag existing rather than on applePayCapabilities alone, because the script-loading suite's beforeEach stubs a ready ApplePaySession with no tag in the DOM and an unconditional fast path breaks the existing onload and timeout tests.

For a tag we did not inject, the 10s timeout resolves rather than rejects, so a merchant-self-injected tag on a browser without Apple Pay waits up to 10s before answering "unsupported".

Testing

The new regression test fails on master with expected 'unsupported' to be 'available' and passes with this change. applePay.test.ts is 75/75; tsc --noEmit and eslint are clean. resetApplePaySDKLoader() exists for test isolation and must be called from the top-level beforeEach.

[changeset-bot]

🦋 Changeset detected

Latest commit: 9e56bbb

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 7 packages

Name	Type
@evervault/browser	Patch
@evervault/inputs	Patch
example-apple-pay	Patch
example-react-google-wallet	Patch
@evervault/browser-e2e-tests	Patch
e2e-tests-ui-components-vanilla-server	Patch
@evervault/inputs-e2e-tests	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR