Data type · Card offers

Bank card offer data, structured — because the terms are where the value is

Almost nobody structures this. It sits as marketing copy on bank pages and as a line at merchant checkout, and the terms that determine the real discount are buried in the same sentence as the headline.

Bank card offer data is the structured record of issuer-funded discounts: which card, at which merchant, with what minimum spend, what maximum discount, which validity window and which exclusions. The headline — 10% off with HDFC — is the least useful part. The cap, the minimum spend and the exclusions decide what a shopper actually saves.

Get a free card offer sample See sample data

Free pilot on your own sources, returned in 24 hours. No card, no trial clock — and you keep the sample data either way.

✓ Terms parsed, not just the headline✓ Both sources: bank site and merchant checkout✓ Caps and exclusions as their own fields

card_offers.jsonl LIVE FEED

// one record per offer per card per merchant {"issuer": "issuer-a", "card_type": "credit", "card_variant": "select_range", "merchant": "example-travel", "category": "flights", "discount_pct": 10, "max_discount": 2500, "currency": "INR", "min_spend": 15000, "effective_max_rate": 16.7, "valid_from": "2026-08-01", "valid_to": "2026-08-31", "txn_cap_per_card": 1, "source_surface": "merchant_checkout", "terms_parsed": true} {"issuer": "issuer-b", "discount_pct": 10, "max_discount": 750, "min_spend": 5000, "note": "same headline 10% — real ceiling is a third of the other"} {"issuer": "issuer-c", "terms_text": "…conditions apply as per issuer discretion…", "terms_parsed": false, "parse_reason": "discretionary_terms_not_quantified"}

3 of 184,220 offer records terms parsed 91.4% · unparsed delivered as text · schema v1.0

Our Data Powers

B2C Marketplace

amazon

D2C + Marketplace

NYKAA

D2C + Marketplace

Walmart

FMCG Marketplace

udaan

Food Delivery

Uber Eats

Quick Commerce

blinkit

Taxi Aggregator

Uber

E-Commerce

Tmall

Summary What it is What's included Schema Markets Who it's for Examples How we engage SLA FAQ

Written and reviewed by the Actowiz Solutions Data Engineering team Published 5 August 2026 Last updated 5 August 2026 Reading time 10 min

Key facts at a glance

What it is: Issuer-funded offers as structured terms, not marketing copy
The headline lies: Two 10% offers can differ threefold once the cap is applied
Fields that matter: Maximum discount, minimum spend, exclusions, transaction cap
Two surfaces: Bank offer pages and merchant checkout — they often disagree
Derived: Effective maximum rate, computed from cap over minimum spend
Unparsed terms: Delivered as text with a reason. Never guessed at
Not collected: Cardholder data, account numbers, statements — none of it, ever
Refresh: Daily; offers change without notice and expire silently

3xdifference between two 10% offersonce caps are applied

2surfaces per offerbank page and merchant checkout

91%typical terms parse ratethe rest delivered as text

24hfree sample on your own merchantswith the parse rate stated

Key takeaways

What it is: Issuer-funded offers as structured terms, not marketing copy
The headline lies: Two 10% offers can differ threefold once the cap is applied
Fields that matter: Maximum discount, minimum spend, exclusions, transaction cap
Two surfaces: Bank offer pages and merchant checkout — they often disagree
Derived: Effective maximum rate, computed from cap over minimum spend
Unparsed terms: Delivered as text with a reason. Never guessed at

Last verified 5 August 2026 by the Actowiz Solutions Data Engineering team.

Definition

Why the headline percentage is the least useful field

Two offers, both advertised as 10% instant discount:

Field	Offer A	Offer B
Headline	10%	10%
Minimum spend	15,000	5,000
Maximum discount	2,500	750
Effective ceiling	16.7% of the minimum	15% of the minimum
On a 40,000 basket	2,500 — 6.3%	750 — 1.9%

At the minimum spend they look similar. On a real basket one is more than three times the other. Nothing in the headline tells you that.

What we deliver instead

Every term as its own typed field: discount_pct, max_discount, min_spend, txn_cap_per_card, valid_from, valid_to, plus exclusions as a structured list. And a derived effective_max_rate, computed as cap over minimum spend, so offers are sortable on something meaningful rather than on the number in the banner.

Where we stop

