[Due for payment 2026-05-20] [$250] Expense - Split action does not trigger paywall in expired workspace

[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.61-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: #87973
Email or phone of affected tester (no customers): aperera+test@applausemail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Windows 11
App Component: Other

Action Performed:

1.Open the https://staging.new.expensify.com/
2.Ensure the workspace is expired
3.Tap on the FAB (Floating Action Button)
4.Select "Split expense"
5.Complete the required fields
6.Submit the expense

Expected Result:

A paywall should be displayed when attempting to create a split expense in an expired workspace, preventing the action from being completed.

Actual Result:

The split expense is created successfully and no paywall is displayed, allowing the user to bypass restrictions in an expired workspace.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7134992_1776783747951.Bug.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @jayeshmangwani

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022046629149920540825
• Upwork Job ID: 2046629149920540825
• Last Price Increase: 2026-04-21

[MelvinBot]

Proposal

What is the root cause of that problem?

The split expense flow is missing paywall checks that other expense types have. The only paywall guard for split is in the compose area's selectOption, which only works when initiated from within a workspace chat. Once past that, there are no further checks:

1. Participant selection (MoneyRequestParticipantsSelector.tsx:534-548): The paywall check at line 536 only fires when option.isPolicyExpenseChat is true. For split expenses, users select individual people, so the check is skipped entirely and falls through to addParticipantToSelection.

2. Active policy check (IOURequestStepParticipants.tsx:125-129): Only applies to CONST.IOU.TYPE.CREATE, explicitly excluding SPLIT.

3. Confirmation step and action layer (Split.ts): Neither has any shouldRestrictUserBillableActions check.

When a user initiates a split from the FAB (not from a workspace chat compose area), or navigates via deep link, there is no policy context to check against and the split proceeds unrestricted.

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

Add a paywall check in the split expense confirmation step. In IOURequestStepConfirmation.tsx, before the split bill is submitted, check shouldRestrictUserBillableActions against the transaction's policyID. If the workspace is expired, navigate to the ROUTES.RESTRICTED_ACTION route instead of proceeding.

This mirrors the pattern used in other expense step pages like IOURequestStepHours.tsx:170 and BaseRequestStepWorkspace.tsx:84.

What alternative solutions did you explore?

An alternative is adding the check earlier in the flow — either at the participant selection step or in the FAB menu itself. However, the confirmation step is the last UI barrier before expense creation and catches all entry paths (FAB, deep links, quick actions), making it the most robust location.

Possibly related issue

• Expensify/App#84370 — "Can create expense through the QAB of the Expired Workspace" (similar paywall bypass via a different entry point)

---

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.

[melvin-bot]

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

[melvin-bot]

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

[alexanderxfgl-bit]

Proposal

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

Users in expired workspaces are able to successfully create split expenses without being presented with the paywall.

What is the root cause of that problem?

The SplitExpensePage.tsx component does not check if the workspace is expired before allowing the user to save the split expense (line 239). This allows users to bypass the paywall intended for expired workspaces. The code proceeds directly to saving the split expense without any validation related to workspace status.

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

Add a check for workspace expiration before saving the split expense. If the workspace is expired, the paywall should be displayed, preventing the user from proceeding. This can be achieved by calling a function isWorkspaceExpired() and displaying the paywall if it returns true.

What alternative solutions did you explore? (Optional)

N/A

[alexanderxfgl-bit]

Contributor details
Your Expensify account email: alexanderxfgl@gmail.com
Upwork Profile Link: https://www.upwork.com/freelancers/~2021935202864784599

[melvin-bot]

✅ Contributor details stored successfully. Thank you for contributing to Expensify!

[alexanderxfgl-bit]

Compare branch with the fix: https://github.com/Expensify/App/compare/main...alexanderxfgl-bit/App:fix/88454-ai?expand=1

[twilight2294]

Proposal

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

When a user selects "Split" from the expense more menu in an expired workspace, the paywall is not shown and the split proceeds unrestricted.

What is the root cause of that problem?

The SPLIT secondary action's onSelected handler in useExpenseActions is missing the shouldRestrictUserBillableActions check. It goes directly to initSplitExpense() with no paywall guard. Compare with the ADD_EXPENSE action in the same file at lines 544–553, which correctly checks shouldRestrictUserBillableActions and navigates to ROUTES.RESTRICTED_ACTION when the workspace is expired. The SPLIT action simply omits this guard.

Note: the quick action path (FAB) for split in QuickActionNavigation already passes shouldRestrictAction: true, so only the secondary actions menu path is broken.

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

Add the restriction check to the SPLIT action's onSelected in useExpenseActions, before initSplitExpense:

onSelected: () => {
    if (transactions.length !== 1) {
        return;
    }
    if (policy && shouldRestrictUserBillableActions(policy, ownerBillingGracePeriodEnd, userBillingGracePeriodEnds, amountOwed)) {
        Navigation.navigate(ROUTES.RESTRICTED_ACTION.getRoute(policy.id));
        return;
    }
    initSplitExpense(currentTransaction, policy);
},

All variables (policy, ownerBillingGracePeriodEnd, userBillingGracePeriodEnds, amountOwed) and imports (shouldRestrictUserBillableActions, Navigation, ROUTES) are already in scope — no new dependencies needed.

What alternative solutions did you explore? (Optional)

MelvinBot's proposal adds the check in IOURequestStepConfirmation.tsx, which is further downstream in the flow. This works as a catch-all but is less precise — the bug is specifically that the more menu entry point skips the guard. Fixing it at the entry point (the onSelected handler) is consistent with how every other secondary action in the same file handles it, and prevents the user from entering the split flow at all rather than letting them fill out the form and blocking at confirmation. alexanderxfgl-bit's proposal references SplitExpensePage.tsx without identifying the specific entry point or code path.

[ReaperOAK]

Proposal

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

A user whose workspace is past its billing grace period (expired) can open the global FAB, pick Split expense, add participants, and successfully submit the split — no paywall / RESTRICTED_ACTION screen is shown. The expired-workspace gate that blocks every other expense type (Submit, Track, Time, Per Diem, etc.) is not enforced for Split, so the user bypasses the billing restriction entirely.

What is the root cause of that problem?

The Split flow has three independent submission paths that all terminate inside the same function — createTransaction in src/pages/iou/request/step/IOURequestStepConfirmation.tsx — and none of them call shouldRestrictUserBillableActions:

1. startSplitBill(...) — split with a scanned receipt (IOURequestStepConfirmation.tsx:1235)
2. splitBill(...) — split from an existing chat report (IOURequestStepConfirmation.tsx:1267)
3. splitBillAndOpenReport(...) — split initiated from the global FAB (IOURequestStepConfirmation.tsx:1303)

The upstream gates that should have caught this are insufficient:

• Compose-area gate in AttachmentPickerWithMenuItems.tsx:182-196 — only runs when Split is initiated from the + menu of a workspace chat; the FAB and deep-link entry points never touch this code.
• Participant-selector gate in MoneyRequestParticipantsSelector.tsx:534-548 — only fires inside onSelectRow and only when the tapped option has isPolicyExpenseChat === true. Two concrete bypasses:
  • Participants that are pre-populated from the route (existingSplitChatReportID), restored from a transaction_draft, or auto-assigned (participantsAutoAssigned) never go through onSelectRow, so the check is skipped.
  • handleConfirmSelection at line 441 calls addSingleParticipant(option) directly when shouldAddSingleParticipant is true — also bypassing the paywall branch.
• Active-policy gate in IOURequestStepParticipants.tsx:123-128 — isActivePolicyRequest is explicitly scoped to iouType === CONST.IOU.TYPE.CREATE, so SPLIT never enters that code path.
• Action layer (src/libs/actions/IOU/Split.ts) — no shouldRestrictUserBillableActions call anywhere; splitData.policyID / participant.policyID are happily written to Onyx and sent to the server.

Additionally, IOURequestStepConfirmation.tsx already derives policyExpenseChatPolicyID (the policyID of the first workspace chat in participants) and has policy/policyID from usePolicyForTransaction, but never reads NVP_PRIVATE_OWNER_BILLING_GRACE_PERIOD_END or SHARED_NVP_PRIVATE_USER_BILLING_GRACE_PERIOD_END, so it has no way to evaluate the restriction even if it wanted to.

Net result: any split that reaches the Confirmation step (which, for FAB + expired-workspace, always happens) proceeds unrestricted.

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

Add one paywall gate at the single convergence point — the entry of createTransaction in IOURequestStepConfirmation.tsx, before formHasBeenSubmitted.current = true is latched. This covers all three split paths, all entry points (FAB / deep link / quick action / compose), and the case where multiple workspace chats are selected as split participants.

1. src/pages/iou/request/step/IOURequestStepConfirmation.tsx

Add the missing imports and Onyx subscriptions near the existing billing-related code:

// top of file — add to existing imports
import {shouldRestrictUserBillableActions} from '@libs/SubscriptionUtils';

// inside IOURequestStepConfirmation, next to the other useOnyx calls
const [userBillingGracePeriodEnds] = useOnyx(ONYXKEYS.COLLECTION.SHARED_NVP_PRIVATE_USER_BILLING_GRACE_PERIOD_END);
const [ownerBillingGracePeriodEnd] = useOnyx(ONYXKEYS.NVP_PRIVATE_OWNER_BILLING_GRACE_PERIOD_END);

Insert the gate at the very top of createTransaction (right after setIsConfirmed(true) / the splitParticipants filter, before formHasBeenSubmitted.current = true):

const createTransaction = useCallback(
    (selectedParticipants: Participant[], locationPermissionGranted = false) => {
        setIsConfirmed(true);
        let splitParticipants = selectedParticipants;

        if (iouType === CONST.IOU.TYPE.SPLIT && transaction?.splitShares) {
            // ...existing splitShares filter...
        }

        // >>> NEW: paywall gate for split expenses when any involved workspace is expired.
        // Mirrors the pattern in IOURequestStepHours.tsx:170 and BaseRequestStepWorkspace.tsx:84,
        // but resolved across every possible policyID carrier in the split flow
        // (policy expense chat participants, the host report's policy, and the resolved
        // transaction policy) because split has no single policyID the way Submit does.
        if (iouType === CONST.IOU.TYPE.SPLIT) {
            const candidatePolicyIDs = [
                ...selectedParticipants
                    .filter((p) => p.isPolicyExpenseChat && !!p.policyID)
                    .map((p) => p.policyID as string),
                policyExpenseChatPolicyID,
                policyID,
            ].filter((id): id is string => !!id);

            const restrictedPolicyID = candidatePolicyIDs.find((id) =>
                shouldRestrictUserBillableActions(id, ownerBillingGracePeriodEnd, userBillingGracePeriodEnds),
            );

            if (restrictedPolicyID) {
                // Unlatch so the user can retry after resolving billing, and avoid a stuck spinner.
                setIsConfirmed(false);
                Navigation.navigate(ROUTES.RESTRICTED_ACTION.getRoute(restrictedPolicyID));
                return;
            }
        }
        // <<< END NEW

        const trimmedComment = transaction?.comment?.comment?.trim() ?? '';

        if (formHasBeenSubmitted.current) {
            return;
        }
        formHasBeenSubmitted.current = true;
        // ...rest of function unchanged...
    },
    [
        // add to deps: userBillingGracePeriodEnds, ownerBillingGracePeriodEnd, policyExpenseChatPolicyID, policyID
        /* ...existing deps... */
    ],
);

Also add userBillingGracePeriodEnds, ownerBillingGracePeriodEnd, policyExpenseChatPolicyID, and policyID to the useCallback dependency array.

2. Close the handleConfirmSelection bypass in the participant selector

In src/pages/iou/request/MoneyRequestParticipantsSelector.tsx, handleConfirmSelection can call addSingleParticipant(option) without going through onSelectRow, so the existing paywall check at line 534 never runs for that path. Extract the policy-restriction check from onSelectRow into a small helper and call it from both sites:

const getRestrictedPolicyIDForOption = useCallback(
    (option: Participant): string | undefined => {
        if (option?.isPolicyExpenseChat && option.policyID &&
            shouldRestrictUserBillableActions(option.policyID, ownerBillingGracePeriodEnd, userBillingGracePeriodEnds)) {
            return option.policyID;
        }
        return undefined;
    },
    [ownerBillingGracePeriodEnd, userBillingGracePeriodEnds],
);

// in handleConfirmSelection, before shouldAddSingleParticipant branch:
if (option) {
    const restrictedPolicyID = getRestrictedPolicyIDForOption(option);
    if (restrictedPolicyID) {
        Navigation.navigate(ROUTES.RESTRICTED_ACTION.getRoute(restrictedPolicyID));
        return;
    }
}

// in onSelectRow, replace the inline check with: getRestrictedPolicyIDForOption(option)

Together these two changes make the gate airtight: (1) early block at selection for every entry point, and (2) a final guarantee at the one function every split submit must traverse.

What alternative solutions did you explore? (Optional)

The most obvious alternative — and the one a naïve reviewer might prefer — is pushing the restriction into the action layer itself (Split.ts → splitBill / splitBillAndOpenReport / startSplitBill). This looks more "correct" because it co-locates the guard with the mutation. I rejected it for three concrete reasons:

1. Wrong UX surface. The action layer cannot navigate to ROUTES.RESTRICTED_ACTION cleanly without reaching back into Navigation, which violates the one-way data flow every other paywall gate in the codebase uses (IOURequestStepHours, BaseRequestStepWorkspace, IOURequestStepReport, IOURequestStepDestination, IOURequestEditReport). Introducing a fourth pattern here would increase maintenance cost.
2. Optimistic-update pollution. By the time control reaches splitBill, the draft transaction, optimistic report preview, and optimistic IOU actions are already built; aborting mid-action would require a rollback path that the other IOU paywalls don't need and that history shows is a rich source of regressions (stuck spinners, ghost report previews).
3. The confirmation step is the one and only UI barrier. FAB, deep link, quick-action, and compose-area entry points all converge on IOURequestStepConfirmation. Gating there — exactly how IOURequestStepHours:170 and BaseRequestStepWorkspace:84 do it — is the smallest, least-regression-prone fix that also makes the code visually consistent with the rest of the request-step family.

A second alternative is gating inside IOURequestStepParticipants.tsx by widening isActivePolicyRequest to include CONST.IOU.TYPE.SPLIT. This fixes the FAB→active-workspace case but not the case where the user selects an inactive expired workspace chat as a split participant, so it would still require the MoneyRequestParticipantsSelector helper fix above. The Confirmation-step gate subsumes both cases in a single location and is therefore the strictly stronger choice.