[$250] Invoice - Unable to pay invoice via Pay dropdown buton

[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: 9.4.28-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-54130/folder/13176671/41237470/1545043037?sort=-identifier
Email or phone of affected tester (no customers): sdjoisjdnojsodjiosjo@gmail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Mac 26.5 / Chrome
App Component: Search

Action Performed:

Precondition:

• User has received an invoice.

1. Go to staging.new.expensify.com
2. Click search button on the top right.
3. Enter type:invoice columns:receipt,date,status,merchant,from,category,tag,amount,action and search.
4. Click Pay button.
5. Click Pay as an individual > Mark as paid.

Expected Result:

Invoice can be paid via Pay dropdown buton.

Actual Result:

Invoice cannot be paid via Pay dropdown buton.
Nothing happens after clicking Mark as paid.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7201020_1783360485755.3.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Svetlana Lazutkina
Bug ID: 7201020

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022074200663086473421
• Upwork Job ID: 2074200663086473421
• Last Price Increase: 2026-07-06

[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/2d0f10affa9aa19c839efeebaa5f4eccdfcedd5d1b36a28b1b228e9e8151626d

[MelvinBot]

Proposal

What is the root cause of that problem?

When you search type:invoice, each invoice renders as a transaction row, not a grouped report row. That path silently drops the chatReport that the Pay action needs.

Concretely, the transaction row renders the Pay dropdown via TransactionItemRowWide.tsx:319-333, which passes reportID, hash, amount — but never a chatReport prop.

When "Mark as paid" is clicked, PayActionCell.confirmPayment hits its first guard:

if (!type || !reportID || !hash || !amount || !chatReport) {
    return;
}

chatReport is undefined, so it returns immediately — payInvoice(...) (PayActionCell.tsx:93-130) is never reached. That is the "nothing happens" symptom.

This is invoice-specific because expense reports render through the grouped-report header ReportListItemHeader.tsx:220, which does pass chatReport. The report/chat-view Pay flow works for the same reason (the invoice room is already loaded and passed in).

Investigation details & evidence chain

1. type:invoice search has no report grouping, so results render as TransactionListItem → TransactionItemRow → TransactionItemRowWide transaction rows.
2. The ACTION column renders DeferredActionCell → PayActionCell without chatReport (TransactionItemRowWide.tsx:319-333).
3. "Pay as an individual" → "Mark as paid" (Pay elsewhere) calls onPress({paymentType: ELSEWHERE}) = confirmPayment.
4. confirmPayment guard returns on !chatReport (PayActionCell.tsx:81-84). No API call fires — silent no-op.
5. Secondary factor: PayActionCell reads iouReport from live Onyx only (PayActionCell.tsx:46), so even past the guard, isInvoiceReport(iouReport) (line 93) can be false if the report isn't loaded, which would send it down the wrong (payMoneyRequest) branch. invoiceReceiverPolicyID is also derived from chatReport (line 52), so a real chatReport is required for the invoice payload regardless.

Alternatives considered: amount being 0 (ruled out — getReimbursableTotal(report) is non-zero for invoices); a broken payInvoice action (ruled out — it works from the report view and from the bulk-selection hooks useSearchBulkActions/useSelectionModePayment, which key their invoice check on reportID rather than the report object).

Confidence: High — deterministic no-op from a missing prop; the working paths (report-grouped rows, report view, bulk selection) all differ by supplying chatReport/keying on reportID.

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

Pass a resolved chatReport into DeferredActionCell in TransactionItemRowWide.tsx:319-333, mirroring what the grouped-report header already does at ReportListItemHeader.tsx:210-221 (resolve from the search snapshot / chatReportID ?? parentReportID). This satisfies the confirmPayment guard and gives payInvoice the room and invoiceReceiverPolicyID it needs.

For robustness, also consider keying the invoice check on reportID (as useSearchBulkActions.ts does) rather than the possibly-unloaded iouReport object, so the correct payInvoice branch is taken even before the report is fully hydrated.

What alternative solutions did you explore? (Optional)

None beyond the above; the fix is localized to the transaction-row Pay wiring.

Possibly related issues

• [$250] Bulk Pay / Pay button not responding in MS Edge #94712 — "Bulk Pay / Pay button not responding" (same Search-page Pay-dispatch area; possibly related).
• [$250] Bulk Pay / Mark as Paid options missing when selecting multiple reports (across workspaces/currencies) #93699 — "Bulk Pay / Mark as Paid options missing when selecting multiple reports" (Search bulk pay; possibly related).

---

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

[kitvasyl]

Proposal

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

Selecting Pay as an individual → Mark as paid from an invoice transaction’s Search action dropdown does not pay the invoice.

What is the root cause of that problem?

The custom transaction-column query renders the action through TransactionItemRowWide, which passes the report ID, hash, and amount to DeferredActionCell, but not chatReport. ActionCell therefore forwards undefined to PayActionCell.

SettlementButton independently loads the chat report from iouReport.chatReportID, so it can still display the invoice-specific Pay as an individual → Mark as paid submenu. However, after that option calls confirmPayment, PayActionCell immediately returns on !chatReport; consequently, payInvoice() is never called.

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

In PayActionCell, restore a local Onyx lookup for the chat report using iouReport?.chatReportID, then resolve paymentChatReport = chatReport ?? liveChatReport. Use that resolved report for eligibility checks, payment context, the guard, report actions, and payInvoice()/payMoneyRequest().

This is a local, safe fallback: report-level Search rows retain their existing snapshot-aware chatReport prop, while transaction rows recover the same live report that SettlementButton already uses. Keep the guard only when neither source resolves a report.

Add a regression test for a transaction-style invoice Search row with no chatReport prop, select Pay as an individual → Mark as paid, and assert that PayInvoice is issued with the invoice and chat report IDs. Manually repeat the reported Chrome flow and verify the paid state/loading update, plus confirm report-level and non-invoice Pay actions remain unchanged.

What alternative solutions did you explore? (Optional)

We could thread parentChatReport from TransactionListItemInner through TransactionListItemWide, TransactionItemRow, and TransactionItemRowWide, but that expands the fix across several generic row components and leaves another prop path that can be omitted; resolving the fallback at the payment boundary is smaller and more robust.

[aswin-s]

Proposal

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

On Web, when a user opens the Search page with type:invoice results and clicks the row's Pay dropdown → Pay as an individual → Mark as paid, nothing happens. The invoice is not paid and no modal, error, or navigation occurs. Expected: clicking Mark as paid should complete the invoice payment (mark it as settled elsewhere) exactly as it does from the report/preview surface.

What is the root cause of that problem?

PayActionCell.confirmPayment short-circuits before ever calling payInvoice/payMoneyRequest because of an overly strict falsy guard. At src/components/Search/SearchList/ListItem/ActionCell/PayActionCell.tsx:82 the handler does if (!type || !reportID || !hash || !amount || !chatReport) { return; }. The amount prop is fed from reportItem.total at src/components/Search/SearchList/ListItem/ReportListItemHeader.tsx:218 (<ActionCell ... amount={reportItem.total} />), and for invoice search-row snapshots that value can be 0/undefined (and, for receivable invoices, is not guaranteed to be a positive truthy number in the search snapshot). The guard therefore returns silently, so Mark as paid produces no navigation, no API call, and no user feedback — matching the reported symptom exactly.

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

1. src/components/Search/SearchList/ListItem/ActionCell/PayActionCell.tsx:82 — drop !amount from the early-return guard (or replace it with amount === undefined only). amount is not needed to dispatch payInvoice/payMoneyRequest — neither call reads it — so it must not gate the click.
2. src/components/Search/SearchList/ListItem/ReportListItemHeader.tsx:218 — pass the sign-normalized total (already computed on lines 148–155) instead of raw reportItem.total, so the value is consistent with what TotalCell renders and any downstream consumer that does need it (display, analytics) gets the intended magnitude.
3. Add a defensive fallback in PayActionCell so that when amount is falsy we fall back to getReimbursableTotal(iouReport) (already imported and used for the button's formattedAmount on line 160) — that way any legitimate future consumer of amount still gets a correct value from the live report.
4. Add a unit/integration test covering: click Pay → Pay as individual → Mark as paid on an invoice search row where reportItem.total is 0/undefined — assert payInvoice is invoked.

What alternative solutions did you explore? (Optional)

[dilshodmackbook-sketch]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-06 18:38:58 UTC.

Proposal

What is the root cause of that problem?

The per-row Pay dropdown in Search is rendered by PayActionCell, whose confirmPayment handler returns early if chatReport is missing:

App/src/components/Search/SearchList/ListItem/ActionCell/PayActionCell.tsx

Lines 81 to 85 in 1908f68

	const confirmPayment = ({paymentType: type, payAsBusiness, methodID, paymentMethod}: PaymentActionParams) => {
	if (!type || !reportID || !hash || !amount || !chatReport) {
	return;
	}

const confirmPayment = ({paymentType: type, payAsBusiness, methodID, paymentMethod}: PaymentActionParams) => {
    if (!type || !reportID || !hash || !amount || !chatReport) {
        return;
    }

PayActionCell receives chatReport only from whatever parent renders ActionCell. In the report-grouped view, ReportListItemHeader derives the chat report and passes it down, so paying works there:

App/src/components/Search/SearchList/ListItem/ReportListItemHeader.tsx

Lines 210 to 222 in 1908f68

	<ActionCell
	action={reportItem.action}
	onButtonPress={handleOnButtonPress}
	isSelected={isSelected}
	isLoading={isActionLoading}
	policyID={reportItem.policyID}
	reportID={reportItem.reportID}
	hash={reportItem.hash}
	amount={reportItem.total}
	shouldDisablePointerEvents={shouldDisableActionPointerEvents}
	chatReport={chatReport}
	/>
	</View>

But the repro uses a transaction-list view (columns:...,action, no groupBy), where each row is rendered by TransactionItemRowWide. It mounts the action cell without a chatReport prop:

App/src/components/TransactionItemRow/TransactionItemRowWide.tsx

Lines 319 to 333 in 1908f68

	{!!transactionItem.action && (
	<DeferredActionCell
	action={transactionItem.action}
	isSelected={isSelected}
	isChildListItem={isReportItemChild}
	onButtonPress={onButtonPress}
	isLoading={isActionLoading}
	reportID={transactionItem.reportID}
	policyID={report?.policyID}
	hash={transactionItem?.hash}
	amount={getReimbursableTotal(report)}
	shouldDisablePointerEvents={isDisabled || shouldDisableActionPointerEvents}
	isMarkAsDone={isMarkAsDone}
	/>
	)}

<DeferredActionCell
    action={transactionItem.action}
    reportID={transactionItem.reportID}
    policyID={report?.policyID}
    hash={transactionItem?.hash}
    amount={getReimbursableTotal(report)}
    // no chatReport passed
/>

So chatReport reaches PayActionCell as undefined, the !chatReport guard trips, and confirmPayment returns before payInvoice is ever called — nothing happens. The other guarded values (type, reportID, hash, amount) are all present; the missing chat report is the sole cause.

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

Make PayActionCell self-sufficient so it works no matter which parent mounts it, by falling back to the report's own chatReportID when the chatReport prop isn't supplied. The cell already loads the live report (iouReport) for the row:

App/src/components/Search/SearchList/ListItem/ActionCell/PayActionCell.tsx

Lines 46 to 47 in 1908f68

	const [iouReport, transactions] = useReportWithTransactionsAndViolations(reportID);
	const policy = usePolicy(policyID);

Add a fallback chat report derived from it:

const [fallbackChatReport] = useOnyx(`${ONYXKEYS.COLLECTION.REPORT}${getNonEmptyStringOnyxID(iouReport?.chatReportID)}`);
const resolvedChatReport = chatReport ?? fallbackChatReport;

Then use resolvedChatReport in place of chatReport inside confirmPayment (the !chatReport guard, the payInvoice/isIndividualInvoiceRoom calls and the chatReportActions lookup, and the payMoneyRequest call). getNonEmptyStringOnyxID, useOnyx and ONYXKEYS are already imported here, so no new dependencies are needed.

This fixes the transaction-list Pay flow (invoices and any other payable row) and leaves the already-working report-grouped path untouched, since it keeps passing the prop.

What alternative solutions did you explore? (Optional)

Thread the prop at the source instead — derive the chat report in TransactionItemRowWide (a useOnyx on report?.chatReportID) and pass chatReport={chatReport} to DeferredActionCell, mirroring ReportListItemHeader. This stays closer to the existing pattern but adds an Onyx read to every transaction row, including non-payable ones, whereas fixing it in PayActionCell confines the extra read to rows that actually render the Pay button.

[lorretheboy]

Proposal

What is the root cause of that problem?

When the old PayMoneyRequestOnSearch API command was removed and Search started calling payInvoice/payMoneyRequest directly from the client, PayActionCell gained a hard requirement on a chatReport prop — its pay callback silently bails out when it's missing:

App/src/components/Search/SearchList/ListItem/ActionCell/PayActionCell.tsx

Lines 81 to 84 in 1908f68

	const confirmPayment = ({paymentType: type, payAsBusiness, methodID, paymentMethod}: PaymentActionParams) => {
	if (!type || !reportID || !hash || !amount || !chatReport) {
	return;
	}

The prop was threaded through the grouped report views (e.g. ReportListItemHeader passes chatReport), but the flat transaction-row view — which is what a search with custom columns: renders — was missed. TransactionItemRowWide renders the action cell without any chatReport:

App/src/components/TransactionItemRow/TransactionItemRowWide.tsx

Lines 319 to 333 in 1908f68

	{!!transactionItem.action && (
	<DeferredActionCell
	action={transactionItem.action}
	isSelected={isSelected}
	isChildListItem={isReportItemChild}
	onButtonPress={onButtonPress}
	isLoading={isActionLoading}
	reportID={transactionItem.reportID}
	policyID={report?.policyID}
	hash={transactionItem?.hash}
	amount={getReimbursableTotal(report)}
	shouldDisablePointerEvents={isDisabled || shouldDisableActionPointerEvents}
	isMarkAsDone={isMarkAsDone}
	/>
	)}

So the chain is: type:invoice columns:… search renders flat transaction rows → TransactionListItemWide → TransactionItemRowWide → ActionCell → PayActionCell with chatReport undefined → the user picks "Mark as paid" → confirmPayment hits the !chatReport guard and returns → nothing happens, no error. (TransactionListItem/index.tsx does resolve parentChatReport, but only feeds it to handleActionButtonPress for the plain action button, not to the Pay dropdown's cell.)

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

Fix it at the convergence point, PayActionCell, instead of prop-drilling through every row component. It already subscribes to the whole report collection:

App/src/components/Search/SearchList/ListItem/ActionCell/PayActionCell.tsx

Lines 46 to 49 in 1908f68

	const [iouReport, transactions] = useReportWithTransactionsAndViolations(reportID);
	const policy = usePolicy(policyID);
	const [bankAccountList] = useOnyx(ONYXKEYS.BANK_ACCOUNT_LIST);
	const [allReports] = useOnyx(ONYXKEYS.COLLECTION.REPORT);

so when the chatReport prop is missing, derive it from the IOU report's chatReportID:

const chatReport = chatReportProp ?? allReports?.[`${ONYXKEYS.COLLECTION.REPORT}${getNonEmptyStringOnyxID(iouReport?.chatReportID)}`];

This fixes the flat-row Pay path for invoices and expense reports alike (the same guard also blocks payMoneyRequest), and keeps the grouped views working since the prop still takes precedence. Everything downstream in the component (invoiceReceiverPolicyID, canIOUBePaid, payInvoice) then receives a real chat report.

What alternative solutions did you explore? (Optional)

Pass chatReport down from TransactionListItemWide/TransactionListItemNarrow (which already resolve parentChatReport) through TransactionItemRow into the action cell — works, but requires threading a prop through several perf-sensitive row components for data PayActionCell can already look up itself.

[ahmdshrif]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-06 18:38:45 UTC.

Proposal

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

On the Search page in the flat transactions view (e.g. type:invoice with a columns: list), clicking a row's Pay dropdown and choosing "Pay as an individual > Mark as paid" does nothing — no payment, no error, no optimistic update.

What is the root cause of that problem?

The Pay handler on flat Search rows silently early-returns because the chatReport prop is never threaded down that render path.

1. In the flat (non-grouped) view, each result is a TransactionListItemWide, which renders the shared TransactionItemRow:

   App/src/components/Search/SearchList/ListItem/TransactionListItem/TransactionListItemWide.tsx

   Lines 177 to 181 in 1908f68

   	{({hovered}) => (
   	<TransactionItemRow
   	transactionItem={transactionItem}
   	report={transactionItem.report}
   	policy={transactionItem.policy}

2. TransactionItemRowWide renders the Action column's DeferredActionCell with reportID, hash, amount — but no chatReport. TransactionItemRow doesn't even declare that prop:

   App/src/components/TransactionItemRow/TransactionItemRowWide.tsx

   Lines 313 to 334 in 1908f68

   	case CONST.SEARCH.TABLE_COLUMNS.ACTION:
   	return (
   	<View
   	key={column}
   	style={[StyleUtils.getReportTableColumnStyles(CONST.SEARCH.TABLE_COLUMNS.ACTION, {isActionColumnWide: isActionColumnWideProp ?? isDeletedTransaction})]}
   	>
   	{!!transactionItem.action && (
   	<DeferredActionCell
   	action={transactionItem.action}
   	isSelected={isSelected}
   	isChildListItem={isReportItemChild}
   	onButtonPress={onButtonPress}
   	isLoading={isActionLoading}
   	reportID={transactionItem.reportID}
   	policyID={report?.policyID}
   	hash={transactionItem?.hash}
   	amount={getReimbursableTotal(report)}
   	shouldDisablePointerEvents={isDisabled || shouldDisableActionPointerEvents}
   	isMarkAsDone={isMarkAsDone}
   	/>
   	)}
   	</View>

3. For action === PAY, ActionCell forwards the (undefined) chatReport to PayActionCell:

   App/src/components/Search/SearchList/ListItem/ActionCell/index.tsx

   Lines 86 to 97 in 1908f68

   	if (action === CONST.SEARCH.ACTION_TYPES.PAY) {
   	return (
   	<PayActionCell
   	isLoading={isLoading}
   	policyID={policyID}
   	reportID={reportID}
   	hash={hash}
   	amount={amount}
   	shouldDisablePointerEvents={shouldDisablePointerEvents}
   	chatReport={chatReport}
   	/>
   	);

4. confirmPayment bails out silently when any guard term is falsy:

   App/src/components/Search/SearchList/ListItem/ActionCell/PayActionCell.tsx

   Lines 81 to 84 in 1908f68

   	const confirmPayment = ({paymentType: type, payAsBusiness, methodID, paymentMethod}: PaymentActionParams) => {
   	if (!type || !reportID || !hash || !amount || !chatReport) {
   	return;
   	}

   . I substituted the repro into each term: type = ELSEWHERE (Mark as paid), reportID is on the item, hash is stamped onto every search item (

   App/src/components/Search/hooks/useSearchSnapshot.ts

   Line 335 in 1908f68

   return {...item, shouldAnimateInHighlight, hash};

   ), amount = getReimbursableTotal ≠ 0 for a real invoice. chatReport === undefined is the lone failing term — the click deterministically dead-ends before any API call, which is exactly "nothing happens".

Structural cause: PR #92297 deprecated the search-specific PayMoneyRequestOnSearch API (which needed only hash/reportID/amount) in favor of calling payInvoice/payMoneyRequest directly, and those need the full chatReport. The PR threaded chatReport into the two report-grouped views — ReportListItemHeader (

App/src/components/Search/SearchList/ListItem/ReportListItemHeader.tsx

Lines 271 to 277 in 1908f68

	const chatReportID = snapshotReport?.chatReportID ?? reportItem.parentReportID;
	return chatReportID ? snapshot?.data?.[`${ONYXKEYS.COLLECTION.REPORT}${chatReportID}`] : undefined;
	}, [snapshot, snapshotReport?.chatReportID, reportItem.parentReportID]);
	const [parentPolicy] = useOnyx(`${ONYXKEYS.COLLECTION.POLICY}${getNonEmptyStringOnyxID(snapshotReport?.policyID ?? reportItem.policyID)}`);
	const [submitterLogin] = originalUseOnyx(ONYXKEYS.PERSONAL_DETAILS_LIST, {selector: personalDetailsLoginSelector(reportItem.ownerAccountID)}, [reportItem.ownerAccountID]);
	const [parentChatReport] = useOnyx(`${ONYXKEYS.COLLECTION.REPORT}${getNonEmptyStringOnyxID(snapshotReport?.chatReportID ?? reportItem.parentReportID)}`);
	const chatReport = parentChatReport ?? snapshotChatReport;

) and ExpenseReportListItem (

App/src/components/Search/SearchList/ListItem/ExpenseReportListItem.tsx

Lines 136 to 141 in 1908f68

	const [parentChatReport] = originalUseOnyx(`${ONYXKEYS.COLLECTION.REPORT}${getNonEmptyStringOnyxID(snapshotReport?.chatReportID ?? reportItem.parentReportID)}`);
	const snapshotChatReport = useMemo(() => {
	const chatReportID = snapshotReport?.chatReportID ?? reportItem.parentReportID;
	return chatReportID ? searchData?.[`${ONYXKEYS.COLLECTION.REPORT}${chatReportID}`] : undefined;
	}, [searchData, snapshotReport?.chatReportID, reportItem.parentReportID]);

) — but never into the flat transaction-row path (its container resolves parentChatReport only for the non-Pay button handler:

App/src/components/Search/SearchList/ListItem/TransactionListItem/index.tsx

Line 141 in 1908f68

const [parentChatReport] = originalUseOnyx(`${ONYXKEYS.COLLECTION.REPORT}${getNonEmptyStringOnyxID(snapshotReport?.chatReportID)}`);

).

Affected paths:

• Invoice rows in the flat view → the payInvoice branch is unreachable (the reported bug):

  App/src/components/Search/SearchList/ListItem/ActionCell/PayActionCell.tsx

  Lines 109 to 129 in 1908f68

  	payInvoice({
  	paymentMethodType: type,
  	chatReport,
  	invoiceReport: iouReport,
  	invoiceReportCurrentNextStepDeprecated: nextStep,
  	introSelected,
  	currentUserAccountIDParam: currentUserAccountID,
  	currentUserEmailParam: email ?? '',
  	currentUserLocalCurrency: localCurrencyCode ?? CONST.CURRENCY.USD,
  	payAsBusiness,
  	existingB2BInvoiceReport,
  	methodID,
  	paymentMethod,
  	activePolicy,
  	betas,
  	isSelfTourViewed,
  	defaultWorkspaceName,
  	additionalOnyxData,
  	chatReportActions,
  	});
  	return;

• Expense-report rows in the flat view with a Pay action → the payMoneyRequest branch dead-ends identically:

  App/src/components/Search/SearchList/ListItem/ActionCell/PayActionCell.tsx

  Lines 132 to 151 in 1908f68

  	payMoneyRequest({
  	paymentType: type,
  	chatReport,
  	iouReport,
  	introSelected,
  	iouReportCurrentNextStepDeprecated: nextStep,
  	currentUserAccountID,
  	currentUserLogin: currentUserLogin ?? '',
  	activePolicy,
  	policy,
  	chatReportPolicy,
  	betas,
  	isSelfTourViewed,
  	userBillingGracePeriodEnds,
  	amountOwed,
  	ownerBillingGracePeriodEnd,
  	methodID: type === CONST.IOU.PAYMENT_TYPE.VBBA ? methodID : undefined,
  	additionalOnyxData,
  	chatReportActions: allReportActions?.[`${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${getNonEmptyStringOnyxID(chatReport?.reportID)}`],
  	});

• canIOUBePaid on flat rows also evaluates with chatReport = undefined, so the dropdown's pay-elsewhere-only logic is computed from wrong inputs:

  App/src/components/Search/SearchList/ListItem/ActionCell/PayActionCell.tsx

  Lines 75 to 77 in 1908f68

  	const canBePaid = canIOUBePaid(iouReport, chatReport, policy, bankAccountList, currentUserLogin ?? '', currentUserAccountID, transactions, false, undefined, invoiceReceiverPolicy);
  	const shouldOnlyShowElsewhere =
  	!canBePaid && canIOUBePaid(iouReport, chatReport, policy, bankAccountList, currentUserLogin ?? '', currentUserAccountID, transactions, true, undefined, invoiceReceiverPolicy);

• NOT affected (explains the platform checkboxes): narrow layout/mobile omits the action button entirely (

  App/src/components/TransactionItemRow/index.tsx

  Line 142 in 1908f68

  // TransactionItemRowNarrow intentionally omits column sizing, hover, action button, and related table-only props that only the wide layout consumes.

  ); expanded-group child rows render a View button, not Pay; bulk-selection Pay resolves its own chatReport in useSearchBulkActions and must not change.

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

Resolve chatReport inside PayActionCell itself — the single convergence point every per-row Pay goes through — by falling back to the live Onyx report collection it already subscribes to (

App/src/components/Search/SearchList/ListItem/ActionCell/PayActionCell.tsx

Line 49 in 1908f68

const [allReports] = useOnyx(ONYXKEYS.COLLECTION.REPORT);

), keyed by iouReport.chatReportID:

function PayActionCell({..., chatReport: chatReportProp}: PayActionCellProps) {
    // after iouReport / allReports:
    const chatReport = chatReportProp
        ?? allReports?.[`${ONYXKEYS.COLLECTION.REPORT}${getNonEmptyStringOnyxID(iouReport?.chatReportID)}`];

Every downstream read (the guard, canIOUBePaid, invoiceReceiverPolicyID, useReportPaymentContext, both pay calls) keeps using chatReport unchanged, so invoice and expense rows are both fixed at once. Regression safety in one sentence: grouped-view callers that already pass chatReport win via ?? so their behavior is byte-identical, and the fallback reuses the existing allReports subscription — no new Onyx connection.

Why the obvious spot fix fails: threading chatReport as a prop from TransactionListItem/index.tsx down through TransactionListItemWide → TransactionItemRow → TransactionItemRowWide → DeferredActionCell adds a prop to the shared TransactionItemRow, consumed by 10+ non-Search surfaces (MoneyRequestReportTransactionItem, duplicate/merge items, UnreportedExpenseListItem, ...) — and any render path that forgets the new prop reproduces this exact silent failure, which is precisely how #92297 broke it (it prop-threaded two of the three render paths and missed this one). Equally, just deleting !chatReport from the guard does not work: payInvoice/payMoneyRequest dereference chatReport to build the request params, so the call would fail deeper instead of paying.

What alternative solutions did you explore? (Optional)

1. Thread the chatReport prop down the five-layer chain from TransactionListItem/index.tsx#L141 — correct but a wider diff through a shared component, and it re-creates the miss-a-caller failure mode described above.
2. Add a search-snapshot fallback (like ReportListItemHeader.tsx#L272) on top of the live-Onyx fallback for reports not yet loaded — cheap follow-up in the PR if wanted; the payer is a participant of the invoice room, so it is in their live Onyx in practice.
3. Restore the hash-based PayMoneyRequestOnSearch API — intentionally deprecated by #92297; not an option.

[samranahm]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-07 20:37:20 UTC.

Proposal

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

On Search, when a user runs type:invoice columns:receipt,date,status,merchant,from,category,tag,amount,action and clicks Pay > Pay as an individual > Mark as paid, nothing happens. The dropdown opens and the submenu looks correct, but confirming the payment produces no optimistic update, no API call, and no error. The same invoice can be paid from the report view.

What is the root cause of that problem?

The reported query renders flat transaction rows, not grouped report rows. Each invoice appears through TransactionListItem > TransactionItemRowWide, and the Action column mounts DeferredActionCell > PayActionCell with reportID, hash, and amount, but never passes chatReport:

App/src/components/TransactionItemRow/TransactionItemRowWide.tsx

Lines 320 to 332 in c08f57f

	<DeferredActionCell
	action={transactionItem.action}
	isSelected={isSelected}
	isChildListItem={isReportItemChild}
	onButtonPress={onButtonPress}
	isLoading={isActionLoading}
	reportID={transactionItem.reportID}
	policyID={report?.policyID}
	hash={transactionItem?.hash}
	amount={getReimbursableTotal(report)}
	shouldDisablePointerEvents={isDisabled || shouldDisableActionPointerEvents}
	isMarkAsDone={isMarkAsDone}
	/>

Grouped report rows (for example ReportListItemHeader) do pass chatReport, which is why Pay works on those paths but fails on the flat invoice transaction path used by this repro.

When the user picks Mark as paid, SettlementButton inside PayActionCell calls confirmPayment. That handler had a hard guard that required the chatReport prop:

App/src/components/Search/SearchList/ListItem/ActionCell/PayActionCell.tsx

Lines 81 to 84 in c08f57f

	const confirmPayment = ({paymentType: type, payAsBusiness, methodID, paymentMethod}: PaymentActionParams) => {
	if (!type || !reportID || !hash || !amount || !chatReport) {
	return;
	}

if (!type || !reportID || !hash || !amount || !chatReport) {
    return;
}

On the flat transaction path, chatReport is undefined, so confirmPayment returns immediately. payInvoice() is never called, which matches the silent no-op in the bug report.

Why the Pay menu still appears: SettlementButton loads the invoice room report on its own from iouReport.chatReportID via useOnyx, so it can render invoice-specific options like Pay as an individual > Mark as paid. The menu and the payment handler therefore use different data sources — the menu works, but the handler bails out before dispatching payment.

Why this matters for invoices specifically: paying an invoice is not the same as paying a regular expense report. payInvoice() needs the invoice room (chatReport) for invoiceReceiver / policy context when building the request and optimistic Onyx data (see buildOnyxDataForInvoice in SendInvoice.ts):

App/src/libs/actions/IOU/SendInvoice.ts

Line 126 in c08f57f

function buildOnyxDataForInvoice(

Without that chat report, the payment command never runs.

The invoice room report is often still available in the Search snapshot or main Onyx under the invoice report's chatReportID, but PayActionCell never looked it up — it only trusted the missing prop.

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

Fix this in PayActionCell.tsx only, at the point where payment is confirmed.

Inside confirmPayment, resolve a chatReportForPayment before the guard, using the same fallback order already used elsewhere for Search pay (getChatReportForSearchPay in Search.ts):

1. Use the chatReport prop when the parent already passed it (grouped report rows — no behavior change).
2. Fall back to the Search snapshot: searchData[REPORT + chatReportID].
3. Fall back to live Onyx: getReportOrDraftReport(chatReportID).

chatReportID comes from iouReport.chatReportID ?? iouReport.parentReportID.

Then replace the guard and all payment calls to use chatReportForPayment instead of the raw chatReport prop:

const searchData = currentSearchResults?.data;
const chatReportID = iouReport?.chatReportID ?? iouReport?.parentReportID;
const chatReportForPayment =
    chatReport ??
    (chatReportID ? searchData?.[`${ONYXKEYS.COLLECTION.REPORT}${chatReportID}`] : undefined) ??
    (chatReportID ? getReportOrDraftReport(chatReportID) : undefined);

if (!type || !reportID || !hash || !amount || !chatReportForPayment) {
    return;
}

Pass chatReportForPayment into payInvoice() / payMoneyRequest() and the related lookups inside confirmPayment (B2B invoice report selection, report actions key, etc.).

This keeps the existing invoice payment API unchanged and only ensures Search passes the invoice room context that payInvoice already expects.

What alternative solutions did you explore? (Optional)

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

Solution verified

Kapture.2026-07-08.at.01.29.22.mp4

[melvin-bot]

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