[Due for payment 2026-07-30] [$250] QBO - Can't connect on Android app

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: v9.4.16-1
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/folder/13176908/test-cases/73685192
Email or phone of affected tester (no customers): -
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Xiaomi RedMi Note 10 / Android 12
App Component: Other

Action Performed:

Precondition: workspace with enabled Accounting feature.

1. Go to workspace > Accounting
2. Tap on QuickBooks Online > Connect

Expected Result:

New tab opens to enter QBO credentials

Actual Result:

Blank tab opens with Autoformatting checkbox

Workaround:

Unknown

Platforms:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome Safari

Screenshots/Videos

Bug7187012_1782046473773.Screenrecorder-2026-06-21-15-43-08-101.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Mita Rachim
Bug ID: 7187012

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022068957073168668976
• Upwork Job ID: 2068957073168668976
• Last Price Increase: 2026-07-20

Issue Owner

Current Issue Owner: @aimane-chnaif

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/f7967ac4653f0bb848b5ca4d3d05b45cd4bdfa36fcbde450ea6337441ebcf4bc

[MelvinBot]

Issue Analysis

Root Cause (medium confidence): On Android the QBO Connect button does not open an external browser tab. It mounts an in-app react-native-webview pointed at the Expensify backend command URL …/api/ConnectPolicyToQuickbooksOnline?policyID=…, authenticating via a Cookie: authToken=… header (ConnectToQuickbooksOnlineFlow/index.native.tsx:58-69). That endpoint is supposed to 302-redirect the WebView into the QuickBooks/Intuit login page. The "blank tab with an Autoformatting checkbox" is the WebView rendering a non-QBO page — i.e. the redirect into QuickBooks is not happening, so the WebView shows whatever HTML the request returned instead.

This is Android-only by design: the web variant opens a real new browser tab via Link.openLink(...) (index.tsx:11-16), which is why iOS / mWeb / desktop are unaffected.

Why this likely isn't an App-repo regression: The native flow component and the URL builder (QuickbooksOnline.ts:19-26) have not changed since April–May 2026, yet the bug is new in v9.4.16 and reproduces in production. That pattern points to a change in what the backend ConnectPolicyToQuickbooksOnline command returns to the WebView request (e.g. the cookie-header auth not being honored, or the redirect chain no longer landing on Intuit), rather than to App code.

Recommended next step: This requires a backend/internal investigation of the ConnectPolicyToQuickbooksOnline endpoint — specifically, what it returns for an Android react-native-webview request carrying Cookie: authToken=… (status code, whether it 302s to Intuit or returns a 200 HTML body, and whether the cookie auth is accepted). That lives outside the App repo, so please escalate to an internal engineer with backend access to confirm. There is no App-side fix to make until the redirect/auth failure is understood.

Investigation details & evidence

Flow on tap (Connect → WebView):

• startIntegrationFlow({name: QBO}) in PolicyAccountingPage.tsx sets the active integration and renders setupConnectionFlow.
• For QBO, setupConnectionFlow is <ConnectToQuickbooksOnlineFlow/> (accounting/utils.tsx:89-98). React Native resolves index.native.tsx on Android, index.tsx on web.
• There is no Linking.openURL on the native path — it's an embedded fullscreen WebView.

The URL loaded is an Expensify backend command, not a QBO URL directly: getQuickbooksOnlineSetupLink builds …/api/ConnectPolicyToQuickbooksOnline?policyID=… with shouldSkipWebProxy: true, which forces the production www.expensify.com host on native. The backend is expected to redirect to Intuit OAuth.

"Autoformatting checkbox" is not an Expensify screen. A full search of src (and src/languages/en.ts) finds no autoformat / auto-format string anywhere in the App — the only matches are inside the node_modules/xlsx library internals. So the checkbox is content of the page the WebView actually loaded (an Intuit/error/interstitial page or Android system WebView chrome), not an in-app route. This rules out an in-app deep-link/route mismatch.

Alternative explanations considered:

