Kepp Mark as paid label and action in sync after selecting Pay with business account

[MelvinBot]

Explanation of Change

When a policy has no business bank account set up, choosing Pay with business account only opens the Add Bank Account flow for KYC (identity verification). It does not complete a payment. The BUSINESS_BANK_ACCOUNT entry in useSettlementButtonPaymentMethods was missing shouldUpdateSelectedIndex: false, while the ELSEWHERE entry already sets it. So selecting Pay with business account from the dropdown bumped the split button's selected index to that option, wiring the main button to re-trigger the Add Bank Account flow — even though the main button's label (driven by lastPaymentMethod, not the selected index) still read Mark as paid. The result was a label/action mismatch: the button said "Mark as paid" but pressing it re-opened the Add Bank Account flow.

This PR adds shouldUpdateSelectedIndex: false to the BUSINESS_BANK_ACCOUNT payment-method definition, matching ELSEWHERE, so selecting Pay with business account no longer changes the main button's default action.

Fixed Issues

$ #90524
PROPOSAL: #90524 (comment)

Tests

Setup: A workspace with USD currency and no business bank account connected. Create two expenses in the workspace chat, then Submit and Approve both so each has its own payable report.

Main scenario — label/action mismatch (the bug this PR fixes):

1. Open the first approved report. On the report header, press the main Pay $X.XX button and pay it via Pay elsewhere. This stores Pay Elsewhere as your last payment method, so from now on the split button's main label defaults to Mark as paid.
2. Open the second approved report. Verify the main split button now reads Mark as paid.
3. Click the split-button dropdown arrow and choose Pay with business account.
4. The Add Bank Account (KYC) RHP opens — close it without completing setup. (This is expected: with no business bank account, this option launches KYC; it does not complete a payment.)
5. Click the main Mark as paid button directly (without opening the dropdown).
6. Verify the button's action matches its label: the expense is marked as paid (via Pay Elsewhere) and the Add Bank Account page does not re-open.
   • Before this fix, the main button would instead re-open the Add Bank Account flow even though it read "Mark as paid".

First-time payer regression check:
7. On a fresh workspace with USD currency and no business bank account (no prior payment made anywhere), open an approved report. Verify the main button reads Pay $X.XX.
8. Open the dropdown and choose Pay with business account. Verify it correctly launches the Add Bank Account (KYC) flow — this is the intended first-time behavior and is unchanged by this PR.

9. Verify that no errors appear in the JS console.

• Verify that no errors appear in the JS console

Offline tests

QA Steps

Same as test steps

• Verify that no errors appear in the JS console

PR Author Checklist

• I linked the correct issue in the ### Fixed Issues section above
• I wrote clear testing steps that cover the changes made in this PR
  • I added steps for local testing in the Tests section
  • I added steps for the expected offline behavior in the Offline steps section
  • I added steps for Staging and/or Production testing in the QA steps section
  • I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
  • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
  • I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).
• I included screenshots or videos for tests on all platforms
• I ran the tests on all platforms & verified they passed on:
  • Android: Native
  • Android: mWeb Chrome
  • iOS: Native
  • iOS: mWeb Safari
  • MacOS: Chrome / Safari
• I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
• I followed proper code patterns (see Reviewing the code)
  • I verified that comments were added to code that is not self explanatory
  • I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
  • I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
• If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
• I followed the guidelines as stated in the Review Guidelines
• I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
• If a new CSS style is added I verified that:
  • A similar style doesn't already exist
  • The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))
• If new assets were added or existing ones were modified, I verified that:
  • The assets are optimized and compressed (for SVG files, run npm run compress-svg)
  • The assets load correctly across all supported platforms.
• If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
• If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
• If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
• If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
• If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:
  • I verified that all the inputs inside a form are aligned with each other.
  • I added Design label and/or tagged @Expensify/design so the design team can review the changes.
• I added unit tests for any new feature or bug fix in this PR to help automatically prevent regressions in this user flow.
• If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

Screen.Recording.2026-07-22.at.3.00.56.p.m.mov

[MelvinBot]

The only failing check is PR Author Checklist / checklist, and it isn't a code problem — it's failing because the checklist boxes in the PR description aren't ticked (You completed 0 out of 38 checklist items). That's a human verification step, so there's nothing for me to push a fix for — checking those boxes on your behalf would defeat the purpose of the check.

Every real CI check is passing:

