[$250] Wallet - Newly added BA does not become default after deleting the previous default BA

[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: v9.4.29-3
Reproducible in staging?: Yes
Reproducible in production?: Unable to validate in Prod - Provide reasoning.
If this was caught during regression testing, add the test name, ID and link from BrowserStack: TC: https://test-management.browserstack.com/projects/2219752/folder/13176687/test-cases/41236664 PR: #51437
Email or phone of affected tester (no customers): testexpensify9+wallettest@gmail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Windows 11, Chrome
App Component: Other

Action Performed:

Preconditions:

• The user has two BAs added in Wallet.
• The first BA is Wells Fargo ending in 1111.
• The second BA is Regions ending in 0000, and it is automatically set as the default when added.

1. Go to http://staging.new.expensify.com/
2. Navigate to Account > Wallet
3. Delete the Regions BA ending in 0000 (the current default BA).
4. Click Add bank account and complete the flow to add the Regions BA ending in 0000 again.

Expected Result:

After deleting the current default BA and adding it again, the newly added BA should automatically be set as the Default BA.

Actual Result:

After deleting the current default BA and adding it again, the newly added BA is not set as the default. Instead, the previously existing BA is automatically set as the default.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7203539_1783579295504.issue.mp4

View all open jobs on GitHub

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

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022075122771867922227
• Upwork Job ID: 2075122771867922227
• Last Price Increase: 2026-07-16

[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/4fc4fcce5e955e53b66f1502dbd495c19b2606804561e3c9ce0ffa052d2ae1a4

[MelvinBot]

Proposal

What is the root cause of that problem?

The default flag is promoted at delete-time, never at add-time, so the account picked when you deleted the old default "sticks" as default through the subsequent add.

Walking the exact repro (delete default Regions → only Wells Fargo left → re-add Regions):

1. Deleting the default promotes the newest remaining existing account (client-side). In WalletPage/index.tsx:298-343, when the deleted method is the current default, the App filters the remaining OPEN personal bank accounts, sorts them by created descending, and promotes the top one — so Wells Fargo becomes default. That choice is written optimistically as isDefault: true + userWallet.walletLinkedAccountID via deletePaymentBankAccount (BankAccounts.ts:648-678) and getMakeDefaultPaymentOnyxData (PaymentMethods.ts:91-145).

2. Adding a bank account never marks it default. addPersonalBankAccount (BankAccounts.ts:487-601) writes nothing to isDefault or walletLinkedAccountID in its optimistic/success/failure data — default status for a new account comes only from the backend response, and the backend does not auto-promote a newly-added account to default when a default already exists.

Net effect: re-adding Regions leaves Wells Fargo (promoted at delete time) as the default. This matches the current design — a non-first added account keeps the existing default. So the report's "Expected Result" is really a product question: should freshly adding a personal BA make it the default?

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

If the product decision is that a freshly-added personal bank account should become the default, mirror the delete flow's promotion in the add flow: have addPersonalBankAccount optimistically set the new account as default (reuse getMakeDefaultPaymentOnyxData), and have the backend AddPersonalBankAccount response designate the new account default.

⚠️ Default state is server-authoritative — the App only overrides it optimistically. A purely App-side optimistic change would be reverted by the backend response on the next sync, so this fix requires a matching backend change (outside Expensify/App) and should be confirmed by an internal engineer before implementation.

What alternative solutions did you explore? (Optional)

Confirm this is working as intended and the test expectation is wrong. Today, adding a non-first account intentionally does not hijack the existing default; only the first account, or the promotion triggered by deleting the default, sets it. If that's the desired behavior, this should be closed as invalid and the regression test's expected result corrected.

Investigation details & confidence

• Confidence: High on the mechanism (verified in code, two independent traces agree); Medium on whether this is a defect vs. intended behavior, since the "expected" result is a product decision and the add-side half depends on backend logic not in this repo.
• The delete API call only sends {bankAccountID} — the new-default choice is applied client-side (optimistic) and by independent backend logic; they must agree or the default badge flickers.
• UI default badge is driven by userWallet.walletLinkedAccountID (PaymentMethodList.tsx:549-552) and per-item isDefault copied through from bankAccountList in PaymentUtils.formatPaymentMethods.
• No existing duplicate found in open App issues.

---

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

[dilshodmackbook-sketch]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-09 07:45:53 UTC.

Proposal

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

On Web, after deleting the current default bank account (Regions •0000) and re-adding it, the newly added BA is not shown as the default — the other pre-existing account (Wells Fargo •1111) keeps the Default badge.

What is the root cause of that problem?

The Default badge is driven solely by userWallet.walletLinkedAccountID:

App/src/pages/settings/Wallet/PaymentMethodList.tsx

Lines 549 to 552 in 35a2f0a

	shouldShowDefaultBadge={shouldShowDefaultBadge(
	filteredPaymentMethodsWithoutStrings,
	invoiceTransferBankAccountID ? invoiceTransferBankAccountID === item.methodID : item.methodID === userWallet?.walletLinkedAccountID,
	shouldHideDefaultBadge,

When the current default is deleted, the client optimistically promotes the remaining sibling by writing its ID into walletLinkedAccountID through getMakeDefaultPaymentOnyxData. This promotion is pushed to optimisticData (and failureData) only — there is no successData, so it's a permanent client-side override that is never reconciled against the server:

App/src/libs/actions/BankAccounts.ts

Lines 648 to 661 in 35a2f0a

	if (newBankAccountID) {
	const newDefaultPaymentMethodOnyxData = getMakeDefaultPaymentOnyxData(newBankAccountID);
	onyxData.optimisticData?.push(
	...(newDefaultPaymentMethodOnyxData as Array<OnyxUpdate<typeof ONYXKEYS.BANK_ACCOUNT_LIST | typeof ONYXKEYS.NVP_LAST_PAYMENT_METHOD | typeof ONYXKEYS.USER_WALLET>>),
	);
	onyxData.optimisticData?.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: ONYXKEYS.BANK_ACCOUNT_LIST,
	value: {
	[newBankAccountID]: {
	isDefault: true,
	},
	},
	});

Re-adding Regions then runs through addPersonalBankAccount, whose optimistic/success data only touch PERSONAL_BANK_ACCOUNT and USER_WALLET.currentStep — it never re-points walletLinkedAccountID:

App/src/libs/actions/BankAccounts.ts

Lines 520 to 549 in 35a2f0a

	const onyxData: OnyxData<typeof ONYXKEYS.PERSONAL_BANK_ACCOUNT | typeof ONYXKEYS.USER_WALLET | typeof ONYXKEYS.NVP_LAST_PAYMENT_METHOD> = {
	optimisticData: [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: ONYXKEYS.PERSONAL_BANK_ACCOUNT,
	value: {
	isLoading: true,
	errors: null,
	plaidAccountID: account.plaidAccountID,
	},
	},
	],
	successData: [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: ONYXKEYS.PERSONAL_BANK_ACCOUNT,
	value: {
	isLoading: false,
	errors: null,
	shouldShowSuccess: true,
	},
	},
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: ONYXKEYS.USER_WALLET,
	value: {
	currentStep: CONST.WALLET.STEP.ADDITIONAL_DETAILS,
	},
	},
	],

And on Web nothing refetches the wallet mid-session — WalletPage calls getPaymentMethods() only on mount/reconnect:

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

Lines 399 to 404 in 35a2f0a

	useEffect(() => {
	if (network.isOffline) {
	return;
	}
	getPaymentMethods();
	}, [network.isOffline]);

So the fabricated walletLinkedAccountID from the delete step survives untouched: the server makes the freshly re-added Regions the default, but the client keeps the badge pinned to Wells Fargo until a full reload.

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

Stop fabricating the wallet default on the client and let the server own it. In the delete flow, drop the getMakeDefaultPaymentOnyxData promotion of USER_WALLET (the part with no successData to reconcile it) and keep only the display-level isDefault on the sibling so the list doesn't momentarily show two/zero defaults:

if (newBankAccountID) {
    // Keep the sibling visually marked while the request is in flight, but don't
    // optimistically re-link the wallet — the server response owns walletLinkedAccountID.
    onyxData.optimisticData?.push({
        onyxMethod: Onyx.METHOD.MERGE,
        key: ONYXKEYS.BANK_ACCOUNT_LIST,
        value: {[newBankAccountID]: {isDefault: true}},
    });
    onyxData.failureData?.push({
        onyxMethod: Onyx.METHOD.MERGE,
        key: ONYXKEYS.BANK_ACCOUNT_LIST,
        value: {[newBankAccountID]: {isDefault: false}},
    });
}

With the client no longer latching a stale link, walletLinkedAccountID follows the authoritative server value: after a plain delete the server-chosen fallback shows as default, and after re-adding a BA the server (which marks a newly added personal BA as default) points the wallet at the new account — so Regions correctly wins.

What alternative solutions did you explore? (Optional)

Refetch the authoritative wallet on add success — call getPaymentMethods() when AddPersonalBankAccountPage reaches its success state, mirroring the existing pattern in ReimbursementAccountPage:

App/src/pages/ReimbursementAccount/ReimbursementAccountPage.tsx

Line 166 in 35a2f0a

getPaymentMethods();

This also corrects the badge, but it spends an extra OpenPaymentsPage round-trip to repair state we can simply avoid corrupting in the first place.

Deriving the badge from each account's isDefault flag instead of walletLinkedAccountID — rejected: PR #51437 intentionally moved to walletLinkedAccountID as the single source of truth to stop two accounts showing the badge at once.

[aswin-s]

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

On the Wallet page, after a user deletes their current default bank account (Regions •0000) and then re-adds the same bank account, the newly added account is not shown as the default. Instead, the other previously existing bank account (Wells Fargo •1111) retains the default badge. Expected: the newly re-added bank account should automatically become the default.

What is the root cause of that problem?

The bug lives entirely in the optimistic Onyx state written during the delete flow — no server MAKE_DEFAULT_PAYMENT_METHOD command is involved.

Delete flow (the source of the stale state):

1. deletePaymentMethod in src/pages/settings/Wallet/WalletPage/index.tsx (≈L312–350) checks paymentMethod.isSelectedPaymentMethodDefault. Because Regions is the default, it computes remainingPaymentMethods (filtered to open, non-business personal BAs, sorted newest-first) and picks newBankAccountID = WF.bankAccountID.

2. It calls deletePaymentBankAccount(Regions.bankAccountID, ..., WF.bankAccountID) in src/libs/actions/BankAccounts.ts (L603).

3. Inside deletePaymentBankAccount (L648–668), because newBankAccountID is truthy, it calls:

   const newDefaultPaymentMethodOnyxData = getMakeDefaultPaymentOnyxData(newBankAccountID);
   onyxData.optimisticData?.push(...newDefaultPaymentMethodOnyxData);

   getMakeDefaultPaymentOnyxData (src/libs/actions/PaymentMethods.ts L87–141) returns only Onyx updates — it does NOT call makeDefaultPaymentMethod and does NOT send a MAKE_DEFAULT_PAYMENT_METHOD server command. makeDefaultPaymentMethod is a completely separate exported function with its own callers (WalletPage.makeDefaultPaymentMethod callback and WorkspaceInvoiceVBASection); it is not called from deletePaymentBankAccount.

4. The Onyx optimistic update sets USER_WALLET.walletLinkedAccountID = WF.bankAccountID and BANK_ACCOUNT_LIST[WF].isDefault = true.

5. The only server command sent is DELETE_PAYMENT_BANK_ACCOUNT with {bankAccountID: Regions.bankAccountID}. There is no successData for USER_WALLET.walletLinkedAccountID in this write, so the optimistic value (WF) persists in Onyx until overwritten by a Pusher update.

Re-add flow (where the bug manifests):

6. User adds Regions again via addPersonalBankAccount (src/libs/actions/BankAccounts.ts L487). Its successData writes only:

   • PERSONAL_BANK_ACCOUNT.shouldShowSuccess = true
   • USER_WALLET.currentStep = CONST.WALLET.STEP.ADDITIONAL_DETAILS

   It does not touch walletLinkedAccountID at all.

7. The server assigns a new bankAccountID to the re-added Regions account. The server may or may not broadcast a Pusher update that sets walletLinkedAccountID to the new Regions ID. Whether or not it does, the stale optimistic value walletLinkedAccountID = WF remains as long as addPersonalBankAccount produces no correction.

8. shouldShowDefaultBadge in src/pages/settings/Wallet/PaymentMethodList.tsx (L136–144) reads userWallet?.walletLinkedAccountID. Since that still points to WF, WF shows the default badge and Regions does not.

Summary: The stale optimistic walletLinkedAccountID = WF set in step 4 is never corrected, because (a) deletePaymentBankAccount has no successData reverting it, and (b) addPersonalBankAccount does not update walletLinkedAccountID.

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

Fix 1 — src/pages/settings/Wallet/WalletPage/index.tsx deletePaymentMethod (≈L312–350):
Remove the automatic computation and passing of newBankAccountID. The wallet should not eagerly promote another BA as default during a delete; that decision should be left to the server. Pass the isSelectedPaymentMethodDefault flag to the action instead:

// BEFORE
if (remainingPaymentMethods.length > 0) {
    const newDefaultMethod = remainingPaymentMethods.at(0);
    newBankAccountID =
        newDefaultMethod?.accountType === CONST.PAYMENT_METHODS.PERSONAL_BANK_ACCOUNT
            ? (newDefaultMethod?.accountData?.bankAccountID ?? CONST.DEFAULT_NUMBER_ID)
            : undefined;
}
// ...
deletePaymentBankAccount(bankAccountID, personalPolicyID, lastUsedPaymentMethods, bankAccount, newBankAccountID);

// AFTER
// Do not compute newBankAccountID — let the server clear the default.
// Pass a boolean so the action knows whether the deleted account was the current default.
const isDefaultAccount = paymentMethod.isSelectedPaymentMethodDefault;
deletePaymentBankAccount(bankAccountID, personalPolicyID, lastUsedPaymentMethods, bankAccount, undefined, isDefaultAccount);

Fix 2 — src/libs/actions/BankAccounts.ts deletePaymentBankAccount (L603–754):

Add an isDefaultAccount boolean parameter to the function signature:

// BEFORE
function deletePaymentBankAccount(
    bankAccountID: number,
    personalPolicyID: string | undefined,
    lastUsedPaymentMethods?: LastPaymentMethod,
    bankAccount?: OnyxEntry<PersonalBankAccount>,
    newBankAccountID?: number,
)

// AFTER
function deletePaymentBankAccount(
    bankAccountID: number,
    personalPolicyID: string | undefined,
    lastUsedPaymentMethods?: LastPaymentMethod,
    bankAccount?: OnyxEntry<PersonalBankAccount>,
    newBankAccountID?: number,
    isDefaultAccount?: boolean,
)

Then, inside the function, guard the walletLinkedAccountID clear on isDefaultAccount — not on !newBankAccountID — so that deleting a non-default BA never touches the current default:

// After the existing successData entry for BANK_ACCOUNT_LIST, add:
if (isDefaultAccount) {
    onyxData.successData?.push({
        onyxMethod: Onyx.METHOD.MERGE,
        key: ONYXKEYS.USER_WALLET,
        value: { walletLinkedAccountID: null },
    });
}

This guard ensures the clear fires only when the user is deleting their current default BA — the exact scenario that creates stale state. Deleting any other BA leaves walletLinkedAccountID untouched.

The failureData entries that revert walletLinkedAccountID to the deleted bankAccountID and reset isDefault on newBankAccountID (added by the if (newBankAccountID) block) can also be removed along with that block, since Fix 1 no longer passes newBankAccountID.

Fix 3 — Verify that the server's ADD_PERSONAL_BANK_ACCOUNT handler sets walletLinkedAccountID to the new account when no default is present. If the server already does this (as evidenced by Regions becoming default upon first addition per the preconditions), clearing walletLinkedAccountID in Fix 2 is sufficient — the next addPersonalBankAccount Pusher response will correctly set the new Regions ID as the linked account.

Note: addPersonalBankAccount's successData cannot directly set walletLinkedAccountID to the re-added Regions ID because the server assigns bankAccountID and that value is unknown to the frontend at call time. The server Pusher update after ADD_PERSONAL_BANK_ACCOUNT is the correct place for that assignment.

Fix 4 — Verify the badge consumer at src/pages/settings/Wallet/PaymentMethodList.tsx L136–144 (shouldShowDefaultBadge). No change is needed there; once walletLinkedAccountID is correctly set, the badge will render correctly.

What alternative solutions did you explore? (Optional)

• Eagerly set the re-added account as default in addPersonalBankAccount successData: Not implementable — the server-assigned bankAccountID of the new account is unknown at call time, so walletLinkedAccountID cannot be set in client-side successData.
• Keep auto-promoting WF at delete time but revert on re-add: Would require a flag (e.g. lastDeletedDefaultBankAccountID in Onyx) to detect the re-add scenario — unnecessary complexity vs. simply clearing the default at delete time and letting the server handle it on add.
• Guard the successData clear on !newBankAccountID instead of a dedicated flag: newBankAccountID is undefined for both non-default deletes and default deletes (after Fix 1 removes the computation). Using !newBankAccountID as the guard would therefore clear walletLinkedAccountID on every delete, including cases where the user removes a non-default BA — incorrectly nulling the current default. A dedicated isDefaultAccount boolean parameter is the correct scope guard.
• Send a MAKE_DEFAULT_PAYMENT_METHOD command from deletePaymentBankAccount: The existing code does not do this (confirmed by tracing outbound calls from deletePaymentBankAccount), and adding it would permanently lock WF as server-side default, making the bug worse.

[lorretheboy]

Proposal

What is the root cause of that problem?

The "Default" badge is driven entirely by userWallet.walletLinkedAccountID (this replaced trusting each account's isDefault flag, introduced in PR #51437 to stop two accounts showing the badge at once):

App/src/pages/settings/Wallet/PaymentMethodList.tsx

Lines 549 to 553 in 35a2f0a

	shouldShowDefaultBadge={shouldShowDefaultBadge(
	filteredPaymentMethodsWithoutStrings,
	invoiceTransferBankAccountID ? invoiceTransferBankAccountID === item.methodID : item.methodID === userWallet?.walletLinkedAccountID,
	shouldHideDefaultBadge,
	)}

When the user deletes the current default account, the app optimistically promotes the remaining account by writing its ID into USER_WALLET.walletLinkedAccountID (via getMakeDefaultPaymentOnyxData), with no success data to reconcile it later:

App/src/libs/actions/BankAccounts.ts

Lines 648 to 661 in 35a2f0a

	if (newBankAccountID) {
	const newDefaultPaymentMethodOnyxData = getMakeDefaultPaymentOnyxData(newBankAccountID);
	onyxData.optimisticData?.push(
	...(newDefaultPaymentMethodOnyxData as Array<OnyxUpdate<typeof ONYXKEYS.BANK_ACCOUNT_LIST | typeof ONYXKEYS.NVP_LAST_PAYMENT_METHOD | typeof ONYXKEYS.USER_WALLET>>),
	);
	onyxData.optimisticData?.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: ONYXKEYS.BANK_ACCOUNT_LIST,
	value: {
	[newBankAccountID]: {
	isDefault: true,
	},
	},
	});

Then when the new account is added, the backend makes it the default, but addPersonalBankAccount's Onyx data never updates walletLinkedAccountID:

App/src/libs/actions/BankAccounts.ts

Lines 532 to 549 in 35a2f0a

	successData: [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: ONYXKEYS.PERSONAL_BANK_ACCOUNT,
	value: {
	isLoading: false,
	errors: null,
	shouldShowSuccess: true,
	},
	},
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: ONYXKEYS.USER_WALLET,
	value: {
	currentStep: CONST.WALLET.STEP.ADDITIONAL_DETAILS,
	},
	},
	],

