[$250] Unable to access Expensify Travel from New Expensify when logged in with a +@team.expensify.com account

[m-natarajan]

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

---

Version Number: 9.4.43-1
Reproducible in staging?: Needs Reproduction (Reproduction blocked)
Reproducible in production?: Needs Reproduction
If this was caught during regression testing, add the test name, ID and link from BrowserStack:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @PedroEspinoza1999
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

1. Log in to New Expensify using a +@team.expensify.com account.
2. Click the + Create button.
3. Select Book Travel.
4. Wait for the system to open Expensify Travel in a new browser tab.
5. Observe that the new tab displays a blank white page and does not complete the authentication process or load the Travel platform.

Expected Result:

The user should be authenticated successfully and redirected to the Expensify Travel platform, where they can access Travel support functionality.

Actual Result:

A new tab opens at a travel.expensify.com/auth/code URL, but the page remains blank and Expensify Travel never loads.

Workaround:

Unknown

Platforms:

Select the officially supported platforms where the issue was reproduced:

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

Screenshots/Videos

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022080791231827400695
• Upwork Job ID: 2080791231827400695
• Last Price Increase: 2026-07-31

Issue Owner

Current Issue Owner: @ShridharGoel

[MelvinBot]

Issue Analysis

Root Cause: This is not an App bug and not a plus-address (+) URL-encoding bug. The App never puts the user's email in the travel.expensify.com/auth/code URL, so a + in the email cannot be corrupted there. The blank page means the backend/Spotnana side could not turn the issued auth code into a valid travel session — most likely because a +@team.expensify.com test/team account is not provisioned in the Spotnana travel provider (or is routed to a staging Spotnana environment it isn't set up in). This matches the Reproduction blocked note on the report.

Where the fix lives: Outside the Expensify/App repo. The App code path here is correct — it only fetches an opaque token via the backend GenerateSpotnanaToken command and hands it to travel.expensify.com, which is served by the travel provider (Spotnana), not App. An internal engineer with backend/Auth access needs to check whether GenerateSpotnanaToken succeeds for this account and whether the account is provisioned in the target Spotnana environment.

Investigation details & evidence

How Book Travel builds the URL — src/libs/actions/Link.ts:104-116 (buildTravelDotURL):

https://travel.expensify.com/auth/code?authCode=<spotnanaToken>&tmcId=<tmcID>[&redirectUrl=<encoded>]

The only params are authCode (a server-generated opaque token), tmcId (a fixed constant), and an optional encoded redirectUrl. The email is never a parameter in this URL — so plus-addressing cannot be mangled here.

Where the token comes from — src/libs/actions/Link.ts:121-152 (openTravelDotLink): App calls the backend GENERATE_SPOTNANA_TOKEN side-effect command (request carries only policyID), and only opens the tab if a token is returned. Since the tab does open but stays blank, a token was issued but the travel provider could not resolve it into a session.

Test-account routing — when the backend response sets isTestAccount, App points the URL at STAGING_TRAVEL_DOT_URL with STAGING_SPOTNANA_TMC_ID (Link.ts:105-106). A +@team.expensify.com account can be routed to a staging Spotnana it isn't provisioned in → blank page.

Gating — team.expensify.com is a private (guides) domain, so it passes the public-domain gate in BookTravelButton and proceeds into token generation. There is no special handling for plus-addressed or team accounts anywhere in the travel gating logic.

Alternative explanation considered: a genuine URL-encoding bug on +. Ruled out because App transmits no email in the URL (contrast the OldDot flow's buildOldDotURL, which does use email=${encodeURIComponent(...)} — that's a different flow).

To confirm on the backend (internal): for the affected account's Book Travel click, check whether GenerateSpotnanaToken returned a token and whether isTestAccount was true, then verify whether that account exists/is provisioned in the corresponding Spotnana environment. If the token is issued fine, the failure is entirely on the Spotnana /auth/code exchange.

Related issues: Quick scan found no open duplicates.

---

This appears to require changes / configuration outside the Expensify/App repo (backend token generation and/or Spotnana travel provisioning). Please escalate to an internal engineer with backend access to confirm whether the account is provisioned in the travel provider.

Next Steps: Reply with @MelvinBot <your feedback> to refine this analysis.

[abbasifaizan70]

Proposal

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

When a user logged in with an internal +@team.expensify.com (Expensify test/team) account clicks + Create → Book Travel, a new tab opens to travel.expensify.com/auth/code but the page stays blank forever — the Spotnana authentication handshake never completes and Expensify Travel never loads.

