Role
Senior Product Designer
Year
2022-2025
Duration
12 months
Context / Problem
Splitwise was a free expense-tracking app with $90B+ in shared transactions and almost no revenue.
Users trusted it to track who owed what, but when it came to actually moving money, they left the app. Investors wanted a path to monetization. The obvious answer was payments. The real problem was trust.
What I Did
I was hired to fix this revenue issue. I identified a revenue stream through transactions and led end-to-end design of Splitwise Pay, Splitwise's first native in-app payment feature.
This included the wallet, settlement flow, compliance-constrained onboarding, and edge-case handling for payment failures and delayed transfers.
Impact
Splitwise Pay drove 114K+ signups and created Splitwise's first transaction-based revenue stream: turning a free debt tracker into a product that could actually move money.
Splitwise had millions of users paying each other back, but all of it happened outside the app. Venmo, cash, bank transfers. Every transaction was a missed opportunity.
Getting users to move money inside Splitwise meant solving two problems at once: building a payments product from scratch, and convincing people who'd never thought of Splitwise as a financial tool to trust it with real money.
What made this hard to execute:
Users tracked money in Splitwise but didn't associate it with sending money
Real transfers introduced compliance requirements the app had never dealt with
The company moved deliberately. Splitwise launched to small groups to avoid trust-breaking mistakes
Joey just had a great bachelor party weekend, and now he's back home. He opens Splitwise to settle up with people he barely knows. He taps on a name. There's no Venmo handle, no PayPal linked. He owes $80 and the only way to pay is an awkward cold text asking for someone's info days after the fact. So he closes the app. He'll deal with it later. He doesn't.
We made the case, got alignment, and built one.
Then the beta launched. And the users panicking weren't the bachelor party strangers. They were regulars: people splitting rent, groceries, recurring expenses with people they knew well. They'd been recording cash payments inside Splitwise for months and assuming money had moved. It hadn't.
We weren't just designing a payment flow. We were designing for users who already had reason not to trust it. And getting them to adopt Splitwise Pay, which tied directly to revenue, meant solving that trust problem before adoption could happen at all.
Before the first transaction: Earning the right to handle money
Tapping Splitwise Pay for the first time triggered a full KYC onboarding flow: name, address, ID verification, and a Plaid bank connection. This was the moment users decided whether to trust Splitwise with their financial information.
I worked with the financial compliance team to rewrite the onboarding language within strict constraints around what Splitwise was and wasn't doing with their money.
During the transaction: control and clarity
I anchored Splitwise Pay as the primary CTA inside the existing settle-up flow, pushing Venmo and PayPal into a third-party dropdown. Users were already at the moment they needed to pay: this put the solution one tap away.
But placement was only half the problem. Once users tapped, they were handing money to an app they'd never trusted with it before. I introduced a wallet model that hadn't existed in Splitwise: funds landed somewhere users could see and control, rather than disappearing into a transfer.
After the transaction: closing the anxiety loop
Transfers took 3-5 business days. For users expecting Venmo-instant, that window was where trust collapsed. I designed status messages at every stage: sent, in progress, received.
And for every failure state, closed accounts, insufficient funds, same-name recipients, each got its own error handling communicated through in-app notifications, push, and email. No user should ever have to wonder what went wrong.
114K+ users signed up for Splitwise Pay after public launch.
Signing up required KYC verification, ID, and connecting a bank account through Plaid. Every one of those 114K signups was a deliberate decision to hand over financial information and trust Splitwise with real money.
A new revenue model.
6 months after implementation, an external partner claimed that Splitwise was now generating $23,000 in weekly revenue, up from close to $0
The trust problem was measurably solved.
Support ticket volume around payment confusion dropped significantly after launch.
The daily inquiries asking whether payments had actually gone through, the clearest signal that users didn't trust the product, stopped.
The onboarding and confirmation work hadn't just reduced friction. It had changed how users understood what Splitwise was.
The foundation held.
Splitwise Pay didn't just launch successfully: it enabled what came next.
The wallet model became the infrastructure for Splitwise Card, a subsequent debit product that extended the wallet into everyday spending and opened a second revenue stream through transaction fees and interest on held balances.
