Investments and payments at scale

A form and a phone call, made self serve.

The old journey was a form and a phone call. The FD product page was a form. Name, amount, tenure, a few basic details. Whether you were a first-time visitor or a customer of ten years, you filled the same form, and then a sales or call centre agent rang you back and placed the investment for you.

That worked. It had worked for years, attached to a physical sales operation doing real volume. There was just no way for a customer to complete an investment on their own.

What I could not touch. The investment management system sat on Salesforce, tightly wired into the offline operation. Changing it meant risking a business that was already running well, so it was off limits. Small incremental changes only, enough to keep the backend stable and nothing more.

That framed the whole problem. The new journey had to sit on top of a system built for agent-mediated investments and sync with it in real time, without that system caring that the person on the other end was now the customer.

Consent is why the flow has steps. The obvious version of this product is one screen. Amount, tenure, confirm.

That version is not legal. Regulation required consent captured at specific points, timestamped, with the relevant terms surfaced at each. Which terms depended on where you were in the journey and what kind of user you were. An existing customer and a new one see different sets. Showing everything up front is not compliant. Neither is showing nothing.

So the journey became staged, each stage ending in a deliberate action that records consent. The steps were not a UX compromise. They were the product working correctly.

Then we took the steps back. Once v1 was live we spent months cutting the journey down, using data the company already had.

Government ID verification was the worst offender. The API failed often, and every failure was a dead end for someone trying to invest. The fix was not a better retry loop. Anyone already holding a Bajaj Finance product had been verified before, somewhere else in the company, so we let them skip it entirely. Same logic for banking details, pulled from prior products rather than re-entered.

We also pre-filled wherever we legitimately could. The target user was not someone who had invested online before, and a blank field is a decision point. A pre-filled one is a confirmation.

The best case happy path ended at three steps.

Where it broke. Backend sync, repeatedly. Data would not flow correctly between the journey and the Salesforce-side system, and since I could not rebuild that system, the answer was a better API contract that captured state properly at each stage rather than assuming one clean handoff. That took iterations to get right.

The government API kept failing regardless of what we did. Storing and reusing verification data was the only durable fix, and it only helped existing customers.

What happened. 40% increase in user acquisition within three to five months of going fully digital, with volume coming from both web and app. Shipped as a PWA serving both.

We expected an increase. We did not expect it from this segment. Minimum FD investment is 25,000 rupees, which is a serious amount to commit with no one on the phone, and Bajaj's customer base was not primarily tier-one or especially tech-forward. The internal assumption was that these customers need an agent.

They didn't. They needed a path they could finish alone, and nobody had built one.

What I took from it. The flow got longer for compliance and conversion went up anyway. Friction and steps are not the same thing. What stops someone mid-journey is uncertainty about what happens next, especially with real money involved, and staged consent answers that question continuously.

The second lesson was cheaper. Most of the steps we eventually removed were steps we were asking a customer to repeat. The data was already inside the company. It was just sitting in a different product.

The infrastructure the investment journey lands on.

Three gateways, because the banks were the problem. The FD journey ends in a payment, and it ran on Bajaj's central payment module, shared across every business in the company.

We integrated three gateways. Not for redundancy in the usual sense, and not for pricing leverage. It was coverage. The customer base skewed away from tier one, which meant payments arriving from small regional banks, and no single gateway had reliable connectivity to all of them. Three was what it took to cover the full set.

Almost every failure originated on the bank processing side rather than the gateway or our own stack. Small regional banks with weak online payment infrastructure fail in ways you cannot fix from the outside. You can only route around them.

Transaction failures dropped 30%.

Three gateways looks like tech debt on an architecture diagram. It was the only configuration that served the actual customer base. Building for the banks we wished our customers used would have quietly excluded the segment that turned out to drive the FD growth.

Wallet integration across the ecosystem. Bajaj also ran a closed-loop wallet, owned by a larger team. My part was integration: working out which businesses across the company could use wallet services, and writing the requirements and use cases for each.

Most of that turned out to be settlement. Cashbacks, discounts, gift cards, refunds. Refunds especially, because returning money to a small regional bank account has the same reliability problem as taking it in, and crediting a wallet does not.