The cross-merchant comparison problem
Why sticker comparators came first
Comparators like PriceDekho, MySmartPrice, BuyHatke and the long tail were built when (a) the dominant pricing variable was the merchant's own discount, and (b) bank offers were rare and small. In that world, the sticker is a reasonable proxy for the checkout total, and ranking merchants by sticker is approximately right.
That world is gone. Bank offers have become the largest single discount line on mid-to-high-AOV electronics, and they are tied to specific cards on specific merchants. The new dominant variable is not visible to a sticker comparator that does not know which cards the buyer holds.
The arithmetic
Consider a representative iPhone listing across three large Indian electronics channels. Stickers cluster within 1–2%; the offer stack varies materially.
| Merchant | Sticker | Best card / offer | Effective price |
|---|---|---|---|
| Marketplace A | ₹1,24,500 | Co-marketed card · ₹6,000 instant + ₹2,000 cashback | ₹1,16,500 |
| Marketplace B | ₹1,23,900 | No card-specific offer; coupon ₹500 | ₹1,23,400 |
| Brand-authorised electronics retailer | ₹1,25,000 | Brand finance EMI ₹4,000 rebate + reward points | ₹1,19,800 |
Sticker rank: B < A < C, gap of ~1%. Effective price rank: A < C < B, gap of ~6%. The cheapest-sticker merchant is the most expensive checkout. A sticker comparator that recommends B is technically correct on the axis it measures and wrong on the axis the buyer cares about.
Why fixing this is hard
- Bank-offer data is fragmented. Each merchant publishes its current offers on its own site; there is no central registry. An effective comparator has to crawl every merchant continuously and normalise the offer terms against a common schema.
- Buyer wallet is private. A general-purpose sticker comparator does not know which cards the buyer holds; without that input, ranking by effective price is meaningless. The buyer has to declare wallet for the ranking to apply to them.
- Cap and stacking rules are per-merchant. A comparator without a per-merchant rulebook will overstate savings for the merchant with the most generous-looking offer text and miss the merchant with quietly stackable rebates.
How Zlash Price Intelligence fixes it
- Continuous per-merchant offer crawler, normalised into a common schema (BIN, cap, tenure, stacking).
- Buyer-declared wallet of cards as a search-time input.
- Effective-price computation using the seven-layer formula for every (merchant × card × payment-rail × offer-stack) combination.
- Output is a ranked merchant list keyed on effective price — not sticker — with the per-merchant offer stack visible for verification.
Compare merchants on what you actually pay
Search any product on Zlash Price Intelligence and the output is the per-merchant effective price for the cards in your wallet. The cheapest merchant shown is the cheapest checkout — not the cheapest sticker.
Open Price Intelligence →