A meaningful minority of offers carry discretionary or unquantified terms — at issuer discretion, on select products. Those are delivered as terms_text with terms_parsed: false and a reason. We do not guess a number, because a guessed cap in a structured field is indistinguishable from an observed one two weeks later.

What we capture

Six offer dimensions, structured

Take everything, or only the issuers and merchants your analysis covers.

Issuer, card and eligibility

Which cards an offer actually applies to.

Issuer and card type — credit, debit, EMI
Card variant or range where the offer is restricted
Network restrictions where stated
Eligibility conditions as published

Discount mechanics

The fields that decide the real saving.

Headline percentage or flat amount
Maximum discount cap
Minimum spend threshold
Derived effective maximum rate

Validity and caps

Offers expire silently and quietly change.

Valid-from and valid-to dates
Transaction cap per card and per period
Day-of-week or time restrictions where stated
First-seen and last-seen, so a quiet withdrawal is visible

Exclusions

The list that decides whether an offer applies at all.

Excluded categories or product types
Excluded merchants or sub-brands
Interaction rules with other offers
Delivered as a structured list, not a paragraph

Surface and disagreement

Bank page and checkout do not always match.

source_surface on every record
Same offer captured from both where both exist
Disagreement flagged rather than resolved
Merchant checkout is the version a shopper acts on

Merchant and category mapping

So offers join to your own data.

Merchant normalised to your naming
Category as the offer defines it
Sub-brand handling where an issuer names a group
Geography where an offer is market-restricted

Service scope

What the ecommerce data scraping service includes

A managed engagement, not a tool licence. We own the pipeline and everything that breaks in it.

✓ Included in every engagement

Discount mechanics, caps and minimum spends as typed fields
Derived effective maximum rate, so offers are comparable
Validity windows, transaction caps and structured exclusions
Both surfaces — bank page and merchant checkout — with disagreement flagged
Unparsed or discretionary terms delivered as text with a reason
Disappeared offers flagged in each batch manifest
Source discovery, scoping and a written collection plan
Free pilot on your own sources before any commitment
Full pipeline build, hosting and proxy infrastructure
Schema design, validation and sampled human QA on every run
Ongoing maintenance when source layouts change — our cost, not yours
Delivery to your warehouse, bucket, SFTP or API endpoint
Documented methodology and compliance notes for your legal review

× Not included — stated upfront

Cardholder data of any kind, including partial numbers or names
Account, statement or transaction records
Anything behind a banking or merchant login
A guessed cap where the published terms do not quantify one
Entering a card or completing a checkout to reveal an offer
Anything behind a login, paywall or credentialed session
Personal data beyond a documented lawful basis
Licensed third-party datasets we do not hold rights to
Guarantees about fields a source simply does not publish

Schema

Card offer fields we deliver

One record per offer per card per merchant per surface.

Card offer schema v1.0 — abbreviated to core fields
Field	Type	What it captures	Refresh
`issuer / card_type / card_variant`	string	Who funds it and which cards qualify	Every record
`merchant / merchant_normalised`	string	As named by the offer, and mapped to your naming	Every record
`category`	string	The category the offer applies to	Every record
`discount_pct / discount_flat`	number	Headline mechanic, whichever applies	Every record
`max_discount / currency`	number / string	The cap, which is usually the binding term	Where stated
`min_spend`	number	Threshold below which the offer does not apply	Where stated
`effective_max_rate`	number	Derived: cap over minimum spend, so offers are comparable	Where computable
`valid_from / valid_to`	date	Validity window as published	Where stated
`txn_cap_per_card / txn_cap_period`	number / string	How often a cardholder can use it	Where stated
`exclusions`	array	Structured list rather than a paragraph	Where stated
`source_surface`	string	bank_page or merchant_checkout	Every record
`terms_parsed / terms_text / parse_reason`	boolean / string	Unparsed terms delivered as text with a reason	Every record

Every batch ships with a manifest containing offer counts by issuer and merchant, the terms parse rate, and offers that disappeared since the previous run.

Coverage

Where card offers are collectable

Both surfaces where both exist. Parse rates differ by issuer and we report them per issuer.

