Travel Card Icon is wrong when an admin is looking at spend view

[blimpich]

As an admin of a travel billing enabled workspace, when I go to spend I can look at two expenses that both are paid with travel cards. One has a travel card icon and the other doesn't, though. The one that does have the icon is my personal expense, whereas the one that doesn't is someone else on the workspace's expense.

Zoom in closer 🔍

Expected: both should be travel card icons since both were booked on travel cards.
Actual: only expenses made by myself are shown with the travel card icon

Issue Owner

Current Issue Owner: @allgandalf

[blimpich]

Slack conversation about this here: https://expensify.slack.com/archives/C05S5EV2JTX/p1782943629578619

[blimpich]

My Claude session analysis

TL;DR

The travel-card icon is derived purely client-side from the card object (isTravelCard(card)), which requires the viewer to already have that card in their Onyx card list. You have your own travel card, so your row gets the plane icon; you don't have another member's card, so their row falls back to the generic Expensify Card icon. The card column text works for everyone because that string is resolved server-side and shipped on the transaction — no card lookup needed. The clean fix is to return the card's feedCountry as a field on the transaction so the client can derive the icon the same way it already gets the name: from data that travels with the transaction.

Root cause

Two different mechanisms decide the icon vs. the column text, and only one of them needs a card object the viewer may not have.

• Column text (works): resolved on the backend and stamped onto the transaction as a plain string. In Auth, SearchUtils.cpp builds the search result and sets transaction["cardName"] from a COALESCE over the joined cards table (auth/lib/SearchUtils.cpp:198-204, assigned at auth/lib/SearchUtils.cpp:1564). The travel branch (Card::getTravelCardNameBranch, auth/lib/Card.cpp:110-117) reads the card's feedCountry out of cards.message JSON and emits the travel name. Because this is server-rendered, the finished string ships with every transaction regardless of whose card it is.
• Icon (broken for other members): derived in the client from the card object. TypeCell computes isTravelCard(card) (src/components/TransactionItemRow/DataCells/TypeCell.tsx), and isTravelCard checks card?.nameValuePairs?.feedCountry === CONST.TRAVEL.PROGRAM_TRAVEL_US (src/libs/CardUtils.ts). The card object comes from the viewer's own card list (and the workspace/non-personal derived list), neither of which contains other members' individual cards.

Why this case and not others: the asymmetry only surfaces when the viewer looks at a travel expense belonging to another member. For your own travel expenses the card is in your list, so the icon resolves. For non-travel expenses the generic icon is correct anyway. Only "someone else's travel card, viewed by me" hits the gap.

Why we didn't already return feedCountry (history)

This is not an oversight in the original travel-name work — the icon didn't exist yet.

• Auth #21127 (merged 2026-04-24) added travel-name resolution to search/exports for Expensify #624134. It did add feedCountry to the SQL, but deliberately collapsed it into producing the display name rather than surfacing it as a field. In the PR discussion the team consciously moved away from program-identity toward name-string resolution to keep the change small (rlinoz suggested just naming the cards; Ben agreed). A review bot even flagged the exact fragility we now care about — "Identify travel cards by feedCountry, not display title" — and it was knowingly deferred. At that time every expense used the Expensify Card icon and that was intended, so there was no consumer that needed feedCountry on the transaction.
• App #88350 (merged 2026-04-28) split travel into its own feed filter, using feedCountry — but read from the card object's NVPs, same dependency as the icon.
• App #90277 (merged 2026-05-12) is where this bug was introduced: it added the plane icon + tooltip, deriving travel-ness from isTravelCard(card). Its own Offline-tests note says "icon selection is local, no network dependency," and its manual test steps only cover a member viewing their own expenses — so the cross-member path was never exercised or reviewed.

Also note: the feature was renamed from "Travel Invoicing" → "Consolidated Travel Billing", and the underlying constant has drifted across "Central invoicing" / "Travel invoicing" / the current localized string. This is precisely why matching on the cardName string is brittle and why feedCountry (immutable program identity) is the right key.

Recommended fix

Return feedCountry on the transaction and let the client derive both icon and column text from it. Two phases, not three.

Phase 1 — Auth: add feedCountry to every transaction-building path. Not just the flat search response. TransactionItemRow also renders in report views (MoneyRequestReportView), unreported-expense lists, and duplicate/merge screens, and those transactions are populated by Transaction::formatTransactionResult / BASE_SELECT_FIELDS, not by search. Add the field to the same three paths #21127 touched: buildTransactionResponse, buildGroupByCardResponse, and formatTransactionResult/BASE_SELECT_FIELDS. Reuse Card::getFeedCountrySelector("c."), and guard it with JSON_VALID (this was a P1 on #21127 — extracting from cards.message without a validity check fails the whole query on a malformed row). The cards table is already joined, so this adds no new join.

Phase 2 — App: key the icon and column on feedCountry. Icon: transaction.feedCountry === CONST.TRAVEL.PROGRAM_TRAVEL_US. Keep isTravelCard(card) (and the current cardName check) as fallbacks so nothing regresses while Auth rolls out and for old cached transactions that lack the field. Bonus: keying the column on feedCountry also lets the client show the correctly localized name for other members' travel expenses, which the current code cannot do (today it only localizes the viewer's own cards).

Do NOT remove the server-side card-name logic. It still serves consumers that can't run client-side feedCountry logic: CSV/PDF exports (ExportSearch.cpp), OldDot, emails, and the group-by-card grouping label. For travel cards cards.cardName is the encrypted PAN, so stripping the travel branch wouldn't degrade gracefully — the COALESCE would fall through to "Expensify Card." Reframe the goal as "NewDot no longer depends on the server travel name for display," not "delete the backend logic."

Deploy ordering: all additive — ship Auth first (old clients ignore the new field), then App (new clients fall back when the field is absent). No atomic coordination needed; there's no window where anything is worse than today.

Correcting an earlier assumption from this session

An initial stopgap keyed the icon on matching transaction.cardName against a hardcoded travel string (isTravelCardTransaction). That is fragile because the display name has been renamed/localized multiple times. feedCountry is the stable identity and supersedes that approach.

Still to confirm

• Exact field name/shape to expose (feedCountry string matching CONST.TRAVEL.PROGRAM_TRAVEL_US) and that all render surfaces above receive it after Phase 1.
• Whether any non-search consumer of the transaction Onyx type needs a type update for the new field.

– written by Claude on Ben's behalf

[blimpich]

@ishpaul777 @allgandalf either of you up for taking this on? I think the right solution is to stop using the transaction.cardName attribute to decide what the frontend should display and instead start sending feedCountry on the transaction data sent in the Search API response. Then we can just use this on the frontend:

if(transaction.feedCountry === CONST.TRAVEL.PROGRAM_TRAVEL_US) {
    // display travel icon
}

[allgandalf]

I can pick this up 👍

[blimpich]

Thank you!

[blimpich]

@allgandalf when can we expect the next PR for this one?

[blimpich]

bump @allgandalf

[allgandalf]

opening the PR up now

• Show the travel card icon for other members' travel expenses #95320