• ✅ typecheck
• ✅ All 8 test (job N) runs
• ✅ Bun tests (includes the updated SettlementButtonUtilsTest)
• ✅ ESLint, React Compiler Compliance, knip
• ✅ Storybook tests, Oxfmt, spellcheck, verifySignedCommits, validate

(The *-perf-tests jobs are long-running and still in progress — they aren't blockers.)

To get the PR green: open the checklist in the description and tick each PR Author Checklist item once you've verified it. The check re-runs automatically and will pass once all 38 boxes are checked.

[MelvinBot]

No code fix is needed — all CI checks pass (tests, typecheck, builds, perf, ESLint, etc.).

The only non-passing check was PR Author Checklist / checklist, which failed with:

You completed 0 out of 38 checklist items with 38 unfinished items — PR Author Checklist is not completely filled out.

This isn't something a code push can fix. It just needs the author to tick the checkboxes in the PR description (and fill in the Tests/QA sections). Since I opened this PR as a bot, I left those boxes for a human to complete — that check will pass once they're checked, and it's excluded from the merge-blocking set anyway.

Nothing to push here.

[MelvinBot]

Analyzed the checks — no code fix is needed. Every functional check is green (all 8 test jobs, typecheck, ESLint, Oxfmt, build, baseline/branch perf tests, Storybook, knip, spellcheck).

The only failing check is PR Author Checklist / checklist, which isn't a code failure. It fails because the PR Author Checklist in the description is unchecked (0/38 items). That check turns green once you tick the boxes in the PR body — it can't be fixed by pushing to the branch, and it's not something I should complete on your behalf.

Action for you: Complete the PR Author Checklist (and fill in the QA Steps / mark [No QA]) in the PR description, and the check will pass on its next run.

[melvin-bot]

@mkhutornyi Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button]

[mkhutornyi]

Reviewer Checklist

• I have verified the author checklist is complete (all boxes are checked off).
• I verified the correct issue is linked in the ### Fixed Issues section above
• I verified testing steps are clear and they cover the changes made in this PR
  • I verified the steps for local testing are in the Tests section
  • I verified the steps for Staging and/or Production testing are in the QA steps section
  • I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
  • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
• I checked that screenshots or videos are included for tests on all platforms
• I included screenshots or videos for tests on all platforms
• I verified that the composer does not automatically focus or open the keyboard on mobile unless explicitly intended. This includes checking that returning the app from the background does not unexpectedly open the keyboard.
• I verified tests pass on all platforms & I tested again on:
  • Android: HybridApp
  • Android: mWeb Chrome
  • iOS: HybridApp
  • iOS: mWeb Safari
  • MacOS: Chrome / Safari
• If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
• I verified proper code patterns were followed (see Reviewing the code)
  • I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
  • I verified that comments were added to code that is not self explanatory
  • I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
  • I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
• If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
• I verified that this PR follows the guidelines as stated in the Review Guidelines
• I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
• If a new component is created I verified that:
  • A similar component doesn't exist in the codebase
  • All props are defined accurately and each prop has a /** comment above it */
  • The file is named correctly
  • The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
  • The only data being stored in the state is data necessary for rendering and nothing else
  • For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
  • Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
  • All JSX used for rendering exists in the render method
  • The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions
• If any new file was added I verified that:
  • The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory
• If a new CSS style is added I verified that:
  • A similar style doesn't already exist
  • The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG)
• If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
• If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
• If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
• If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
• If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:
  • I verified that all the inputs inside a form are aligned with each other.
  • I added Design label and/or tagged @Expensify/design so the design team can review the changes.
• For any bug fix or new feature in this PR, I verified that sufficient unit tests are included to prevent regressions in this flow.
• If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
• I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Android: HybridApp

android.mov

Android: mWeb Chrome

iOS: HybridApp

ios.mov

iOS: mWeb Safari

MacOS: Chrome / Safari

web.mov

[trjExpensify]

1. Create a workspace with USD currency (no business bank account connected).
2. Create an expense in the workspace chat > Submit > Approve.
3. On the report header, click the Mark as paid split-button dropdown arrow and choose Pay with business account.
4. The Add Bank Account RHP opens — close it without completing setup.
5. Click the main Mark as paid button directly (without opening the dropdown).
6. Verify the expense is marked as paid (Pay Elsewhere) and the Add Bank Account page does not re-open.
7. Verify that no errors appear in the JS console.

The tests don't sound right. If this is your first time paying, the button label should read "Pay" and clicking it on the USD currency workspace is intended to launch the Add Bank Account flow?