and nothing refetches the wallet — WalletPage only calls getPaymentMethods() on mount/reconnect:

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

Lines 399 to 404 in 35a2f0a

	useEffect(() => {
	if (network.isOffline) {
	return;
	}
	getPaymentMethods();
	}, [network.isOffline]);

So the chain is: delete writes a stale walletLinkedAccountID pointing at the old account → adding the new account never updates it → the badge (which trusts only walletLinkedAccountID) stays on the old account until a page refresh. The same stale value also breaks the "Make default payment method" button check in isCurrentPaymentMethodDefault.

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

Refetch the authoritative wallet data once adding a personal bank account succeeds: in AddPersonalBankAccountPage, call getPaymentMethods() (in a useEffect when shouldShowSuccess becomes true, or in exitFlow). OpenPaymentsPage returns the server's userWallet and bankAccountList, so walletLinkedAccountID points at the newly added account and the badge (and the "Make default" button) are correct without a refresh.

App/src/pages/AddPersonalBankAccountPage.tsx

Lines 48 to 60 in 35a2f0a

	const exitFlow = (shouldContinue = false) => {
	const exitReportID = personalBankAccount?.exitReportID;
	const onSuccessFallbackRoute = personalBankAccount?.onSuccessFallbackRoute ?? '';
	if (exitReportID) {
	Navigation.dismissModalWithReport({reportID: exitReportID});
	} else if (shouldContinue && onSuccessFallbackRoute) {
	continueSetup(kycWallRef, onSuccessFallbackRoute);
	} else {
	goBack();
	clearPersonalBankAccount();
	}
	};

