[$250] Wallet - KYC flow doesn't trigger after adding bank account when paying another user

[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.3.84-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/TR-33913/folder/13177075/41237820/1441603496?sort=%2Bidentifier
Email or phone of affected tester (no customers): vquoc+2705@applausemail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Pixel 7 Pro/Android 16
App Component: Money Requests

Action Performed:

Preconditions: Both users in USD currency default
Steps:

1. Navigate to NewDot and open a 1:1 conversation with any user
2. Open the + menu and click "Pay [user]"
3. Enter any amount and continue
4. Verify the payment method selected in the confirm button is "Pay with personal account"
5. Confirm the payment
6. Verify the KYC verification flow is triggered (confirm additional details to process the payment)

KYC flow

1. Continue the flow with the bank details (below)
2. Click/tap Save and continue
3. Verify you proceed to the Onfido privacy page

Expected Result:

3. Verify you proceed to the Onfido privacy page

Actual Result:

The app goes back to the Add bank account page

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7163962_1779852194800.KYC_not_trigger.mp4

View all open jobs on GitHub

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

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022059702618953667070
• Upwork Job ID: 2059702618953667070
• Last Price Increase: 2026-05-27
• Automatic offers:
• samranahm | Contributor | 111562435

Issue Owner

Current Issue Owner: @samranahm

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

[MelvinBot]

Proposal

What is the root cause of that problem?

The step-selection logic in EnablePayments.tsx:69-71 unconditionally overrides userWallet.currentStep based on hasExpensifyPaymentMethod():

const enablePaymentsStep = !hasExpensifyPaymentMethod(paymentCardList, bankAccountList ?? {}, hasActivatedWallet)
    ? CONST.WALLET.STEP.ADD_BANK_ACCOUNT
    : userWallet?.currentStep || CONST.WALLET.STEP.ADDITIONAL_DETAILS;

When addPersonalBankAccount succeeds, its successData sets USER_WALLET.currentStep to ADDITIONAL_DETAILS but does not update BANK_ACCOUNT_LIST. The bank account list is only updated by the server response's onyxData. When EnablePayments.tsx re-renders, if BANK_ACCOUNT_LIST hasn't been updated yet (or the new account doesn't satisfy all criteria in hasExpensifyPaymentMethod — open, personal, US), the ternary forces the step back to ADD_BANK_ACCOUNT, ignoring that currentStep has already advanced.

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

In EnablePayments.tsx:69-71, respect currentStep when it has already advanced past ADD_BANK_ACCOUNT. Only fall back to the hasExpensifyPaymentMethod gate when currentStep is undefined or is itself ADD_BANK_ACCOUNT:

const currentStep = userWallet?.currentStep;
const enablePaymentsStep = (currentStep && currentStep !== CONST.WALLET.STEP.ADD_BANK_ACCOUNT)
    ? currentStep
    : (!hasExpensifyPaymentMethod(paymentCardList, bankAccountList ?? {}, hasActivatedWallet)
        ? CONST.WALLET.STEP.ADD_BANK_ACCOUNT
        : currentStep || CONST.WALLET.STEP.ADDITIONAL_DETAILS);

This way, once the backend advances currentStep to ADDITIONAL_DETAILS (or beyond), the user proceeds forward regardless of any timing gap in BANK_ACCOUNT_LIST updates.

What alternative solutions did you explore? (Optional)

Adding an optimistic BANK_ACCOUNT_LIST update to the addPersonalBankAccount successData was considered, but this is fragile — we'd need to fabricate a bank account object matching all server-side fields. The step-logic fix is simpler and directly addresses the root cause: the client shouldn't second-guess the server-driven currentStep.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.

[yusufdeveloper2903]

🚨 Edited by proposal-police: This proposal was edited at 2026-05-27 19:16:26 UTC.

Proposal

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

When a 1:1 chat user (no existing payment method) confirms a P2P pay via "Pay with personal account" and completes the bank-account setup flow, tapping the success-screen "Continue" button bounces them back to the Add bank account page instead of advancing into the KYC flow toward the Onfido privacy screen. Identity verification never runs, so the payment cannot complete.

What is the root cause of that problem?

After addPersonalBankAccount resolves, its successData only updates ONYXKEYS.PERSONAL_BANK_ACCOUNT (shouldShowSuccess: true) and ONYXKEYS.USER_WALLET (currentStep: ADDITIONAL_DETAILS). It does not write the new account to ONYXKEYS.BANK_ACCOUNT_LIST — that key is only filled in by the server's response/Pusher push, which is asynchronous with respect to the synchronous success-page "Continue" tap.

https://github.com/Expensify/App/blob/0eaf9f735fb43/src/libs/actions/BankAccounts.ts#L497-L514

"Continue" calls exitFlow(true) → continueSetup(kycWallRef, ROUTES.ENABLE_PAYMENTS), which immediately invokes kycWallRef.current.continueAction({goBackRoute: ROUTES.ENABLE_PAYMENTS}) in the same JS tick (Navigation.goBack has not flushed yet, and the parent SettlementButton's useOnyx(BANK_ACCOUNT_LIST) has not re-rendered with the freshly-added account).

https://github.com/Expensify/App/blob/0eaf9f735fb43/src/libs/actions/PaymentMethods.ts#L39-L48

Inside continueAction, hasExpensifyPaymentMethod(paymentCardList, bankAccountList, true) reads the stale empty bankAccountList and returns false, so the !isExpenseReport && bankAccountList !== null && !hasValidPaymentMethod guard fires the "no valid payment method" branch on line 287. The call has no paymentMethod/policy/iouPaymentType (only goBackRoute), so control falls through to setShouldShowAddPaymentMenu(true).

https://github.com/Expensify/App/blob/0eaf9f735fb43/src/components/KYCWall/BaseKYCWall.tsx#L281-L313

Now the second-pass AddPaymentMethodMenu opens. The mount-point — ConfirmationFooterContent's <SettlementButton …shouldShowPersonalBankAccountOption … /> — does not pass iouReport, so the popover sees iouReport === undefined. Consequently isIOU = isIOUReport(undefined) === false, canUseBusinessBankAccount = false, canUsePersonalBankAccount = shouldShowPersonalBankAccountOption === true, and isPersonalOnlyOption === true. The useEffect on lines 83–90 immediately fires onItemSelected(PERSONAL_BANK_ACCOUNT) without any user input.

https://github.com/Expensify/App/blob/0eaf9f735fb43/src/components/MoneyRequestConfirmationList/ConfirmationFooterContent.tsx#L82-L105
https://github.com/Expensify/App/blob/0eaf9f735fb43/src/components/AddPaymentMethodMenu.tsx#L73-L90

selectPaymentMethod(PERSONAL_BANK_ACCOUNT) → openPersonalBankAccountSetupView({shouldSetUpUSBankAccount: isIOUReport(iouReport)}). With iouReport still undefined, shouldSetUpUSBankAccount === false, so we Navigation.navigate(ROUTES.SETTINGS_ADD_BANK_ACCOUNT.getRoute(…)) — landing on InternationalDepositAccount (header "Add bank account"), which is exactly the page the tester observes after the bounce.

https://github.com/Expensify/App/blob/0eaf9f735fb43/src/libs/actions/BankAccounts.ts#L119-L139

The parallel AddDebitCardPage / ActivateStep exits do not hit this bug because they call continueSetup(kycWallRef) with no fallbackRoute, so continueAction is invoked with goBackRoute=undefined and the activated-wallet branch's existing goBackRoute !== enablePaymentsRoute guard (line 322) takes a different path.

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

Apply the same goBackRoute === enablePaymentsRoute short-circuit that already protects the activated-wallet branch to the missing-payment-method branch. The goBackRoute === enablePaymentsRoute predicate is the canonical "we are continuing a KYC setup, not initiating one" signal — every caller of continueSetup that passes a fallback (AddPersonalBankAccountPage.exitFlow, AddBankAccount.exitFlow, …) is doing so from a success path, so re-gating on bankAccountList is wrong by construction at that point.

In src/components/KYCWall/BaseKYCWall.tsx around line 287:

-            if ((isExpenseReport && !hasOpenConnectedBusinessBankAccount) || (!isExpenseReport && bankAccountList !== null && !hasValidPaymentMethod)) {
+            const isContinuingKYC = !!goBackRoute && goBackRoute === enablePaymentsRoute;
+            if (!isContinuingKYC && ((isExpenseReport && !hasOpenConnectedBusinessBankAccount) || (!isExpenseReport && bankAccountList !== null && !hasValidPaymentMethod))) {
                 Log.info('[KYC Wallet] User does not have valid payment method');

After the guard is skipped, control falls through to the existing !isExpenseReport block on line 315. There, hasActivatedWallet === false and !policy, so the activated-wallet check is hit, and its line-322 if (goBackRoute !== enablePaymentsRoute) already no-ops the redundant Navigation.navigate(enablePaymentsRoute) (because the synchronous Navigation.goBack(ROUTES.ENABLE_PAYMENTS) from continueSetup is already pending). continueAction then returns, the goBack flushes, EnablePaymentsPage mounts at currentStep === ADDITIONAL_DETAILS, renders <AdditionalDetailsStep />, and submission of that step advances userWallet.currentStep to ONFIDO on the server response — exactly the expected OnfidoPrivacy landing.

Regression check on continueAction callers — every other call path passes goBackRoute === undefined, so isContinuingKYC === false and the new guard does not change behavior for them:

• AddDebitCardPage.tsx: continueSetup(kycWallRef) (no fallback) → unaffected.
• ActivateStep.tsx: continueSetup(kycWallRef) (no fallback) → unaffected.
• pages/EnablePayments/AddBankAccount/AddBankAccount.tsx and pages/AddPersonalBankAccountPage.tsx: both pass onSuccessFallbackRoute from PERSONAL_BANK_ACCOUNT, which is set by setPersonalBankAccountContinueKYCOnSuccess to either ROUTES.ENABLE_PAYMENTS (Pay) or ROUTES.SETTINGS_WALLET (wallet page). For the ROUTES.ENABLE_PAYMENTS case (our bug), the new guard short-circuits and the user lands on EnablePaymentsPage; for ROUTES.SETTINGS_WALLET, goBackRoute !== enablePaymentsRoute, so the guard does not trigger and the existing behavior is preserved.
• Direct render-time invocation from KYCWall (BaseKYCWall.tsx:399) is the original Pay click, where goBackRoute is undefined and the guard does not fire.

Test plan:

• Pay → 1:1 → "Pay with personal account" → enter bank details in the substep flow → Confirm → tap "Continue" on the success page → verify the next screen is the OnfidoPrivacy privacy page (header "Verify identity"), not the "Add bank account" country selector.
• Pay → 1:1 with a user who already has KYC complete: verify "Continue" on the success page still resumes the payment (gated action) instead of stopping at EnablePaymentsPage.
• Wallet → "Enable wallet" entry: verify the new EnablePayments.tsx flow still works end-to-end (goBackRoute is ROUTES.SETTINGS_WALLET, not ROUTES.ENABLE_PAYMENTS, so the guard is inert).
• AddDebitCardPage happy path: verify the debit-card success still resumes the gated payment (no fallbackRoute passed → guard inert).

Files touched: src/components/KYCWall/BaseKYCWall.tsx only.

What alternative solutions did you explore? (Optional)

1. Optimistically push the new account into BANK_ACCOUNT_LIST from addPersonalBankAccount's successData. Rejected: we don't know the server-assigned bankAccountID, verification state, account type, or routing/account numbers in the optimistic shape required by hasExpensifyPaymentMethod. Fabricating a placeholder entry leaks into WalletPage, PaymentMethodList, MoneyReportHeader, and other consumers of the key until the server push reconciles it.

2. Short-circuit on personalBankAccount.shouldShowSuccess instead of goBackRoute. Equivalent in this scenario, but conceptually less precise — shouldShowSuccess is a UI flag for the post-add screen and persists until clearPersonalBankAccount runs, so it could mis-suppress the guard in unrelated re-entries to continueAction. goBackRoute is a per-call argument, scoped exactly to the "continuing a setup" intent.

3. Make AddPersonalBankAccountPage.exitFlow(true) bypass continueSetup and just Navigation.navigate(ROUTES.ENABLE_PAYMENTS) directly. Rejected: the gated payment action (the original Pay) is wired through kycWallRef.current.continueAction. Skipping it here breaks the case where the user has already completed KYC and the bank-add success screen should resume the payment directly rather than re-enter EnablePaymentsPage.

4. Pass iouReport into SettlementButton from ConfirmationFooterContent so the AddPaymentMethodMenu auto-fire stops mis-routing to the international/country picker. This would change the bounce destination from SETTINGS_ADD_BANK_ACCOUNT to SETTINGS_ADD_US_BANK_ACCOUNT, but the user would still bounce back into a bank-setup screen — the underlying race in continueAction is the root cause, and only fixing the auto-fire treats the symptom.

[MobileMage]

🚨 Edited by proposal-police: This proposal was edited at 2026-05-27 18:35:55 UTC.

Proposal

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

After tapping "Pay with personal account" and completing the personal bank account setup (Plaid/manual → personal info → confirm), tapping "Continue" on the success screen sends the user back to the "Add bank account" page instead of advancing into the KYC flow (Additional Details → Onfido → Terms).

What is the root cause of that problem?

The root cause is a stale-closure race in BaseKYCWall.continueAction. After the bank account is added successfully, exitFlow(true) calls continueSetup(kycWallRef, ROUTES.ENABLE_PAYMENTS). continueSetup calls Navigation.goBack(ROUTES.ENABLE_PAYMENTS) followed immediately by kycWallRef.current.continueAction({goBackRoute: ROUTES.ENABLE_PAYMENTS}) — both run synchronously in the same microtask.

App/src/libs/actions/PaymentMethods.ts

Lines 39 to 48 in 650d46c

	function continueSetup(kycWallRef: RefObject<KYCWallRef | null>, fallbackRoute?: Route) {
	if (!kycWallRef.current?.continueAction) {
	Navigation.goBack(fallbackRoute);
	return;
	}
	// Close the screen (Add Debit Card, Add Bank Account, or Enable Payments) on success and continue with setup
	Navigation.goBack(fallbackRoute);
	kycWallRef.current.continueAction({goBackRoute: fallbackRoute});
	}

continueAction is a useCallback in BaseKYCWall that captures bankAccountList from its closure. addPersonalBankAccount does not include BANK_ACCOUNT_LIST in its client-side successData — it only sets PERSONAL_BANK_ACCOUNT.shouldShowSuccess and USER_WALLET.currentStep:

App/src/libs/actions/BankAccounts.ts

Lines 485 to 525 in 650d46c

	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,
	},
	},
	],
	failureData: [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: ONYXKEYS.PERSONAL_BANK_ACCOUNT,
	value: {
	isLoading: false,
	errors: getMicroSecondOnyxErrorWithTranslationKey('walletPage.addBankAccountFailure'),
	},
	},
	],
	};

