GPay Smart Settle

Why a zero-balance user was still making two payments — and how one structural decision could fix it without changing the underlying product at all.

The problem I found

Three friends. One hotel. Everyone opens GPay to settle up. Mahesh owes Karan ₹1,000. Karan owes me ₹1,000. My net? Zero. But GPay sees two separate debts and asks me to make two transactions — one to Karan, one to receive from Mahesh.

This is the gap between tracking debt and optimising settlement. GPay already had all the data. It just didn’t connect it.

“Why am I making a payment when my balance is zero?”

How I framed the problem

The mechanism I designed

A → Me → B becomes A → B, When GPay detects that my incoming and outgoing debts cancel out, it surfaces a Smart Settle option. Instead of me acting as a financial relay, the payment routes directly — eliminating a redundant transaction.

My role shifts from executor → approver. I verify the reroute. Mahesh’s debt clears. Karan gets paid. Zero money leaves from my account.

The choices I made to earn trust

The gap, visualised

What I actually changed

The Approval Flow

The second-order problem I designed for

I designed for the confusion 3 months later, The payment itself is a secondary interaction. I realised the real problem happens in September when Mahesh messages: “Did I pay you or Karan? I can’t remember.”

So I designed the Smart Settle receipt to name who paid whom, on whose behalf, from which group, and what was approved — making it a dispute-proof artifact, not an afterthought

The outcomes I designed toward

Let’s be honest about this

Smart Settle is a low-volume feature by GPay’s standards. Group payments with circular debt chains happen — but they’re not the daily transaction. GPay processes hundreds of millions of UPI payments. Smart Settle would touch a small percentage of those. I know that. Here’s what I think is still worth saying.

How I’d know if this is working

These are the signals I’d track — not to prove success, but to understand behaviour and catch failure early. Each metric maps to a specific design assumption that could be wrong.

What I considered and why I moved past it

The approval modal wasn’t the first approach. Two alternatives were considered and rejected. Showing the reasoning matters more than showing the final answer.

My design principle

*The best financial product is one that reduces the number of transactions needed to settle a group — *without breaking the trust people have in every payment they make.