There is precedent for this pattern — ReimbursementAccountPage already calls getPaymentMethods() after a bank account is connected:

App/src/pages/ReimbursementAccount/ReimbursementAccountPage.tsx

Line 166 in 35a2f0a

getPaymentMethods();

This fixes it at the single convergence point (the Onyx USER_WALLET key) rather than patching the badge logic, so every consumer of walletLinkedAccountID is corrected.

What alternative solutions did you explore? (Optional)

Have the backend include the updated userWallet in the AddPersonalBankAccount response onyxData — cleaner (no extra request) but requires an Auth change; the frontend refetch works today.

[samranahm]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-16 02:45:44 UTC.

Proposal

What is the root cause of that problem?

When a user deletes the current default bank account and then re-adds it, the remaining bank account (Wells Fargo ending in 1111) stays flagged as default and the newly added Regions account is never promoted.

The problem is in how the default is reassigned during deletion versus during add. The Default badge reads userWallet.walletLinkedAccountID:

App/src/pages/settings/Wallet/PaymentMethodList.tsx

Lines 549 to 553 in 646f5f5

	shouldShowDefaultBadge={shouldShowDefaultBadge(
	filteredPaymentMethodsWithoutStrings,
	invoiceTransferBankAccountID ? invoiceTransferBankAccountID === item.methodID : item.methodID === userWallet?.walletLinkedAccountID,
	shouldHideDefaultBadge,
	)}

