A checkout is one of the most designable things in a product. There is a price, a button, a spinner, and a confirmation. I designed one for Chiblu in an afternoon. Then I started wiring it up, and found out the screen was the smallest part of the problem.
From the outside, a payment is three states. The buyer taps Pay. Something spins. The buyer sees a confirmation. That model holds up fine when money moves from one person to one business.
Chiblu was a marketplace. One buyer paid once, and that single payment had to end up in two places: a cut for the platform and the rest to the maker who made the thing. The three-state model had nothing to say about that, and neither did my checkout screen.
What was actually behind the button
Taking the money turned out to be the smallest of four jobs.
Splitting it. A marketplace payment is not one transfer, it is one payment that has to divide. Razorpay calls it Route. The buyer sees a single amount; underneath it becomes two.
Getting the seller ready to receive it. A maker cannot be paid until her bank details and PAN are on file and verified. That is KYC, and it is a gate with its own states, its own waiting, and its own ways of not finishing.
Sending it back. A refund on a split payment has to travel back along the same path it took out.
Knowing when any of it failed. This was the one I had not thought about at all.
Where it actually breaks
The happy path hides all of this, which is exactly what makes it a bad thing to design against. Three failures taught me more than the checkout did.
The first was the silent webhook. A payment provider confirms a payment by pinging your product automatically. Sometimes that ping never arrives. The buyer’s money has left. The product does not know it. Both of those are true at the same time, and neither the checkout screen nor the confirmation screen has anywhere to put that.
The second was a seller account that got stuck partway through onboarding. Not rejected, not approved. Just stopped, with no state I could honestly show the maker.
The third was an error the payment provider threw that was documented nowhere, the kind that costs engineers days.
None of those are edge cases in the sense designers usually mean. They are ordinary Tuesdays. The gap between “it works in the demo” and “it works when a real person’s bank says no” is where most of the actual experience lives.
What that changed for me
I still reviewed the flow as a designer. Does it feel calm. Is the empty state handled. Does the error message sound like a person rather than a wall of red text. Those are the right questions, and they are mine to ask.
But I could only ask them about states I knew existed. Before Chiblu I would have drawn a confirmation screen and a generic error screen and called the flow covered. I would have missed the paid-but-unconfirmed state entirely, because from the interface it looks like nothing happened.
That is the part that stayed with me. The interface is the visible surface of a system that has more states than the interface shows. I do not need to be able to build all of it. I do need to know enough about what is underneath to know which states are possible, because those are the ones I am on the hook for designing.
I did not become a payments engineer. I packed what I learned wiring up Chiblu into a free skill, so the next designer can build the scary part on fake money before finding an engineer to take it live. It is on GitLab at gitlab.com/pradeepsiddappa/razorpay-integration, for Indian payments via Razorpay, unofficial, and it always defers to the official docs.
Designing the checkout took an afternoon. Understanding what it was the front of took considerably longer.