Case Study · 2025
← Back to WorkPay-in-Full Pricing
A new checkout option that lets guests pay everything upfront at a discount. Converting price-sensitive browsers into confirmed bookings and generating +$ 1M in month one.
Role
Sole Product Designer
Team
PM, payments engineers, finance, legal, data analyst
Timeline
5-week design sprint · 2025
Platforms
Web & mobile checkout
Renting our product is expensive. Average order value hovers around $ 1,800. The standard payment model splits this into a deposit at booking and a balance due later. But analysis showed a segment of guests who wanted simplicity: one payment, done, don't think about it again.
The hypothesis was straightforward: offer a small discount (3–5%) for paying the full amount upfront. Guests get a price break and peace of mind. We get immediate cash flow instead of chasing balances. Hosts get faster payouts.
The challenge wasn't the concept it was the complexity. Our checkout already handles deposits, insurance add-ons, damage protection, service fees, and cancellation policies. Introducing a third payment path meant untangling all of those interactions.
Mapping every edge case: deposits, insurance, cancellation refunds, host payouts, and service fee recalculation
Decision 1
Show the savings, not the math
Early prototypes showed the full pricing breakdown: original total, discount percentage, new total. Guest testing revealed this felt like a negotiation. The final design shows the discounted price as the primary number with a simple "You save $ X" line. One number, one benefit.
Decision 2
Default to split, upsell full
We debated defaulting to pay-in-full. Data showed that a higher-looking upfront price increased cart abandonment for budget guests. The final approach: default to the familiar split payment, with the full-pay option surfaced as a highlighted alternative with the discount visible.
Decision 3
Cancel gracefully
The hardest edge case: what happens when a pay-in-full booking gets cancelled? The guest paid a discounted rate, but the refund policy is based on the original rate. I worked with legal and engineering to design a refund flow that's fair to both sides. It refunds the actual amount paid, proportional to the cancellation policy.
Decision 4
Host-side transparency
Hosts see that a guest chose pay-in-full, and their payout timeline reflects the immediate payment. This was a deliberate choice to build trust: hosts know the guest is financially committed, which reduces cancellation anxiety.
Five weeks, from idea to launch-ready
- Week 1: Map the money. With engineering and finance, I mapped every way money moves through a booking: deposits, balances, insurance, damage protection, service fees, refunds and host payouts. That map became the reference for every decision that followed.
- Week 2: Prototype the options. I explored how pay-in-full could appear at checkout, from a simple toggle to a side-by-side comparison, and prototyped the strongest directions.
- Week 3: Test with guests. Moderated sessions surfaced the “negotiation” problem with showing the full math, which led directly to the first design decision below.
- Weeks 4–5: Edge cases and handoff. Cancellations, modifications and payout timing were designed and specified with engineering, legal and finance before handoff.
Designing with finance and legal in the room
Payments touch far more than the checkout screen. Finance needed the discount accounted for correctly, legal needed refund language that matched our policies, and the payments team needed rules simple enough to build without introducing billing bugs. Keeping everyone working from the same flows meant disagreements surfaced early as design questions, not later as production issues.
Launching carefully
We launched to a portion of traffic first and watched three things closely: adoption of pay-in-full, overall checkout conversion, and payment-related support contacts. The worry going in was cannibalization, that the discount would simply hand money to guests who would have booked anyway. Measured against the split-payment control, the option drove genuinely incremental revenue, which is why we report the +$1M as incremental rather than total.
Who actually wants to pay upfront?
Before designing anything, I wanted to understand the guests the hypothesis was about. Booking data showed that guests who paid their balance early tended to book further ahead and for longer trips. Conversations with guests filled in the why: families planning a summer trip months in advance liked having it fully paid and off their minds, while some first-time renters simply preferred one clear number to a schedule of payments.
That shaped the tone of the feature. Pay-in-full wasn’t positioned as a financial product; it was positioned as peace of mind with a reward attached. It also told us who not to push: budget-conscious guests comparing prices across platforms reacted badly to a larger upfront total, which is exactly why split payment stayed the default.
These findings went into a one-page summary the whole team used during the sprint, so engineering, finance and legal were designing for the same guest I was.
What I’d do next
With adoption proven, the next opportunities are personalizing the offer, such as highlighting pay-in-full on longer or higher-value trips where the savings matter most, and testing how the size of the discount affects uptake.
Results
+$ 1M in 30 days.
+$ 1M
Incremental revenue in the first month from pay-in-full bookings
+$ 3M
Projected Q1 revenue based on adoption rate
40%
Of eligible bookings chose pay-in-full in the first month
0
Payment-related support tickets in the first 30 days
Revenue from pay-in-full bookings