When the default BA is deleted, the app optimistically promotes the only remaining payment method to default via deletePaymentBankAccount (writes walletLinkedAccountID / isDefault):

App/src/libs/actions/BankAccounts.ts

Lines 648 to 678 in 646f5f5

	if (newBankAccountID) {
	const newDefaultPaymentMethodOnyxData = getMakeDefaultPaymentOnyxData(newBankAccountID);
	onyxData.optimisticData?.push(
	...(newDefaultPaymentMethodOnyxData as Array<OnyxUpdate<typeof ONYXKEYS.BANK_ACCOUNT_LIST | typeof ONYXKEYS.NVP_LAST_PAYMENT_METHOD | typeof ONYXKEYS.USER_WALLET>>),
	);
	onyxData.optimisticData?.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: ONYXKEYS.BANK_ACCOUNT_LIST,
	value: {
	[newBankAccountID]: {
	isDefault: true,
	},
	},
	});
	onyxData.failureData?.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: ONYXKEYS.USER_WALLET,
	value: {
	walletLinkedAccountID: bankAccountID,
	walletLinkedAccountType: CONST.PAYMENT_METHODS.PERSONAL_BANK_ACCOUNT,
	},
	});
	onyxData.failureData?.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: ONYXKEYS.BANK_ACCOUNT_LIST,
	value: {
	[newBankAccountID]: {
	isDefault: false,
	},
	},
	});