The bank account list is updated exclusively by the server's response onyxData. Even though that data arrives in the same HTTP response as the successData, the KYCWall component (rendered by SettlementButton in the chat report page) may not have re-rendered and re-created continueAction with the updated list by the time continueSetup invokes it. The useImperativeHandle that writes continueAction to kycWallRef.current runs in React's commit phase, which hasn't happened yet because we're still inside the synchronous event handler that started with the user's "Continue" tap.

So continueAction evaluates hasExpensifyPaymentMethod(paymentCardList, bankAccountList, shouldIncludeDebitCard) with a stale empty bankAccountList and gets false. It enters the "no valid payment method" block:

App/src/components/KYCWall/BaseKYCWall.tsx

Lines 287 to 313 in 650d46c

	if ((isExpenseReport && !hasOpenConnectedBusinessBankAccount) || (!isExpenseReport && bankAccountList !== null && !hasValidPaymentMethod)) {
	Log.info('[KYC Wallet] User does not have valid payment method');
	if (!shouldIncludeDebitCard || (isFromWalletPage && !hasValidPaymentMethod)) {
	selectPaymentMethod(CONST.PAYMENT_METHODS.PERSONAL_BANK_ACCOUNT);
	return;
	}
	if (paymentMethod || policy) {
	setShouldShowAddPaymentMenu(false);
	selectPaymentMethod(paymentMethod, policy);
	return;
	}
	if (iouPaymentType && isExpenseReport) {
	setShouldShowAddPaymentMenu(false);
	selectPaymentMethod(CONST.PAYMENT_METHODS.BUSINESS_BANK_ACCOUNT);
	return;
	}
	const clickedElementLocation = getClickedTargetLocation(targetElement as HTMLDivElement);
	const position = getAnchorPosition(clickedElementLocation);
	setPositionAddPaymentMenu(position);
	setShouldShowAddPaymentMenu(true);
	return;

Since continueSetup passes no paymentMethod, policy, or iouPaymentType — only goBackRoute — all three specific sub-conditions fail and the code falls through to setShouldShowAddPaymentMenu(true). AddPaymentMethodMenu then auto-fires for P2P IOUs because isPersonalOnlyOption is true (debit cards are disabled for P2P):

App/src/components/AddPaymentMethodMenu.tsx

Lines 83 to 90 in 650d46c

	useEffect(() => {
	if (!isVisible || !isPersonalOnlyOption || isLoadingIntroSelected) {
	return;
	}
	completePaymentOnboarding(CONST.PAYMENT_SELECTED.PBA, introSelected, isSelfTourViewed, betas, currentUserAccountID);
	onItemSelected(CONST.PAYMENT_METHODS.PERSONAL_BANK_ACCOUNT);
	}, [betas, currentUserAccountID, introSelected, isLoadingIntroSelected, isPersonalOnlyOption, isVisible, onItemSelected, isSelfTourViewed]);

This calls onItemSelected(PERSONAL_BANK_ACCOUNT) → KYCWall's selectPaymentMethod(PERSONAL_BANK_ACCOUNT) → openPersonalBankAccountSetupView({shouldSetUpUSBankAccount: true}) → Navigation.navigate(ROUTES.SETTINGS_ADD_US_BANK_ACCOUNT) — back to the "Add bank account" page.

The core issue is that continueAction conflates two roles: (a) initiating a KYC flow from scratch (where the payment-method gate is necessary), and (b) continuing an in-progress KYC flow after bank account addition (where the gate is harmful). The existing goBackRoute === enablePaymentsRoute guard at line 323 correctly handles case (b), but it's positioned inside the "user has a valid payment method" branch — it's never reached when hasExpensifyPaymentMethod returns false.

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

In BaseKYCWall.tsx, hoist the goBackRoute === enablePaymentsRoute check above the payment-method gate. When goBackRoute matches enablePaymentsRoute, the caller is continueSetup returning from a successful payment-method addition — the user is already being routed to EnablePaymentsPage where the wallet's currentStep (set to ADDITIONAL_DETAILS by addPersonalBankAccount successData) will drive step rendering. Skip the payment-method re-evaluation and proceed directly to the wallet-activation check.

App/src/components/KYCWall/BaseKYCWall.tsx

Lines 257 to 339 in 650d46c

	const continueAction = useCallback(
	(params?: ContinueActionParams) => {
	const {event, iouPaymentType, paymentMethod, policy, goBackRoute} = params ?? {};
	const currentSource = walletTerms?.source ?? source;
	/**
	* Set the source, so we can tailor the process according to how we got here.
	* We do not want to set this on mount, as the source can change upon completing the flow, e.g. when upgrading the wallet to Gold.
	*/
	setKYCWallSource(source, chatReportID);
	if (shouldShowAddPaymentMenu) {
	setShouldShowAddPaymentMenu(false);
	return;
	}
	// Use event target as fallback if anchorRef is null for safety
	const targetElement = anchorRef.current ?? (event?.currentTarget as HTMLDivElement);
	transferBalanceButtonRef.current = targetElement;
	const isExpenseReport = isExpenseReportReportUtils(iouReport);
	const paymentCardList = fundList ?? {};
	const hasOpenConnectedBusinessBankAccount = getOpenConnectedToPolicyBusinessBankAccounts(bankAccountList, policy).length > 0;
	const hasValidPaymentMethod = hasExpensifyPaymentMethod(paymentCardList, bankAccountList, shouldIncludeDebitCard);
	const isFromWalletPage = source === CONST.KYC_WALL_SOURCE.ENABLE_WALLET || source === CONST.KYC_WALL_SOURCE.TRANSFER_BALANCE;
	// Check if the user needs to add or select a payment method before continuing.
	// - For expense reports: Proceeds if no accounts that are connected are valid and usable (`OPEN`)
	// - For other expenses: Proceeds if the user lacks a valid personal bank account or debit card
	if ((isExpenseReport && !hasOpenConnectedBusinessBankAccount) || (!isExpenseReport && bankAccountList !== null && !hasValidPaymentMethod)) {
	Log.info('[KYC Wallet] User does not have valid payment method');
	if (!shouldIncludeDebitCard || (isFromWalletPage && !hasValidPaymentMethod)) {
	selectPaymentMethod(CONST.PAYMENT_METHODS.PERSONAL_BANK_ACCOUNT);
	return;
	}
	if (paymentMethod || policy) {
	setShouldShowAddPaymentMenu(false);
	selectPaymentMethod(paymentMethod, policy);
	return;
	}
	if (iouPaymentType && isExpenseReport) {
	setShouldShowAddPaymentMenu(false);
	selectPaymentMethod(CONST.PAYMENT_METHODS.BUSINESS_BANK_ACCOUNT);
	return;
	}
	const clickedElementLocation = getClickedTargetLocation(targetElement as HTMLDivElement);
	const position = getAnchorPosition(clickedElementLocation);
	setPositionAddPaymentMenu(position);
	setShouldShowAddPaymentMenu(true);
	return;
	}
	if (!isExpenseReport) {
	// Ask the user to upgrade to a gold wallet as this means they have not yet gone through our Know Your Customer (KYC) checks
	const hasActivatedWallet = userWallet?.tierName && [CONST.WALLET.TIER_NAME.GOLD, CONST.WALLET.TIER_NAME.PLATINUM].some((name) => name === userWallet.tierName);
	if (!hasActivatedWallet && !policy) {
	Log.info('[KYC Wallet] User does not have active wallet');
	// If the goBackRoute is the enablePaymentsRoute there's no need to directly navigate to it here
	if (goBackRoute !== enablePaymentsRoute) {
	Navigation.navigate(enablePaymentsRoute);
	}
	return;
	}
	if (policy || (paymentMethod && (!hasActivatedWallet || paymentMethod !== CONST.PAYMENT_METHODS.PERSONAL_BANK_ACCOUNT))) {
	setShouldShowAddPaymentMenu(false);
	selectPaymentMethod(paymentMethod, policy);
	return;
	}
	}
	Log.info('[KYC Wallet] User has valid payment method and passed KYC checks or did not need them');
	onSuccessfulKYC(iouPaymentType, currentSource);

Concretely, before line 287, add:

if (!isExpenseReport && goBackRoute && goBackRoute === enablePaymentsRoute) {
    return;
}

This short-circuits the function for the specific case where continueSetup invokes continueAction after a successful bank-account or debit-card addition. The Navigation.goBack(enablePaymentsRoute) call in continueSetup has already navigated to EnablePaymentsPage, and the wallet's server-driven currentStep will render the correct KYC step. No payment-method re-evaluation is needed.

This is safe for all callers:

• Initial KYC trigger (user taps Pay button): goBackRoute is undefined (not passed by triggerKYCFlow), so the guard doesn't fire.
• Expense reports: guarded by !isExpenseReport.
• Wallet page flow: goBackRoute is ROUTES.SETTINGS_WALLET, which doesn't match enablePaymentsRoute (ROUTES.ENABLE_PAYMENTS), so the guard doesn't fire.

What alternative solutions did you explore? (Optional)

Including the new bank account in addPersonalBankAccount's successData for BANK_ACCOUNT_LIST would make hasExpensifyPaymentMethod return true immediately, but we don't know the server-assigned bankAccountID or the full accountData shape client-side, so the optimistic entry would be incomplete and could mis-render in other consumers of BANK_ACCOUNT_LIST until the server push reconciles it.

[Abdulloh0109]

Proposal

What is the root cause of that problem?
I traced the full Pay → KYC → Bank → expected-Onfido chain and found the bug lives in BaseKYCWall.continueAction, not in the EnablePayments page I initially suspected.

Step-by-step evidence chain for the symptom "goes back to Add bank account page":

Pay click triggers KYC. SettlementButton/index.tsx:565 and PayPrimaryAction.tsx:199 mount KYCWall with enablePaymentsRoute=ROUTES.ENABLE_PAYMENTS. In PaymentUtils.ts:251-252, triggerKYCFlow({event, iouPaymentType, policy}) and setPersonalBankAccountContinueKYCOnSuccess(ROUTES.ENABLE_PAYMENTS) run, which writes onSuccessFallbackRoute = ROUTES.ENABLE_PAYMENTS into PERSONAL_BANK_ACCOUNT via BankAccounts.ts:290-291.

User is routed to the US bank account entry. BaseKYCWall.tsx:140 calls openPersonalBankAccountSetupView({shouldSetUpUSBankAccount: isIOUReport(iouReport)}). In BankAccounts.ts:134-136, because shouldSetUpUSBankAccount=true, it navigates to ROUTES.SETTINGS_ADD_US_BANK_ACCOUNT. That route is wired to AddPersonalBankAccountPage.tsx in src/libs/Navigation/AppNavigator/ModalStackNavigators/index.tsx:513.

AddPersonalBankAccountPage renders PersonalInfoPage. By default it returns (AddPersonalBankAccountPage.tsx:86), which runs useSubStep with bodyContentWithPlaid = [PlaidBankAccount, LegalName, Address, PhoneNumber, Confirmation] (PersonalInfo.tsx:22, 75-79). User completes the substeps and the last "Save and continue" press fires onFinished → submitBankAccountForm → addPersonalBankAccount(accountData, personalPolicyID) at PersonalInfo.tsx:42-63.

Server successData advances state. BankAccounts.ts:497-514 merges PERSONAL_BANK_ACCOUNT.shouldShowSuccess=true and USER_WALLET.currentStep=ADDITIONAL_DETAILS. Critically, BANK_ACCOUNT_LIST is NOT updated by successData — the new account only lands in that key later, via the next OpenPaymentsPage read or a Pusher push, and even then needs OPEN status to count.

Success ConfirmationPage shows briefly. AddPersonalBankAccountPage.tsx:58-83 branches on shouldShowSuccess and renders a ConfirmationPage titled bankAccount.addBankAccount (line 68) — the same header label used on the substep flow, which is why the user describes the eventual state as "Add bank account page". User taps Continue → exitFlow(true) (line 77).

Bug: continueSetup re-runs the KYC gating check on stale data. exitFlow at AddPersonalBankAccountPage.tsx:42-54 reads onSuccessFallbackRoute=ROUTES.ENABLE_PAYMENTS and calls continueSetup(kycWallRef, ROUTES.ENABLE_PAYMENTS). PaymentMethods.ts:39-48 does Navigation.goBack(ROUTES.ENABLE_PAYMENTS) and then kycWallRef.current.continueAction({goBackRoute: ROUTES.ENABLE_PAYMENTS}).

continueAction re-checks hasExpensifyPaymentMethod and falls into the "no payment method" branch. BaseKYCWall.tsx:281 recomputes hasValidPaymentMethod = hasExpensifyPaymentMethod(paymentCardList, bankAccountList, shouldIncludeDebitCard). Because BANK_ACCOUNT_LIST doesn't yet contain the just-added account in OPEN state, hasValidPaymentMethod=false. The IOU branch of the condition at line 287 (!isExpenseReport && bankAccountList !== null && !hasValidPaymentMethod) is true. Depending on shouldIncludeDebitCard and source, control either calls selectPaymentMethod(CONST.PAYMENT_METHODS.PERSONAL_BANK_ACCOUNT) directly (lines 290-292) or pops the AddPaymentMethodMenu (lines 307-311). The former calls openPersonalBankAccountSetupView({shouldSetUpUSBankAccount: true}) again at BaseKYCWall.tsx:140, which re-navigates to ROUTES.SETTINGS_ADD_US_BANK_ACCOUNT — i.e. the user lands back on the same "Add bank account" entry.

Why the parallel AddDebitCardPage flow is unaffected: AddDebitCardPage.tsx:44 calls continueSetup(kycWallRef) with NO fallbackRoute, so continueAction is invoked with goBackRoute=undefined. The bank-account success path is the only caller that funnels a stale Onyx state into continueAction while expecting it to skip re-gating, because successData updates USER_WALLET.currentStep and PERSONAL_BANK_ACCOUNT.shouldShowSuccess but the bank-list source-of-truth used by hasExpensifyPaymentMethod lags behind.

What changes do you think we should make in order to solve the problem?
Fix layer is the selector/guard inside continueAction — that is the single decision point that re-routes the user. Fixing it lower (forcing an optimistic OPEN entry into BANK_ACCOUNT_LIST from successData) is unsafe because we don't have the server-assigned bankAccountID or verified status, and fabricating one would leak into other consumers of that key.

Concrete change in src/components/KYCWall/BaseKYCWall.tsx:287-313:

Read personalBankAccount?.shouldShowSuccess and userWallet?.currentStep via useOnyx at the top of KYCWall (alongside the existing userWallet/bankAccountList reads at lines 61-64).
Before the no-payment-method branch at line 287, add a short-circuit: if goBackRoute === enablePaymentsRoute AND (personalBankAccount?.shouldShowSuccess is true OR userWallet?.currentStep is set to a value beyond ADD_BANK_ACCOUNT), skip the entire branch and fall through to the !hasActivatedWallet block at lines 315-328. That block already handles the "navigate to enable payments to finish KYC" intent and respects the goBackRoute === enablePaymentsRoute no-op at lines 322-325.
Effect: after the user completes the bank-account success screen and presses Continue, continueSetup still does Navigation.goBack(ROUTES.ENABLE_PAYMENTS) (which lands on EnablePaymentsPage.tsx:23), and the subsequent continueAction call no longer pulls them back to the bank-account entry. EnablePaymentsPage.tsx:80-94 then switches on userWallet.currentStep=ADDITIONAL_DETAILS and renders , which advances to per its normal completion logic.

Files touched: src/components/KYCWall/BaseKYCWall.tsx only.

Files NOT touched: BankAccounts.ts, PaymentUtils.ts, PaymentMethods.ts, AddPersonalBankAccountPage.tsx, EnablePaymentsPage.tsx, PersonalInfo.tsx. No changes to successData, no changes to Navigation.goBack behavior, no changes to any substep.

Platforms: BaseKYCWall.tsx is shared by web (KYCWall/index.tsx) and native (KYCWall/index.native.ts:1-3), so the fix lands on Android App, iOS App, and Windows/Chrome simultaneously — matching the three platforms checked in the issue. I did not run a simulator/browser repro; my analysis is code-trace only.

Edge cases:

Offline: successData does not run while offline, so shouldShowSuccess stays false and the existing flow remains intact — no regression.
Optimistic rollback / API failure: failureData at BankAccounts.ts:515-524 sets errors but does NOT set shouldShowSuccess; the guard does not trigger, and the user stays on the substep with surfaced errors.
Fresh wallet user (no currentStep and no prior bank): shouldShowSuccess=false and currentStep is unset → guard does not trigger, regular menu logic applies.
KYC for VBBA / Expense Report path: line 287 also has the isExpenseReport && !hasOpenConnectedBusinessBankAccount branch — my guard sits AFTER both conditions are evaluated and only short-circuits the IOU branch when the success flag is set, so business bank flows are untouched.
Regression check on continueAction callers:

useImperativeHandle exposes continueAction via kycWallRef (BaseKYCWall.tsx:373-379).
continueSetup is the only consumer that passes goBackRoute explicitly (PaymentMethods.ts:47). Its four callers: AddPersonalBankAccountPage.tsx:49 (bank account success — the case we're fixing), AddDebitCardPage.tsx:44 (no fallbackRoute → guard does not trigger → safe), ActivateStep.tsx:45 (no fallbackRoute → safe), and pages/EnablePayments/AddBankAccount/AddBankAccount.tsx:61 (this file is dead code; not imported from EnablePaymentsPage.tsx and only referenced by the unused EnablePayments.tsx, which itself has no importers — confirmed via grep).
Direct continueAction invocations from KYCWall render (BaseKYCWall.tsx:399) pass no goBackRoute either → guard does not trigger → safe.
What alternative solutions did you explore? (Optional)
Alternative 1 — Optimistically push an OPEN entry into BANK_ACCOUNT_LIST from successData. Rejected because addPersonalBankAccount (BankAccounts.ts:485-525) doesn't know the server-assigned bankAccountID, the verification state, or routing/account numbers we'd want to display elsewhere; fabricating an OPEN entry would also affect MoneyReportHeader, WalletPage, and other readers of the key.

Alternative 2 — Make the success-screen Continue button call Navigation.navigate(ROUTES.ENABLE_PAYMENTS) directly and skip continueSetup. Rejected because the gated action behind KYC (the actual Pay invocation) is wired through kycWallRef.current.continueAction. Skipping continueAction here breaks the case where the user has already completed KYC and the bank-add success screen should resume the payment.

Alternative 3 — Gate the EnablePaymentsPage step selector on personalBankAccount.shouldShowSuccess. Rejected because the actual rendered page during KYC (EnablePaymentsPage.tsx) already does the right thing — its switch on userWallet.currentStep at lines 82-94 would correctly land on AdditionalDetailsStep if it were ever reached. The page is never reached because continueAction re-routes the user before EnablePaymentsPage can mount. The bug is upstream, not downstream. (Note: there's a separate file src/pages/EnablePayments/EnablePayments.tsx whose hasExpensifyPaymentMethod-gated switch looks like the bug, but that file is dead — not imported anywhere — confirmed via grep "from.*EnablePayments/EnablePayments[^P]" returning zero matches.)

Honest verification limits: I confirmed every link in the chain by reading the files in this repo at HEAD, but I did not reproduce the bug on simulator/browser, and the Applause screen-recording attachment in the issue (platform.applause.com/services/links/...) wasn't accessible to me. The exact sub-branch of continueAction that fires (direct selectPaymentMethod at line 291 vs AddPaymentMethodMenu at line 311) depends on the runtime value of shouldIncludeDebitCard and source for this specific entry point; either branch ends with the user effectively back on the Add Bank Account screen, but a repro would let us confirm which it is.

[melvin-bot]

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

[wildan-m]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[melvin-bot]

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