• react-native-webview bump altering Android cookie/redirect/incognito handling — the component already uses the Android-only incognito workaround (line 66), which disables cookie persistence on Android. A backend change to how the authToken cookie is validated would interact badly with this. Worth ruling out alongside the backend check.
• In-app route mismatch — ruled out (no Autoformatting screen exists in App).

---

Next Steps for Contributor+ team: The likely fix is backend, not App. Please escalate the ConnectPolicyToQuickbooksOnline redirect/auth behavior to an internal engineer.
To refine: @MelvinBot <your feedback> (e.g. if you can share a device repro of what the WebView actually displays, or a requestID from an affected attempt).

[MobileMage]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-07 22:28:37 UTC.

Proposal

Please re-state the problem that we are trying to solve in this issue.

On the Android app, Workspace > Accounting > QuickBooks Online > Connect opens a blank page with an "Autoformatting" checkbox instead of the QBO credentials page, so the connection can never be completed on Android. This still reproduces on latest main, where the flow now lives in QuickbooksOnlineSetupPage → the shared AccountingSetupWebViewPage (PR #92512) and the WebView already passes userAgent={getUAForWebView()}.

What is the root cause of that problem?

The "blank page with an Autoformatting checkbox" is not a rendering problem — it is Android System WebView's built-in JSON viewer, whose pretty-print checkbox only appears when the document response is application/json. So the WebView never receives Intuit's login page; it receives a JSON error from the setup endpoint, matching the chrome://inspect capture shared earlier in this thread: 200 application/json with {"jsonCode":407, "title":"Session expired"}. In other words, ConnectPolicyToQuickbooksOnline is reached unauthenticated. The flow's only credential is the raw session token injected as a request header on the WebView source:

App/src/pages/workspace/accounting/AccountingSetupWebViewPage.tsx

Lines 60 to 64 in 6a0f1e5

	source={{
	uri,
	headers: {
	Cookie: `authToken=${authToken}`,
	},

That transport is fragile by design on Android: source.headers only accompany the initial loadUrl navigation (the incognito prop on this very WebView exists solely to work around the Cookie header being dropped, react-native-webview/react-native-webview#1352), so any hop inserted in front of the command — a redirect or an interstitial — re-requests the URL without the header. That environment has now changed: www.expensify.com/api/* sits behind Cloudflare bot mitigation (a plain GET to any /api/ command from a non-browser client returns 403 with cf-mitigated: challenge, while the same client fetches the homepage with 200), and this WebView is a prime target for it because getUAForWebView() spoofs a two-year-stale Chrome/124.0.6367.159 UA that contradicts the Chromium version the WebView advertises in its Sec-CH-UA client hints. A managed challenge auto-solves and reloads the URL without the one-shot Cookie header, the API answers 407 "Session expired" as JSON, and the JSON viewer paints the reported "blank" page. Because the trigger is server-side risk scoring rather than App code, this explains why the bug appeared in production and staging with no relevant App change, why reproduction has been intermittent per device and network (not reproducible on 2026-06-24, reproducible again now), and why web is unaffected — it never uses a WebView, and openLink → openOldDotLink authenticates the very same command URL with a short-lived token in the URL, which survives any reload. On iOS getUAForWebView() returns undefined, so its WKWebView presents a genuine UA instead of a spoofed one.

The decisive falsification of the user-agent theory (which the original version of this proposal also advanced) is issue #95199: Xero — which has carried userAgent={getUAForWebView()} since 2024 and now shares this exact AccountingSetupWebViewPage — started failing the same way on Android in production and staging on 2026-07-02. The UA override was also added to the QBO WebView by PR #92512 and the bug still reproduces on main. Both issues share one mechanism: the Cookie-header auth transport, not the user agent.

What changes do you think we should make in order to solve the problem?

Authenticate the WebView the way web and the already-shipped HR connect flow authenticate the same class of OldDot links: fetch a short-lived auth token and carry it in the URL, so every hop (challenge reloads and redirects included) stays authenticated. The helper already exists in src/libs/actions/Link.ts — it calls OpenOldDotLink, appends authToken=<shortLivedAuthToken> to the link, and falls back to the raw link if the request fails:

App/src/libs/actions/Link.ts

Lines 429 to 433 in 6a0f1e5

	function getShortLivedAuthTokenURL(setupLink: string): Promise<string> {
	// eslint-disable-next-line rulesdir/no-api-side-effects-method
	return API.makeRequestWithSideEffects(SIDE_EFFECT_REQUEST_COMMANDS.OPEN_OLD_DOT_LINK, {}, {})
	.then((response) => {
	if (!response?.shortLivedAuthToken) {

In the shared AccountingSetupWebViewPage, resolve the authenticated URL before mounting the WebView and load that instead of the bare uri:

const [authenticatedUrl, setAuthenticatedUrl] = useState<string | null>(null);
useEffect(() => {
    getShortLivedAuthTokenURL(uri).then(setAuthenticatedUrl);
}, [uri]);

While authenticatedUrl is null we show the existing renderLoading indicator, then render the WebView with source={{uri: authenticatedUrl}}; incognito, startInLoadingState, the offline wrapper and back handling all stay as they are, and the existing Cookie header can be kept as belt-and-braces or dropped in the PR since correctness no longer depends on it. This is precisely the pattern ConnectToHRFlow ships with today on Android and iOS against the same OldDot backend (PR #92075):

App/src/components/ConnectToHRFlow/index.native.tsx

Lines 36 to 40 in 6a0f1e5

	if (hasFetched.current) {
	return;
	}
	hasFetched.current = true;
	getShortLivedAuthTokenURL(setupLink).then(setAuthenticatedUrl);

Because the change lands in the shared component, it fixes this issue and #95199 (Xero) together, adds one round-trip that web already pays for the same links, and touches no web code — ConnectToQuickbooksOnlineFlow/index.tsx keeps opening the link through openLink exactly as before.

What alternative solutions did you explore? (Optional)

Writing the session cookie into the Android cookie store natively (CookieManager from @react-native-cookies/cookies) before loading — rejected because it adds a native dependency and cookie state is exactly what the incognito profile and challenge interstitials clear, so it re-creates the same fragility. Opening the setup link in the external browser via openOldDotLink, mirroring web — rejected because it abandons the established in-app WebView UX for accounting connections and would diverge QBO/Xero from every sibling native flow.

[lorretheboy]

Proposal

Please re-state the problem that we are trying to solve in this issue.

On the Android native app, Workspace > Accounting > QuickBooks Online > Connect opens a blank tab (the tester sees only an "Autoformatting" checkbox overlay) instead of the QBO credentials/OAuth page, so the QBO connection can never be completed on Android. iOS native and web/mWeb work.

What is the root cause of that problem?

The QBO connect flow on native loads getQuickbooksOnlineSetupLink(policyID) inside a single in-app WebView:

App/src/components/ConnectToQuickbooksOnlineFlow/index.native.tsx

Lines 58 to 69 in 2b78b56

	<WebView
	ref={webViewRef}
	source={{
	uri: getQuickbooksOnlineSetupLink(policyID),
	headers: {
	Cookie: `authToken=${authToken}`,
	},
	}}
	incognito // 'incognito' prop required for Android, issue here https://github.com/react-native-webview/react-native-webview/issues/1352
	startInLoadingState
	renderLoading={renderLoading}
	/>

That OldDot endpoint redirects into Intuit's OAuth flow, and the Intuit/OldDot handoff opens its next step in a new window (a target="_blank" link / window.open). On Android, react-native-webview defaults setSupportMultipleWindows to true, which routes any new-window request to the native onCreateWindow path. Our QBO WebView provides no onOpenWindow handler and does not set setSupportMultipleWindows, so Android honors the new-window request but has nowhere to put it — it surfaces an empty secondary view with no loaded content. That is exactly the "blank tab" the reporter sees; the "Autoformatting checkbox" is just Android's autofill overlay on an empty page.

This is Android-only because setSupportMultipleWindows is an Android-WebView concept: on iOS WebKit the same target="_blank" navigation is loaded in the main frame by default, so the OAuth page appears and iOS works. Android is the one platform that splits the flow off into an unhandled blank window.

Note this is a distinct mechanism from the user-agent theory: even with a Chrome UA, an unhandled new-window navigation on Android still lands in a blank window. The missing piece here is multiple-window handling, not the UA string.

What changes do you think we should make in order to solve the problem?

Tell the QBO WebView to keep the OAuth navigation in the same frame instead of spawning an unhandled new window, by setting setSupportMultipleWindows={false} on the WebView:

App/src/components/ConnectToQuickbooksOnlineFlow/index.native.tsx

Lines 58 to 69 in 2b78b56

	<WebView
	ref={webViewRef}
	source={{
	uri: getQuickbooksOnlineSetupLink(policyID),
	headers: {
	Cookie: `authToken=${authToken}`,
	},
	}}
	incognito // 'incognito' prop required for Android, issue here https://github.com/react-native-webview/react-native-webview/issues/1352
	startInLoadingState
	renderLoading={renderLoading}
	/>

<WebView
    ref={webViewRef}
    source={{uri: getQuickbooksOnlineSetupLink(policyID), headers: {Cookie: `authToken=${authToken}`}}}
    setSupportMultipleWindows={false}
    incognito
    startInLoadingState
    renderLoading={renderLoading}
/>

With setSupportMultipleWindows={false}, Android loads target="_blank"/window.open navigations in the current WebView rather than handing them to an unmanaged new window, so the QBO/Intuit credentials page renders inline and the user can complete the connection. The prop is a no-op on iOS (it only affects the Android WebChromeClient), so the working iOS behavior is preserved exactly, and no web/mWeb code changes. The existing Cookie: authToken header, incognito, loader, and offline wrapper are untouched.

What alternative solutions did you explore? (Optional)

• Add the new window as a managed popup: keep setSupportMultipleWindows enabled and implement an onOpenWindow handler that renders the target URL in an overlay WebView (the pattern used by the HR connection flow), with Android back closing the popup first. This works but adds popup state, an extra WebView, and back-handling for what is a linear OAuth step, so forcing same-window navigation is the smaller fix.
• Override the WebView user agent with getUAForWebView() (as the Xero flow does). That addresses a different failure mode (embedded-WebView UA rejection) and does not handle the unmanaged new-window navigation that produces the blank tab here.
• Drop the in-app WebView entirely and open the setup link externally via Link.openLink (matching the web index.tsx). That changes the established in-app, cookie-authenticated flow and is a larger behavioral change than keeping the navigation inside the existing WebView.

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @aimane-chnaif (External)

[kitvasyl]

Proposal

Please re-state the problem that we are trying to solve in this issue.

On Android native, tapping Workspace > Accounting > QuickBooks Online > Connect should open the QBO credentials/OAuth flow, but it opens a blank tab/page instead.

What is the root cause of that problem?

The Android app is using src/components/ConnectToQuickbooksOnlineFlow/index.native.tsx, not the shared index.tsx flow. In ConnectToQuickbooksOnlineFlow, lines 58-69 render getQuickbooksOnlineSetupLink(policyID) directly inside a react-native-webview with only a manually injected authToken cookie.

That bypasses the working Link.openLink(getQuickbooksOnlineSetupLink(policyID), environmentURL) path used by src/components/ConnectToQuickbooksOnlineFlow/index.tsx. openLink() routes old-dot Expensify URLs through openOldDotLink() in src/libs/actions/Link.ts, which requests a short-lived auth token and opens the authenticated old-dot/OAuth URL externally. The QBO connect flow is an external OAuth flow, so loading it in the Android WebView causes the blank tab instead of reaching the QBO credentials page.

What changes do you think we should make in order to solve the problem?

Add an Android-specific implementation for QBO connect, e.g. src/components/ConnectToQuickbooksOnlineFlow/index.android.tsx, that mirrors the shared browser-opening flow:

• call PolicyAction.enablePolicyTaxes(policyID, false) as today;
• call Link.openLink(getQuickbooksOnlineSetupLink(policyID), environmentURL) instead of rendering the setup URL in a WebView;
• return null, matching index.tsx.

This keeps the change scoped to Android, preserves the existing tax-disabling side effect, and reuses the existing authenticated old-dot external-link handling in src/libs/actions/Link.ts instead of adding QBO-specific OAuth/WebView logic.

Manual verification: on Android native, go to Workspace > Accounting > QuickBooks Online > Connect and confirm the QBO credentials page opens instead of a blank tab. Also verify web still opens the same QBO setup link and existing connected-workspace accounting settings are unchanged.

What alternative solutions did you explore? (Optional)

We could try to make the QBO WebView support this OAuth flow by adding a custom user agent, popup handling, cookie sharing, and redirect handling similar to other native WebView flows. That is riskier for this bug because the expected behavior is an external tab and the app already has a working authenticated external-link path for old-dot commands.

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022068957073168668976

[mukhrr]

Proposal

What is the root cause of that problem?

The Android QBO native connection flow loads the OldDot QBO setup endpoint inside a single react-native-webview and does not handle popup/new-window navigation from the OAuth flow. On Android, when the QBO setup page opens the provider auth step in a new window, our WebView has no onOpenWindow handler, so Android creates the wrong blank WebView/tab instead of showing the QBO credentials page.

Evidence:

• QBO native uses one WebView, with no onOpenWindow or popup WebView handling:

  App/src/components/ConnectToQuickbooksOnlineFlow/index.native.tsx

  Lines 58 to 69 in cc90dd2

  	<WebView
  	ref={webViewRef}
  	source={{
  	uri: getQuickbooksOnlineSetupLink(policyID),
  	headers: {
  	Cookie: `authToken=${authToken}`,
  	},
  	}}
  	incognito // 'incognito' prop required for Android, issue here https://github.com/react-native-webview/react-native-webview/issues/1352
  	startInLoadingState
  	renderLoading={renderLoading}
  	/>

• That WebView points at the ConnectPolicyToQuickbooksOnline command URL, so the OAuth handoff happens from inside this WebView:

  App/src/libs/actions/connections/QuickbooksOnline.ts

  Lines 19 to 25 in cc90dd2

  	function getQuickbooksOnlineSetupLink(policyID: string) {
  	const params: ConnectPolicyToAccountingIntegrationParams = {policyID};
  	const commandURL = getCommandURL({
  	command: READ_COMMANDS.CONNECT_POLICY_TO_QUICKBOOKS_ONLINE,
  	shouldSkipWebProxy: true,
  	});
  	return commandURL + new URLSearchParams(params).toString();

• We already fixed the same class of Android/native OAuth popup issue in HR import. PR [HR Import] ConnectToHRFlow popup handling and authentication on native #92075 explicitly says the Android implementation handles popup windows via onOpenWindow: [HR Import] ConnectToHRFlow popup handling and authentication on native #92075
• The current HR flow has the missing pattern: it stores event.nativeEvent.targetUrl in handleOpenWindow, renders an overlay popup WebView, and makes Android back close the popup first:

  App/src/components/ConnectToHRFlow/index.native.tsx

  Lines 66 to 91 in cc90dd2

  	const handleOpenWindow = (event: WebViewOpenWindowEvent) => {
  	setPopupUrl(event.nativeEvent.targetUrl);
  	setIsPopupVisible(true);
  	};
  	const dismiss = () => {
  	setIsWebViewOpen(false);
  	onDone?.();
  	};
  	const handleBackPress = () => {
  	if (isPopupVisible) {
  	// Keep the popup WebView mounted (hidden) so in-flight OAuth redirects
  	// can complete and shared cookies remain intact for Merge Link.
  	setIsPopupVisible(false);
  	return;
  	}
  	dismiss();
  	};
  	const handleNavigationStateChange = (navState: WebViewNavigation) => {
  	if (!navState.url.includes(ROUTES.CONNECTION_COMPLETE)) {
  	return;
  	}
  	dismiss();

  and

  App/src/components/ConnectToHRFlow/index.native.tsx

  Lines 123 to 144 in cc90dd2

  	// Not using incognito here so the popup WebView can share cookies
  	// with the main flow (required for OAuth handoffs).
  	<WebView
  	source={{uri: authenticatedUrl}}
  	onOpenWindow={handleOpenWindow}
  	onNavigationStateChange={handleNavigationStateChange}
  	startInLoadingState
  	renderLoading={renderLoading}
  	/>
  	)}
  	{!!popupUrl && (
  	<View
  	style={[StyleSheet.absoluteFill, !isPopupVisible && styles.opacity0]}
  	pointerEvents={isPopupVisible ? 'auto' : 'none'}
  	>
  	<WebView
  	source={{uri: popupUrl}}
  	onOpenWindow={handleOpenWindow}
  	startInLoadingState
  	renderLoading={renderLoading}
  	/>
  	</View>

• QBO file history only shows loading/back-button maintenance, not OAuth popup handling. PR Use ActivityIndicator in ConnectToQuickbooksOnlineFlow #87594 changed only the loader in this same QBO native file: Use ActivityIndicator in ConnectToQuickbooksOnlineFlow #87594

What changes do you think we should make in order to solve the problem?

Add Android-only popup handling to ConnectToQuickbooksOnlineFlow/index.native.tsx, matching the proven HR OAuth pattern, while keeping the existing QBO setup URL, auth cookie header, incognito, loader, modal, and offline wrapper unchanged.

Small diff sketch:

+import type {WebViewOpenWindowEvent} from 'react-native-webview/lib/WebViewTypes';

 const [isWebViewOpen, setIsWebViewOpen] = useState(false);
+const [popupUrl, setPopupUrl] = useState<string | null>(null);
+const [isPopupVisible, setIsPopupVisible] = useState(false);

+const handleOpenWindow = (event: WebViewOpenWindowEvent) => {
+    setPopupUrl(event.nativeEvent.targetUrl);
+    setIsPopupVisible(true);
+};

+const handleBackPress = () => {
+    if (isPopupVisible) {
+        setIsPopupVisible(false);
+        return;
+    }
+    setIsWebViewOpen(false);
+};

 <WebView
     source={{uri: getQuickbooksOnlineSetupLink(policyID), headers: {Cookie: `authToken=${authToken}`}}}
+    onOpenWindow={handleOpenWindow}
     incognito
     startInLoadingState
     renderLoading={renderLoading}
 />
+{!!popupUrl && (
+    <View style={[StyleSheet.absoluteFill, !isPopupVisible && styles.opacity0]} pointerEvents={isPopupVisible ? 'auto' : 'none'}>
+        <WebView source={{uri: popupUrl}} startInLoadingState renderLoading={renderLoading} />
+    </View>
+)}

To avoid regressions:

• Scope the behavior to native QBO only; no web/mWeb changes.
• If reviewers prefer stricter Android scope, guard onOpenWindow and popup rendering with Android platform checks so iOS native keeps the exact current behavior.
• Preserve the existing Cookie: authToken, incognito, FullPageOfflineBlockingView, and loader.
• Test Android native QBO connect, Android back behavior from the popup, offline state, and smoke-test iOS native QBO to confirm unchanged behavior.

What alternative solutions did you explore? (Optional)

Opening the QBO URL externally with Linking.openURL could bypass WebView popup handling, but it changes the existing authenticated in-app flow and risks losing the current cookie/header behavior. Reusing the already-merged HR OAuth popup pattern fixes the Android-specific root cause with a smaller blast radius.