[CFI] Allow assigning Expensify Cards to members on non-USD workspaces by linking an existing US card feed

[MelvinBot]

Problem
Admins want to issue Expensify Cards (funded from a US account) to employees who live outside the US and sit on non-USD workspaces (e.g. a CAD or GBP workspace), and have those card expenses land on the employee's own workspace rather than the US workspace.

In New Expensify, this isn't possible: when an admin tries to link the US Expensify Card feed to a non-USD workspace, they hit a modal telling them they need to change the workspace currency to USD.

Expected behavior
Admins should be able to link an existing Expensify Card feed to a non-USD workspace (e.g. CAD, GBP, EUR) and assign cards to members on that workspace, with expenses showing up on the correct workspace.

Chuck: "Poking around in dev, New Expensify already allows linking GBP and EUR workspaces to a USD feed — the currency modal appears to be overzealous enforcement (intended to block enrolling in the e-card with an unsupported currency), and it's blocking the valid "link an existing feed" path."

Notes / context

• There was a related PR that may have been ECUK-specific; if workspaces have existing feeds to link, we should allow it regardless of workspace currency.
• Reported by a customer via a CAM.

Reported in Slack.

[trjExpensify]

@MelvinBot do 2 things:

1. Write a proposal for the change above.
2. Give me your opinion on if this below should work in the meantime:

Given that we seemingly already support this case via this PR, I think we might be able to use the "Manage linked policies" supportal tool to link additional policies to the feed in the meantime to have it appear enabled on the workspace. Does that sound about right?

[MelvinBot]

Proposal

What is the root cause of that problem?

When an admin opens the Expensify Card page on a non-USD workspace, the "issue a card" CTA runs a currency check before it decides which flow to start. That check is in the empty-state component:

• The gate is WorkspaceExpensifyCardPageEmptyState.tsx:179: if (!(policy?.outputCurrency === CONST.CURRENCY.USD || isUkEuCurrencySupported)) → it opens the "Update to USD" modal (promptCurrencyChangeAndStartFlow, L127‑142).
• isUkEuCurrencySupported only bypasses the gate for GBP/EUR and only with the EXPENSIFY_CARD_EU_UK beta (useExpensifyCardUkEuSupported.ts), because isCurrencySupportedForECards allow-lists only GBP and EUR.

The problem is that this gate exists to protect enrolling a brand-new card program (which requires a USD bank account), but it fires unconditionally — even when the admin has an existing feed to link. startFlow() already branches correctly: if hasAccessibleFeeds is true it routes to the feed selector instead of bank-account setup (L82, L91‑107). But the currency check runs before that branch, so the "link an existing feed" path is blocked by a rule that only the "new program" path actually needs. This matches Chuck's observation that the modal is overzealous enforcement.

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

Skip the USD currency gate when the admin is linking an existing feed, and only apply it to the new-program (bank-account setup) path:

• In the CTA handler at L179, only prompt the currency change when there are no accessible feeds — i.e. gate on !hasAccessibleFeeds && !(policy?.outputCurrency === CONST.CURRENCY.USD || isUkEuCurrencySupported). When hasAccessibleFeeds is true, call startFlow() directly so it routes to the feed selector.
• No new linking logic is needed: the "From other workspaces" section of the feed selector already calls linkCardFeedToPolicy, and PR #93331 already made the card UI derive currency from the feed itself (useCurrencyForExpensifyCard / getCardOrFeedCurrency), so a USD feed linked to a CAD/GBP/EUR workspace displays the correct currency.

Validation to confirm before/while implementing

