/ Case study 02
Concept project · Product management · Payments
Airbnb Group Pay
Group travel is booked by groups. It's paid for by one person. A payments concept that kills the organizer tax.
Type
Concept project, Technion PM course
Role
Product manager: research, MRD, PRD, UX
Team
Guy Amar, Oz Shaar-Moshe, Snir Zarin
Timeline
3 weeks, 2026
Deliverables
MRD, PRD, 82-slide deck
At a glance
The problem
67.6%
of surveyed travelers paid the full group booking on their own card (n=37).
The idea
Pay your share, not everyone's
The organizer locks a listing by paying only their share. A 12-hour secure window collects the rest, guest by guest.
Scoped end to end
Survey research, host-risk modeling, MRD and PRD, and a piloted rollout with kill criteria.
01
Problem
The organizer tax
Book an Airbnb with friends and one person takes on a second job: fronting the cost, chasing shares, absorbing the risk. Guests abandon expensive bookings. Hosts lose prime dates.
And Airbnb only ever sees the organizer. The rest of the group is invisible.
Problem space: how a booking is paid today
1
Guest selects
A guest finds and selects a property.
2
One payer
The organizer carries the full financial liability.
3
Escrow
Airbnb holds the money centrally.
4
24h hold
A safety buffer protects the transaction.
5
Host paid
One payment to the host, minus fees.
Host risk by lead time. Illustrative, based on our lead-time risk model (60+ days low, 30–60 moderate, 14–30 high, under 14 extreme), not measured data. It's why the pilot only allows bookings 30+ days out.
02
Research
What travelers told us
67.6%
paid the full booking on their own card
Survey, n=37
37.8%
said having to front the full cost changes what they book
Survey, n=37
21.6%
said someone else in the group fronted the full amount
Survey, n=37
$2.1B
in bookings lost to the fronting problem yearly
Team projection, not measured
Research method
A survey, then interviews
We surveyed 37 travelers about their last group booking: who paid the upfront cost, and whether having to front it changes what they book. We followed up with interviews on how groups split and chase payments today.
Survey, n=37
Who paid upfront on your last group booking?
I paid the full amount on my card
67.6%
Another person paid the full amount
21.6%
Split some other way, or don't remember
10.8%
89% of groups had one person front the whole stay.
Three people, three risks
Organizer
Steve
Chases payments while his card is maxed out.
Contributor
Leo
Will pay his share, won't join the planning.
Host
Rachel
Fears groups that hold dates and never pay.
03
Requirements
From what the market needs to what we build
Market requirement
“Show clearly who has paid and who has not.”
→
Product requirement
A dashboard listing each member as paid or pending, with reminders.
Market requirement
“Split the payment at checkout, before anyone is charged.”
→
Product requirement
A “Pay as group” option for eligible stays (2+ bedrooms, over $1,500, 30+ days out), split equally across up to 10 guests.
Market requirement
“Switch back to a single payment mid-process.”
→
Product requirement
The organizer can pay the remaining balance at any point, and the booking confirms immediately.
Market requirement
“Cancel and get everyone refunded, each to their own payment method.”
→
Product requirement
If the group isn't fully paid when the 12-hour window closes, each member is refunded their share and the listing goes back on the market.
04
Solution
A new way to check out
Group Pay is a new payment option at checkout. Instead of fronting the full amount, the organizer pays only their share.
That payment locks the listing and starts a 12-hour secure window: the property disappears from search while each guest pays their own part through a shared link. No app to download and no account needed to pay, but each contributor page offers a one-tap signup with their details already filled in. At 100%, the booking confirms like any other. If not, everyone is refunded automatically and the listing goes back on the market.
Key insight
Nobody bankrolls the trip, and the host's calendar is never held hostage.
1
Organizer pays share
2
Inventory locked
3
12-hour window opens
4
Guests pay individually
5
Booking confirmed
Key screens
1 · Order creation
2 · Listing after booking
3 · Contributor payment
User flow
05
Metrics & rollout
Success and failure, defined first
We defined success and failure before writing a single requirement. The feature ships behind a flag with rollback triggers agreed upfront.
North star
90%
of group bookings fully funded within 12 hours
Growth target
1.5
new verified users per Group Pay booking
Kill criteria
>15% · >5%
of held listings end in cancellation, or of pilot hosts turn Group Pay off. The first shortens the window; the second means it doesn't scale.
Rollout
1
Internal test
2
US pilot, bookings 30+ days from check-in
3
Expand only where the risk model says it's safe
06
Reflection
What I'd take from this
What I'd validate next
Will hosts accept a 12-hour hold in peak season?
It's the riskiest open assumption: a held listing can't be booked by anyone else, which hurts most on holidays. The US pilot tests it directly. If more than 5% of pilot hosts switch Group Pay off, the hold costs hosts more than the demand is worth.
