Locked BA - After going online and clicking Pay Locked BA modal is not shown, failed attempt

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

---

Version Number: 9.4.56-2
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/folder/54018437/test-cases/98913455
Email or phone of affected tester (no customers): applausetester+lockedba@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: MacBook Air 26.5.2 Chrome
App Component: Money Requests

Action Performed:

1. Sign in to ND with a applausetester+lockedba@applause.expensifail.com account
2. Create a manual expense in the workspace, submit and approve it
3. Open the expense details, go offline
4. Click green Pay button and select Pay with bank account
5. Click Cancel on the Locked bank account modal
6. Go online and repeat step 4

Expected Result:

Locked bank account modal is displayed

Actual Result:

After going online and clicking Pay "Locked BA" modal is not shown. "Paid with bank account xxxx" system message appears with an error "The selected bank account isn't a valid withdrawal account for you. Please choose a different account to pay from."

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7237540_1787165296876.Locked_BA.mp4

View all open jobs on GitHub

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

[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/1540f96c9ed2d6fe8674fe035ed07cb21dd923245fcb0cb8f1a6746bd86e24e7

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[melvin-bot]

Triggered auto assignment to @tylerkaraszewski (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[MelvinBot]

🔍 Investigation Summary

Classification: Undetermined (leaning Frontend/data) — no App PR confidently identified
Causing PR: None identified with sufficient confidence (see ruled-out candidates below)
Related Issues: N/A

Recommendation: NEEDS INVESTIGATION

The client-side guard that should surface the "Locked bank account" modal lives in SettlementButton and is unchanged since 2026-08-10 (already on production), yet the bug only reproduces on staging — so I could not pin it to a specific PR in this deploy. Keeping the label and flagging for the Payments team.

Assigned: none (no causing PR at medium+ confidence)
Labels: No changes. DeployBlockerCash kept (issue does not reproduce on production, and no clear App PR could be blamed — erring on the side of keeping the blocker).

📋 Detailed Analysis

Root Cause (hypothesis)

The Pay button on the expense-details header renders SettlementButton (via MoneyReportHeaderPrimaryAction/PayPrimaryAction). When "Pay with bank account" is chosen, runPaymentAction → checkForNecessaryAction → checkForPostValidationBlockers gates the payment. The locked-BA gate is:

const isBankAccountLocked = policy?.achAccount?.state === CONST.BANK_ACCOUNT.STATE.LOCKED; // L197
...
if (isBankAccountLocked) { showConfirmModal(... 'bankAccount.lockedBankAccount' ...); return true; } // L206

• Offline (step 4): the cached policy still has achAccount.state === LOCKED, so the gate fires and the modal is shown correctly.
• Online (step 6): the modal is not shown and the payment is dispatched, then the backend rejects it ("The selected bank account isn't a valid withdrawal account…"). For the gate to stop firing, policy.achAccount.state must no longer equal LOCKED after the app reconnects/refetches.

So the regression most likely comes from what the app receives/merges for policy.achAccount when going back online, not from the gate logic itself (which is identical to production).

Verification

• Affected decision path: src/components/SettlementButton/index.tsx L197–L262 (isBankAccountLocked, checkForPostValidationBlockers, checkForNecessaryAction, runPaymentAction).
• git/GitHub history: last change to SettlementButton/index.tsx was 2026-08-10, i.e. it shipped in a prior (production) release. No PR in the 9.4.56 StagingDeployCash touches this file, useVerifyAccountAndResume.ts, or the isBankAccountLocked / achAccount state path.

Candidate PRs examined and ruled out

• Fix - Search bulk pay drops the selected payment method after magic code verification #98310 "Search bulk pay drops the selected payment method after magic code verification" — only touches Search/SearchBulkActionsButton.tsx and actions/Search.ts (Search bulk-pay flow), not the expense-report Pay path.
• [Payment due @Pujan92] Add Cancel payment action for pending P2P wallet payments #95005 "Add Cancel payment action for pending P2P wallet payments" — adds a new cancelSendMoneyPayment branch in PayMoneyRequest.ts; does not change payMoneyRequest or the locked-BA gate.
• Show non-USD bank accounts as incomplete instead of pending #98023 "Show non-USD bank accounts as incomplete instead of pending" — BankAccountUtils.getBankAccountConnectionStatus; its own tests assert LOCKED is unaffected.
• [Internal QA] Fix Account and Wallet RBR still showing for personal cards past the 90-day grace period #96364 "Fix Account and Wallet RBR… past the 90-day grace period" — actions/PaymentMethods.ts (card RBR), unrelated to withdrawal-account locking.
• Move multi-level tag Required from the Tags table to Rules #98414 — multi-level tag Required (PolicyUtils/tags), unrelated.

Why NEEDS INVESTIGATION (not a revert)

The user-facing gate is App code and unchanged from production, so a straight revert has no obvious target. The staging-only reproduction points at a change in the data returned/merged for the locked withdrawal account on reconnect. This needs eyes from the Payments/withdrawal-account owners to confirm whether the offending change is in the app's online data merge or in the API response for the locked account. Because the issue does not reproduce on production, the DeployBlockerCash label is intentionally kept.

Suggested next steps for the assignee

1. On staging, reproduce and inspect policy.<id>.achAccount.state in Onyx immediately after going online — confirm whether it flips away from LOCKED.
2. If it flips, bisect the source of the refreshed policy data (OpenReport/reconnect payload vs. client merge). If the API now omits the locked-account state, this is a backend issue and should be re-classified.

[Beamanator]

Investigation update

What the evidence shows

The expected behavior is clear: a locked business bank account must block every payment entry point and show the locked-account modal; it must not submit PayMoneyRequest.

• #96624 is an open, closely related report: payment could proceed from another surface despite the bank account being locked. It reproduced on both staging and production in 9.4.41-0, so it supports a pre-existing cross-surface guard gap rather than a new staging-only regression.
• #95026 established the same contract and regression test: lock the account, attempt payment, and verify the locked-account modal appears. Its App fix (#95063) was deployed; that issue is still open only for administrative/payment follow-up.
• #91300 separately defines the locked-account status UX ("requires attention" / unlock path).

App code and log evidence

The report-details payment path still goes through SettlementButton's locked-account guard. The file is byte-for-byte unchanged between production 9.4.55-4 and the reported staging build 9.4.56-2; there is no release diff that bypasses this guard.

Staging logs show that the attempted action did reach the backend: PayMoneyRequest was rejected with the business error "Payer does not own a valid withdrawal bank account with that ID" on 9.4.56-2. Crucially, the same error is also present in staging logs from 9.4.55-3, before this issue's release range. That rules out 9.4.56-2 as the introduction point, but does not prove why the client allowed the request.

The available logs contain request metadata and the backend rejection, but not the returned Onyx policy payload. The remaining question is whether, after reconnect, the client received:

1. policy.achAccount.state !== LOCKED (or a missing/wrong policy), while the backend still rejects the selected withdrawal account — a staging data/server consistency issue; or
2. state === LOCKED, but a payment entry point still submitted — an App guard defect, likely related to [Exploratory] Bank-Expenses can be paid using a locked bank account from the Spend page #96624.

Recommendation

Do not close this as an invalid expectation, and do not ship a speculative App change or revert. Reclassify it as a pre-existing staging payment-state investigation until we capture the policy/bank-account snapshot around reconnect. If the account is still LOCKED, link this to #96624 and fix the bypass; if it is not, route it to the team that owns the policy/bank-account response consistency.

@MelvinBot please investigate this independently, focusing on the policy and bank-account data delivered immediately after reconnect for the reported staging test account, and reconcile it with the backend's withdrawal-account rejection.

🤖 Posted by Codex, an AI coding agent acting for @Beamanator.