• Confirm the backend linkCardFeedToPolicy (BankConnection) actually allows linking a USD feed to a workspace of any currency (Chuck saw GBP/EUR work in dev; the issue also calls out CAD). If the backend restricts currencies, the gate relaxation should mirror that allow-list.
• Verify end-to-end on a non-GBP/EUR currency (e.g. CAD): after linking, the admin can assign a card (issueNew/AssigneeStep, touched by PR #93331) and the resulting expense lands on the member's own workspace with the feed's currency (USD).

What alternative solutions did you explore? (Optional)

Extend isCurrencySupportedForECards to allow more currencies — rejected, because that governs new-program enrollment (which genuinely needs USD/UK/EU banking) and would incorrectly change the setup gate rather than the linking path.

---

On the supportal "Manage linked policies" workaround

Short answer: yes, that sounds about right as a stopgap — with one thing to verify.

The blocker here is purely the frontend empty-state currency gate; the underlying link operation and the display layer already handle non-USD workspaces. The supportal "Manage linked policies" tool performs the same linkCardFeedToPolicy link server-side, so it bypasses the CTA gate entirely. Once the feed is linked to the non-USD workspace, that workspace no longer renders the empty state (and its gate) — it shows the linked feed and the assign-card flow, and PR #93331 ensures the currency displays correctly for a feed whose policy currency differs.

The one caveat: PR #93331 was explicitly tested for GBP/EUR display. So for a CAD workspace, I'd validate end-to-end after linking that (a) cards can actually be assigned to members on that workspace and (b) the expenses post to the correct workspace in the feed's currency. If that checks out, linking via the supportal tool is a reasonable interim path to make the feed appear enabled on the non-USD workspace.

---

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

[trjExpensify]

@chuckdries fancy guiding melv on a PR for this?

[chuckdries]

Sure thing. @MelvinBot double check how hasAccessibleFeeds is populated - will it have a value when the user presses the CTA for the first time?

[MelvinBot]

Good catch — it's not guaranteed to be correct on the first CTA press. hasAccessibleFeeds is a pure Onyx derivation with no fetch behind it, and the card page never loads other workspaces'/domains' feeds. So there's a real false-negative window.

Why: useExpensifyCardFeedsForFeedSelector just reads three whole collections straight from Onyx — PRIVATE_EXPENSIFY_CARD_SETTINGS, POLICY, DOMAIN — and derives feeds from them (useExpensifyCardFeedsForFeedSelector.ts:15-22). It triggers no load. The only fetch the card page fires on mount is openPolicyExpensifyCardsPage(policyID, defaultFundID), which loads settings for the current workspace's fund only. A linkable feed on another domain/workspace requires that domain's card settings (keyed by its domainAccountID/workspaceAccountID) plus its DOMAIN entry — none of which this page loads.

So hasAccessibleFeeds is only reliable if those collections were already populated by an earlier OpenApp/ReconnectApp. If they weren't yet, allFeeds is empty on first render → hasAccessibleFeeds === false even though the user has a feed. And the page's isLoading gate only covers the current fund — it doesn't protect the cross-domain collection.

The good news for the proposal: the gating direction is safe. hasAccessibleFeeds is a true-positive-only signal (a feed is either present in Onyx or not), so skipping the USD prompt when it's true is always correct and never introduces a new bug. The worst case is the false negative above — a user with an existing feed still sees the USD prompt — which is exactly today's behavior, so the fix is still a strict improvement, it just doesn't fully cure that race on its own.

To close the window, we'd want a positive "feeds loaded" signal rather than treating an empty collection as "no feeds." Two paths:

1. Confirm OpenApp/ReconnectApp already ships the full set of the user's admin card settings + DOMAIN entries at startup — you'd know the backend better than I can see from App. If it does, the window is only the brief post-cold-start moment and the simple fix is probably fine.
2. If it doesn't, have the card page trigger a read that loads the admin feed set (the way the feed selector consumes it) and gate both the CTA and the USD prompt on that loading flag — so we never prompt for a currency change while feeds are still unknown.

I couldn't verify (1) from the App repo alone since that data arrives as backend onyxData; that's the one thing worth confirming before deciding whether the simple gate is sufficient or we need the explicit load in option 2.

[chuckdries]

OpenPolicyExpensifyCardsPage actually does return all the domain's feeds' card settings, so we'll be alright. @MelvinBot go ahead and implement your proposal here

[MelvinBot]

🤖 Draft PR created: #98509

What it does: skips the "Update to USD" currency gate on the Expensify Card empty state when the workspace already has accessible feeds (hasAccessibleFeeds), so the "link an existing feed" path proceeds to the feed selector regardless of workspace currency. The USD prompt still applies to the brand-new-program setup path (no accessible feeds). Change is one guard in WorkspaceExpensifyCardPageEmptyState.tsx — no new linking or currency logic, since the feed selector already links feeds and PR #93331 already derives the correct display currency from the feed.

Checks run locally: oxfmt, ESLint (clean), npm run typecheck (tsc, clean), and React Compiler compliance (clean).

Note on testing: I didn't add a unit test — this component has no existing test harness, and a live functional test isn't reproducible in a generic account since it needs a non-USD workspace with an existing card feed available to link. I've left suggested manual test steps in the PR body for the human co-author to run and fill in the Tests/QA sections.

chuckdries please review, run the manual test steps, and mark it "Ready for review" when it's good to go.

[chuckdries]

@MelvinBot that works great! But I noticed that now we need to hide the "Issue card" button from the /select-feed panel to make sure they aren't able to try to apply for a new card feed on an unsupported currency

[MelvinBot]

Good catch — confirmed, and here's the precise spot plus the nuance to get right.

Where: The button lives in the feed selector's footer: WorkspaceExpensifyCardFeedSelectorPage.tsx:203-210. It's a single MenuItem that switches label and behavior based on issueCardFundID:

• issueCardFundID !== undefined → label "Issue card" → handleAddCardPress — issues a card on an existing feed. Safe on any currency; this is the feature we want.
• issueCardFundID === undefined → label "Issue new card" → handleSetUpNewProgramPress — routes to bank-account / new program setup. This is the leak: on an unsupported-currency workspace that only reached this page because it has linkable feeds, primaryFeeds is empty → issueCardFundID is undefined (getIssueCardFundID, L87-101) → the button becomes "Issue new card" and lets them apply for a brand-new feed, bypassing the currency gate we just relaxed.

Fix: Don't hide the whole button — only suppress the new-program branch on unsupported currencies. Keep the "Issue card" (existing-feed) branch and the "From other workspaces" link rows so the page stays useful. Concretely, gate the footer MenuItem on:

issueCardFundID !== undefined || policy?.outputCurrency === CONST.CURRENCY.USD || isUkEuCurrencySupported

That reuses the same currency check as the empty-state gate — isUkEuCurrencySupported from useExpensifyCardUkEuSupported (which allow-lists GBP/EUR via isCurrencySupportedForECards). The hook just needs importing into this page. Result on an unsupported-currency workspace: they can still link an existing feed (the selectOtherFeed rows) but can't apply for a new one.

I'll fold this into the proposal's solution as a second change alongside relaxing the empty-state gate.

---

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

[chuckdries]

@MelvinBot implement this