Methodology

How We Verify Credit Card Data

Last updated: June 2026

This is the technical companion to our editorial policy. It explains the process behind every reward rate, fee, and cap on WhichWise: how we capture it, verify it, label it, and why we only publish cards whose data we can currently stand behind.

1. Why this page exists

Indian credit card comparison sites are full of unverifiable claims. Reward rates that don't match the bank's page. Caps that are silently wrong. Benefits that were discontinued two years ago. Readers cannot tell accurate from stale, because nobody shows their work.

Credit cards are a YMYL (Your Money, Your Life) topic in Google's quality guidelines, the same category as medical and legal content. Our position: YMYL data should be auditable. Every claim on a card page should be traceable back to a primary source, and every source should be something a reader could independently check.

This page documents exactly how we do that. If the process described here is not what you're seeing on a specific card page, email hello@whichwise.com. That is a bug we want to fix.

2. The verification process

Every card on WhichWise passes through a multi-lane verification pipeline before it is published. Each lane has a binary pass/fail gate. A card is considered “verified” only when every lane passes.

Lane A: Data accuracy

Every structured field (annual fee, reward rate, monthly cap, excluded categories, forex markup, lounge access, welcome bonus, etc.) is verified against the issuer's official card page and MITC document. Gate: zero mismatches.

Lane B: Content specificity

Card descriptions, pros, cons, FAQ answers, and verdicts must reference specific numbers, real competitors, and concrete use cases, not generic filler. Gate: specificity, competitor-reference, and FAQ criteria all pass.

Lane C: Render correctness

The rendered page is tested for reward-math accuracy, milestone reachability logic, cap handling, online/offline split math, and a series of other render sub-checks. Gate: all reward-math and render checks pass.

Lane D: Human audit

Every card goes through a human review cycle alongside the automated lanes. Feedback is filed, researched, disputed where appropriate, and resolved before the card is approved to ship. Nothing goes live on automated checks alone.

3. What “verified” means on our pages

When you see “Verified against issuer T&C, last checked [date]” on a card page, it specifically means:

  • Every structured numeric fieldwas checked against the issuer's official source on the date shown.
  • Source files were captured and stored in our source cache with a cryptographic hash. If the bank changes their page, we can diff against the version we verified.
  • Claims are labeled (see the Truth Labels section below), so editorial inferences are distinguishable from factual claims pulled from the source.
  • The verification is recent, within 180 days. Past that window, the card is held back from publication until re-verified.

4. What we publish and what we hold back

We've scoped and verified data for hundreds of Indian credit cards, but we only publish a card once it has cleared the verification process above. This is a deliberate data transparency choice: we'd rather launch with a smaller, fully-verified lineup than a large one we can't currently stand behind.

A card that hasn't cleared verification (or whose last check is older than 180 days) is held back from the published lineup until it's re-verified, rather than shown with stale numbers.

This is the harder, slower path. Every other Indian comparison site lists every card they have data for, verified or not. Our position: publishing a confident page on data we cannot currently stand behind is worse than showing nothing. YMYL content should err on the side of admitting what we don't know. The lineup grows as verification catches up, by design.

5. How we calculate ₹ reward

Every reward number on WhichWise comes from the same engine, the same code that powers card detail pages, comparison pages, and our internal audits. It is a pure function of the card's structured data plus your spend profile.

The engine applies, in order:

  1. Partner bonus earn: any merchant-specific rate (Amazon, Swiggy, Flipkart, etc.) is applied first, respecting per-partner monthly caps.
  2. Category bonus earn: category rules (e.g., 5% on groceries) are applied next, respecting per-category caps.
  3. Online / offline split: cards with different online and offline rates apply the correct rate to the correct share of spend.
  4. Excluded categories: spend in excluded categories earns ₹0, and is removed from the base-rate calculation before step 5.
  5. Base rate on remaining spend: whatever was not already claimed by partner, category, or excluded logic earns the effective base rate.
  6. Tiered spend thresholds: some cards pay a higher rate above a monthly spend threshold; the engine applies the correct rate to each tier.
  7. Aggregate monthly cap: if the card has an overall cap, the total earn is clipped to it.
  8. Fuel surcharge waiver:where applicable, the 1% fuel surcharge is waived up to the card's per-transaction and monthly caps.
  9. Welcome bonus and milestones: year-1 welcome bonus and spend milestones the user would actually hit are added.
  10. Annual fee and fee waiver:if the user's spend hits the fee waiver threshold, the annual fee is set to ₹0; otherwise it is subtracted.
  11. Redemption value:points are converted to rupees at the card's point value (conservative / best / transfer tier as selected).