Bank offer and promotions pagesMerchant checkout offer panelsTravel booking platformsAirline and hotel direct sitesEcommerce marketplace checkoutsFood delivery platformsQuick commerce platformsFuel and utility payment pagesElectronics and appliance retailersFashion and beauty retailersGrocery and supermarket checkoutsRide-hailing payment screensInsurance and financial product pagesEducation and course platformsCredit card offer aggregatorsEMI and no-cost-EMI termsWallet and UPI-linked card offersCo-branded card promotions

Coverage is defined by issuer and merchant rather than by site count. A tight scope of eight issuers across twenty merchants is a far more useful dataset than a broad sweep with thin terms. Request a source we don't list →

Markets served

Countries and markets where this service is in highest demand

We deliver into 40+ countries. These are the markets where this particular service is requested most, and the reason demand concentrates there.

Highest-demand markets for this service, and why demand concentrates there
Market	Why demand concentrates here

North America

United StatesCanadaMexico

United Kingdom & Ireland

United KingdomIreland

Western Europe

GermanyFranceNetherlandsBelgiumSpainItalySwitzerlandAustria

Nordics

SwedenNorwayDenmarkFinland

Middle East

United Arab EmiratesSaudi ArabiaQatarKuwaitIsrael

Asia Pacific

SingaporeAustraliaNew ZealandJapanSouth KoreaMalaysiaIndonesiaThailandVietnamPhilippines

South Asia

IndiaBangladeshSri LankaPakistan

LATAM

BrazilArgentinaChileColombia

Africa

Building offer discovery or a card recommender needs machine-readable terms.

What we deliver

Typed fields with an effective maximum rate, and unparsed terms flagged rather than guessed.

Metric that moves

Recommendation quality

Use cases

How card offer data gets used

Four patterns, two of them not obvious.

Effective competitive price, not headline price

Card offers joined to observed prices at the same merchants, so a competitor 4% more expensive with a 10% card offer is correctly read as cheaper for a large share of shoppers.

Outcome: Price positions that reflect what shoppers actually pay.

Issuer partnership benchmarking

What terms competing merchants have secured from which issuers, structured so caps and minimum spends are comparable rather than buried in copy.

Outcome: Negotiations that open from the market position rather than from a guess.

Offer-driven demand attribution

Validity windows and first-seen dates against your own traffic and conversion, so a lift that came from an issuer offer is not credited to a campaign.

Outcome: Marketing attribution that survives scrutiny.

Silent withdrawal detection

Offers that disappear without an expiry date are flagged in the manifest, which is how most offers actually end.

Outcome: Knowing an offer stopped before a customer tells you.

Engagement examples

Two engagements, anonymised

Clients rarely permit naming. These are real engagement shapes with identifying detail removed, so you can judge whether the work resembles your situation.

Examples are anonymised at client request. Named references are available on request under NDA. See published case studies →

The 24-hour sample — run on your sources, not ours

Before you commit to anything, we run this service against your own sources and send you the output. If the coverage isn't there, the sample will show you that too — which is the point. We would rather lose the deal at the pilot than at month three.

Real extraction from your actual sources
Returned within 24 hours
Coverage and QA note included
You keep the data either way
No card, no trial clock
Named engineer on the call

Get my free sample Book a 20-min scoping call Reply within one business day. Reference calls available under NDA.

How we engage

Three ways to engage us

Same collection pipeline and QA underneath. The difference is who holds the schedule and how the data reaches you.

Managed service (most common)

We own the collection, the QA and the delivery. You receive clean data on a schedule and never touch a scraper.

Dedicated engineer assigned to your account
Site changes fixed by us, not reported to you
Scheduled delivery to your warehouse or S3
Named contact on Slack or email

Best fit: Teams who need the data, not the infrastructure.

API access

The same collection pipeline exposed as an authenticated REST endpoint your systems query directly.

On-demand and scheduled endpoints
Rate limits agreed to your load profile
Sandbox keys for integration testing
Versioned schema with deprecation notice

Best fit: Product and engineering teams building on live data.

One-time or project extraction

A defined pull for a specific question — market sizing, diligence, a pitch, a one-off audit.

Fixed scope agreed in writing upfront
Single delivery with full QA report
Methodology documented for your records
Converts to managed if you want continuity

Best fit: Research, strategy and diligence work with a deadline.

Pricing