Later, when the new BA is added, addPersonalBankAccount does not clear that promoted default, so a default already exists and the newly added account is never linked as default:

App/src/libs/actions/BankAccounts.ts

Lines 520 to 549 in 646f5f5

	const onyxData: OnyxData<typeof ONYXKEYS.PERSONAL_BANK_ACCOUNT | typeof ONYXKEYS.USER_WALLET | typeof ONYXKEYS.NVP_LAST_PAYMENT_METHOD> = {
	optimisticData: [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: ONYXKEYS.PERSONAL_BANK_ACCOUNT,
	value: {
	isLoading: true,
	errors: null,
	plaidAccountID: account.plaidAccountID,
	},
	},
	],
	successData: [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: ONYXKEYS.PERSONAL_BANK_ACCOUNT,
	value: {
	isLoading: false,
	errors: null,
	shouldShowSuccess: true,
	},
	},
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: ONYXKEYS.USER_WALLET,
	value: {
	currentStep: CONST.WALLET.STEP.ADDITIONAL_DETAILS,
	},
	},
	],

So the gap is: deletion promotes a fallback default, and the subsequent add never re-evaluates which account should actually be default, leaving the stale promotion in place.

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

1. In the personal bank account add success flow, reconcile the default so the newly added bank account becomes the default after a delete-time auto-promotion.

When PERSONAL_BANK_ACCOUNT.shouldShowSuccess is true and the created account is present in BANK_ACCOUNT_LIST (match by plaidAccountID), clear the previously promoted default and set the new account as default by reusing the existing action:

if (userWallet?.walletLinkedAccountID !== newBankAccountID) {
    makeDefaultPaymentMethod(newBankAccountID, 0);
}

Wire that into the add-success surfaces (AddPersonalBankAccountPage and the Enable Payments wallet flow):

App/src/pages/AddPersonalBankAccountPage.tsx

