An intuitive custom-page-builder for merchants to accept payments
<aside> 📌 #MVP • #Product-from-scratch • #Design • #WYSIWYG • #Case-Study
Image: A step in between Payment page creation.
Note: This is a retrospective case study. As product building is an ever-evolving process, there were things I/we learnt or realised on the way. I’ve tried to document things in a way to make it easy to understand which may have not been the actual order of execution. Also, to shorten the case-study (and save my time), I’ve oversimplified things or grouped similar information from different timelines under one section.
Razorpay is a B2B2C organisation. We build fintech products for businesses which often have an interface to end-customers too. A “business” for us varies from a really small business (like someone selling home-made stuff online) to the largest corporations in India, and everything in between.
Often, large businesses have the capability and the need to build their own customer-facing interfaces to accept payments. They only need Razorpay’s APIs to get things rolling. On the other side, MSMEs (Micro, Small and Medium Enterprises) use our products out of the box. These businesses rely on our product suite for a significant (or all) of their customer payments.
Only in a few months from its launch, Payment Pages became the most important product in this suite.
A product like this had always been a part of Razorpay’s long term plan. A product that would help merchants host an online store, create event pages, collect payments, et cetera without coding. We learnt from the market that there’s a great opportunity to build such a product where merchants are able to create appealing pages to accept payments with zero development.
The project began in May 2018. Since then, there have been multiple releases in all of which I led the design work. This case-study covers the journey since the beginning and a couple of things thereafter.