CouponBay
Home › How we verify

How We Verify Coupons June 2026 · CouponBay

We don't test codes at checkout. Here's what we actually do — and why we won't pretend otherwise.

1. Authorized feed sourcing

We ingest coupons from merchant-authorized feed pages — the same feeds the merchant publishes for their own affiliates and partners. We do not scrape checkout pages, run test purchases, or guess at codes.

2. Daily re-scrape cycle

Each store is re-fetched on a roughly 15-day rolling cycle. The raw HTML is archived immutably the moment we receive it; every subsequent parse re-reads that archive, so a parsing bug never triggers a re-scrape against the live merchant site.

3. The offer verification ledger

For every coupon we publish, a Silver-layer ledger row records: when we first saw the offer in the feed, the last time we re-confirmed it, the source feed URL, the merchant-stated expiry, and the most recent shopper click that resolved through our redirect.

4. Daily expiry purge

Once a day, a rollup job walks the ledger and marks any offer past its expiry — or no longer present in the latest feed fetch — as expired. Expired offers are removed from the servable set: they don't appear in coupon lists, search results, or the money-path redirect. The alive→expired transition is monotonic — we never silently revive an expired offer.

5. What we deliberately don't do

We don't test codes at checkout. We don't build real carts or run transactions. We don't fabricate success rates, review counts, or editor personas. We don't infer whether a code "worked" for any specific shopper — we only know it was present in an authorized feed as of a specific date, and that shoppers clicked through to the merchant via our redirect.

Frequently asked questions

How is CouponBay different from other coupon sites?

Most coupon sites publish a success rate, an editor byline, or a "hand-tested at checkout" claim. We don't. We show you what we actually have: the date each offer was last seen in an authorized merchant feed, how many shoppers clicked it, and when it expires. The trust narrative is the data, not a persona.

Why do you say "seen in feed" instead of "tested"?

Because we don't test at checkout. A merchant's authorized affiliate feed is the canonical source — when an offer is removed from that feed, it's almost always because the merchant ended it. "Seen in feed as of {date}" is the most precise honest statement we can make. Claiming "tested working" would require building a real cart at every merchant, which we don't do.

How often are coupons refreshed?

Each store is re-fetched on a roughly 15-day rolling cycle. The most recent feed fetch date is surfaced on every store page as "last seen in authorized feed {date}". High-traffic stores may be re-checked more frequently; the ledger always reflects the most recent confirmation.

What happens when a code stops working?

Once the offer disappears from the merchant's authorized feed OR passes its stated expiry, our daily purge marks it expired and removes it from the servable set. You won't see it in coupon lists or search. If a code stops working before our purge catches it, that's a real gap — the "last seen" date tells you how fresh our knowledge is.

Do you test codes at checkout?

No. We don't build carts, run transactions, or observe whether a code applied successfully. Doing so at scale across every merchant would be both operationally infeasible and a violation of merchant terms of service. Our verification is feed-based: the offer exists in the authorized source on the date we claim, period.