Lines 26 to 60 in 646f5f5

	function AddPersonalBankAccountPage() {
	const styles = useThemeStyles();
	const {translate} = useLocalize();
	const [personalBankAccount] = useOnyx(ONYXKEYS.PERSONAL_BANK_ACCOUNT);
	const shouldShowSuccess = personalBankAccount?.shouldShowSuccess ?? false;
	const topmostFullScreenRoute = navigationRef.current?.getRootState()?.routes.findLast((route) => isFullScreenName(route.name));
	const kycWallRef = useContext(KYCWallContext);
	const goBack = () => {
	switch (topmostFullScreenRoute?.name) {
	case NAVIGATORS.SETTINGS_SPLIT_NAVIGATOR:
	Navigation.goBack(ROUTES.SETTINGS_WALLET);
	break;
	case NAVIGATORS.REPORTS_SPLIT_NAVIGATOR:
	Navigation.closeRHPFlow();
	break;
	default:
	Navigation.goBack();
	break;
	}
	};
	const exitFlow = (shouldContinue = false) => {
	const exitReportID = personalBankAccount?.exitReportID;
	const onSuccessFallbackRoute = personalBankAccount?.onSuccessFallbackRoute ?? '';
	if (exitReportID) {
	Navigation.dismissModalWithReport({reportID: exitReportID});
	} else if (shouldContinue && onSuccessFallbackRoute) {
	continueSetup(kycWallRef, onSuccessFallbackRoute);
	} else {
	goBack();
	clearPersonalBankAccount();
	}
	};

App/src/libs/actions/PaymentMethods.ts

Lines 151 to 160 in 646f5f5

	function makeDefaultPaymentMethod(bankAccountID: number, fundID: number, previousPaymentMethod?: PaymentMethod, currentPaymentMethod?: PaymentMethod) {
	const parameters: MakeDefaultPaymentMethodParams = {
	bankAccountID,
	fundID,
	};
	API.write(WRITE_COMMANDS.MAKE_DEFAULT_PAYMENT_METHOD, parameters, {
	optimisticData: getMakeDefaultPaymentOnyxData(bankAccountID, fundID, previousPaymentMethod, currentPaymentMethod, true),
	failureData: getMakeDefaultPaymentOnyxData(bankAccountID, fundID, previousPaymentMethod, currentPaymentMethod, false),
	});

Do not call getPaymentMethods() in that same moment, or OpenPaymentsPage can briefly overwrite walletLinkedAccountID with the old default and blink the badge.

2. Keep the deletion auto-promotion for UX, but treat it as provisional: the add-success makeDefaultPaymentMethod call above is what lets the newly added account take over, so the delete-time fallback does not permanently block the new default.

Together these changes make the newly added BA become the default after deleting the previous default, matching the expected result.

What alternative solutions did you explore? (Optional)

Refetching getPaymentMethods() on add success alone: rejected, because the server may still return the delete-time fallback as walletLinkedAccountID until App explicitly makes the new account default.

Solution Verification Result

Kapture.2026-07-16.at.07.44.16.mp4




[mukhrr]

Proposal

What is the root cause of that problem?

The Wallet default badge intentionally uses USER_WALLET.walletLinkedAccountID as the source of truth, not bankAccount.isDefault.

App/src/pages/settings/Wallet/PaymentMethodList.tsx

Lines 549 to 552 in be792a8

	shouldShowDefaultBadge={shouldShowDefaultBadge(
	filteredPaymentMethodsWithoutStrings,
	invoiceTransferBankAccountID ? invoiceTransferBankAccountID === item.methodID : item.methodID === userWallet?.walletLinkedAccountID,
	shouldHideDefaultBadge,

This was introduced after PR #51437. The history shows the first approach tried to infer the latest/default account locally, then changed to userWallet.walletLinkedAccountID because that is the backend source of truth:

• 839e379b203 tried “latest bank account shows default badge”
• 9fd23d12781 added a latest-added Onyx key
• 65237d3f7c8 replaced that with userWallet.walletLinkedAccountID

So we should not go back to created, Plaid ID, or “latest item” heuristics.

The regression comes from an asymmetry between similar default-changing flows:

1. Manual “Make default payment method” updates USER_WALLET.walletLinkedAccountID through getMakeDefaultPaymentOnyxData().

App/src/libs/actions/PaymentMethods.ts

Lines 91 to 145 in be792a8

	function getMakeDefaultPaymentOnyxData(
	bankAccountID: number,
	fundID?: number,
	previousPaymentMethod?: PaymentMethod,
	currentPaymentMethod?: PaymentMethod,
	isOptimisticData = true,
	): Array<OnyxUpdate<typeof ONYXKEYS.USER_WALLET | typeof ONYXKEYS.BANK_ACCOUNT_LIST | typeof ONYXKEYS.FUND_LIST>> {
	const onyxData: Array<OnyxUpdate<typeof ONYXKEYS.USER_WALLET | typeof ONYXKEYS.BANK_ACCOUNT_LIST | typeof ONYXKEYS.FUND_LIST>> = [
	isOptimisticData
	? {
	onyxMethod: Onyx.METHOD.MERGE,
	key: ONYXKEYS.USER_WALLET,
	value: {
	walletLinkedAccountID: bankAccountID || fundID,
	walletLinkedAccountType: bankAccountID ? CONST.PAYMENT_METHODS.PERSONAL_BANK_ACCOUNT : CONST.PAYMENT_METHODS.DEBIT_CARD,
	// Only clear the error if this is optimistic data. If this is failure data, we do not want to clear the error that came from the server.
	errors: null,
	},
	}
	: {
	onyxMethod: Onyx.METHOD.MERGE,
	key: ONYXKEYS.USER_WALLET,
	value: {
	walletLinkedAccountID: bankAccountID || fundID,
	walletLinkedAccountType: bankAccountID ? CONST.PAYMENT_METHODS.PERSONAL_BANK_ACCOUNT : CONST.PAYMENT_METHODS.DEBIT_CARD,
	},
	},
	];
	if (previousPaymentMethod?.methodID) {
	onyxData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: previousPaymentMethod.accountType === CONST.PAYMENT_METHODS.PERSONAL_BANK_ACCOUNT ? ONYXKEYS.BANK_ACCOUNT_LIST : ONYXKEYS.FUND_LIST,
	value: {
	[previousPaymentMethod.methodID]: {
	isDefault: !isOptimisticData,
	},
	},
	});
	}
	if (currentPaymentMethod?.methodID) {
	onyxData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: currentPaymentMethod.accountType === CONST.PAYMENT_METHODS.PERSONAL_BANK_ACCOUNT ? ONYXKEYS.BANK_ACCOUNT_LIST : ONYXKEYS.FUND_LIST,
	value: {
	[currentPaymentMethod.methodID]: {
	isDefault: isOptimisticData,
	},
	},
	});
	}
	return onyxData;
	}

2. Deleting the current default bank account also updates USER_WALLET.walletLinkedAccountID optimistically to a replacement account. This was added in 13f4ef1233fc / refined in 575d49cb1513 to fix “default badge not reassigned when deleting the top default payment”.

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