What is the root cause of that problem?

BookTravelButton calls openTravelDotLink, which for the web platform delegates to openTravelDotLink in Link.ts. That function calls the GENERATE_SPOTNANA_TOKEN API and then builds the Travel Dot URL purely from the API response, defaulting isTestAccount to false whenever the response doesn't explicitly say otherwise:

App/src/libs/actions/Link.ts

Lines 133 to 151 in e40fe0b

	asyncOpenURL(
	// eslint-disable-next-line rulesdir/no-api-side-effects-method
	API.makeRequestWithSideEffects(SIDE_EFFECT_REQUEST_COMMANDS.GENERATE_SPOTNANA_TOKEN, parameters, {})
	.then((response) => {
	if (!response?.spotnanaToken) {
	reject(error);
	throw error;
	}
	const travelURL = buildTravelDotURL(response.spotnanaToken, response.isTestAccount ?? false, postLoginPath);
	resolve(undefined);
	return travelURL;
	})
	.catch(() => {
	reject(error);
	throw error;
	}),
	(travelDotURL) => travelDotURL ?? '',
	);
	});

buildTravelDotURL uses that single boolean to pick both the domain (production travel.expensify.com vs staging.travel.expensify.com) and the matching Spotnana TMC id — these two must be paired correctly or the handshake breaks:

App/src/libs/actions/Link.ts

Lines 104 to 116 in e40fe0b

	function buildTravelDotURL(spotnanaToken: string, isTestAccount: boolean, postLoginPath?: string): string {
	const environmentURL = isTestAccount ? CONST.STAGING_TRAVEL_DOT_URL : CONST.TRAVEL_DOT_URL;
	const tmcID = isTestAccount ? CONST.STAGING_SPOTNANA_TMC_ID : CONST.SPOTNANA_TMC_ID;
	const authCode = `authCode=${spotnanaToken}`;
	const tmcIDParam = `tmcId=${tmcID}`;
	const redirectURL = postLoginPath ? `redirectUrl=${encodeURIComponent(Url.addLeadingForwardSlash(postLoginPath))}` : '';
	const paramsArray = [authCode, tmcIDParam, redirectURL];
	const params = paramsArray.filter(Boolean).join('&');
	const travelDotDomain = addTrailingForwardSlash(environmentURL);
	return `${travelDotDomain}auth/code?${params}`;
	}

+@team.expensify.com accounts are Expensify's internal test/team accounts (already recognized elsewhere in the app as CONST.EMAIL.GUIDES_DOMAIN / CONST.EXPENSIFY_TEAM_EMAIL_DOMAIN, e.g. via the isExpensifyTeam helper), and these accounts are provisioned in Spotnana's staging tenant, not production. Because the client trusts response.isTestAccount ?? false alone with no client-side safety net, when that flag doesn't come back true for a team account the client opens production travel.expensify.com while pairing it with a token/TMC combination that actually belongs to the staging tenant. Spotnana's auth/code page then can't validate the mismatched token/tenant pair and renders a blank page instead of completing authentication — exactly what's reported.

The existing domain-based team-account check (already used for exactly this kind of "is this an internal test account" decision) lives here:

App/src/libs/PolicyUtils.ts

Lines 701 to 704 in e40fe0b

	function isExpensifyTeam(email: string | undefined): boolean {
	const emailDomain = Str.extractEmailDomain(email ?? '');
	return emailDomain === CONST.EXPENSIFY_PARTNER_NAME || emailDomain === CONST.EMAIL.GUIDES_DOMAIN;
	}

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

Add a client-side fallback so that team/test accounts are routed to the staging Travel Dot even if the backend response omits or misreports isTestAccount, instead of silently defaulting to production. Reuse the existing isExpensifyTeam domain check (already exported from PolicyUtils) rather than adding a new helper.

In src/libs/actions/Link.ts, import isExpensifyTeam from @libs/PolicyUtils and the current user's login (e.g. via the existing session selector already used in this flow), then OR it into the isTestAccount value passed to buildTravelDotURL at line 141:

const travelURL = buildTravelDotURL(response.spotnanaToken, (response.isTestAccount ?? false) || isExpensifyTeam(currentUserEmail), postLoginPath);

This way, whenever the logged-in account's domain is @team.expensify.com (or @expensify.com, per the existing isExpensifyTeam definition), the app always builds the URL against STAGING_TRAVEL_DOT_URL / STAGING_SPOTNANA_TMC_ID, keeping the domain and the token's issuing tenant consistent regardless of what the backend response reports, which resolves the blank auth page for these accounts.

