Trip Splits and Guest Participants in MyFam360

Most trips in India go the same way. Three people, four people, sometimes more. One pays for the OYO check-in. Another picks up the cab. A third covers the Mylari mutton biriyani. The next morning, somebody (usually the most organised one) sits with the app and logs every expense from the previous day’s WhatsApp screenshots.

In the old MyFam360 model, every expense was attributed to whoever logged it. The Mylari bill paid by Karthik but logged by Priya showed up as a Priya expense. By the time anyone tried to settle, the actual payer information was gone — and so was the goodwill, sometimes.

The recent trip updates fix this. This post covers the two changes: proper Paid-by attribution and persistent guest participants.

If you’ve never set up a trip in MyFam360, the shared expenses guide is the foundation.

---

The Old Model and Why It Broke

A trip expense in MyFam360 is a regular expense with a trip_id foreign key, plus a list of expense_splits rows that specify how the cost divides between members.

The old model had two gaps:

Gap 1 — The Payer Was Lost

When a member logged an expense and marked some of its splits as “paid manually outside MyFam360”, the payer info was attached to the splits in the request but not always persisted in the database. The UI rendered “logged by Priya” instead of “paid by Karthik” because that’s all the API returned.

This was the v2.0.88 fix: ensure the split-level paid markers persist through create/update, and ensure the trip expenses API payload includes paid_by_name and paid_by_avatar_url.

Gap 2 — Guests Were Display-Only

Trip “guests” (non-MyFam360 friends or relatives on the trip) were stored as a JSON string field called dummy_member_names on the trip row. That string was displayed in the UI but didn’t participate in any math:

• Fair-share calculations ignored guests
• Member-count totals excluded them
• They couldn’t appear as the payer of any split
• Settlements couldn’t reference them

This was the v2.1.3 fix: replace the JSON string with a proper trip_guest_members table.

---

How Paid-By Attribution Renders Now

Open any trip’s detail page and look at the Trip Expenses list. Each row shows:

• Left: category icon and expense description
• Middle: amount and date
• Right: a “Paid by” line with the payer’s name and avatar

If the person who logged the expense is the same as the payer, only “Paid by” appears.

If the logger differs from the payer (the common case during trips), a secondary “Added by [name]” line appears below in smaller, dimmer text. The hierarchy makes the payer the dominant fact and the logger a piece of audit context.

This works identically on desktop and mobile — the layout adapts but the information hierarchy doesn’t change.

---

Guest Participants As Real Members

When you create or edit a trip, the form has a Guest Participants section. You type names; each name becomes a row in trip_guest_members with:

• A stable UUID
• A display name
• A reference to the trip
• A is_settled boolean (set when the guest’s chain is marked paid manually)
• Soft-delete fields so removing a guest doesn’t break historical splits

Guests then appear:

• In the trip member dropdown when adding an expense (alongside real members)
• In the split row when an expense is split, with the same checkbox behaviour
• In the fair-share calculation as full participants
• In the trip summary’s member count
• In the settlement chain list if money is owed between a guest and a real member

The only thing a guest can’t do is log in. They’re a financial entity, not a user.

---

Fair-Share Math With Guests

The default split type on a trip expense is equal, calculated as amount / participant_count where participant_count includes both real members and guests.

A worked example. A 3-night Coorg trip with:

• Real members: Karthik, Priya, Lakshmi
• Guest: Arjun (Karthik’s college friend, doesn’t use MyFam360)

Expenses logged:

Expense	Amount	Paid by	Split
OYO room	₹6,000	Karthik	4-way equal
Cabs	₹2,400	Lakshmi	4-way equal
Dinner	₹3,200	Priya	4-way equal
Coffee (Karthik’s only)	₹400	Karthik	personal

After all expenses:

• Total paid: Karthik ₹6,400, Priya ₹3,200, Lakshmi ₹2,400, Arjun ₹0
• Total owed: each person owes ₹2,900 (₹11,600 ÷ 4) for shared expenses
• Net: Karthik +₹3,100, Priya +₹300, Lakshmi -₹500, Arjun -₹2,900

The trip summary shows these balances, and settlement chains are created to close them.

---

Settling With a Guest

Because a guest doesn’t have a MyFam360 account, “settling” with them is a manual closure:

1. The settlement chain shows the guest as the payer of a debt.
2. You collect the cash or UPI transfer from them outside the app.
3. You open the settlement chain in MyFam360 and tap Mark Paid Manually.
4. The chain status flips to settled, the guest’s is_settled flag is set, and the balance disappears from the trip summary.

There’s no notification flow — the guest doesn’t know MyFam360 exists. The mark-paid action is the manual closure note.

---

The Backfill Migration

Existing trips that used the old dummy_member_names JSON field are automatically converted on upgrade via Alembic migration d1e2f3a4b5c6:

• Each comma-separated name in the legacy JSON becomes a trip_guest_members row
• The legacy field is preserved (not dropped) for one release cycle in case rollback is needed
• The trip summary continues to show the same names because the API was updated to read from the new table first

You don’t need to do anything. Open an existing trip after the upgrade and the guest names are still there, just better-modelled underneath.

---

What This Means For You

Two practical takeaways:

1. Add guest participants properly. If you have a friend joining a trip who doesn’t use MyFam360, add them as a guest participant during trip creation. Now they get counted in fair-share math automatically and you don’t need to manually adjust split percentages.

2. Log who actually paid, not who logged. When you bulk-enter trip expenses from WhatsApp screenshots, take the extra two seconds per expense to set the Paid-by field correctly. The split-level “paid manually” toggle is what powers all downstream attribution.

The Trip module isn’t the most-used part of MyFam360 — most months you’re not on a trip. But when you are, getting the splits right the first time prevents a round of “but I paid for that, remember?” two weeks later.

---

See Also

• How to Track and Settle Shared Expenses Between Family Members — the underlying settlement mechanics
• The Reimbursement Flow in MyFam360
• What’s New in MyFam360 — the Roundup