Lines 301 to 339 in be792a8

	let newBankAccountID: number | undefined;
	if (paymentMethod.isSelectedPaymentMethodDefault) {
	const paymentCardList = fundList ?? {};
	const allPaymentMethods = formatPaymentMethods(bankAccountList ?? {}, paymentCardList, styles, translate);
	const remainingPaymentMethods = allPaymentMethods
	.filter(
	(method) =>
	method.methodID !== paymentMethod.methodID &&
	method.accountType === CONST.PAYMENT_METHODS.PERSONAL_BANK_ACCOUNT &&
	method.accountData?.type !== CONST.BANK_ACCOUNT.TYPE.BUSINESS &&
	method.accountData?.state === CONST.BANK_ACCOUNT.STATE.OPEN &&
	method.pendingAction !== CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE,
	)
	.sort((a, b) => {
	const aCreated = a.accountData?.created ?? '';
	const bCreated = b.accountData?.created ?? '';
	if (!aCreated && !bCreated) {
	return 0;
	}
	if (!aCreated) {
	return 1;
	}
	if (!bCreated) {
	return -1;
	}
	return new Date(bCreated).getTime() - new Date(aCreated).getTime();
	});
	if (remainingPaymentMethods.length > 0) {
	const newDefaultMethod = remainingPaymentMethods.at(0);
	newBankAccountID =
	newDefaultMethod?.accountType === CONST.PAYMENT_METHODS.PERSONAL_BANK_ACCOUNT ? (newDefaultMethod?.accountData?.bankAccountID ?? CONST.DEFAULT_NUMBER_ID) : undefined;
	}
	}
	if (paymentMethod.selectedPaymentMethodType === CONST.PAYMENT_METHODS.PERSONAL_BANK_ACCOUNT && bankAccountID) {
	const bankAccount = bankAccountList?.[paymentMethod.methodID] ?? {};
	deletePaymentBankAccount(bankAccountID, personalPolicyID, lastUsedPaymentMethods, bankAccount, newBankAccountID);

App/src/libs/actions/BankAccounts.ts

Lines 648 to 668 in be792a8

	if (newBankAccountID) {
	const newDefaultPaymentMethodOnyxData = getMakeDefaultPaymentOnyxData(newBankAccountID);
	onyxData.optimisticData?.push(
	...(newDefaultPaymentMethodOnyxData as Array<OnyxUpdate<typeof ONYXKEYS.BANK_ACCOUNT_LIST | typeof ONYXKEYS.NVP_LAST_PAYMENT_METHOD | typeof ONYXKEYS.USER_WALLET>>),
	);
	onyxData.optimisticData?.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: ONYXKEYS.BANK_ACCOUNT_LIST,
	value: {
	[newBankAccountID]: {
	isDefault: true,
	},
	},
	});
	onyxData.failureData?.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: ONYXKEYS.USER_WALLET,
	value: {
	walletLinkedAccountID: bankAccountID,
	walletLinkedAccountType: CONST.PAYMENT_METHODS.PERSONAL_BANK_ACCOUNT,
	},

3. But adding a personal bank account does not update USER_WALLET.walletLinkedAccountID. Its success data only advances currentStep.

App/src/libs/actions/BankAccounts.ts

Lines 520 to 548 in be792a8

	const onyxData: OnyxData<typeof ONYXKEYS.PERSONAL_BANK_ACCOUNT | typeof ONYXKEYS.USER_WALLET | typeof ONYXKEYS.NVP_LAST_PAYMENT_METHOD> = {
	optimisticData: [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: ONYXKEYS.PERSONAL_BANK_ACCOUNT,
	value: {
	isLoading: true,
	errors: null,
	plaidAccountID: account.plaidAccountID,
	},
	},
	],
	successData: [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: ONYXKEYS.PERSONAL_BANK_ACCOUNT,
	value: {
	isLoading: false,
	errors: null,
	shouldShowSuccess: true,
	},
	},
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: ONYXKEYS.USER_WALLET,
	value: {
	currentStep: CONST.WALLET.STEP.ADDITIONAL_DETAILS,
	},
	},

In this issue’s exact flow, deleting Regions sets Wells Fargo as the local walletLinkedAccountID. Re-adding Regions does not replace that local wallet value, so the UI continues showing Wells Fargo as default even though the add flow should make the newly added account the default.

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

Make the AddPersonalBankAccount success response include/update the newly added bankAccountID in USER_WALLET.walletLinkedAccountID, the same way OpenPaymentsPage and MakeDefaultPaymentMethod use that field as the source of truth.

Then apply that returned Onyx data in the existing addPersonalBankAccount() success data. Do not change the badge logic in PaymentMethodList, because using walletLinkedAccountID is the non-regressing behavior established by PR #51437.

Small illustrative diff:

 successData: [
   {
     onyxMethod: Onyx.METHOD.MERGE,
     key: ONYXKEYS.PERSONAL_BANK_ACCOUNT,
     value: {
       isLoading: false,
       errors: null,
       shouldShowSuccess: true,
     },
   },
   {
     onyxMethod: Onyx.METHOD.MERGE,
     key: ONYXKEYS.USER_WALLET,
     value: {
       currentStep: CONST.WALLET.STEP.ADDITIONAL_DETAILS,
+      walletLinkedAccountID: newlyAddedBankAccountID,
+      walletLinkedAccountType: CONST.PAYMENT_METHODS.PERSONAL_BANK_ACCOUNT,
     },
   },
 ]

To avoid regressions:

