How we verify
MasaDeals publishes a promo code as an offer only after the code has survived a real checkout. This page is the method, the ranking rule, and our measured track record — including where our code sources have failed.
The pipeline: from listing to verdict
- A code starts as a claim. Codes arrive from affiliate-network declarations, merchants’ own pages, and public deal listings. Entering the feed, a code is declared — advertised somewhere, proven nowhere. Declared codes are tracked but never served as offers.
- We test it in a real guest cart. An operator puts the code into the merchant’s own promo field on the merchant’s own site, in a real cart, and records exactly what the cart does. No purchase is completed to manufacture a verdict, and a test that would require submitting personal details is recorded as blocked instead of being forced.
- The result is a dated receipt. Every test produces one of four verdicts, stored on the code with the date, the cart, and the discount observed or the merchant’s own refusal message:
- verified — the cart applied the code and took a real discount. Published as an offer, with the receipt.
- rejected — the cart refused it. Kept and published as a certified negative; never served as an offer.
- conditional — the cart recognized the code and its offer, but a stated condition kept it from applying in that cart. Recorded with the condition; not verified, not served.
- blocked — no verdict was possible (site failure, or reaching the promo field would require personal details). Removed from the feed; kept in the verification ledger.
- Agent telemetry keeps verdicts current. Every code an agent tries at a real checkout is reported back through
report_outcomeand folded into a rolling success rate. Verdicts decay: a verified code that stops being confirmed goes stale, and failing re-tests flip it. A receipt is a dated fact, not a permanent one — codes are re-tested on a weekly sweep.
The ranking principle
Codes are ranked by observed checkout success — never by commission. The ranking function reads checkout outcomes only; commission rates, where known, are stored for reporting and are never read by ranking. That separation is enforced by an automated test: mutating every commission rate in the store must not change the order codes are served in. A code that pays more does not rank higher, is not labeled verified sooner, and is not served in preference to a better-verified code. When nothing clears the bar, the answer is the certified negative — no_verified_code — even when a paying link could have been served instead. See the Affiliate Disclosure for how money is made and why it cannot buy a verdict.
Certified negatives are published, not hidden
A rejected code is information: it tells the next shopper — and the next agent — not to burn a checkout attempt on it. MasaDeals keeps rejected codes visible with the date they failed and the merchant’s own refusal message, on the merchant pages and in the Black Friday section. A no_verified_code verdict means “no code verified for a cart like this, as of the date shown” — a checked, dated answer, not a failed search.
Round 1 results (October 31, 2026)
Our first verification round tested 22 codes at 10 merchants in real guest carts: 12 verified, 7 rejected, 1 conditional, 2 blocked. The full per-code ledger is maintained with the feed data and updated with every verification batch.
Measured source hit rates
Every source we take codes from earns a ranking from our own checkout tests: hit rate = verified ÷ (verified + rejected). Blocked and conditional tests count neither way. Merchant-direct sources (the merchant’s own coupons page, in-cart banners) are trusted by default but still cart-tested; third-party listings are ranked purely by what our carts measured — and a source at 0% gets dropped, however reputable it looks.
| Source | Type | Tested | Verified | Rejected | Hit rate |
|---|---|---|---|---|---|
| Merchant-direct (cvs.com coupons page, michaels.com in-cart banner) | Merchant-direct | 3 | 3 | 0 | 3/3 — trusted by default, still tested |
| moneysavingmom.com | Listing | 2 | 2 | 0 | 100% (n=2 decided) |
| dealnews.com | Listing | 2 | 2 | 0 | 100% (n=2 decided) |
| daily.slickdeals.net | Listing | 2 | 1 | 0 | 100% (n=1 decided; 1 blocked) |
| dontpayfull.com | Listing | 9 | 4 | 4 | 50% (n=8 decided; 1 conditional) |
| hotdeals.com | Listing | 3 | 0 | 3 | 0% (n=3) |
| retailcoupons.com | Listing | 1 | 0 | 0 | No decided tests (1 blocked) |
Small samples, stated as such: an n=2 source at 100% is a promising lead, not a law. The ranking updates with every round, and sourcing priority follows the measured order — merchant-direct first, then the listings in hit-rate order.
What verification is not
- Not a listing check. Seeing a code advertised — even on the merchant’s own site — is evidence it was published, not that it works. Only a cart test or reported checkout outcomes make a verdict.
- Not a guarantee. Verification is sampled from prior checkouts, ours and agents’. A code can die between the receipt date and your cart; that is why receipts carry dates and stale verdicts are labeled stale.
- Not complete coverage. Member-only, account-targeted, and single-use codes are structurally invisible to guest-cart testing. “No verified code” never means “no code exists anywhere.”
Page generated 2026-11-01 03:04:17 UTC. Method questions: [email protected].