The Curious Case of the ₹122 Vada (and the ghost idlies) from Zomato

I recently placed a simple Zomato order: 4 idlis and 1 vada for ₹159.

The payment failed.

Zomato then showed me the very familiar, frictionless:

“Retry Payment”

The retry picked up the payment flow immediately. My phone auto-filled the OTP, and the payment went through in seconds. It was seamlessly fast.

Until the food arrived.

There was one vada.

The four idlis were missing.

The final bill for that single vada was ₹122.

I had just paid over a hundred rupees for a single, small-cart item. Welcome to the curious case of the ₹122 vada and Zomato's ghost idlis.

What happened to the idlis?

The idlis went out of stock.

They vanished from inventory precisely between my original payment attempt and the successful retry.

That is not the problem.

Inventory fluctuates. Payments fail. These things happen in high-scale food delivery.

The problem is what Zomato’s system did when the order state changed.

I did not go back to the restaurant page and decide to create a new order containing only one vada. I clicked the button Zomato provided:

Retry Payment.

To any customer, that action clearly means:

Payment failed → attempt to pay for the exact same order again.

Instead, the system silently transformed the “retry” into a brand new checkout based on a mutated order state, without explicit consent.

A payment retry shouldn't silently become a new checkout

The Retry Payment action never told me:

“Your order has changed since your previous payment attempt.”

If the four idlis were unavailable, the platform should have presented me with a clear confirmation screen. The logic should be:

Payment failed → Retry Payment → Order changed due to inventory → [Show comparison / Review Order] → Customer Confirms → OTP → Success.

Instead, Zomato is optimizing for an "improved" but dangerous state transition:

Retry Payment → OTP (auto-filled) → Success → Surprise mutation.

This flow is designed to maximize payment conversion, but it does so by sacrificing customer transparency and transaction consent.

The ₹122 Vada: The Threshold Trap

This is how a ₹35-ish vada ends up costing ₹122 delivered.

When the idlis were removed, the order value instantly dropped below the restaurant’s minimum-order threshold. The system automatically removed threshold-based discounts and simultaneously tacked on delivery charges or small-cart fees.

My intended transaction flow was:

4 idlis + 1 vada (meeting threshold) → ~₹159

What was actually executed was:

1 vada → ~₹35 (vada) + threshold fees & delivery → ~₹122

In UX and product terms, this is Silent Cart Mutation. An order is an agreement between the consumer and the platform. By allowing the payment retry to complete after silently altering both the line items and the pricing structure, the platform violates core transaction consent.

The support experience didn't help

My attempt to explain this through Zomato support only made it clear that this isn't handled as a systemic product defect.

Getting past the predefined automated chatbot trees to a place where I could describe what actually happened took unnecessary effort. Once I finally explained that the 'Retry Payment' flow coupled with an out-of-stock event caused a silent cart mutation, the response was a boilerplate apology for the "system issue" that ultimately claimed I had placed a new order.

I didn't "place a new order."

I retried payment on the order Zomato had already created.

If the backend state reconciliation automatically modifies cart line items during a retry, Zomato should not reframe backend state transitions as an intentional customer action after the fact.

This is a solved problem in e-commerce

This is a classic inventory reconciliation and distributed state management problem, and it has solved patterns across the industry.

Platforms like Amazon have well-established UX workflows for this exact scenario: they halt the transaction. When a cart item goes out of stock during checkout, the flow stops, highlights the exact quantity change, updates the total, and requires an explicit confirmation before letting you proceed.

The underlying principle is straightforward:

If a material change happens to the transaction (inventory, price, or delivery fees), the customer must explicitly confirm.

You cannot expect the customer to anticipate backend state changes. The application must surface them.

The incentive structure problem

It is easy to see the product metrics that incentivize this design.

A frictionless:

Payment failed → Retry → OTP (auto-filled) → Success

flow delivers exceptional payment conversion rates. Every confirmation modal added to a retry flow introduces drop-offs.

However, when conversion optimization overrides transaction integrity, it creates an uncomfortable incentive structure:

Maximize conversion for millions of transactions, and handle the small percentage of edge-case disputes through automated support or ad-hoc refunds.

Most customers won't spend 20 minutes wrestling with automated support over a ₹50 or ₹80 fee discrepancy; they simply shrug and move on. But customer fatigue should not be an acceptable buffer for poor UX architecture.

The fix is straightforward

Zomato needs to review the exact state machine when:

Payment fails + inventory changes + customer taps Retry Payment.

The expected behavior is simple:

Your order has changed

4 × Idli: unavailable (out of stock)
1 × Vada: ₹35

Original total: ₹159
Updated total: ₹122 (Delivery & small-cart charges applied)

[Review & Pay (₹122)]   [Cancel Order]

This single check prevents customer frustration, eliminates support tickets, and avoids the absurdity of a ₹35 vada wondering how it turned into a ₹122 meal.

I clicked “Retry Payment.”

I did not click “Surprise me with whatever is left in the kitchen.”

Consider this a bug report disguised as an idli story, Zomato. Let's make checkout flows transparent.