A WebView is sold as «just a browser.» For your fraud and risk team, it is a device-identity lottery. The page loads, the user taps pay, and somewhere a risk engine scores the request. What it cannot see is that the «device» it is scoring changes every time the app opens a new view or a privacy mode quietly wipes the cookie jar. The same human becomes a different device — and your false-decline rate is the bill.
Three partitions, three ways to lose identity
The trouble is not one bug; it is three independent partition decisions stacking up. On iOS, WebKit's Intelligent Tracking Prevention partitions third-party LocalStorage and IndexedDB per first party and caps client-side cookies set through document.cookie to seven days. Apple's own tracking-prevention document states the default WebKit cookie policy disallows a third-party from setting new cookies unless it already has some, and that partitioned storage is made ephemeral. On top of that, a WKWebView configured with WKWebsiteDataStore.nonPersistent() — the standard way teams implement «private» or throwaway sessions — stores nothing to disk at all and discards everything when the view goes away. On Android, the reverse problem: the CookieManager is process-wide, so there is no honest way to give one WebView an isolated session without destructively clearing the cookies shared with every other WebView in the app. The cross-platform reality is a patchwork where identity is sometimes partitioned, sometimes ephemeral, and sometimes shared — and never under your control.
What the risk engine sees
Fraud and KYC stacks rely on a stable device or install signal to separate a returning good customer from a fraudster spinning up fresh containers. When that signal is a cookie or localStorage value that the OS partitions, expires, or deletes, the same real user presents as a brand-new, anonymous device on every session. That is exactly the pattern risk models treat as high-risk: new device, no history, geo or behavior that does not match the last known good session. The platform does not intend to block the customer. It just cannot recognize them. Meanwhile a real fraudster using a clean container looks no different from your best customer opening the app after an ITP wipe.
The cost is real, and it is not the fraud
The money lost to false declines dwarfs the money lost to fraud. Industry research summarized by payment-recovery analysts puts global e-commerce revenue lost to false declines at roughly $443 billion a year, with about 58% of all declines being false positives and roughly $13 lost to false declines for every $1 lost to fraud. A Raconteur and Riskified report found that in 2023 alone, $1,570 billion of US e-commerce sales were exposed to false declines, with $81 billion estimated permanently lost, and 47% of retailers said false declines severely hurt customer satisfaction. A falsely declined customer rarely complains — they just leave, and about a third never come back. When your WebView's cookie churn is quietly manufacturing those false positives, the runtime is costing you more than any fraudster.
Privacy pressure makes it worse
Aggressive storage partitioning does reduce cross-site tracking, but security researchers have long warned it pushes the web toward opaque browser fingerprinting — signals derived from hardware and configuration that users cannot see or control. Inside a WebView, that means fraud teams, denied reliable first-party cookies, lean harder on fingerprinting, which is exactly what privacy regimes (GDPR, and Apple's own stance) are trying to constrain. You end up choosing between recognizing your own customers and respecting the privacy rules, with the WebView's partition behavior forcing the worst of both.
The runtime fix
A host-owned runtime does not ask the browser to remember who the user is. It issues one stable, signed, consent-gated device or install identity from the host layer and injects it deterministically into every view and every request — the same identifier whether the WebView is ephemeral, partitioned, or shared. Server-side session reconciliation ties that identity to the real account, so returning customers are recognized even after an ITP wipe, and genuine fraudsters spinning fresh containers still stand out. Identity becomes a property the runtime guarantees, not a coin flip inside partitioned storage.
| Dimension | WebView | Host-owned runtime |
|---|---|---|
| iOS storage | ITP partitions per first party; 7-day cookie cap | Stable identity injected by host |
| Ephemeral views | nonPersistent() discards all identity | Same signed ID across ephemeral views |
| Android storage | Process-wide cookie jar; no per-view isolation | Per-install ID, not dependent on CookieManager |
| Risk scoring | Identity drifts per session → false positives | Consistent device signal → fewer false declines |
| Privacy | Forced toward opaque fingerprinting | Consent-gated, first-party, auditable |
The through-line of this series is control. A WebView hands your fraud stack a device identity it does not own and cannot trust. A runtime lets you issue one. For a catalog of other people's pages transacting inside your app, that difference is the gap between a checkout that converts and a checkout that quietly turns good customers away.
Sources
- WebKit Tracking Prevention — third-party storage is partitioned per first party and client-side cookies are capped to 7 days — Apple's policy doc: default cookie policy blocks third-party writes, partitioned LocalStorage/IndexedDB made ephemeral.
- Apple Developer —
WKWebsiteDataStore.nonPersistent()stores nothing to disk — the standard private/throwaway WebView configuration discards all cookies and storage on teardown. - Android
CookieManageris process-wide — no honest per-WebView isolation — secure-webview security model notes ephemeral sessions fail closed on Android because cookies are shared app-wide. - The True Cost of False Declines — ~$443B/year lost to false declines; 58% of declines are false positives — industry research: $13 lost to false declines per $1 lost to fraud.
- Juniper: online payment fraud $44B (2024) → $107B (2029); false declines cost the industry $443B annually — fraud-loss projections versus the larger false-decline drag on revenue.