Every engagement is quoted individually, because the honest answer depends on your scope: how many sources, how many records, how often, and how the data reaches you. We scope it with you, run a free pilot on your own sources, and then quote a fixed monthly figure — no per-request metering and no overage billing when volumes move. Request a quote and you will have a number after one call.

Build vs buy

Collect card offers in-house, or take the feed?

In-house is reasonable for a handful of issuers at one merchant. It stops being reasonable quickly.

In-house build vs self-serve tool vs Actowiz managed service
Consideration	In-house scraping team	Generic proxy / DIY tool	Actowiz managed feed
Time to first usable data	6–12 weeks of engineering before anything is trustworthy	Days, but output needs manual cleanup before use	Free pilot in 24 hours, production in 5–10 business days
Who fixes it when a source changes	Your engineers, at the cost of their roadmap	You do — tools report failures, they don't resolve them	We do, same business day, inside the retainer
Data quality assurance	Whatever your team has time to build	None beyond HTTP success	Schema validation plus sampled human QA on every run
Compliance documentation	Rarely produced, then requested urgently by legal	Not provided; terms risk sits with you	Sources, method and lawful basis documented for review
Accountability	Distributed across a team with other priorities	A support ticket queue	A named engineer and an account owner
True annual cost	Engineer salaries, proxies, hosting, ongoing maintenance	Low licence fee plus significant hidden analyst time	One fixed monthly retainer, quoted after scoping

Bank page and merchant checkout frequently disagree

The same offer appears in two places, and they are not always the same offer.

The bank page is a marketing surface, updated on the issuer's schedule, and it sometimes carries offers that have already ended at the merchant.
The merchant checkout is the version a shopper actually acts on, and it sometimes carries terms the bank page does not mention.
Caps and exclusions are the fields that most often differ.

We capture both where both exist, record source_surface on every record, and flag the disagreement rather than resolving it. Picking one would hide a real signal: a bank page still advertising a withdrawn offer is itself worth knowing about, and so is a checkout carrying a cap the bank page omitted.

For most analytical purposes the checkout version is the one to weight. For partnership benchmarking, the bank page version is what the issuer is publicly committing to. They answer different questions.

What we will never collect here, and why it matters more in this category

This is payments-adjacent data, so the boundary needs stating plainly rather than assumed.

Never, under any framing

Cardholder data. No card numbers, no partial numbers, no BINs tied to individuals, no names.
Account or statement data. Nothing behind a banking login, ever.
Transaction records. Not ours to hold and not publicly available.
Anything requiring a signed-in banking or merchant session.

Everything on this page comes from publicly displayed promotional pages and publicly visible checkout offer panels. No account is created, no card is entered, and no checkout is completed.

Why the line sits there

Offer terms are marketing information published to attract customers. Cardholder data is regulated financial information about individuals. They sit on opposite sides of a line that does not move, and a vendor blurring the two in this category is a serious problem rather than an aggressive one.

How it works

How a card offer feed goes live in 5 to 10 business days

Scope by issuer and merchant, not by site count.

Name the issuers and merchants, not the URLs

Coverage here is defined by which issuers and which merchants matter to you. A tight scope with full terms beats a broad sweep with thin ones.

We report the terms parse rate per issuer

Before quoting. Issuers differ substantially in how quantifiable their terms are, and a low rate on your key issuer is something to know upfront.

Free sample within 24 hours

Real offers from your own merchants, with parsed terms, the derived effective rate, and any unparsed terms shown as text so you can see both.

Decide which surface to weight

Checkout for effective-price analysis, bank page for partnership benchmarking. We deliver both and flag disagreement; the weighting is your choice.

Production and monitoring

Live in 5 to 10 business days, with disappeared offers flagged in each batch manifest since silent withdrawal is how most offers end.

Formats & destinations

JSON, JSONL, CSV, Parquet or XLSX, delivered to Amazon S3, Google Cloud Storage, Azure Blob, Snowflake, BigQuery, SFTP or a REST endpoint.

Compliance & data ethics

We collect only publicly displayed promotional terms from bank pages and merchant checkout panels. We never collect cardholder data, account or statement information, or transaction records, and we never create an account, enter a card or complete a checkout.

Service commitments

What we commit to, in writing

These are contractual, not marketing copy. They appear in the engagement document.

