Security and privacy

highwire.js collects a fixed set of browser and checkout context signals in the cardholder's browser. Review Device data for the complete collected-field list, payload shape, and field limits.

PCI scope

highwire.js is a context collector, not a card-data collector. It does not read PAN, CVV, card-field values, or pasted content. Card data remains in the merchant's existing checkout and payment path.

Those product facts do not determine a merchant's PCI DSS scope or SAQ eligibility. Confirm the complete integration with your acquirer, payment brands, QSA, or other compliance-accepting entity. PCI SSC FAQ 1588 describes script-related SAQ A eligibility and directs merchants to the entity accepting their compliance; FAQ 1092 explains that outsourcing payment processing does not remove merchant responsibilities.

Data highwire.js does not collect

The complete set of collected signals is documented in Device data. Outside that set, the library does not collect card data, input values, pasted content, cookie data, device fingerprints, or geolocation.

It does not use canvas, WebGL, or audio probes; hash a visitor identifier; depend on a fingerprinting library; or trigger the browser's geolocation permission prompt.

The optional document.referrer signal can contain URL data from the referring page. Review URL and referrer-policy design so sensitive values are not placed in URLs.

Input handling

Field observation is opt-in. For each registered element, the library listens only for a paste event and records the supported field name supplied by the merchant. It never reads element.value or clipboard contents.

Recorded field names remain in memory for the life of the HighWire instance. They are not written to cookies or browser storage.

See hw.observeField(element, fieldName) for the accepted field names and listener-cleanup behavior.

Browser storage

The library does not read or set cookies, write to localStorage or sessionStorage, or persist a visitor identifier in the browser.

Network requests

The only requests made by the library are unauthenticated public-IP lookups during collect(). It requests GET https://api.ipify.org?format=json, then attempts ifconfig.co if the first provider fails with GET https://ifconfig.co/json.

Each provider has a five-second timeout, so collection makes at most one request to each provider. The library loads no third-party JavaScript at runtime and has no runtime dependencies.

Both requests are unauthenticated and use omitted credentials. Merchant CSP permission controls whether the browser may attempt each origin; provider-side CORS independently controls whether JavaScript can read the response.

highwire.js itself calls only the two public-IP providers and does not call HighWire or Stripe. After collection, merchant-owned browser code sends the payload to the merchant backend, which forwards it through the existing payment path. See Integration for those handoffs.

Downstream use and retention

Browser collection and server-side downstream processing are separate. Only when the pre-authorization Stripe Payment Evaluations feature is enabled and deviceData is present, HighWire sends relevant device and behavioral signals to Stripe Radar for that optional evaluation.

As part of that optional path, the gateway retains the raw deviceData payload in a payment-evaluation record. When Stripe returns an evaluation result, that result may also be retained. When this optional evaluation is disabled, HighWire does not send or retain deviceData through the Payment Evaluations path. These steps happen server-side after merchant forwarding; they are not additional browser requests made by highwire.js.

Content Security Policy

The documented UMD setup loads both the self-hosted library and the same-origin companion integration file as external scripts. The CSP baseline required by these examples is:

script-src 'self';
connect-src 'self' https://api.ipify.org https://ifconfig.co;

'self' in script-src permits the two same-origin script files without allowing inline code. 'self' in connect-src preserves the same-origin merchant checkout endpoint used by the examples. If the checkout calls another API origin, preserve every additional merchant API origin when merging these values into the existing policy.

The two provider origins let the browser attempt public-IP lookups. CSP permission does not guarantee success: provider-side CORS can still keep a response unreadable. Do not add unsafe-inline; keep integration code in the companion file or use a separately reviewed nonce/hash policy.

Subresource Integrity

For a script-tag integration, use the SHA-384 SRI value delivered with that exact UMD file and retain crossorigin="anonymous". The hash covers the exact bytes HighWire shipped. If the file is minified, transformed, or otherwise rewritten, the browser reports an integrity mismatch and refuses to execute it.

Bundled ESM imports do not use the separately delivered SRI hash. See Choose a build and Self-host the UMD build for the canonical setup.

Browser support

The distributed JavaScript targets ES2019 syntax. The collection path requires globalThis, Promise, Set, fetch, AbortController, and navigator.userAgent; paste observation also requires DOM event targets. Referrer and time-on-page are optional and may be omitted when document.referrer or performance.timeOrigin is unavailable.

This repository does not have a real-browser compatibility matrix, so the documentation does not promise exact browser-version floors. Validate the supported product browser matrix in real checkout browsers, including CSP, CORS, SRI, and the required APIs above.

Importing ESM and constructing the factory do not access DOM APIs, collect context, or make network requests, but collect() must run in the cardholder's browser. Loading UMD has the expected effect of registering window.HighWire. Review browser-only collection and React and Next.js.