[Due for payment 2026-07-13] [$250] Expensify Card - Limit type appears again after revealing card details

[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.6-2
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #89379
Email or phone of affected tester (no customers): applausetester+ssndjois2jd1@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: User Settings

Action Performed:

Precondition:

• Assign a virtual card to yourself.

1. Go to staging.new.expensify.com
2. Go to Account > Wallet.
3. Open the virtual card.
4. Click Reveal details.
5. Enter magic code.

Expected Result:

Limit type will not appear again after revealing card details.

Actual Result:

Limit type appears again after revealing card details.

Workaround:

Unknown

Platforms:

• 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

Applause Internal Information
Exported by: Svetlana Lazutkina
Bug ID: 7179251

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022065521128474182943
• Upwork Job ID: 2065521128474182943
• Last Price Increase: 2026-06-19

Issue Owner

Current Issue Owner: @bernhardoj

[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/ec1b62f088fde0fed1ae03b2b7f09f0d5c58b0ba822cf0c47f5a9f8e6acfded3

[MelvinBot]

Proposal

What is the root cause of that problem?

The card page renders the Limit type row twice once virtual card details are revealed.

1. There is an always-visible "Limit type" row near the top of the page that renders for the current card regardless of reveal state: ExpensifyCardPage/index.tsx:394-404.
2. After the magic code is entered, the revealed virtual card renders <CardDetails> and passes it limitType at ExpensifyCardPage/index.tsx:456. CardDetails then renders its own "Limit type" row at CardDetails.tsx:64-71.

So before revealing there is 1 limit-type row; after revealing there are 2 — matching the report that "Limit type appears again."

The redesign in PR #89379 ("Update Expensify card UI", merged 2026-05-19) added the dedicated always-visible limit-type row (item 1), which made the limit-type row inside CardDetails (item 2) redundant.

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

Stop passing limitType (and its now-orphaned cardHintText) into <CardDetails> at ExpensifyCardPage/index.tsx:445-463. Because CardDetails only renders its limit-type row when limitType is truthy (the !!limitType guard at CardDetails.tsx:64), dropping the prop removes the duplicate row while the always-visible row at index.tsx:394-404 continues to show the limit type. cardHintText is consumed only inside that same block, so it can be removed from the call site as well.

Optionally, the now-unused limitType/cardHintText props and the corresponding block in CardDetails.tsx can be cleaned up if no other caller relies on them.

What alternative solutions did you explore? (Optional)

Hide the top-level limit-type row (index.tsx:394-404) once details are revealed instead. Rejected because that row is the intended canonical location from the redesign and should stay visible in all states; the duplicate originates from CardDetails.

Investigation details

• Reproduction path matches the code: the static limit-type row is unconditional, and the revealed CardDetails adds a second one.
• getTranslationKeyForLimitType and getCardHintText are used in both places, so the two rows display identical content — visually a clear duplicate.
• Confidence: High. Pure frontend issue, fully contained in Expensify/App. No backend/log confirmation needed.
• Related open issues: a quick search surfaced none beyond this one.

---

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

[lorretheboy]

Proposal

What is the root cause of that problem?

The Expensify Card page always renders a dedicated "Limit type" row near the top, for every card, regardless of reveal state:

App/src/pages/settings/Wallet/ExpensifyCardPage/index.tsx

Lines 394 to 404 in 97981a1

	<MenuItemWithTopDescription
	description={translate('workspace.card.issueNewCard.limitType')}
	title={currentCardLimitTypeTranslationKey ? translate(currentCardLimitTypeTranslationKey) : ''}
	interactive={false}
	hintText={getCardHintText(
	currentCard?.nameValuePairs?.validFrom,
	currentCard?.nameValuePairs?.validThru,
	personalDetails?.[currentCard?.accountID ?? CONST.DEFAULT_NUMBER_ID]?.timezone?.selected,
	translate,
	)}
	/>

When the virtual card details are revealed, the same page swaps the masked number row for the CardDetails component and passes it the card's limitType:

App/src/pages/settings/Wallet/ExpensifyCardPage/index.tsx

Lines 444 to 463 in 97981a1

	{!!revealedDetails && revealedDetails.pan ? (
	<CardDetails
	pan={revealedDetails.pan}
	expiration={formatCardExpiration(revealedDetails.expiration ?? '')}
	cvv={revealedDetails.cvv}
	onUpdateAddressPress={() => {
	if (route.name === SCREENS.DOMAIN_CARD.DOMAIN_CARD_DETAIL) {
	Navigation.navigate(ROUTES.SETTINGS_DOMAIN_CARD_UPDATE_ADDRESS.getRoute(String(card.cardID)));
	return;
	}
	Navigation.navigate(ROUTES.SETTINGS_WALLET_CARD_DIGITAL_DETAILS_UPDATE_ADDRESS.getRoute(domain));
	}}
	limitType={card?.nameValuePairs?.limitType}
	cardHintText={getCardHintText(
	card?.nameValuePairs?.validFrom,
	card?.nameValuePairs?.validThru,
	personalDetails?.[card?.accountID ?? CONST.DEFAULT_NUMBER_ID]?.timezone?.selected,
	translate,
	)}
	/>

CardDetails then renders its own "Limit type" row whenever limitType is truthy:

App/src/pages/settings/Wallet/WalletPage/CardDetails.tsx

Lines 64 to 71 in 97981a1

	{!!limitType && (
	<MenuItemWithTopDescription
	description={translate('workspace.card.issueNewCard.limitType')}
	title={translate(getTranslationKeyForLimitType(limitType))}
	interactive={false}
	hintText={cardHintText}
	/>
	)}

So after revealing, the limit type is shown twice — once by the always-present page row, and once inside CardDetails. The recently added limit-type block in CardDetails duplicates information the page already shows.

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

Stop CardDetails from rendering a second "Limit type" row, since the page already shows one for all cards. Remove the limit-type block here:

App/src/pages/settings/Wallet/WalletPage/CardDetails.tsx

Lines 64 to 71 in 97981a1

	{!!limitType && (
	<MenuItemWithTopDescription
	description={translate('workspace.card.issueNewCard.limitType')}
	title={translate(getTranslationKeyForLimitType(limitType))}
	interactive={false}
	hintText={cardHintText}
	/>
	)}

and drop the now-unused limitType / cardHintText props passed into CardDetails (and their type definitions). CardDetails is only used on this page, so no other call sites are affected. This keeps a single "Limit type" row visible before and after reveal.

What alternative solutions did you explore? (Optional)

Alternatively, keep the limit type inside CardDetails and hide the always-present page row for virtual cards once details are revealed. This is more code and risks the row disappearing in edge cases, so removing the duplicate from CardDetails is cleaner.

[ahmdshrif]

Proposal

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

On the Wallet virtual card page, the "Limit type" row is shown once by default, but a second, duplicate "Limit type" row appears after the user reveals the card details (Reveal details → magic code).

What is the root cause of that problem?

The page renders "Limit type" from two independent places, and revealing the card mounts the second one.

1. The card summary always renders a permanent "Limit type" MenuItemWithTopDescription for the current card, regardless of reveal state.

   App/src/pages/settings/Wallet/ExpensifyCardPage/index.tsx

   Lines 394 to 404 in 97981a1

   	<MenuItemWithTopDescription
   	description={translate('workspace.card.issueNewCard.limitType')}
   	title={currentCardLimitTypeTranslationKey ? translate(currentCardLimitTypeTranslationKey) : ''}
   	interactive={false}
   	hintText={getCardHintText(
   	currentCard?.nameValuePairs?.validFrom,
   	currentCard?.nameValuePairs?.validThru,
   	personalDetails?.[currentCard?.accountID ?? CONST.DEFAULT_NUMBER_ID]?.timezone?.selected,
   	translate,
   	)}
   	/>

2. In the virtualCards.map, before reveal the card shows only the masked number + Reveal button. Once revealedDetails.pan exists, it swaps to <CardDetails> and passes limitType.

   App/src/pages/settings/Wallet/ExpensifyCardPage/index.tsx

   Lines 438 to 463 in 97981a1

   	{virtualCards.map((card) => {
   	const detailsFromSCA = scaRevealedCardDetails[String(card.cardID)];
   	const detailsFromMagicCode = cardsDetails[card.cardID];
   	const revealedDetails = detailsFromSCA ?? detailsFromMagicCode;
   	return (
   	<React.Fragment key={card.cardID}>
   	{!!revealedDetails && revealedDetails.pan ? (
   	<CardDetails
   	pan={revealedDetails.pan}
   	expiration={formatCardExpiration(revealedDetails.expiration ?? '')}
   	cvv={revealedDetails.cvv}
   	onUpdateAddressPress={() => {
   	if (route.name === SCREENS.DOMAIN_CARD.DOMAIN_CARD_DETAIL) {
   	Navigation.navigate(ROUTES.SETTINGS_DOMAIN_CARD_UPDATE_ADDRESS.getRoute(String(card.cardID)));
   	return;
   	}
   	Navigation.navigate(ROUTES.SETTINGS_WALLET_CARD_DIGITAL_DETAILS_UPDATE_ADDRESS.getRoute(domain));
   	}}
   	limitType={card?.nameValuePairs?.limitType}
   	cardHintText={getCardHintText(
   	card?.nameValuePairs?.validFrom,
   	card?.nameValuePairs?.validThru,
   	personalDetails?.[card?.accountID ?? CONST.DEFAULT_NUMBER_ID]?.timezone?.selected,
   	translate,
   	)}
   	/>

3. CardDetails itself renders its own "Limit type" row whenever limitType is truthy.

   App/src/pages/settings/Wallet/WalletPage/CardDetails.tsx

   Lines 64 to 71 in 97981a1

   	{!!limitType && (
   	<MenuItemWithTopDescription
   	description={translate('workspace.card.issueNewCard.limitType')}
   	title={translate(getTranslationKeyForLimitType(limitType))}
   	interactive={false}
   	hintText={cardHintText}
   	/>
   	)}

The permanent row in step 1 was added in the 2026-05-01 "Align Expensify Card details with Figma" change, while CardDetails already surfaced limit type earlier. Now both render: on reveal the CardDetails copy stacks on top of the permanent summary row, so the user sees "Limit type" twice — exactly the reported "appears again after revealing card details."

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

Remove the now-redundant "Limit type" block from CardDetails, since the page-level summary row already shows limit type permanently for the displayed card.

In src/pages/settings/Wallet/WalletPage/CardDetails.tsx, drop the limitType MenuItem (and the now-unused limitType/cardHintText props + getTranslationKeyForLimitType import):

App/src/pages/settings/Wallet/WalletPage/CardDetails.tsx

Lines 64 to 71 in 97981a1

	{!!limitType && (
	<MenuItemWithTopDescription
	description={translate('workspace.card.issueNewCard.limitType')}
	title={translate(getTranslationKeyForLimitType(limitType))}
	interactive={false}
	hintText={cardHintText}
	/>
	)}

And stop passing limitType into it:

App/src/pages/settings/Wallet/ExpensifyCardPage/index.tsx

Line 456 in 97981a1

limitType={card?.nameValuePairs?.limitType}

This is safe because WalletPage/CardDetails is imported only by ExpensifyCardPage, and the permanent summary row keeps showing limit type for the selected card before and after reveal — only the duplicate is removed; card number / expiration / CVV / address rows are untouched.

What alternative solutions did you explore? (Optional)

• Hide the permanent summary row while the card is revealed (toggle on revealedDetails) — rejected: more state-coupled, and the summary row is the Figma-intended permanent placement.

[melvin-bot]

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

[godzillaxbox19982014-lgtm]

Proposal

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

Expensify Card - Limit type appears again after revealing card details

What is the root cause of that problem?

I traced this to the path that handles iOS:

• src/pages/workspace/expensifyCard/DynamicExpensifyCardLimitTypePage.tsx:67 (assigneePersonalDetails): const assigneePersonalDetails = personalDetails?.[card?.accountID ?? CONST.DEFAULT_NUMBER_ID];
• src/pages/ReimbursementAccount/NonUSD/types.ts:21 (types): isComingFromExpensifyCard?: boolean;
• src/pages/EnablePayments/Wallet/EnablePayments.tsx:69 (enablePaymentsStep): const enablePaymentsStep = !hasExpensifyPaymentMethod(paymentCardList, bankAccountList ?? {}, hasActivatedWallet)
• The local evidence matches this recurring failure shape: NewDot and OldDot read different default account/card fields. Here, src/pages/workspace/expensifyCard/DynamicExpensifyCardLimitTypePage.tsx:67 and src/pages/ReimbursementAccount/NonUSD/types.ts:21 do not agree on the same iOS value, so the user-visible path can show a missing or stale state even though nearby data already has the needed context.

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

• Update src/pages/workspace/expensifyCard/DynamicExpensifyCardLimitTypePage.tsx:67 to derive iOS from the card/accounting data source that owns this flow before the value is consumed.
• Carry the same normalized value through src/pages/ReimbursementAccount/NonUSD/types.ts:21; that follows the safer family move to add fallback at the export/mapping layer, so the write/optimistic/read paths agree instead of only changing the visible component.
• Keep the change inside the Payments, Wallet, Bank, Billing, Cards surface and avoid changing money movement, bank/card/account settings.

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/Payment*.ts for the exact issue flow: Expensify Card - Limit type appears again after revealing card details.
2. Cover the counter-case near src/pages/workspace/expensifyCard/DynamicExpensifyCardLimitTypePage.tsx:67 so valid existing iOS 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 iOS consistent at the first read/write boundary shown above.

[melvin-bot]

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

[aswin-s]

Proposal

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

On the Expensify Card page (Account > Wallet > virtual card), after the user clicks "Reveal details" and enters the magic code, the "Limit type" row is shown twice — once from the always-rendered section above the card details and once inside the revealed CardDetails block. Expected: only one "Limit type" row should appear after revealing.

What is the root cause of that problem?

ExpensifyCardPage/index.tsx:394-404 unconditionally renders a MenuItemWithTopDescription for workspace.card.issueNewCard.limitType for currentCard. Independently, when card details are revealed, virtualCards.map (line 438) renders CardDetails with the same limitType prop (line 456), and CardDetails.tsx:64-71 renders a second MenuItemWithTopDescription with the identical workspace.card.issueNewCard.limitType description. After reveal, both render → duplicate row.

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

1. src/components/CardDetails.tsx (lines 41, 47, 64-71): remove the internal limitType row and the limitType/cardHintText props — the parent page is the single source for the Limit type row.
2. src/pages/settings/Wallet/ExpensifyCardPage/index.tsx (lines 456-462): stop passing limitType and cardHintText to CardDetails. The existing outer MenuItemWithTopDescription at lines 394-404 already shows Limit type + cardHintText for the current card, so revealing details no longer duplicates it.
3. Verify no other consumer relies on CardDetails' limitType prop (grep <CardDetails) — at the time of writing, ExpensifyCardPage is the only consumer that passes it.

What alternative solutions did you explore? (Optional)

Hide the outer limit-type row when revealedDetails exists for the current card — rejected because it would also hide the availableSpend's associated remainingLimitHint context and adds conditional state coupling; deleting the duplicate inside CardDetails is the narrower, sibling-consistent fix (other reveal-only fields like PAN/expiration/CVV legitimately live in CardDetails; limitType does not change on reveal).