Service level commitments written into every managed engagement
Commitment	What we hold ourselves to
Pilot turnaround	A real sample from your own sources within 24 hours of scoping, at no cost.
Go-live	Production collection running within 5–10 business days of sign-off.
Delivery punctuality	99.5% on-schedule delivery, measured monthly and reported to you.
Breakage response	Source layout changes triaged same business day; critical sources inside 4 hours.
Data quality	Schema validation on every run plus sampled human QA before any delivery leaves us.
Escalation	A named engineer and an account owner, not a shared ticket queue.
Change requests	Field additions and source changes handled inside the retainer, not re-quoted.
Exit	Your historical data exported in full on request. No lock-in, no export fee.

Why teams pick Actowiz for this work

Engineers, not a dashboard. You get people who fix breakages, not a self-serve tool you maintain yourself.
We tell you what we can't do. Scope limits and coverage gaps are stated before you sign, not discovered in month three.
QA is part of the service. Schema validation and sampled human review run before delivery, every run.
Compliance is documented. Sources, method and lawful basis written down so your legal team can review them.
Fixed monthly cost. No per-request metering, no surprise overage on a month when a competitor adds SKUs.
Six years, 40+ countries. Long-running production pipelines across retail, travel, mobility and finance.

Definitions

Terms used on this page

Plain definitions of the terms used on this page, so procurement and legal reviewers are working from the same vocabulary as your data team.

FAQ

Bank card offer data: frequently asked questions

Straight answers, including where the boundary sits.

Because it is the least informative field. Two offers advertised as 10% can differ threefold on a real basket once the maximum discount cap is applied.

We deliver every term as a typed field and derive an effective maximum rate from cap over minimum spend, so offers sort on something meaningful rather than on the number in the banner.

They are delivered as terms_text with terms_parsed: false and a reason.

We do not guess a cap. A guessed number in a structured field becomes indistinguishable from an observed one within about two weeks, and nobody downstream remembers which was which.

Because they frequently disagree. The bank page sometimes still advertises an offer the merchant has ended, and the checkout sometimes carries a cap the bank page omits.

We record source_surface and flag the disagreement rather than resolving it. Weight checkout for effective-price work and the bank page for partnership benchmarking — they answer different questions.

No, under any framing. No card numbers, no partial numbers, no names, nothing behind a banking login, no transaction records.

Offer terms are marketing information published to attract customers. Cardholder data is regulated information about individuals. Those sit on opposite sides of a line that does not move.

The card offer layer, yes — travel merchants are one of the richest sources of card offers and it is a strong use case. Fare collection itself is a separate question with its own licensing position, which we would rather discuss explicitly than fold into this scope.

Most of the value in the combination sits on the offer side, because fares are widely available and structured card terms are not.

Fast, and often silently. Many offers end without reaching their stated expiry, and many appear with no announcement.

We collect daily and flag offers that disappeared since the previous run in the batch manifest, because a withdrawal with no expiry date is how most offers actually end.

Yes. The mechanic exists wherever issuers fund merchant discounts, and it is particularly rich in India, the GCC, Southeast Asia and parts of Latin America.

Scope is defined by issuer and merchant rather than by geography, so a multi-market scope is a longer list rather than a different service.

Yes, and it is the strongest use of the service. Card offers joined to observed prices at the same merchants show effective competitive position rather than headline position.

A competitor 4% more expensive with a 10% card offer is cheaper for a large share of shoppers, and a price feed alone will never tell you that.

We quote individually. Drivers are issuer count, merchant count, market count and refresh frequency — issuer count matters most, because each issuer's terms language needs its own parsing.

One scoping call, a free sample within 24 hours with the parse rate per issuer, then a fixed monthly quote. Request a quote.

See real card offers from your own merchants

Name the issuers and merchants that matter. We return parsed terms, the derived effective rate, and anything unparsed shown as text.

Get a free card offer sample Book a 20-min scoping call

No sales sequence. If your key issuer publishes terms too vaguely to parse, the sample is where you find that out.

Enterprise Data Extraction

AI Training Data

24-hour sample

AI Dynamic Pricing

Social Commerce

GCC Quick Commerce

KitchenIntel

UK Grocery Price Tracker

What we can collect

Sample data

Ready-Made Scrapers

API Playground

Need it managed instead?

Case Studies

Sample Datasets

ROI Calculator