[$250] Expensify Card - Not here page opens after clicking Learn more in Settlement frequency

[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: 9.4.42-0
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/test-runs/65766458/folder/13176890/41237383/1590695395?sort=-identifier
Email or phone of affected tester (no customers): applausetester+ssndjois2jd1@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Mac 26.5 / Chrome
App Component: Workspace Settings

Action Performed:

Precondition:

• Workspace is set up with Expensify Card feature.

1. Go to staging.new.expensify.com
2. Go to workspace settings > Expensify Card.
3. Click Settings.
4. Click Learn more.

Expected Result:

Article site will open.

Actual Result:

Not here page opens after clicking Learn more in Settlement frequency.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7214471_1784725676768.2.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7214471

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022079925009216510609
• Upwork Job ID: 2079925009216510609
• Last Price Increase: 2026-07-22

[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/3733f594113b805256969d15777b7f30481692e4719fd2c4d47c3a8f51f3b750

[MelvinBot]

Proposal

What is the root cause of that problem?

The "Learn more" link under Settlement frequency points to a help article URL that no longer exists, so the help site returns its 404 ("Not here") page.

The link uses the MANAGE_EXPENSIFY_CARDS_ARTICLE_LINK constant, which is https://help.expensify.com/articles/new-expensify/expensify-card/Manage-Expensify-Cards — a 404.

That article was split into two locale-specific articles (Set-Up-and-Manage-the-Expensify-Card-US and -UK-EU), and the Manage-Expensify-Cards path was retired. The redirects.csv entry meant to cover the old path is also broken — it redirects to Set-Up-and-Manage-the-Expensify-Card (no -US/-UK-EU suffix), which is itself a 404. So both the direct link and its redirect dead-end on the "Not here" page.

Evidence

• Broken link definition: src/CONST/index.ts:4630
• Only usage (the "Learn more" link in the settlement-frequency info): WorkspaceCardSettingsPage.tsx:98
• Broken redirect: docs/redirects.csv:861

HTTP checks:

Manage-Expensify-Cards                     → 404 (linked URL)
…redirects to Set-Up-and-Manage-the-Expensify-Card → 404 (redirect target also dead)
Set-Up-and-Manage-the-Expensify-Card-US    → 200 ✅
Set-Up-and-Manage-the-Expensify-Card-UK-EU → 200 ✅

There is no Manage-Expensify-Cards.md in docs/articles/new-expensify/expensify-card/; the live articles are the -US and -UK-EU files.

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

1. Primary fix (resolves the user-facing symptom): Point MANAGE_EXPENSIFY_CARDS_ARTICLE_LINK at a live article — https://help.expensify.com/articles/new-expensify/expensify-card/Set-Up-and-Manage-the-Expensify-Card-US (returns 200).
2. Fix the stale redirect at docs/redirects.csv:861 so the old Manage-Expensify-Cards path forwards to a real article (e.g. …/Set-Up-and-Manage-the-Expensify-Card-US) instead of the equally-dead Set-Up-and-Manage-the-Expensify-Card. This catches any other places (external links, old bookmarks) still using the old URL.

What alternative solutions did you explore? (Optional)

Because the article is now locale-split (US vs UK/EU), a more thorough option is to choose the article based on the workspace's Expensify Card region rather than hardcoding -US. The single-link fix is the minimal change that removes the 404; region-aware linking can be a follow-up if desired.

Related issues

• [HOLD for payment 2024-11-05] [$250] Expensify Card - Nothing happens after tapping on Learn more button under Settlement frequency #50496 — "Nothing happens after tapping on Learn more button under Settlement frequency" (closed) — same button, earlier bug. Possibly related, not a duplicate.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/96742) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[abbasifaizan70]

Proposal

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

On the Workspace Settings > Expensify Card > Settings page, when the Settlement Frequency is blocked (daily settlement not allowed) and the user clicks the "Learn more" link in the hint text, the article link goes to a HelpDot "Not here" (404) page instead of opening the expected help article.

What is the root cause of that problem?

The "Learn more" link's href is hard-coded to CONST.EXPENSIFY_CARD.MANAGE_EXPENSIFY_CARDS_ARTICLE_LINK:

App/src/pages/workspace/expensifyCard/WorkspaceCardSettingsPage.tsx

Lines 93 to 106 in 046d450

	hintText={
	isSettlementFrequencyBlocked ? (
	<>
	{translate('workspace.expensifyCard.settlementFrequencyInfo')}{' '}
	<TextLink
	href={CONST.EXPENSIFY_CARD.MANAGE_EXPENSIFY_CARDS_ARTICLE_LINK}
	style={styles.label}
	>
	{translate('common.learnMore')}
	</TextLink>
	.
	</>
	) : undefined
	}

That constant points to a HelpDot article slug, Manage-Expensify-Cards, that no longer exists:

App/src/CONST/index.ts

Line 4630 in 046d450

MANAGE_EXPENSIFY_CARDS_ARTICLE_LINK: 'https://help.expensify.com/articles/new-expensify/expensify-card/Manage-Expensify-Cards',

The article was renamed/split. There is no Manage-Expensify-Cards.md file under docs/articles/new-expensify/expensify-card/ anymore — the content now lives in Set-Up-and-Manage-the-Expensify-Card-US.md (and a UK/EU variant). This is confirmed by the docs/redirects.csv chain, which shows the old slug being redirected twice before landing on the current article:

Manage-Expensify-Cards -> Set-Up-and-Manage-the-Expensify-Card -> Set-Up-and-Manage-the-Expensify-Card-US

Relying on a two-hop redirect chain for a hard-coded in-app link is fragile — since HelpDot's redirect handling isn't guaranteeing that chain resolves for all users/environments, the request is landing on the "Not here" page instead of the article. The fix is to point the app directly at the current, valid article slug instead of the stale one.

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

Update the constant so it points straight to the existing, current article instead of a slug that requires chained redirects:

App/src/CONST/index.ts

Line 4630 in 046d450

MANAGE_EXPENSIFY_CARDS_ARTICLE_LINK: 'https://help.expensify.com/articles/new-expensify/expensify-card/Manage-Expensify-Cards',

MANAGE_EXPENSIFY_CARDS_ARTICLE_LINK: 'https://help.expensify.com/articles/new-expensify/expensify-card/Set-Up-and-Manage-the-Expensify-Card-US',

No changes are needed in WorkspaceCardSettingsPage.tsx since it already consumes the constant via CONST.EXPENSIFY_CARD.MANAGE_EXPENSIFY_CARDS_ARTICLE_LINK — updating the single source of truth fixes every usage of this link across the app.

[dilshodmackbook-sketch]

Proposal

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

On Workspace Settings > Expensify Card > Settings, when the settlement-frequency row is blocked, clicking the Learn more link opens the help site's "Not here" page instead of the article.

What is the root cause of that problem?

The Learn more link's href is hard-coded to CONST.EXPENSIFY_CARD.MANAGE_EXPENSIFY_CARDS_ARTICLE_LINK:

App/src/pages/workspace/expensifyCard/WorkspaceCardSettingsPage.tsx

Lines 93 to 106 in c88326a

	hintText={
	isSettlementFrequencyBlocked ? (
	<>
	{translate('workspace.expensifyCard.settlementFrequencyInfo')}{' '}
	<TextLink
	href={CONST.EXPENSIFY_CARD.MANAGE_EXPENSIFY_CARDS_ARTICLE_LINK}
	style={styles.label}
	>
	{translate('common.learnMore')}
	</TextLink>
	.
	</>
	) : undefined
	}

and that constant still points at the retired Manage-Expensify-Cards slug:

App/src/CONST/index.ts

Line 4619 in c88326a

MANAGE_EXPENSIFY_CARDS_ARTICLE_LINK: 'https://help.expensify.com/articles/new-expensify/expensify-card/Manage-Expensify-Cards',

There is no Manage-Expensify-Cards.md under docs/articles/new-expensify/expensify-card/ anymore — the article was renamed to Set-Up-and-Manage-the-Expensify-Card, and the old path only survives through a redirect:

App/docs/redirects.csv

Line 861 in c88326a

https://help.expensify.com/articles/new-expensify/expensify-card/Manage-Expensify-Cards,https://help.expensify.com/articles/new-expensify/expensify-card/Set-Up-and-Manage-the-Expensify-Card

So the App links to a slug that no longer exists and leans on the help-site redirect to resolve it. HelpDot is a client-rendered SPA: it serves the shell for any path and decides in the browser whether the requested article exists. When the redirect doesn't take effect for this path (stale CDN redirect cache, the native in-app browser not following the 301, or before the redirect was deployed), the retired slug has no article and the SPA renders its client-side "Not here" page — which is what the tester hits, on every platform, because it's purely a URL problem and not tied to any app logic.

I verified the destination: the current article Set-Up-and-Manage-the-Expensify-Card is live and renders a full article (heading "Set Up and Manage the Expensify Card", it covers the settlement-frequency content), so the fix is simply to link to it directly instead of routing users through a redirect off a dead slug.

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

Point the constant straight at the live article so the link never depends on a redirect:

MANAGE_EXPENSIFY_CARDS_ARTICLE_LINK: 'https://help.expensify.com/articles/new-expensify/expensify-card/Set-Up-and-Manage-the-Expensify-Card',

No component change is needed — WorkspaceCardSettingsPage (the only consumer of this constant) picks up the corrected destination automatically, and the settlement-frequency Learn more opens the live article on every platform.

It's also worth flattening the docs/redirects.csv entry so the old Manage-Expensify-Cards path forwards to the same live article for anyone still hitting the old URL (older app versions, external links).

What alternative solutions did you explore? (Optional)

• Region-split link. The site also publishes Set-Up-and-Manage-the-Expensify-Card-US and Set-Up-and-Manage-the-Expensify-Card-UK-EU variants, and the page already derives isUSProgram (

  App/src/pages/workspace/expensifyCard/WorkspaceCardSettingsPage.tsx

  Line 48 in c88326a

  const isUSProgram = programKey === CONST.COUNTRY.US || programKey === CONST.EXPENSIFY_CARD.CARD_PROGRAM.CURRENT;

  ), so the link could be chosen per card program. I didn't go with this because Set-Up-and-Manage-the-Expensify-Card is the single canonical article file in docs/ and renders full content for both regions, so one link is simpler and avoids embedding region logic into a help link — the split can be a follow-up if the docs team confirms the region variants are the intended landing pages.
• Fix only the redirect and leave the constant. That would patch the symptom, but the App shouldn't rely on a redirect to reach a first-party help page that was renamed long ago; pointing at the canonical URL removes the dependency entirely.

[samranahm]

Proposal

What is the root cause of that problem?

When a user opens workspace settings, then Expensify Card, then Settings, and clicks "Learn more" under Settlement frequency, NewDot navigates to a route that has no matching screen, so the router falls through and renders the generic Not Here page.

NotFoundPage is exactly what the user sees, and it only knows how to send them back to Home once it is already shown:

App/src/pages/ErrorPage/NotFoundPage.tsx

Lines 24 to 60 in 532794c

	function NotFoundPage({onBackButtonPress = () => Navigation.goBack(), isReportRelatedPage, shouldShowOfflineIndicator, ...fullPageNotFoundViewProps}: NotFoundPageProps) {
	// We need to use isSmallScreenWidth instead of shouldUseNarrowLayout to go back to the not found page on large screens and to the home page on small screen
	// eslint-disable-next-line rulesdir/prefer-shouldUseNarrowLayout-instead-of-isSmallScreenWidth
	const {isSmallScreenWidth} = useResponsiveLayout();
	const topmostReportId = Navigation.getTopmostReportId();
	const [report] = useOnyx(`${ONYXKEYS.COLLECTION.REPORT}${topmostReportId}`);
	const route = useRoute();
	const isOnGenericErrorScreen = route.name === SCREENS.NOT_FOUND;
	useAbsentPageSpan();
	return (
	<ScreenWrapper
	testID="NotFoundPage"
	shouldShowOfflineIndicator={shouldShowOfflineIndicator}
	>
	<FullPageNotFoundView
	shouldShow
	onBackButtonPress={() => {
	if (!isReportRelatedPage || !isSmallScreenWidth) {
	onBackButtonPress();
	return;
	}
	// detect the report is invalid
	if (topmostReportId && (!report || report.errorFields?.notFound)) {
	Navigation.dismissModal();
	return;
	}
	onBackButtonPress();
	}}
	{...fullPageNotFoundViewProps}
	onLinkPress={isOnGenericErrorScreen ? () => Navigation.goBack(ROUTES.HOME) : fullPageNotFoundViewProps.onLinkPress}
	/>
	</ScreenWrapper>
	);
	}

The "Learn more" affordance in the Settlement frequency settings is expected to open an external help article, but it is currently resolving as an internal in-app route instead of an absolute https://help.expensify.com URL. The Expensify Card settlement settings live alongside the settlement account picker in SettlementAccountSelector and the surrounding card settings page:

App/src/components/SettlementAccountSelector.tsx

Lines 62 to 114 in 532794c

	function SettlementAccountSelector({
	listOptions,
	onSelectAccount,
	onAddNewBankAccount,
	showAddNewAccountOption = false,
	customHeaderContent,
	initiallyFocusedItemKey,
	}: SettlementAccountSelectorProps) {
	const styles = useThemeStyles();
	const {translate} = useLocalize();
	const icons = useMemoizedLazyExpensifyIcons(['Plus']);
	const handleSelectRow = ({value}: BankAccountListItem) => {
	onSelectAccount(value ?? 0);
	};
	// Render "Add new bank account" as list footer when enabled
	const listFooterContent =
	showAddNewAccountOption && onAddNewBankAccount ? (
	<MenuItem
	icon={icons.Plus}
	title={translate('workspace.expensifyCard.addNewBankAccount')}
	onPress={onAddNewBankAccount}
	/>
	) : undefined;
	// If no list options and we should show add new account, just show the menu item
	if (listOptions.length === 0 && showAddNewAccountOption && onAddNewBankAccount) {
	return (
	<View style={styles.flex1}>
	{customHeaderContent}
	<MenuItem
	icon={icons.Plus}
	title={translate('workspace.expensifyCard.addNewBankAccount')}
	onPress={onAddNewBankAccount}
	/>
	</View>
	);
	}
	return (
	<SelectionList
	addBottomSafeAreaPadding
	data={listOptions}
	ListItem={SingleSelectListItem}
	onSelectRow={handleSelectRow}
	shouldSingleExecuteRowSelect
	initiallyFocusedItemKey={initiallyFocusedItemKey}
	customListHeaderContent={customHeaderContent}
	listFooterContent={listFooterContent}
	/>
	);
	}

Because the "Learn more" link value is not a valid absolute external URL (it is being treated as an app path with no registered screen), the navigator cannot match it and hands off to the NOT_FOUND screen, which is why the Not Here page appears on all listed platforms.

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

1. In the Expensify Card Settings screen that renders the Settlement frequency section (the same area that hosts SettlementAccountSelector), the "Learn more" link must open the help article as an external link rather than route in-app.

App/src/components/SettlementAccountSelector.tsx

Lines 62 to 114 in 532794c

	function SettlementAccountSelector({
	listOptions,
	onSelectAccount,
	onAddNewBankAccount,
	showAddNewAccountOption = false,
	customHeaderContent,
	initiallyFocusedItemKey,
	}: SettlementAccountSelectorProps) {
	const styles = useThemeStyles();
	const {translate} = useLocalize();
	const icons = useMemoizedLazyExpensifyIcons(['Plus']);
	const handleSelectRow = ({value}: BankAccountListItem) => {
	onSelectAccount(value ?? 0);
	};
	// Render "Add new bank account" as list footer when enabled
	const listFooterContent =
	showAddNewAccountOption && onAddNewBankAccount ? (
	<MenuItem
	icon={icons.Plus}
	title={translate('workspace.expensifyCard.addNewBankAccount')}
	onPress={onAddNewBankAccount}
	/>
	) : undefined;
	// If no list options and we should show add new account, just show the menu item
	if (listOptions.length === 0 && showAddNewAccountOption && onAddNewBankAccount) {
	return (
	<View style={styles.flex1}>
	{customHeaderContent}
	<MenuItem
	icon={icons.Plus}
	title={translate('workspace.expensifyCard.addNewBankAccount')}
	onPress={onAddNewBankAccount}
	/>
	</View>
	);
	}
	return (
	<SelectionList
	addBottomSafeAreaPadding
	data={listOptions}
	ListItem={SingleSelectListItem}
	onSelectRow={handleSelectRow}
	shouldSingleExecuteRowSelect
	initiallyFocusedItemKey={initiallyFocusedItemKey}
	customListHeaderContent={customHeaderContent}
	listFooterContent={listFooterContent}
	/>
	);
	}

Point the "Learn more" text at the absolute help article URL and open it externally so the router never tries to match it as a screen:

<TextLink href={CONST.SETTLEMENT_FREQUENCY_HELP_URL}>
    {translate('common.learnMore')}
</TextLink>

Use a full https://help.expensify.com/... value for that constant so TextLink opens it in the browser instead of dispatching an in-app navigation.

2. Since the failure ends on NotFoundPage, confirm the fix by verifying the click no longer reaches the NOT_FOUND screen:

App/src/pages/ErrorPage/NotFoundPage.tsx

Lines 24 to 60 in 532794c

	function NotFoundPage({onBackButtonPress = () => Navigation.goBack(), isReportRelatedPage, shouldShowOfflineIndicator, ...fullPageNotFoundViewProps}: NotFoundPageProps) {
	// We need to use isSmallScreenWidth instead of shouldUseNarrowLayout to go back to the not found page on large screens and to the home page on small screen
	// eslint-disable-next-line rulesdir/prefer-shouldUseNarrowLayout-instead-of-isSmallScreenWidth
	const {isSmallScreenWidth} = useResponsiveLayout();
	const topmostReportId = Navigation.getTopmostReportId();
	const [report] = useOnyx(`${ONYXKEYS.COLLECTION.REPORT}${topmostReportId}`);
	const route = useRoute();
	const isOnGenericErrorScreen = route.name === SCREENS.NOT_FOUND;
	useAbsentPageSpan();
	return (
	<ScreenWrapper
	testID="NotFoundPage"
	shouldShowOfflineIndicator={shouldShowOfflineIndicator}
	>
	<FullPageNotFoundView
	shouldShow
	onBackButtonPress={() => {
	if (!isReportRelatedPage || !isSmallScreenWidth) {
	onBackButtonPress();
	return;
	}
	// detect the report is invalid
	if (topmostReportId && (!report || report.errorFields?.notFound)) {
	Navigation.dismissModal();
	return;
	}
	onBackButtonPress();
	}}
	{...fullPageNotFoundViewProps}
	onLinkPress={isOnGenericErrorScreen ? () => Navigation.goBack(ROUTES.HOME) : fullPageNotFoundViewProps.onLinkPress}
	/>
	</ScreenWrapper>
	);
	}

Once the link uses an absolute external URL, the navigator no longer attempts to resolve it as a screen, the article opens, and the Not Here page is no longer shown.

What alternative solutions did you explore? (Optional)

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

[melvin-bot]

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

[wildan-m]

Proposal

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

On the workspace Expensify Card settings page, the Settlement frequency row shows a hint with a Learn more link. Clicking it opens the HelpDot "Not here" (404) page instead of the intended help article.

What is the root cause of that problem?

The Learn more link points at a help article slug that no longer exists.

The hint is rendered here, and its href is CONST.EXPENSIFY_CARD.MANAGE_EXPENSIFY_CARDS_ARTICLE_LINK:

App/src/pages/workspace/expensifyCard/WorkspaceCardSettingsPage.tsx

Lines 93 to 106 in e9dfff4

	hintText={
	isSettlementFrequencyBlocked ? (
	<>
	{translate('workspace.expensifyCard.settlementFrequencyInfo')}{' '}
	<TextLink
	href={CONST.EXPENSIFY_CARD.MANAGE_EXPENSIFY_CARDS_ARTICLE_LINK}
	style={styles.label}
	>
	{translate('common.learnMore')}
	</TextLink>
	.
	</>
	) : undefined
	}

That constant is:

App/src/CONST/index.ts

Line 4630 in e9dfff4

MANAGE_EXPENSIFY_CARDS_ARTICLE_LINK: 'https://help.expensify.com/articles/new-expensify/expensify-card/Manage-Expensify-Cards',

There is no Manage-Expensify-Cards.md under docs/articles/new-expensify/expensify-card/ anymore — the article was renamed, and the URL now depends on a redirect. But the redirect list contains a two-hop chain, and only the first hop is served:

App/docs/redirects.csv

Line 861 in e9dfff4

https://help.expensify.com/articles/new-expensify/expensify-card/Manage-Expensify-Cards,https://help.expensify.com/articles/new-expensify/expensify-card/Set-Up-and-Manage-the-Expensify-Card

App/docs/redirects.csv

Line 1016 in e9dfff4

https://help.expensify.com/articles/new-expensify/expensify-card/Set-Up-and-Manage-the-Expensify-Card,https://help.expensify.com/articles/new-expensify/expensify-card/Set-Up-and-Manage-the-Expensify-Card-US

Manage-Expensify-Cards redirects to Set-Up-and-Manage-the-Expensify-Card, which is itself only a redirect entry (there is no such article file — the live articles are Set-Up-and-Manage-the-Expensify-Card-US.md and Set-Up-and-Manage-the-Expensify-Card-UK-EU.md). These redirects are served as Cloudflare Bulk Redirects, which resolve a single hop, so the second hop is never applied and the request lands on the HelpDot 404 "Not here" page.

Verified against the live help site:

• .../expensify-card/Manage-Expensify-Cards → 301 to .../expensify-card/Set-Up-and-Manage-the-Expensify-Card
• .../expensify-card/Set-Up-and-Manage-the-Expensify-Card → 404 (the "Not here" page the tester sees)
• .../expensify-card/Set-Up-and-Manage-the-Expensify-Card-US → 200

So the app is linking to a dead URL, which is why every platform reproduces it.

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

Point the link at an article that actually exists, instead of relying on a broken redirect chain.

In src/CONST/index.ts, replace the single MANAGE_EXPENSIFY_CARDS_ARTICLE_LINK constant with the two live article URLs — the US one (Set-Up-and-Manage-the-Expensify-Card-US) and the UK/EU one (Set-Up-and-Manage-the-Expensify-Card-UK-EU) — since the Expensify Card help content is split by card program.

Then in WorkspaceCardSettingsPage.tsx, pick the correct one for the workspace's card program when building the href of the Learn more TextLink. The page already derives exactly the flag needed for this — isUSProgram, computed from the card program key just above the render:

App/src/pages/workspace/expensifyCard/WorkspaceCardSettingsPage.tsx

Lines 45 to 48 in e9dfff4

	const settings = getCardSettings(cardSettings);
	const programKey = getCardProgramKey(cardSettings);
	const privateSubscription = usePrivateSubscription();
	const isUSProgram = programKey === CONST.COUNTRY.US || programKey === CONST.EXPENSIFY_CARD.CARD_PROGRAM.CURRENT;

So the link becomes the US article when isUSProgram is true and the UK/EU article otherwise. This is relevant here beyond correctness: settlement frequency and the monthly-settlement rules the hint is explaining are documented per program, so the US-program admin should not be sent to the UK/EU article and vice versa.

Additionally, the stale redirect should be repaired so that other entry points (and any existing links in the wild) stop dead-ending: in docs/redirects.csv, the Manage-Expensify-Cards row should target the live Set-Up-and-Manage-the-Expensify-Card-US article directly rather than the intermediate slug that has no article, removing the unresolvable second hop.

Compare branch: https://github.com/Expensify/App/compare/main...wildan-m:App:wildan/96742-expensify-card-learn-more-404?expand=1

What alternative solutions did you explore? (Optional)

Only fixing docs/redirects.csv and leaving the app constant pointing at Manage-Expensify-Cards. That would stop the 404, but it leaves the app depending on a redirect for a link we control, and it still sends every admin to the US article regardless of their card program, so I prefer fixing the source link in the app as well.

Keeping one shared constant and always linking to the US article. Simpler, but it shows UK/EU admins US-specific settlement content, which is a different kind of wrong answer to the same click.

[mukhrr]

Proposal

What is the root cause of that problem?

The settlement-frequency hint renders Learn more with CONST.EXPENSIFY_CARD.MANAGE_EXPENSIFY_CARDS_ARTICLE_LINK:

App/src/pages/workspace/expensifyCard/WorkspaceCardSettingsPage.tsx

Lines 93 to 103 in ed960a2

	hintText={
	isSettlementFrequencyBlocked ? (
	<>
	{translate('workspace.expensifyCard.settlementFrequencyInfo')}{' '}
	<TextLink
	href={CONST.EXPENSIFY_CARD.MANAGE_EXPENSIFY_CARDS_ARTICLE_LINK}
	style={styles.label}
	>
	{translate('common.learnMore')}
	</TextLink>
	.

That constant points at Manage-Expensify-Cards:

App/src/CONST/index.ts

Line 4630 in ed960a2

MANAGE_EXPENSIFY_CARDS_ARTICLE_LINK: 'https://help.expensify.com/articles/new-expensify/expensify-card/Manage-Expensify-Cards',

I traced what that URL actually serves today, hop by hop:

Request	Response
.../expensify-card/Manage-Expensify-Cards	301 → .../Set-Up-and-Manage-the-Expensify-Card
.../expensify-card/Set-Up-and-Manage-the-Expensify-Card	404, no Location header
.../expensify-card/Set-Up-and-Manage-the-Expensify-Card-US	200

The 404 body is literally Hmm it's not here... — that is the "Not here page" in the report.

The reason the first hop dead-ends is that the article was renamed to Set-Up-and-Manage-the-Expensify-Card-US in 2583e22eb5f (2026-07-17), so no un-suffixed article exists on main anymore:

App/docs/articles/new-expensify/expensify-card/Set-Up-and-Manage-the-Expensify-Card-US.md

Lines 1 to 5 in ed960a2

	---
	title: Set Up and Manage the Expensify Card in the US
	description: Learn how to set up and manage the Expensify Card for US businesses, including enabling the card, issuing cards, and managing card settings.
	keywords: [New Expensify, Expensify Card setup, manage virtual card, card limits, Expensify Visa, card settings, Workspace Admin, Card Admin]
	internalScope: Applies to Workspace Admins and Card Admins. Covers Expensify Card setup and management. Does not cover troubleshooting or third-party feeds.

docs/redirects.csv does contain both halves of the path, but as a two-hop chain:

App/docs/redirects.csv

Line 861 in ed960a2

https://help.expensify.com/articles/new-expensify/expensify-card/Manage-Expensify-Cards,https://help.expensify.com/articles/new-expensify/expensify-card/Set-Up-and-Manage-the-Expensify-Card

App/docs/redirects.csv

Line 1016 in ed960a2

https://help.expensify.com/articles/new-expensify/expensify-card/Set-Up-and-Manage-the-Expensify-Card,https://help.expensify.com/articles/new-expensify/expensify-card/Set-Up-and-Manage-the-Expensify-Card-US

These are published as Cloudflare Bulk Redirects:

App/.github/scripts/createHelpRedirects.sh

Lines 1 to 14 in ed960a2

	#!/bin/bash
	#
	# Adds new routes to the Cloudflare Bulk Redirects list for communityDot to helpDot
	# pages. Sanity checking is done upstream in the PRs themselves in verifyRedirect.sh.
	set -e
	source scripts/shellUtils.sh
	info "Adding any new redirects from communityDot to helpDot"
	declare -r LIST_ID="20eb13215038446a98fd69ccf6d1026d"
	declare -r ZONE_ID="$CLOUDFLARE_ACCOUNT_ID"
	declare -r REDIRECTS_FILE="docs/redirects.csv"

Only the first hop is served — the second never fires, which is exactly what I measured above (404 with no Location). This is not deploy lag: sibling articles from the same 2026-07-17 batch (Manage-Your-Expensify-Card-PIN, Set-Up-and-Manage-the-Expensify-Card-UK-EU) both return 200, so the rename is live and only the chained redirect is dead.

So the app ships a link whose single redirect hop lands on a deleted article.

Note this also rules out the "just point at Set-Up-and-Manage-the-Expensify-Card" fix: that is precisely the URL returning 404 today, so it would reproduce the same Not-here page.

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

1. Point the constant at the article that actually exists. In src/CONST/index.ts:

-        MANAGE_EXPENSIFY_CARDS_ARTICLE_LINK: 'https://help.expensify.com/articles/new-expensify/expensify-card/Manage-Expensify-Cards',
+        MANAGE_EXPENSIFY_CARDS_ARTICLE_LINK: 'https://help.expensify.com/articles/new-expensify/expensify-card/Set-Up-and-Manage-the-Expensify-Card-US',

-US is the correct destination for this specific link: settlement frequency is a US Expensify Card program concept (the row is gated behind isMonthlySettlementAllowed), and the -US article is the one that documents it — it contains "To change the linked bank account, update settlement frequency, or manage cash back settings, click Settings", while the -UK-EU article has no settlement-frequency section. rg confirms this constant has exactly one consumer, so nothing else changes.

2. Collapse the dead redirect chain in docs/redirects.csv so users on already-released builds (9.4.42 and earlier, which have the old URL compiled in) stop hitting the Not-here page before they update:

-.../expensify-card/Manage-Expensify-Cards,.../expensify-card/Set-Up-and-Manage-the-Expensify-Card
+.../expensify-card/Manage-Expensify-Cards,.../expensify-card/Set-Up-and-Manage-the-Expensify-Card-US

The same one-line collapse applies to the sibling Set-up-the-Expensify-Card entry, which chains into the same dead target. Since Bulk Redirects resolve one hop, every entry must name a live final article directly.

3. Regression test. I added tests/ui/WorkspaceCardSettingsPageTest.tsx, which seeds a US card program with isMonthlySettlementAllowed: false (the only state where the hint renders), presses Learn more, and asserts the URL handed to Link.openLink:

fireEvent.press(screen.getByText(TestHelper.translateLocal('common.learnMore')), {preventDefault: () => {}});

expect(openLinkMock).toHaveBeenCalledWith('https://help.expensify.com/articles/new-expensify/expensify-card/Set-Up-and-Manage-the-Expensify-Card-US', expect.any(String));

This covers both the render gate and the destination. I confirmed it fails on unfixed code (Received: ".../Manage-Expensify-Cards") and passes with the change.

I verified the fix end to end in a real browser: the current link resolves to 404 / "Hmm it's not here…", and the new URL returns 200 on the article section describing settlement frequency.

What alternative solutions did you explore? (Optional)

I considered making the link region-aware using the isUSProgram flag already computed on this page, routing UK/EU admins to Set-Up-and-Manage-the-Expensify-Card-UK-EU. I left it out because the hint is about switching to monthly settlement, which only the US article documents — sending UK/EU admins to the -UK-EU article would surface a page that does not answer the question. If the team wants region-aware help links generally, that is worth doing as its own issue across all card help links rather than folding into this fix.

[melvin-bot]

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