The engine is pure: no random adjustments, no “editorial smoothing”, no secret multipliers. The same inputs produce the same outputs every time. If two of our pages show different reward numbers for the same card at the same spend level, that is a bug.

6. The source cache: our evidence layer

When we verify a card, we don't just read the issuer's page and move on. We capture the pages we verified against and store them in a source cache with a SHA-256 hash, the retrieval timestamp, and the role of each file (card page, T&C, fee schedule, MITC, RBI circular, etc.).

Two reasons this matters:

  • Auditability. If a reader challenges a specific claim, we can point to the exact version of the issuer page that backs it.
  • Drift detection.When a card is re-verified, the pipeline compares the new source against the cached version and flags any fields where the issuer's stated value has changed. This is how we catch silent devaluations.

No claim goes into the source cache without a quote that appears verbatim in the retrieved source. If a field's claimed value cannot be substring-matched to any quote in the source files, it is rejected as unverified.

7. Truth labels: our provenance system

Every field on every card is labeled with one of nine provenance categories:

  • verified: matches a quote from an issuer source
  • verified_by_absence:the source explicitly confirms the field is null (e.g., “no welcome bonus”)
  • observed: derived from verified values by a deterministic rule
  • derived: computed by a documented formula from verified inputs
  • editorial: WhichWise interpretation, clearly labeled as opinion
  • editorial_whichwise: our editorial opinion, with a rationale and a set-by operator
  • unverified: a value exists but we could not find a source for it
  • blocked: the field cannot be verified without direct issuer contact
  • legacy_unlabeled: imported before the truth label system existed; will be re-labeled on next enrichment

Labels are stored alongside every field in our card database and drive how the UI renders. Fields labeled blocked or unverified get explicit treatment on the card page. You will see them called out, not silently filled in.

8. Data refresh cadence

  • On launch.Every card is fully verified before it gets a “last verified” date and is published.
  • On an ongoing basis. We re-verify cards over time rather than on a fixed schedule, prioritising cards more likely to have changed. Some are checked more often than others. The source cache comparison flags any fields where the issuer changed their stated value since the last check.
  • On 180-day expiry. Any card whose last verification is older than 180 days is held back from publication until re-verified. This is enforced by a freshness gate in code. There is no manual override that can extend a stale verification.
  • On devaluation alerts. When a user, a public source, or our monitoring detects a change, we aim to re-verify promptly and file a recent change on the card page.

9. No affiliate relationships

WhichWise does not accept affiliate commissions from any card issuer. Rankings are based on data, not partnerships. This is a load-bearing editorial choice: the moment commission influences order, every rank on the site loses meaning.

If we ever add affiliate links in the future, they will be disclosed on the card page itself (not silently embedded), and they will be applied after the ranking is computed, with no influence on rank order. Order will still be derived solely from the verified data and the reward engine described above.

10. Found an error? Report it

If a number on WhichWise does not match what you're seeing on the issuer's page, we want to know. Email hello@whichwise.com with:

  • The card name (and the URL of our page, if you have it)
  • The specific field or claim that looks wrong
  • A link to the issuer's official page you're comparing against

Every report is investigated against the source cache and against a fresh retrieval from the issuer. If you were right, the card is re-verified and the fix goes live on the next build. If we disagree, you'll get a reply explaining why, with the specific issuer quote that backs our claim.

See also: editorial policy · about WhichWise · disclaimer