I think maybe this is intended for after you've "Marked as paid" once, such that it's stored as your lastPaymentMethod? Please make sure the tests are updated, and also test there's no regression with the first time payer case either. Thanks!

[MelvinBot]

The only failing check is PR Reviewer Checklist / checklist — all other checks (tests, typecheck, ESLint, build, perf, etc.) are passing.

This isn't a code failure. The check fails with:

❌ PR Reviewer Checklist is not completely filled out. Please check every box to verify you've thought about the item.

It's a human-completed checklist that a reviewer must fill out by checking each box in the PR's reviewer checklist comment. There's nothing to fix in the code and nothing I can push to resolve it — the assigned reviewer just needs to complete the checklist and it will turn green.

[mkhutornyi]

@MelvinBot update Tests Steps as per #96525 (review)

[MelvinBot]

Updated the Tests and QA steps. trjExpensify was right — the original steps were misleading, and the fix is exactly for the "after you've marked as paid once" case you suspected.

Key correction: the main button's label is driven by lastPaymentMethod, not by the selected dropdown option (SettlementButton/index.tsx:586-593). So:

• First-time payer (no lastPaymentMethod): the main button reads Pay $X.XX, and choosing Pay with business account launching the Add Bank Account / KYC flow is the intended behavior — this PR does not change it. Added an explicit regression check for this.
• The actual bug: once you've paid via Pay elsewhere, lastPaymentMethod = ELSEWHERE, so the main label defaults to Mark as paid. Selecting Pay with business account from the dropdown then bumped the split button's selected index to that option (ButtonWithDropdownMenu/index.tsx:351-367), so pressing the main button re-triggered the Add Bank Account flow — even though it still said "Mark as paid". That label/action mismatch is what shouldUpdateSelectedIndex: false fixes.

The revised steps set up the two-expense scenario (pay one via Pay elsewhere first, so the label becomes "Mark as paid") and separately cover the first-time-payer case to confirm no regression.

[github-actions]

🚧 marcochavezf has triggered a test Expensify/App build. You can view the workflow run here.

[OSBotify]

✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

[github-actions]

🧪🧪 Use the links below to test this adhoc build on Android, iOS, and Web. Happy testing! 🧪🧪
Built from App PR #96525.

Android 🤖	iOS 🍎
https://ad-hoc-expensify-cash.s3.us-east-1.amazonaws.com/rock-artifacts/ad-hoc/rock-android-Adhoc-9ba645fb008-30f2be0-a59579ab31b6e6f664f1afa7eddd235d3695f4df/index.html	https://ad-hoc-expensify-cash.s3.us-east-1.amazonaws.com/rock-artifacts/ad-hoc/rock-ios-device-AdHoc-9ba645f-30f2be0-893792bdf2e015a2d4827c09584d7c72cca14de6/index.html

Web 🕸️
https://96525.pr-testing.expensify.com

---

👀 View the workflow run that generated this build 👀

[OSBotify]

🚀 Deployed to staging by https://github.com/marcochavezf in version: 9.4.46-0 🚀

platform	result
🕸 web 🕸	success ✅
🤖 android 🤖	success ✅
🍎 iOS 🍎	success ✅

[MelvinBot]

🤖 No help site changes required.

I reviewed the changes in this PR against Expensify's help site files under App/docs/articles and no documentation updates are needed, so I did not create a draft docs PR.

Why: This is an internal correctness fix. It adds shouldUpdateSelectedIndex: false to the BUSINESS_BANK_ACCOUNT entry in src/libs/SettlementButtonUtils.ts so that selecting Pay with business account from the split-button dropdown no longer changes the main button's default action — resolving a label/action mismatch where the button read Mark as paid but re-opened the Add Bank Account flow.

The fix makes the button behave the way users already expect. It:

• Adds no new feature, setting, tab, or button
• Renames nothing and changes no user-facing labels
• Alters no documented workflow

The user-facing payment behavior (paying via a business bank account, "Pay elsewhere"/mark as paid) is already covered by existing help articles, and none of them describe the internal split-button behavior this PR corrects. So there is nothing to add or amend.

If you feel a specific article should call out this behavior, let me know which one and I'll draft the update.

@marcochavezf, since no help-site changes were required, there is no linked docs PR to review or mark Ready for review.

[OSBotify]

🚀 Deployed to production by https://github.com/marcaaron in version: 9.4.46-10 🚀

platform	result
🕸 web 🕸	success ✅
🤖 android 🤖	success ✅
🍎 iOS 🍎	success ✅

Bundle Size Analysis (Sentry):

• Android