[mukhrr]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-24 23:05:19 UTC.

Proposal

What is the root cause of that problem?

Problem: When a generated Spotnana authentication code contains URL-reserved characters such as +, the code is altered while parsing the Travel URL, preventing the user from being authenticated.

I found that buildTravelDotURL() interpolates spotnanaToken directly into the query string without encoding it. A + is interpreted as a space in query parameters, so Travel receives a different authentication code and leaves the /auth/code page blank. The other variable parameter, redirectUrl, is already encoded.

App/src/libs/actions/Link.ts

Lines 104 to 115 in e40fe0b

	function buildTravelDotURL(spotnanaToken: string, isTestAccount: boolean, postLoginPath?: string): string {
	const environmentURL = isTestAccount ? CONST.STAGING_TRAVEL_DOT_URL : CONST.TRAVEL_DOT_URL;
	const tmcID = isTestAccount ? CONST.STAGING_SPOTNANA_TMC_ID : CONST.SPOTNANA_TMC_ID;
	const authCode = `authCode=${spotnanaToken}`;
	const tmcIDParam = `tmcId=${tmcID}`;
	const redirectURL = postLoginPath ? `redirectUrl=${encodeURIComponent(Url.addLeadingForwardSlash(postLoginPath))}` : '';
	const paramsArray = [authCode, tmcIDParam, redirectURL];
	const params = paramsArray.filter(Boolean).join('&');
	const travelDotDomain = addTrailingForwardSlash(environmentURL);
	return `${travelDotDomain}auth/code?${params}`;

The generated token is passed directly from the API response into this URL builder, confirming that no earlier step encodes it.

App/src/libs/actions/Link.ts

Lines 121 to 149 in e40fe0b

	function openTravelDotLink(policyID: OnyxEntry<string>, postLoginPath?: string) {
	if (policyID === null || policyID === undefined) {
	return;
	}
	const parameters: GenerateSpotnanaTokenParams = {
	policyID,
	};
	return new Promise((resolve, reject) => {
	const error = new Error('Failed to generate spotnana token.');
	asyncOpenURL(
	// eslint-disable-next-line rulesdir/no-api-side-effects-method
	API.makeRequestWithSideEffects(SIDE_EFFECT_REQUEST_COMMANDS.GENERATE_SPOTNANA_TOKEN, parameters, {})
	.then((response) => {
	if (!response?.spotnanaToken) {
	reject(error);
	throw error;
	}
	const travelURL = buildTravelDotURL(response.spotnanaToken, response.isTestAccount ?? false, postLoginPath);
	resolve(undefined);
	return travelURL;
	})
	.catch(() => {
	reject(error);
	throw error;
	}),
	(travelDotURL) => travelDotURL ?? '',

Git history shows this has been latent since the Travel URL builder was introduced: the token was interpolated without encoding from its first implementation.

App/src/libs/actions/Link.ts

Lines 68 to 72 in 05a9cc6

	function buildTravelDotURL(spotnanaToken: string): Promise<string> {
	return Environment.getTravelDotEnvironmentURL().then((environmentURL) => {
	const travelDotDomain = Url.addTrailingForwardSlash(environmentURL);
	return `${travelDotDomain}auth/code?authCode=${spotnanaToken}&tmcId=${CONST.SPOTNANA_TMC_ID}`;
	});

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

I think we should encode the authentication code inside buildTravelDotURL() before adding it to the query string:

- const authCode = `authCode=${spotnanaToken}`;
+ const authCode = `authCode=${encodeURIComponent(spotnanaToken)}`;

I would also add focused tests to tests/unit/LinkTest.ts for buildTravelDotURL() using both an ordinary token and one containing characters such as +, &, and =. Parsing the resulting URL should return the original token exactly.

This is safe for existing callers because URL-safe tokens produce the same effective parameter value, while encoded characters are decoded once by Travel’s query parser. Both production and staging URLs, web navigation, native WebView navigation, and post-login redirects use this centralized builder, so no caller-specific changes are needed.

What alternative solutions did you explore? (Optional)

I considered rebuilding the entire query with the existing Url.getUrlWithParams() helper, which also provides proper parameter encoding.

App/src/libs/Url.ts

Lines 136 to 153 in e40fe0b

	* Generate a URL with properly encoded query parameters.
	*
	* @param baseUrl - The base URL.
	* @param params - Object containing key-value pairs for query parameters.
	* @returns A URL string with encoded query parameters.
	*/
	function getUrlWithParams<TBase extends string, TParams extends UrlParams>(baseUrl: TBase, params: TParams): UrlWithParams<TBase> {
	const [path, existingQuery] = baseUrl.split('?', 2);
	const searchParams = new URLSearchParams(existingQuery || '');
	for (const [key, value] of Object.entries(params)) {
	if (value) {
	searchParams.set(key, String(value));
	}
	}
	const queryString = searchParams.toString();
	return (queryString ? `${path}?${queryString}` : path) as UrlWithParams<TBase>;

However, encoding only spotnanaToken is the smaller fix because tmcId is a controlled constant and redirectUrl is already encoded.

[ahmdshrif]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-24 23:09:11 UTC.

Proposal

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

Logging in with a +@team.expensify.com (Expensify staff/test) account and pressing + Create > Book Travel opens a new tab at travel.expensify.com/auth/code?authCode=… that stays permanently blank — the auth code is never redeemed and Travel never loads.

What is the root cause of that problem?

The app resolves which travelDot environment + Spotnana TMC to open from a single optional response field, and collapses "flag missing" to "production". Staff test accounts are provisioned on the staging TMC, so they get sent to production with a code that is only redeemable on staging.

1. Book Travel calls openTravelDotLink(activePolicy?.id) → GenerateSpotnanaToken (params contain only policyID):

   App/src/pages/inbox/sidebar/FABPopoverContent/menuItems/TravelMenuItem.tsx

   Lines 46 to 52 in e40fe0b

   	if (isTravelEnabled) {
   	openTravelDotLink(activePolicy?.id);
   	return;
   	}
   	Navigation.navigate(ROUTES.TRAVEL_MY_TRIPS.getRoute(activePolicy?.id));
   	};

2. The environment pick is response.isTestAccount ?? false:

   App/src/libs/actions/Link.ts

   Line 141 in e40fe0b

   const travelURL = buildTravelDotURL(response.spotnanaToken, response.isTestAccount ?? false, postLoginPath);

   — isTestAccount is optional on the response type, so when it is absent the app silently assumes production.
3. buildTravelDotURL then hard-selects production travel.expensify.com + production tmcId from that boolean:

   App/src/libs/actions/Link.ts

   Lines 104 to 116 in e40fe0b

   	function buildTravelDotURL(spotnanaToken: string, isTestAccount: boolean, postLoginPath?: string): string {
   	const environmentURL = isTestAccount ? CONST.STAGING_TRAVEL_DOT_URL : CONST.TRAVEL_DOT_URL;
   	const tmcID = isTestAccount ? CONST.STAGING_SPOTNANA_TMC_ID : CONST.SPOTNANA_TMC_ID;
   	const authCode = `authCode=${spotnanaToken}`;
   	const tmcIDParam = `tmcId=${tmcID}`;
   	const redirectURL = postLoginPath ? `redirectUrl=${encodeURIComponent(Url.addLeadingForwardSlash(postLoginPath))}` : '';
   	const paramsArray = [authCode, tmcIDParam, redirectURL];
   	const params = paramsArray.filter(Boolean).join('&');
   	const travelDotDomain = addTrailingForwardSlash(environmentURL);
   	return `${travelDotDomain}auth/code?${params}`;
   	}

4. Test accounts (staff/QA domains) live on the staging TMC — that is the entire reason STAGING_TRAVEL_DOT_URL/STAGING_SPOTNANA_TMC_ID exist (

   App/src/CONST/index.ts

   Lines 5866 to 5871 in e40fe0b

   	TRAVEL_DOT_URL: 'https://travel.expensify.com',
   	STAGING_TRAVEL_DOT_URL: 'https://staging.travel.expensify.com',
   	TRIP_ID_PATH: (tripID?: string) => (tripID ? `trips/${tripID}` : undefined),
   	TRIP_SUPPORT: '/support',
   	SPOTNANA_TMC_ID: '8e8e7258-1cf3-48c0-9cd1-fe78a6e31eed',
   	STAGING_SPOTNANA_TMC_ID: '7a290c6e-5328-4107-aff6-e48765845b81',

   ). Production Spotnana cannot redeem an auth code for a traveler that exists on the staging TMC, so its /auth/code SPA silently renders nothing — exactly the screenshot: production domain, full hex authCode, blank page. (The token is plain hex, so this is not a URL-encoding problem.)
5. Structural cause: PR Open Spotnana URL based on isTestAccount from response #56431`` / #57036 ("Open Spotnana URL based on isTestAccount from response") deleted the app's per-account fallback — the `Onyx.connect` on `nvp_travelSettings.testAccount` ("Whether the user is setup for staging travelDot"). That NVP is still synced and still in the Onyx model (

   App/src/types/onyx/TravelSettings.ts

   Lines 9 to 10 in e40fe0b

   	/** Whether the user is setup for staging travelDot */
   	testAccount?: boolean;

   ) but now has zero readers. So for staging-provisioned accounts where this response path doesn't carry the flag, "unknown" degrades to production instead of to the account's known environment.

The same collapse is replicated at every open-travel path:

• Web token path:

  App/src/libs/actions/Link.ts

  Line 141 in e40fe0b

  const travelURL = buildTravelDotURL(response.spotnanaToken, response.isTestAccount ?? false, postLoginPath);

• Web wrapper (isTestAccount ?? false):

  App/src/libs/openTravelDotLink/index.ts

  Lines 7 to 9 in e40fe0b

  	const openTravelDotLink = (activePolicyID?: string, postLoginPath?: string, spotnanaToken?: string, isTestAccount?: boolean) => {
  	if (spotnanaToken) {
  	asyncOpenURL(Promise.resolve(), () => buildTravelDotURL(spotnanaToken, isTestAccount ?? false, postLoginPath));

• Accept-terms flow (response.isTestAccount ?? false):

  App/src/pages/Travel/DynamicTravelTerms.tsx

  Line 140 in e40fe0b

  openTravelDotLink(policyID, undefined, response.spotnanaToken, response.isTestAccount ?? false);

• Native: the flag is stringified into the route (isTestAccount=${isTestAccount} → "undefined"), then parsed with isTestAccount === 'true' → false:

  App/src/ROUTES.ts

  Lines 3428 to 3434 in e40fe0b

  	TRAVEL_DOT_LINK_WEB_VIEW: {
  	route: 'travel-dot-link',
  	getRoute: (token: string, isTestAccount?: boolean, postLoginPath?: string) => {
  	const redirectURL = postLoginPath ? `&redirectUrl=${encodeURIComponent(postLoginPath)}` : '';
  	return `travel-dot-link?token=${token}&isTestAccount=${isTestAccount}${redirectURL}` as const;
  	},
  	},

  and

  App/src/pages/Travel/TravelDotLinkWebview.tsx

  Lines 21 to 25 in e40fe0b

  	const {token, isTestAccount, redirectUrl} = route.params;
  	const webViewRef = useRef<WebView>(null);
  	const styles = useThemeStyles();
  	const url = buildTravelDotURL(token, isTestAccount === 'true', redirectUrl);

This explains every symptom detail: only staff +@team.expensify.com aliases break (only they are staging-TMC travelers; customers resolve to production correctly), the tab shows a valid-looking production URL with a full auth code (token minting succeeded — only the environment is wrong), there's no in-app error (the app "succeeded"; the failure happens after redirect on Spotnana's side), and QA marked it "Reproduction blocked" (needs a staff alias).

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

Restore the per-account fallback at the single convergence point, buildTravelDotURL, so "flag absent" resolves from the account's own nvp_travelSettings.testAccount instead of defaulting to production:

let isTravelTestAccount: boolean | undefined;
Onyx.connectWithoutView({
    key: ONYXKEYS.NVP_TRAVEL_SETTINGS,
    callback: (value) => (isTravelTestAccount = value?.testAccount),
});
// buildTravelDotURL(spotnanaToken: string, isTestAccount?: boolean, ...)
const useStagingTravelDot = isTestAccount ?? isTravelTestAccount ?? false;

(mirrors the existing module-level SESSION subscription in the same file:

App/src/libs/actions/Link.ts

Lines 44 to 53 in e40fe0b

	let currentUserEmail = '';
	let currentUserAccountID = -1;
	// Use connectWithoutView since this is to open an external link and doesn't affect any UI
	Onyx.connectWithoutView({
	key: ONYXKEYS.SESSION,
	callback: (value) => {
	currentUserEmail = value?.email ?? '';
	currentUserAccountID = value?.accountID ?? CONST.DEFAULT_NUMBER_ID;
	},
	});

). Then make the call sites pass the flag through without the premature ?? false: Link.ts#L141, openTravelDotLink/index.ts#L7-L9, DynamicTravelTerms.tsx#L140; on native, keep the tri-state through the route param and parse 'true'/'false'/else → undefined in TravelDotLinkWebview.tsx#L25 so the fallback still applies inside buildTravelDotURL. One line of note: the true source is the backend flag for this account/alias, but this client fallback is the mergeable fix that restores access either way.

Regression safety in one sentence: ?? fires only when the response omits the flag — whenever the backend supplies isTestAccount (true or false) behavior is byte-identical, and non-test accounts have no testAccount NVP so they still resolve to production.

Why the obvious spot fix fails: patching only Link.ts#L141 leaves the identical ?? false collapse live at DynamicTravelTerms.tsx#L140 (the accept-terms → open flow), openTravelDotLink/index.ts#L9, and the native route-param stringification ("undefined" !== 'true' → false) — the same account still lands on the wrong TMC right after accepting terms and on every native open, which is why the fallback must live inside buildTravelDotURL, the one function all four paths funnel through.

What alternative solutions did you explore? (Optional)

1. encodeURIComponent(spotnanaToken) in the authCode param — refuted: the screenshot token is plain hex (URL-safe), so encoding is not the mechanism; this spot fix changes nothing for these accounts.
2. Client-side domain heuristic — fall back to isExpensifyTeam(currentUserEmail) (PolicyUtils.ts#L701-L704) when the flag is absent. Over-broad: it would force every @expensify`.com`/@team.expensify.com login to staging travel even when the backend intentionally provisions them on production; the NVP is the backend-set per-account truth, so it is the safer signal.
3. Backend-only fix (always return isTestAccount from GenerateSpotnanaToken for aliased team logins) — addresses the source but isn't mergeable by an external contributor; the client fallback above fixes access now and stays correct after any backend change.

[lorretheboy]

Proposal

What is the root cause of that problem?

The Spotnana authorization code returned by GenerateSpotnanaToken embeds the user's identity, so for accounts with a + in the email (e.g. name+test@team.expensify.com) the token contains a literal + (and can contain other URL-reserved characters). buildTravelDotURL concatenates that token into the query string raw, without URL-encoding:

App/src/libs/actions/Link.ts

Line 108 in e40fe0b

const authCode = `authCode=${spotnanaToken}`;

Note the asymmetry with redirectUrl right below it, which is encoded. In a query string a + is decoded as a space, so travel.expensify.com receives a corrupted authCode at /auth/code, the code exchange fails, and the tab stays blank.

The native path has the same defect one step earlier — the raw token is also interpolated into the internal route, before it even reaches buildTravelDotURL:

App/src/ROUTES.ts

Lines 3428 to 3433 in e40fe0b

	TRAVEL_DOT_LINK_WEB_VIEW: {
	route: 'travel-dot-link',
	getRoute: (token: string, isTestAccount?: boolean, postLoginPath?: string) => {
	const redirectURL = postLoginPath ? `&redirectUrl=${encodeURIComponent(postLoginPath)}` : '';
	return `travel-dot-link?token=${token}&isTestAccount=${isTestAccount}${redirectURL}` as const;
	},

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

Encode the token at the single convergence point that every travel entry (web openTravelDotLink, DynamicTravelTerms, and the native TravelDotLinkWebview) flows through — the authCode param in buildTravelDotURL:

const authCode = `authCode=${encodeURIComponent(spotnanaToken)}`;

And apply the same encoding to the token param in ROUTES.TRAVEL_DOT_LINK_WEB_VIEW.getRoute so the token survives the internal navigation on native (React Navigation decodes the param before TravelDotLinkWebview rebuilds the URL, so it won't be double-encoded).

What alternative solutions did you explore? (Optional)

Encoding at each caller (Link.ts, openTravelDotLink/index.ts, TravelDotLinkWebview) — rejected, since fixing the shared builder covers all of them and avoids double-encoding mistakes. The backend could also return a URL-safe token, but the client should not assume that.

[wildan-m]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-24 23:11:29 UTC.

Proposal

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

When signed in to New Expensify with a +@team.expensify.com account and choosing + Create → Book Travel, a new tab opens on travel.expensify.com/auth/code?... and stays blank — Expensify Travel never authenticates or loads.

What is the root cause of that problem?

Internal @team.expensify.com accounts are provisioned against Spotnana's sandbox/staging environment, not production. Which Travel environment we send the user to is decided entirely by the isTestAccount flag in the GenerateSpotnanaToken response, and that flag is optional on the response type:

App/src/types/onyx/Response.ts

Lines 75 to 76 in 7cb1068

	/** Whether the account is set for testing Travel and should use the sandbox environment */
	isTestAccount?: boolean;

openTravelDotLink reads it and coalesces a missing value straight to false:

App/src/libs/actions/Link.ts

Lines 136 to 144 in 7cb1068

	.then((response) => {
	if (!response?.spotnanaToken) {
	reject(error);
	throw error;
	}
	const travelURL = buildTravelDotURL(response.spotnanaToken, response.isTestAccount ?? false, postLoginPath);
	resolve(undefined);
	return travelURL;
	})

buildTravelDotURL then uses that single boolean to pick both the domain and the TMC ID:

App/src/libs/actions/Link.ts

Lines 104 to 116 in 7cb1068

	function buildTravelDotURL(spotnanaToken: string, isTestAccount: boolean, postLoginPath?: string): string {
	const environmentURL = isTestAccount ? CONST.STAGING_TRAVEL_DOT_URL : CONST.TRAVEL_DOT_URL;
	const tmcID = isTestAccount ? CONST.STAGING_SPOTNANA_TMC_ID : CONST.SPOTNANA_TMC_ID;
	const authCode = `authCode=${spotnanaToken}`;
	const tmcIDParam = `tmcId=${tmcID}`;
	const redirectURL = postLoginPath ? `redirectUrl=${encodeURIComponent(Url.addLeadingForwardSlash(postLoginPath))}` : '';
	const paramsArray = [authCode, tmcIDParam, redirectURL];
	const params = paramsArray.filter(Boolean).join('&');
	const travelDotDomain = addTrailingForwardSlash(environmentURL);
	return `${travelDotDomain}auth/code?${params}`;
	}

So when the response does not carry isTestAccount for these accounts, ?? false silently classifies a sandbox-provisioned user as a production user. We build the link with the production domain (https://travel.expensify.com) and the production TMC ID, but the authCode we hand over was minted in Spotnana's sandbox. Travel cannot resolve that auth code against the production tenant, so /auth/code never completes the exchange and renders a blank page — exactly the symptom and exactly the URL in the report.

There is a second, independent source of truth for this that the app already stores but no longer consults: the testAccount field on the nvp_travelSettings NVP, documented as "Whether the user is setup for staging travelDot":

App/src/types/onyx/TravelSettings.ts

Lines 9 to 10 in 7cb1068

	/** Whether the user is setup for staging travelDot */
	testAccount?: boolean;

That NVP used to be the value driving the environment choice — buildTravelDotURL subscribed to it directly. It was removed in favour of the response flag in commit 2fa435401db ("new isTestAccount when building travel url"), and since then nothing in src/ reads travelSettings.testAccount at all. The removal left the app with no fallback whenever the response omits the flag, which is what breaks these internal accounts.

The same defaulting mistake is repeated on the native path, where an absent flag is stringified into the route and compared against 'true', again yielding production:

App/src/ROUTES.ts

Lines 3428 to 3434 in 7cb1068

	TRAVEL_DOT_LINK_WEB_VIEW: {
	route: 'travel-dot-link',
	getRoute: (token: string, isTestAccount?: boolean, postLoginPath?: string) => {
	const redirectURL = postLoginPath ? `&redirectUrl=${encodeURIComponent(postLoginPath)}` : '';
	return `travel-dot-link?token=${token}&isTestAccount=${isTestAccount}${redirectURL}` as const;
	},
	},

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

Stop treating "the response didn't tell us" as "this is a production account", and restore the stored NVP as the fallback signal.

1. In src/libs/actions/Link.ts, re-subscribe to the nvp_travelSettings Onyx key and keep the user's testAccount value in a module-level variable, the way the file did before commit 2fa435401db (this file already uses that module-variable subscription pattern, via Onyx.connectWithoutView, for the session).

2. Where the Travel link is built after GenerateSpotnanaToken resolves, resolve the environment as "the response flag when the response actually provided one, otherwise the stored travelSettings.testAccount value". Concretely, replace the response.isTestAccount ?? false coalescing with a coalescing onto the NVP-backed variable, so a missing flag falls back to what we know about the account instead of silently defaulting to production.

3. Apply the same fallback at every remaining call site that currently hard-defaults to false / undefined, so all entry points pick the same environment: both openTravelDotLink wrappers in src/libs/openTravelDotLink/ (web and native), and the accept-terms flow in src/pages/Travel/DynamicTravelTerms.tsx, which should hand the raw flag to the wrapper instead of pre-collapsing it to false. On native this also means ROUTES.TRAVEL_DOT_LINK_WEB_VIEW.getRoute receives a resolved boolean rather than a possibly-undefined one (today undefined is interpolated into the query string as the literal text undefined, which then fails the === 'true' check in TravelDotLinkWebview and lands on production too).

The result is that a sandbox-provisioned @team.expensify.com user is sent to https://staging.travel.expensify.com/auth/code with the staging TMC ID, matching the environment their authCode was issued for, and the page authenticates instead of rendering blank. Production users are unaffected — their NVP value is falsy, so the resolved value stays false exactly as today.

Compare branch: https://github.com/Expensify/App/compare/main...wildan-m:App:wildan/97012-travel-test-account-fallback?expand=1

What alternative solutions did you explore? (Optional)

• Derive the environment from the signed-in email domain (treat any @team.expensify.com login as a test account). Rejected: it hardcodes an internal domain into the client, and it would be wrong for team members whose Travel account genuinely lives in production. The NVP already records the real provisioning state, so it is the correct signal.

• Fail loudly instead of guessing — block the redirect and surface an error when isTestAccount is absent. This turns a blank page into a readable message, but it does not let internal accounts book travel, so it addresses the symptom rather than the cause. It could be layered on later as a safety net.

• Treat a missing flag as true (default to staging instead of production). Rejected as strictly worse: it would break real customers whenever the field is momentarily missing, trading an internal-account bug for a production one.

[melvin-bot]

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

[godzillaxbox19982014-lgtm]

Proposal

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

Unable to access Expensify Travel from New Expensify when logged in with a +@team.expensify.com account

What is the root cause of that problem?

I traced this to the path that handles unable, access, travel:

• src/pages/workspace/accounting/common/TravelInvoicingContinuousReconciliationSection.tsx:53 (travelInvoicingReconciliationBankAccount): const travelInvoicingReconciliationBankAccount = getConnectionBankAccountsForReconciliation(policy?.connections, connectionName).find(
• src/pages/workspace/accounting/common/TravelInvoicingContinuousReconciliationSection.tsx:91 (navigateToTravelInvoicingReconciliationAccountSettings): onPress={navigateToTravelInvoicingReconciliationAccountSettings}
• src/pages/workspace/accounting/common/TravelInvoicingContinuousReconciliationSection.tsx:92 (TravelInvoicingContinuousReconciliationSection): title={travelInvoicingReconciliationBankAccount?.name}
• src/pages/workspace/accounting/intacct/export/DynamicSageIntacctTravelInvoicingConfigurationPage.tsx:29 (travelPayableAccount): const travelPayableAccount = policy?.connections?.intacct?.data?.creditCards?.find((account) => account.name === config?.export?.travelInvoicingPayableAccountID);
• src/pages/workspace/accounting/common/TravelInvoicingContinuousReconciliationSection.tsx:53 is the first concrete decision that matches unable, access, travel, and src/pages/workspace/accounting/common/TravelInvoicingContinuousReconciliationSection.tsx:91 is the next matching consumer/mutation. The failing behavior is introduced at this handoff: the second path does not preserve the condition/state established by the first path for the repro case.

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

• Change the issue-matching decision at src/pages/workspace/accounting/common/TravelInvoicingContinuousReconciliationSection.tsx:53 so the unable, access, travel repro state is represented before src/pages/workspace/accounting/common/TravelInvoicingContinuousReconciliationSection.tsx:91 consumes it.
• Keep the patch at this first decision/consumer boundary (map the API error to the user-facing translation at the action boundary) instead of masking the downstream UI symptom.
• Keep the change inside the Auth, Login, Onboarding, Account Details surface and avoid changing account/login flows, auth tokens.

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

1. Add or update a regression in tests/unit/Session*.ts for the exact issue flow: Unable to access Expensify Travel from New Expensify when logged in with a +@team.expensify.com account.
2. Cover the counter-case near src/pages/workspace/accounting/common/TravelInvoicingContinuousReconciliationSection.tsx:53 so valid existing unable, access, travel behavior still works.
3. Manually repeat the issue steps after the patch and confirm the visible state/action is no longer stale.

What alternative solutions did you explore? (Optional)

• I would not add a broad new condition outside these referenced paths; the safer fix is to keep unable, access, travel consistent at the first read/write boundary shown above.