Expense - Received payment option remains after receiving payment and it causes error

[lanitochka17]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: 9.3.69-0
Reproducible in staging?: Yes
Reproducible in production?: N/A - new feature, doesn't exist in prod
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #86174
Email or phone of affected tester (no customers): odijsdoojdiosjnodnjsio@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.2 / Chrome
App Component: Money Requests

Action Performed:

Precondition:

• Admin invites member to the workspace.

1. Go to staging.new.expensify.com
2. [Member] Go to workspace chat, submit an expense and click Submit on the expense preview.
3. [Admin] Open member's report and click Approve.
4. [Member] Open the report.
5. [Member] Click More > Received payment > Yes, I've received payment.
6. [Member] Click More > Received payment > Yes, I've received payment.

Expected Result:

Received payment option will disappear after receiving payment.

Actual Result:

Received payment option remains after receiving payment and it causes error.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7148492_1778255598169.4.mp4

View all open jobs on GitHub

[melvin-bot]

You have been assigned to this deploy blocker because you recently merged this PR: #86174

[melvin-bot]

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

[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.

[OSBotify]

Investigation Summary

Classification: Frontend bug
Causing PR: #86174 - "Allow submitters to select 'Received reimbursement' option" by @nabi-ebrahimi (High confidence)
Related Issues: #83035

Recommendation: REVERT

PR #86174 introduced the "Received payment" option but the visibility logic in isReceivedPaymentAction does not hide the option after it has been used, allowing the action to be triggered multiple times and causing an error.

Assigned: @nabi-ebrahimi (PR author), @Pujan92, @luacmartins (approving reviewers)
Labels: DeployBlockerCash kept (Frontend bug in App). No label changes made.

Detailed Analysis

Evidence

• The melvin-bot already flagged PR Allow submitters to select "Received reimbursement" option #86174 as the causing PR.
• PR Allow submitters to select "Received reimbursement" option #86174 is in the StagingDeployCash checklist and was merged on 2026-05-07, just before this bug was reported.
• The bug report shows the "Received payment" option remains visible after being used and causes an error when triggered a second time.
• The issue is staging-only (new feature, not in production), consistent with this PR being the cause.

Verification

• The affected files are src/libs/ReportSecondaryActionUtils.ts and src/libs/actions/IOU/PayMoneyRequest.ts.
• PR Allow submitters to select "Received reimbursement" option #86174 modifies both of these files directly.
• The PR adds isReceivedPaymentAction to src/libs/ReportSecondaryActionUtils.ts and adds markReportPaymentReceived to src/libs/actions/IOU/PayMoneyRequest.ts.

Root Cause

The isReceivedPaymentAction function in src/libs/ReportSecondaryActionUtils.ts (lines 442-466) determines whether to show the "Received payment" option. Its logic returns true (show the option) when:

1. The report is in a supported state: approved, closed, or settled (isSettled).
2. There is no bank payment action (i.e., no PAY action with paymentType !== ELSEWHERE).

When the user clicks "Received payment," markReportPaymentReceived in PayMoneyRequest.ts creates an optimistic PAY action with paymentType: CONST.IOU.PAYMENT_TYPE.ELSEWHERE and sets the report statusNum to REIMBURSED (settled). After the action completes, isSettled(report) returns true, which keeps isSupportedState = true. The check for hasBankPaymentAction filters for actions where paymentType !== ELSEWHERE, so the newly added ELSEWHERE pay action does NOT trigger removal of the button. As a result, the "Received payment" option stays visible after use.

A unit test added in the same PR (includes RECEIVED_PAYMENT option when only pay-elsewhere action exists) explicitly validates this behavior as intentional — meaning the logic was designed to allow the option to persist even after a pay-elsewhere action exists, but this creates the user-facing bug where clicking it a second time causes an error because the report has already been fully settled.

The fix should either: (a) hide the option once a pay-elsewhere action exists with the specific action type used by markReportPaymentReceived, or (b) check the report's statusNum === REIMBURSED state to suppress the option once the payment is received. Because the fix requires careful reasoning about state transitions, reverting PR #86174 and re-landing it with the corrected visibility guard is the safest path.

[MelvinBot]

Proposal

What is the root cause of that problem?

The visibility check for the "Received payment" option in isReceivedPaymentAction() filters for payment actions where paymentType !== ELSEWHERE. But when the user confirms "Yes, I've received payment", markReportPaymentReceived() creates a PAY action with type ELSEWHERE. Since the check explicitly excludes ELSEWHERE payments, it never detects that payment was already received — so the option stays visible. Clicking it again tries to settle an already-reimbursed report, causing an error.

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

In ReportSecondaryActionUtils.ts:457-463, the hasBankPaymentAction check should also account for ELSEWHERE payments that were created by the "Received payment" flow. The simplest fix is to check if the report is already settled/reimbursed (statusNum === REIMBURSED) and hide the option in that case, or change the filter to detect any PAY action (not just bank payments) so the option disappears after any form of payment is recorded.

What alternative solutions did you explore? (Optional)

An alternative would be to add a guard in the click handler (useLifecycleActions.tsx:256-293) to prevent the action if the report is already reimbursed. However, fixing the visibility logic is cleaner since the option shouldn't appear at all after payment is received.

Investigation details

Evidence chain:

1. markReportPaymentReceived() at PayMoneyRequest.ts:811 creates a PAY action with paymentType: CONST.IOU.PAYMENT_TYPE.ELSEWHERE
2. isReceivedPaymentAction() at ReportSecondaryActionUtils.ts:462 checks paymentType !== CONST.IOU.PAYMENT_TYPE.ELSEWHERE — this filter was designed to only detect bank payments (ACH), so ELSEWHERE payments pass through undetected
3. Since hasBankPaymentAction remains false, the function returns true and the option stays visible
4. The report status does change to REIMBURSED (line 854), but the visibility function at line 451 includes isSettled(report) as a supported state — meaning settled/reimbursed reports still show the option

Related issues: #90033 and #90034 appear to be duplicates of this issue.

Introduced by: PR #86174 (merged 2026-05-07), which added the "Received reimbursement" feature.

---

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.

[luacmartins]

Dupe of #90033