• Keep PaymentMethodList using userWallet.walletLinkedAccountID; do not reintroduce latest-created/Plaid-ID logic.
• Only set walletLinkedAccountID from a real backend-confirmed bank account ID, not an optimistic temporary ID.
• Keep currentStep unchanged so the enable-payments/add-bank-account flow still advances normally.
• If the add command fails, do not change the wallet-linked account, so the fallback account chosen during delete remains intact.
• Confirm manual/non-Plaid bank accounts are covered, because the prior PR discussion explicitly noted some accounts can be added outside Plaid.

What alternative solutions did you explore? (Optional)

Calling OpenPaymentsPage after every successful add would refresh walletLinkedAccountID, but it adds an extra request and still works around the missing add-command Onyx update.

Inferring the default from created, Plaid ID, or local ordering was already explored in PR #51437 and rejected because walletLinkedAccountID is the source of truth and local heuristics can be unreliable.

[MobileMage]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-09 07:40:59 UTC.

Proposal

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

In Wallet, when a user has two personal bank accounts, deletes the one that is currently the default, and then re-adds a bank account, the newly added account is expected to become the default but does not. Instead the previously existing (older) account keeps the "Default" badge, so the account the user just added is not linked as the wallet default.

What is the root cause of that problem?

Since PR #51437 the "Default" badge is bound strictly to userWallet.walletLinkedAccountID. PaymentMethodList renders the badge only for the account whose methodID equals walletLinkedAccountID, ignoring each account's own isDefault flag (every open bank account carries isDefault: true, which is exactly why #51437 needed walletLinkedAccountID as the tiebreaker):

App/src/pages/settings/Wallet/PaymentMethodList.tsx

Lines 536 to 540 in 984116c

	shouldShowDefaultBadge={shouldShowDefaultBadge(
	filteredPaymentMethodsWithoutStrings,
	invoiceTransferBankAccountID ? invoiceTransferBankAccountID === item.methodID : item.methodID === userWallet?.walletLinkedAccountID,
	shouldHideDefaultBadge,
	)}

The frontend keeps walletLinkedAccountID in sync in only two flows: makeDefaultPaymentMethod (the "Make default" action) and the delete-the-default branch of deletePaymentBankAccount. When you delete the default account, WalletPage.deletePaymentMethod picks the newest surviving open personal account (remainingPaymentMethods.at(0)) as newBankAccountID and passes it down, and deletePaymentBankAccount promotes that account to default via getMakeDefaultPaymentOnyxData, which writes walletLinkedAccountID = newBankAccountID:

App/src/libs/actions/BankAccounts.ts

Lines 643 to 647 in 984116c

	if (newBankAccountID) {
	const newDefaultPaymentMethodOnyxData = getMakeDefaultPaymentOnyxData(newBankAccountID);
	onyxData.optimisticData?.push(
	...(newDefaultPaymentMethodOnyxData as Array<OnyxUpdate<typeof ONYXKEYS.BANK_ACCOUNT_LIST | typeof ONYXKEYS.NVP_LAST_PAYMENT_METHOD | typeof ONYXKEYS.USER_WALLET>>),
	);

Walking the repro: deleting the default Regions account re-links the wallet to the surviving Wells Fargo account (walletLinkedAccountID = WellsFargo, and the backend DeletePaymentBankAccount does the same). Re-adding Regions then calls addPersonalBankAccount, which adds the account and marks it isDefault: true but never touches walletLinkedAccountID — the add flow has no equivalent of the delete flow's promotion step. The backend only auto-links a freshly added account when the wallet has no valid linked account, and it already has one (Wells Fargo), so when the page mounts and calls getPaymentMethods() → OpenPaymentsPage, the server returns walletLinkedAccountID = WellsFargo. Both accounts now have isDefault: true, but the badge tiebreak item.methodID === userWallet?.walletLinkedAccountID resolves to Wells Fargo, not the newly added Regions — exactly the reported symptom.

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

Mirror the delete-default behavior in the add flow: when a personal bank account is successfully added and the wallet already has a linked default account, promote the newly added account to the wallet default so walletLinkedAccountID points to it. Because the new bankAccountID is assigned server-side, the promotion belongs in the add success path — once the new account appears in bankAccountList (with its isDefault: true), if a prior default existed we call the same helper the delete flow already uses:

// after the added account resolves and a previous default exists
makeDefaultPaymentMethod(newBankAccountID, 0, previousDefaultMethod, newlyAddedMethod);

This reuses makeDefaultPaymentMethod, which writes walletLinkedAccountID = newBankAccountID through getMakeDefaultPaymentOnyxData and persists it via MAKE_DEFAULT_PAYMENT_METHOD, keeping the badge and the backend in sync:

App/src/libs/actions/PaymentMethods.ts

Lines 147 to 151 in 984116c

	function makeDefaultPaymentMethod(bankAccountID: number, fundID: number, previousPaymentMethod?: PaymentMethod, currentPaymentMethod?: PaymentMethod) {
	const parameters: MakeDefaultPaymentMethodParams = {
	bankAccountID,
	fundID,
	};

It is safe because it only fires when a default already exists — the first-bank-account case is untouched (the backend auto-links the only account), and passing previousDefaultMethod flips the old account's optimistic isDefault correctly so we never end up with two badges.

What alternative solutions did you explore? (Optional)

Changing shouldShowDefaultBadge to pick the most-recently-created isDefault account instead of walletLinkedAccountID. Rejected because #51437 deliberately made walletLinkedAccountID the source of truth, and the "Make default" button and isCurrentPaymentMethodDefault also key off it — diverging the badge from walletLinkedAccountID would show "Default" on an account the wallet is not actually linked to, causing a payout/UX mismatch rather than fixing the underlying default assignment.

[melvin-bot]

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