Defects fixed

342 defects closed in the original hardening round, and the August 2026 measurement round closed five more — they are marked with their round below. The count is not the interesting part — what matters is that most of them never showed an error message. They took money, leaked data or lost stock quietly, which means a shop owner would only discover them from a customer complaint or a bank statement that did not add up.

Everything below was reproduced on a running shop with real data before it was fixed.

Defects that cost money

These are the ones worth reading first, because they are the ones that turn into refunds.

A coupon's minimum spend was never enforced. The admin panel let you set it. The code never read it. Proven live: a coupon requiring a ₹999 minimum order was accepted on an order worth ₹1. Six live coupons had minimums configured, all of them ignored.

Discounts ran on the wrong clock. The database kept time in UTC and the application in India time — measured 5 hours 30 minutes apart on a live install. An 18:00–22:00 evening discount therefore never applied during the evening, and switched itself on at 2 a.m. Worse: the listing screen and the checkout used different clocks, so a store could be advertised as discounted and then charge full price.

Add-on quantities were charged against the wrong add-on. Quantities were matched to add-ons by their position in a list — but the customer's app sends them in menu order while the database returns them in internal-ID order. Demonstrated on the server: an order the customer intended at ₹270 was billed ₹550. The same mistake existed in 8 separate places.

The stock check tested a different number than the one it changed. The final guard compared the product's overall stock; the decrement happened on the chosen variation's stock. On live data that meant 56 products where a legitimate purchase would be refused, and 1,451 where an oversell would go through undetected.

A repeated payment callback credited the payment twice. A customer refreshing the gateway's return page was enough to trigger it. Fixed once, at a level that covers all 47 gateways.

A withdrawal could be approved twice. Reproduced live: approving twice credited the withdrawn amount twice and drove the pending balance to −50.00. A double-click or a back-button did it.

Two riders could accept the same order, and two customers could buy the last unit — classic check-then-write races, now single atomic database claims, proven with concurrent transactions.

Security holes

Any customer's order was readable and editable by anyone. More than six endpoints accepted any order ID with a guessed guest ID. Reproduced with no authentication at all: the response contained another customer's items, prices and delivery address. The wallet-payment endpoint on the same path had no balance check either.

A payment gateway switched off could still settle payments. Turning a gateway off in the admin panel only removed it from the customer's list of choices — its callback URL stayed live, and many gateway callbacks mark an order paid on nothing more than a status word in the URL. With every gateway switched off, a callback still completed successfully, so a customer could confirm their own order without paying. Now fails closed, with 102 probes across every gateway prefix confirming it.

Vendors could act on other vendors' data — edit or delete another store's products, add-ons and banners, including the admin's own home-screen banners. Replying to a review reassigned that review to the replying vendor's store.

The API had no rate limit at all, so password guessing and OTP sending (which costs real money per message) were unbounded.

The listing cache could be poisoned. Its key was computed from part of the request only, so an unauthenticated visitor could choose which products, stores and prices other shoppers saw.

"Remember me" stored the admin's actual password in a browser cookie (August 2026 round). Ticking the box saved the e-mail and password encrypted — not hashed — so anything that could read the cookie and the site key got the real password back: an XSS, a shared computer, a proxy that logs headers. The optimised fork now prefills only the e-mail; the password is never written to the browser. SixPreflight reports this on stock installs, because the vendor code still does it.

Plain breakage

Three API endpoints returned a server error on a clean install — popular stores, latest stores, and payment methods. All three now answer in 41–150 ms. These are on the first screen of the app, on a shop that has just been installed and has never been touched.

Four admin pages answered a server error to an ordinary GET (August 2026 round, found by sweeping all 297 admin pages): two crashed on a stale link or an unknown id where "not found" was the honest answer, and two were routes pointing at controller methods that do not exist in the codebase at all — dead since the vendor shipped them.

The counts, honestly

The project's own tally rates 4 of the security holes critical and 6 of the defects money-affecting, out of 342 fixed.

Those are lower than the number of items named on this page, and deliberately so — they are the conservative published figures, and we quote them rather than the larger counts our own notes would support. This page lists every defect we reproduced, not only those inside the two headline tallies.

Why they were all still there

None of this is exotic. It is the ordinary result of code tested against a demo dataset by people who were never a shop's customer. Most of these are invisible until there is real money and real concurrency — which is exactly what the scale test provided, and why it is where most of them surfaced.

A test suite ships with the build so each of these stays fixed. What has not been solved is on what is still open.