Card-Linked Loyalty Programs Explained

1. What is card-linked loyalty?

Three terms travel together and are not synonyms. Getting them apart is the first step, because vendors, banks and analysts each use them slightly differently and the differences are commercially significant.

A card-linked loyalty program is the whole structure: enrolment, eligibility rules, reward logic, funding, delivery and measurement, built around a registered payment card. A card-linked offer — usually abbreviated CLO — is a single promotional instance inside such a structure: a specific merchant, a specific reward, usually a specific window, typically requiring the customer to activate it first. Card-linked rewards is the loosest of the three and simply describes the payout mechanism: something of value delivered because a card transaction met a rule.

In practice most consumer-facing card-linked activity in the United States is offer-shaped rather than program-shaped. Chase describes its version in one sentence that captures the model's entire appeal: "There are no coupons, codes or vouchers to remember." The customer adds an offer to a card and pays; the recognition happens behind them.

The terminology box

Related concepts: merchant-funded offer network, coalition loyalty, closed-loop measurement, loyalty cards, customer loyalty cards.

2. How card-linked loyalty works

The generalised flow, in eight steps

1. Enrolment. The cardholder registers a payment credential with the program and consents to transaction monitoring on it. Depending on the architecture, the platform may take the full account number, or may need only a bank identification number and last four digits, or may work entirely from a feed the issuer already controls.
2. Association. The program associates that credential with a customer record by an appropriate secure mechanism. Serious providers do not sit on cleartext account numbers — one card-linking API states plainly that it "uses a proprietary tokenization system and does not store any card numbers" and exposes only the first six and last four digits to developers.
3. Merchant registration. Every participating merchant location must be registered with each card scheme the program monitors, so that transactions there can be attributed. This step is invisible to the customer and is where most implementation time goes.
4. Purchase. The cardholder pays with the enrolled card at a participating location, on a payment path the program actually monitors.
5. Transaction availability. Transaction information becomes available to the program through the relevant infrastructure — a card network's offer platform drawing on the authorization stream, an issuer or processor feed, an acquirer integration, or a direct point-of-sale feed.
6. Eligibility evaluation. The program tests the transaction against its rules: enrolled card, registered merchant, amount thresholds, date window, category, first-purchase-only conditions, exclusions.
7. Reward calculation. A percentage of qualifying spend, a flat amount, a points accrual, a tier progression, or a threshold unlock.
8. Reward delivery and notification. The reward is credited according to the program's design and the cardholder is informed. Published timings from live bank programs run from "within 30 days after qualifying transactions post" to "within 60 days of the qualifying transaction posting", with one issuer noting that in some cases it may take up to 90 days.

Card-Linked Loyalty Architecture

The seven links that have to hold

3. Payment-rail integration: the four architectures

This is the section where card-linked marketing material is least useful, because "integrated with the card networks" is a phrase that covers four quite different things. Here is what each one actually means, with what the operators themselves publish.

(a) Card-network offer platforms

The networks run their own card-linked infrastructure and sell access to issuers. Visa's Offers Platform is documented as providing "near real-time transaction data capabilities to operate card-linked programs", with a Users API to add "consented cardholders" and a merchant API supporting "card-linked programs based off merchant categories, named merchants, merchant locations, e-commerce". Visa states that the platform "retrieves data from the VisaNet authorization stream to monitor enrolled cardholder transactions". Visa Offers Network — a separate product, described as "a marketplace for issuers to distribute affiliate and card-linked offers to their cardholders" — adds a Consumer Enrollment bundle that "[a]llows clients to enroll and manage consumers and their Primary Account Numbers (PANs) for offers participation", plus a Ledger bundle that "record[s] offer, transaction, and statement credit events".

Mastercard's equivalent is marketed under its Commerce Media umbrella as merchant-funded personalised offers for issuers and publishers, described as qualifying offers "across anonymized transaction details".

(b) Issuer and processor data feeds

The largest card-linked business in the world by transaction coverage does not connect to networks at all — it connects to banks. Cardlytics, the only publicly traded pure-play in the category, describes itself in its 2025 annual report as a "financial media network that we run within our partners' digital channels", and states that it analysed "approximately $5.7 trillion in purchases" in 2025 and ingests "approximately one in every two debit and credit card transactions" in the United States. Its own FAQ describes the scope: "Through our bank partnerships we see credit, debit, ACH, and bill pay transactions, including related purchases made via mobile wallets." For smaller institutions it works through bank processors rather than direct bank connections.

Two structural features of this architecture matter to a merchant evaluating it. First, the platform explicitly does not receive identity: "Our platforms are designed so that we do not receive or have access to any personal data from our FI partners", and "The data provided by the FI partner is anonymized so that it cannot be associated with any one individual." Second, the bank retains editorial control. The same filing states that agreements with financial-institution partners "generally do not require us to serve as their sole offer provider, or require our FI partners to publish any given offer on their channels" — and discloses, as a risk, that its largest partner "has recently substantially increased the number of marketers that are subject to such restrictions".

(c) Multi-scheme aggregation via an API provider

A third model sits between the merchant and the schemes: an API company that maintains connections to Visa, Mastercard and American Express, registers merchant locations on each, and exposes a single transaction webhook. This is the architecture most accessible to a mid-sized merchant or a fintech, and it is also the one with the most publicly documented mechanics — which is why so much of this guide's technical detail comes from it. One such provider documents three event types per purchase: an authorisation event in real time, a clearing event when funds move, and a third event if the payment is reimbursed. It states that "Clearing transactions - also known as settled transactions - are processed when a payment transaction settles. This usually happens 48 to 72 hours after a payment is made."

(d) Direct issuer-pushed feeds and point-of-sale integration

A fintech or bank that already holds its own transaction ledger can push transactions to a rewards engine directly rather than obtaining them from anyone. One rewards-as-a-service provider recommends exactly that — clients "provide all consumer transactions via the Kard API" — and notes that it needs no personally identifying information, only a user identifier, a name, and the card's bank identification number and last four digits.

Separately, item-level or SKU-level reward logic cannot be done on network data at all, because network messages do not carry basket contents. Doing it requires ingesting point-of-sale or shopping-cart data directly — an approach described in patent filings as ingesting data "from either bricks and mortar register systems or ecommerce shopping cart systems" to determine "whether SKUs purchased in each transaction qualify for the offer". This is no longer really card-linked loyalty; it is POS-linked loyalty that happens to use the card as a key.

4. The payment actor matrix

5. Authorization, clearing and settlement — and why your reward is late

A Federal Reserve Bank of Philadelphia tutorial on interbank card processing separates the three cleanly. Authorization transmits the card information electronically and runs "automated tests and decisions" on validity, account status and fraud risk, returning an answer in seconds. Clearing is "the nonmonetary exchange of transaction-related information", typically "within one day for dual message transactions". Settlement is the actual exchange of funds, "usually within two days for dual message transactions" and conducted on an "aggregate net basis".

6. The merchant matching problem

Every card-linked program depends on four data elements that were designed for clearing and dispute handling, not for marketing attribution. In ISO 8583 terms — the message standard underlying card transactions — these are the transaction amount, the merchant category code, the card acceptor identification code, and the card acceptor name and location. That is the whole toolkit.

What the fields actually contain

The merchant name field is 25 characters. Visa's Merchant Data Standards Manual states that "Visa authorization and clearing systems provide 25 spaces in which to describe the Merchant name" and requires that "The Merchant name must be the name most prominently displayed by the Merchant and by which cardholders recognize the Merchant." That requirement exists because the field is the one cardholders read on a statement — and Visa acknowledges elsewhere that statements are "filled with unrecognizable merchant names", selling a Merchant Search service to "transform unrecognizable merchant names into clean, easy-to-read merchant information".

The merchant category code is a four-digit classification, not a description. Visa defines an MCC as "a four-digit number assigned to describe a Merchant's primary business based on annual sales volume measured in local currency", used "for a range of purposes, including activity tracking, reporting, and risk management." The code values are standardised internationally by ISO 18245:2023, which defines them as classifying merchants "into specific categories based on the type of business, trade or services supplied". A category code tells you a business is a restaurant. It does not tell you which restaurant, and it says nothing about what was bought.

The merchant ID is assigned by the processor, not by the merchant. It is the key that matching actually runs on, and a card-linking provider documents five different ways it has to go looking for one — transaction lookup, manual lookup, brand-supplied, processor-supplied and third-party — noting that "MID requests are processed asynchronously and typically take up to 7 days to complete due to card network constraints."

Why intermediaries break attribution

When a payment facilitator, marketplace or delivery platform is the merchant of record, the name in the message is theirs, not yours. Visa's rules require facilitators to populate the field with "(i) the name of the Payment Facilitator (or an abbreviation), (ii) followed by an asterisk (*), and (iii) the sponsored Merchant name" — the familiar PAYFAC*SUBMERCHANT pattern. That convention helps a human read a statement. It does not guarantee a clean programmatic match, and shared merchant IDs across a facilitator's estate make it worse: one provider warns directly that facilitators "may be using shared merchant IDs that have an impact on how transactions are monitored."

This is not a theoretical concern, and the issuers say so in their own terms. American Express's UK offer terms warn that transactions may fail to qualify when "made using certain third parties, such as 'payment facilitators', resellers, delivery services, or other intermediaries"; its US terms require that purchases be made directly with the participating merchant and state that "Purchases made through third parties (such as resellers, delivery services, or other intermediaries) do not qualify."

7. Why businesses use card-linked loyalty

Taken honestly, the advantages are real and specific.

No checkout friction. The customer does not scan, type a phone number, open an app or remember a code. In a queue, that is worth more than most loyalty features combined, and it removes the staff-training burden that sinks a large share of small-business loyalty programs.

Automatic recognition where it works. Enrolment happens once. Every subsequent qualifying purchase is recognised without further customer effort — which means participation does not decay the way it does with a card that has to be carried.

Payment-linked attribution. A matched card transaction is stronger evidence than a survey response or a coupon code. Cardlytics describes its measurement as "closed loop-measurement" producing results that are "not probabilistic or based on models, but are based on actual in-store and online purchases" at customer or account level. That is a genuine difference in kind from most marketing measurement — with the caveat, covered in Section 17, that observing a purchase is not the same as proving you caused it.

Distribution you do not own. Bank offer platforms put a merchant in front of that bank's customers inside the bank's own app. For an independent merchant, that is reach which no amount of owned-channel work can replicate.

Reward costs are contingent. In the dominant commercial model the merchant funds the reward, so the largest cost element is incurred only when a qualifying purchase occurs. That is a genuinely attractive risk profile compared with fixed media spend.

Cross-merchant and coalition structures become possible. Because the identifier is the payment card rather than a merchant-issued credential, a single enrolment can span many unrelated merchants. Dining programs are the clearest example: one operator's platform currently powers airline and hotel dining programs for United, Delta, American, Marriott, Hilton, IHG and JetBlue simultaneously, on the same linked-card mechanic.

8. Limitations of card-linked loyalty

This section exists because most published material on card-linked loyalty is written by people selling it. Everything below is documented by the operators themselves.

Rewards are delayed — and the delay is published

Live programs state their own timings. Chase: statement credits appear "within 30 days after qualifying transactions post to your account". Wells Fargo: cash back is credited "within 60 days of the qualifying transaction posting to your account". American Express: rewards are "generally" applied within 30 days of the qualifying purchase, but "In certain cases, it may take up to 90 days after the Offer end date." A dining program describes pending miles arriving 3–5 days after the meal and transferring to the loyalty account five business days after the transaction.

Rewards can be taken back

Every major issuer program we examined reserves this right in terms. American Express's US offer terms are the most explicit: "Purchases that are refunded, returned, or cancelled, in whole or in part, will not count toward any minimum spend required for the Offer, and any reward or redemption issued in connection with an Offer may be reversed", and separately, "Statement credits may be reversed if any Offer-related transactions are cancelled, refunded, or otherwise deemed ineligible subsequent to a credit being issued." Wells Fargo: "Cash back or statement credits may be reversed if a qualifying purchase is returned/canceled."

At the platform layer, matching a refund back to the transaction that earned the reward is itself best-effort. One card-linking provider documents that it "tries to identify the initial transaction for which the refund was issued" and returns the original transaction identifier only where it succeeds.

The limitations nobody advertises

No basket visibility. Network and issuer feeds carry an amount, a merchant, a category and a time. They do not carry what was bought. Any reward that depends on a specific product requires point-of-sale data, which is a different integration entirely.

Coverage is bounded by the architecture. A bank-feed program reaches that bank's customers and no one else. A network-platform program reaches participating issuers on that network. A multi-scheme API reaches cards on the schemes it supports. None reaches everyone, and none can tell you who it missed.

Someone else controls placement. A publicly filed risk disclosure from the largest operator in the sector notes that its largest bank partner "has recently substantially increased the number of marketers that are subject to such restrictions, and has further informed us that this list of restricted marketers will expand in the future." A merchant's access to a bank's customers is a permission, not an asset.

Concentration risk is real and recent. That same operator's 2025 annual report discloses that its top three financial-institution partners accounted for more than 80% of partner share in 2025, and its relationship with Bank of America — historically its largest partner — ended on 16 February 2026. A merchant whose program depends on one platform inherits that platform's counterparty risk.

Implementation is not trivial. Merchant ID sourcing measured in days, per-scheme location sync measured in weeks, a rules engine, a reconciliation process for refunds, a support path for customers whose rewards did not arrive, and a commercial agreement with at least one party that is not you. This is a project, not a setting.

9. Card-linked loyalty vs traditional loyalty models

10. Card-linked loyalty vs wallet-pass loyalty

This is the comparison the category most needs and least often gets, because the two models are frequently sold under overlapping language. Set out plainly:

Card-linked loyalty answers the question "did this customer buy from me?" It is strong on automatic recognition, transaction-level attribution and cashback-shaped mechanics. It is weak on immediacy, basket detail, customer-facing presence and self-sufficiency, and it requires deep integration with parties you do not control.

Wallet-pass loyalty answers the question "how do I stay present with this customer and tell them things?" It is strong on visible status, a persistent credential on a device the customer already carries, no app install, and a direct update-and-notify channel. It is weak — categorically — on knowing that a payment happened. A pass cannot see a card transaction. Something else has to tell it.

They can be combined — and here is the honest version of how

An integrated architecture is straightforward to describe and non-trivial to build: a payment transaction is recognised by a card-linked engine; the engine updates the customer's loyalty state in a system of record; that system pushes the new state to the customer's wallet pass; the customer sees an updated balance, tier or reward on their phone.

Background on the wallet side: what wallet marketing is · what a wallet pass actually is · digital membership cards.

11. The tap boundary: what Apple VAS and Google Smart Tap actually do

This is the section that makes the rest of the article coherent, and it is the one almost universally got wrong. The confusion is understandable: on an iPhone, a payment card and a loyalty pass live in the same app, and at a well-configured terminal they are used in the same physical gesture. It is easy to conclude that the wallet has joined them. It has not — the terminal has, and only for that one transaction, and only inside the merchant's own systems.

What Apple documents

Apple's developer material on loyalty passes describes the mechanism by name. The contactless pass experience "is enabled by a protocol called Apple Pay Value Added Services (VAS), which can be implemented on contactless terminals and uses NFC to communicate with supported Apple devices." Apple calls the automatic surfacing of the right pass "auto-presentment": "with features like auto-presentment, customers simply tap on a contactless reader to automatically pull up their membership pass and check in."

The single-tap behaviour is documented directly: "The customer simply taps their iPhone to pay via Apple Pay. Because Apple Wallet loyalty features are activated, your contactless loyalty or membership pass in Apple Wallet is automatically appended to the Apple Pay transaction to be processed at the same time."

The prerequisites tell you where the join happens. Apple states that the terminals "must already accept Apple Pay and be certified for VAS", and that "Your point-of-sale software must be able to manage the new modes that are introduced when integrated with VAS-certified terminals or readers. These new modes are 'VAS Only' and 'Payment and VAS'." Reader manufacturers go through Apple's reader certification program.

What Google documents

Google's equivalent is Smart Tap, and its documentation describes a pass handoff with no payment element at all. Smart Tap "lets customers redeem any passes in their wallet by simply holding their phone to any compatible NFC terminal." The flow is keyed on identifiers: the terminal transmits its Collector ID, and "the Google Wallet app then examines the Class ID and Collector ID of each stored pass. When one or more matches are found, the Google Wallet app transmits the matching passes to the terminal." What crosses is a set of Service Object records carrying the value set in the pass's redemption-value property.

Google is explicit about who does the work afterwards: "You must also ensure that the data in the pass is conveyed correctly from the terminal to your system. Once your system(s) process the transaction, make sure to update the pass object so that the user sees their new balance or status."

The boundary, drawn

Three consequences worth stating outright

1. A wallet pass is not a card-linked program, even at one tap. If the loyalty logic runs off what your POS saw, you have POS-linked loyalty with an excellent input method. That may well be better for your business than card-linked — it is instant, it is basket-aware, and nothing can silently fail to match — but it is a different architecture with different prerequisites.

2. Apple's own privacy documentation closes the other direction. Apple states that "Apple doesn't store the original credit, debit, or prepaid card numbers that you use with Apple Pay" and that "when you use Apple Pay with credit, debit, or prepaid cards, Apple doesn't retain any transaction information that can be tied back to you." The Wallet Passes framework's documented capabilities are pass creation, real-time content updates, multiple events on one ticket, system integrations such as Maps and notifications, and flight tracking for boarding passes. There is no API, field or event for reading a user's payment transactions.

3. Neither platform sells a card-linked offer product. Apple's coupon pass and Google's offers vertical are both pass constructs — a discount represented as a pass — not transaction-matched offers. We found no Apple or Google first-party product that links a payment card to a merchant offer and matches cleared transactions to it.

12. Types of card-linked loyalty programs

13. Best-fit use cases by industry

14. Card-linked loyalty for small businesses

The honest way to answer this is to ask what the business actually needs, and then to notice how rarely the answer is "transaction matching".

Simpler alternatives in depth: POS loyalty programs · QR code loyalty sign-ups · the digital punch card · free loyalty software, evaluated.

15. How to build a card-linked loyalty program

This is a project, not a configuration. Anyone describing it as a no-code setup is describing something else.

1. Define the business objective in one sentence, without a mechanic in it. "Recover lapsed weekday customers" is an objective. "Launch cashback" is a mechanic pretending to be one.
2. Define the customer behaviour that qualifies. First purchase, return visit, category spend, cumulative threshold, frequency within a window. Write it precisely enough that a rules engine could implement it without asking a question.
3. Choose the reward model and its funding. Cashback, points, tier or unlock — and, separately, who pays for it. Those are two decisions and they are often conflated.
4. Determine the payment-data architecture. Network platform, issuer or processor feed, multi-scheme aggregation, or your own ledger. This decision comes before vendor selection because it eliminates most of the market.
5. Select the technology partner against the architecture you chose, not against a feature grid.
6. Define merchant and transaction eligibility in writing. Which locations, which card types, which payment paths, which channels, which exclusions. Assume every ambiguity will be resolved against you by a customer with a screenshot.
7. Design enrolment and consent. What the customer is told, what they agree to, how they see what is collected, and how they leave. Design the opt-out before the opt-in.
8. Specify reward calculation precisely. Which amount — authorised or cleared. Whether tips, taxes, shipping and gratuities count. Rounding. Caps. What happens when two offers could apply.
9. Specify returns, refunds and chargebacks. Whether rewards are reversed, within what window, what the customer is told, and who absorbs the cost when a reversal cannot be matched to its original.
10. Design customer communication. Enrolment confirmation, offer activation, reward earned, reward delivered, reward reversed. The last one is the one programs forget, and it is the one that generates complaints.
11. Test transaction matching before launch. Real cards, real terminals, every scheme, every payment path you claim to support — card-present, card-not-present, PIN debit, mobile wallet, refund, partial refund. Record which combinations fail.
12. Run a controlled pilot. One region or one segment, a defined period, and a holdout group. Without a holdout, step thirteen is impossible.
13. Measure incremental behaviour, not rewarded behaviour. See Section 17. The difference between these two numbers is usually the difference between a program and a subsidy.
14. Optimise, and re-test matching after any change to merchant estate, processor, POS or offer structure. Each of those can silently break registrations.

• Objective written in one sentence with no mechanic in it
• Qualifying behaviour defined precisely enough to implement without clarification
• Reward model and funding source decided separately and documented
• Payment-data architecture selected and its coverage limits written down
• Vendor selected against that architecture, with the "whose data is it, and who can switch it off" question answered
• Every participating location registered and confirmed Active on every scheme you claim to support
• Excluded card types listed — commercial, purchasing, prepaid, and anything already linked elsewhere
• Unmonitored payment paths listed — PIN debit, third-party apps, gift cards, marketplaces, delivery platforms
• Reward basis decided — authorised or cleared amount — and stated in the customer terms
• Refund, return and chargeback handling specified, including the unmatched-reversal case
• Duplicate, split-payment and partial-authorisation handling specified
• The "my reward didn't arrive" support path built, with someone able to read a matching log
• Consent language drafted and the withdrawal path tested end to end
• Matching tested on real cards across every scheme and payment path, with failures recorded
• Holdout group defined before launch, or incrementality cannot be measured afterwards
• Re-test trigger agreed for processor, POS, estate or offer changes

16. Card-linked loyalty economics

Two identities worth writing on the wall

Revenue ≠ profit. A 5% reward on a category running a 30% gross margin consumes a sixth of the margin on every qualifying sale — not a twentieth of the revenue. Card-linked rewards are percentage-of-spend by construction, which makes them expensive in exactly the low-margin, high-frequency categories where they are most often deployed.

Rewarded transaction ≠ incremental transaction. This is the one that decides whether a program is an investment or a discount. Every card-linked program rewards a mixture of purchases that happened because of it and purchases that would have happened anyway. Only the first kind is revenue. The second kind is a transfer from your margin to your existing customers, delivered with excellent precision.

17. Was the reward incremental?

Step one: split the rewarded population

• Would this purchase probably have happened anyway? → The reward is a subsidy on existing behaviour. It has a real cost and no revenue attached.
• Would it probably not have happened? → The reward bought incremental behaviour. This is the only population that supports a return claim.
• Is it a purchase that was going to happen, but happened here because of the reward? → Switched behaviour, which is genuinely incremental to you and worth separating, because it behaves differently over time than newly created demand.

Step two: do the subtraction honestly

Incremental revenue, times gross margin, minus reward cost on the whole rewarded population — not just the incremental part — minus platform and payment costs, minus operational costs, equals incremental contribution. The asymmetry in that sentence is the entire point: you earn margin only on the incremental slice, but you pay the reward on all of it.

Step three: acknowledge what you cannot see

Card-linked measurement is unusually good at one thing and blind to several others. It sees purchases at participating merchants on enrolled cards through monitored paths. It does not see the same customer's purchases on a different card, purchases that failed to match, purchases through a delivery app, or the customer who saw the offer, did not use it, and came in anyway.

18. Privacy, security and consent

What is actually collected

The clearest first-party statement comes from Mastercard's own loyalty and rewards privacy notice, effective 9 February 2026, which describes processing "Transaction information related to the card(s) enrolled in a Program, such as date / time of payment(s), personal account number, name of merchant, commercial and transaction code, currency and amount of a purchase, and a tokenized ID generated to identify whether your purchases are eligible for the Programs." That is the honest inventory: an account number, a merchant, a time, an amount, a category.

Different architectures hold different parts of it. A card-linking API states that it "uses a proprietary tokenization system and does not store any card numbers", exposing only the first six and last four digits to developers. A rewards-as-a-service provider says it "does not require any PII" beyond a user identifier, a name, and a bank identification number and last four digits. A bank-feed platform states the strongest version: "Our platforms are designed so that we do not receive or have access to any personal data from our FI partners", with data "anonymized so that it cannot be associated with any one individual."

Card data security: what PCI DSS actually says

If your architecture involves account numbers, the Payment Card Industry Data Security Standard is the relevant framework. As of September 2026 the active version is PCI DSS v4.0.1, published June 2024; the Council describes it as a limited revision containing "corrections to formatting and typographical errors" and clarifications, with "no additional or deleted requirements in this revision." Version 4.0 was retired on 31 December 2024, and the future-dated requirements introduced in v4.x became effective on 31 March 2025. The Council opened a request for comments on the next iteration in June 2026; no successor version has been published.

On storage, Requirement 3.5.1 requires that the account number be rendered unreadable wherever it is stored — by strong one-way hashing of the entire number, truncation, index tokens, or strong cryptography with associated key management. Requirement 3.5.1.1 tightened the hashing option to keyed cryptographic hashes and became mandatory on 31 March 2025.

On tokenization, the Council's guidance is more nuanced than vendor marketing usually implies. Its tokenization information supplement states that "Tokenization solutions do not eliminate the need to maintain and validate PCI DSS compliance, but they may simplify a merchant's validation efforts by reducing the number of system components for which PCI DSS requirements apply", and that systems which are adequately segmented and handle only tokens "may be considered outside of the CDE and possibly out of scope for PCI DSS." Note the hedging in the Council's own sentence — "may", "possibly". Tokenization reduces scope; it does not delete it.

And on outsourcing: the Council's third-party guidance states plainly that using a service provider "does not relieve the entity of ultimate responsibility for its own PCI DSS compliance, or exempt the entity from accountability and obligation for ensuring that its cardholder data and CDE are secure."

Tokenization, PAR and why linkage is getting harder

Network tokenization has a complicated relationship with card-linked loyalty. EMVCo's Payment Account Reference was created partly to solve it: a 29-character non-financial reference with a one-to-one relationship to the account number and a one-to-many relationship to its tokens, which cannot be used to initiate a transaction. EMVCo's own framing lists PAN-based loyalty among the use cases it supports, and industry guidance describes it as letting an operator "reestablish an effective payment-card-linked loyalty program and preserve simplified recognition of customers." EMVCo notes that PAR data is not itself PCI account data — though a system handling both PAR and account data remains in scope.

That is the theory. In practice, availability is uneven, and the failure mode is concrete: a card-linking provider states that digital-wallet spend is trackable "as long as the full PAN from the front of the card is enrolled", and that where a customer enrols a tokenised or virtual number instead, the platform cannot enrol it. As payment credentials become more tokenised, a linkage model built on account numbers gets less reliable, not more. That is a structural headwind for the category, and it is worth asking any prospective vendor how they are handling it.

Consent

Consent in card-linked programs is layered, and customers rarely see all the layers. At the platform level, one provider's enrolment SDK "contains a block of text… a checkbox that the cardholder must tick in order to proceed with the enrolment", and clients integrating the API directly must obtain consent themselves. At the network level, Visa's offer platform documentation describes adding "consented cardholders" and managing cards "per cardholder consent". At the bank level, the exit is through the bank: one platform tells cardholders that "If you are currently participating in and want to opt out of a Cardlytics card-linked marketing program, you can do so through your bank."

Visa's public rulebook, effective 18 April 2026, contains a section on cardholder loyalty programs including a rule specifically titled "Card Linked Offers – Europe Region". We could not retrieve the body text of that rule and therefore do not characterise its contents — only that it exists, and that anyone operating a card-linked program in Europe should read it at source.

19. Real-world card-linked programs

Consolidation is the category's defining recent story

Anyone evaluating a card-linked partner should understand how much the supply side has moved. Empyr was acquired by Augeo in April 2020 and folded into Figg; Figg was then acquired by JPMorgan Chase in mid-2022 — a major issuer buying its own card-linking supplier. Cardlytics shut down its consumer cashback app Dosh on 28 February 2025, sold the Bridg identity-resolution business to PAR Technology in March 2026, and saw its relationship with Bank of America — historically its largest financial-institution partner — end on 16 February 2026. In Australia, Commonwealth Bank's Yello program is converting from cashback to points from 1 October 2026, removing its cashback benefits entirely.

20. What the evidence does and does not show

This section is the ledger. We publish it because the alternative — quietly using the numbers everyone else uses — is how unsourced statistics become facts.

21. How wallet marketing complements card-linked loyalty

It helps to draw the stack explicitly, because the layers have different owners, different costs and very different implementation timelines.

Read bottom to top, a combined program works like this: a payment transaction is recognised by the card-linked layer; reward logic runs and the loyalty layer's customer state is updated; that state is pushed to the wallet pass; the customer's phone shows a new balance, tier or reward and, within platform limits, notifies them. Read top to bottom, it explains why so many businesses start at layer 3: it is the only layer that produces something a customer can see on day one.

22. Where PushNotice fits

What it does, verifiably. Customers save a pass to Apple Wallet on iPhone or Google Wallet on Android from a link or QR code — no app download and no account creation. Passes update over the air when a stamp, tier or detail changes, and pass-level push notifications are delivered through the platforms' own notification services. Passes can be associated with places so the card surfaces when a customer is nearby, a paid-tier feature. Higher tiers add tagging and segmentation and multiple workspaces for multi-location operators, and an agency tier adds white-label dashboard branding with a workspace per client. Pricing runs from a permanent free plan at $0 with no card required, through Starter at $29 per month and Pro at $79 per month, to custom agency pricing.

Where a business would use both. If you run or join a card-linked program, that program tells you a purchase happened. It does not give the customer a credential to carry, a visible status to check, or a channel you control to speak through. A wallet pass does those three things and nothing else. In a combined architecture, your card-linked engine and your system of record would compute the reward, and the wallet layer would display it and notify the customer. PushNotice supplies only that last part, and only when something else tells it what to display.

Product pages: wallet marketing · membership card maker · industry pages · plans and limits.

23. The linkage decision framework

Frequently asked questions

The core questions

How the linkage actually works

Wallets and platforms

Buying, building and measuring

Methodology, sources & disclosure

How claims were sourced

Four categories of claim appear here and they are treated differently. Payments infrastructure — authorization, clearing and settlement mechanics, merchant data standards, message fields, tokenization and Payment Account Reference — is cited to card network documentation, EMVCo and standards-body material, PCI Security Standards Council publications, and a Federal Reserve Bank of Philadelphia tutorial. Platform behaviour — enrolment, matching, refunds, merchant registration timelines — is cited to the operators' own developer documentation, quoted rather than paraphrased where precision matters. Live program terms — reward timing, exclusions, clawback — come from the issuers' published terms and conditions, with their revision dates recorded. Wallet platform behaviour comes from Apple and Google developer documentation consulted on 18 September 2026. Everything else — the eight frameworks, the matrices, the decision tree, the attribution chain, the economics stack and the industry-fit judgements — is PushNotice analysis and labelled as such.

What we deliberately excluded, and why

Every vendor-published performance figure we encountered. Specifically: average statement credits earned per cardholder, quoted without a denominator; total "incentivised spend" driven through a network, quoted without defining the term; cardholder, merchant and driven-sales totals from marketing pages; re-engagement percentages and return-on-ad-spend ratios with no stated methodology; and an average percentage-back figure "earned by customers" at a bank's partner retailers. We also excluded a 2021 industry-association survey reporting that 35% of participants said their card-linking programs grew by more than 100% year on year, because no sample size, respondent count or methodology was published and the study is five years old. Section 20 is the full ledger.

Where we could not verify something, we say so in the text

Five limits are stated openly rather than smoothed over. Visa's Offers Platform documentation is access-restricted by Visa's own statement, and Mastercard's card-linked offer API references did not return substantive technical content, so no network-side matching internals or latency figures are given. Visa's public rulebook contains a rule titled "Card Linked Offers – Europe Region" whose body text we could not retrieve, so we report only that it exists. The PCI Security Standards Council's document servers returned errors to automated retrieval, so Requirements 3.5.1 and 3.5.1.1 are reported as indicative from mirrored copies and flagged for verification at source; the version numbers and dates come from the Council's own posts. Google does not document whether a Smart Tap pass can be read in the same tap as a contactless payment, so we assert no parity with Apple's "Payment and VAS" mode. And we found no primary documentation of open-banking data being used for loyalty attribution, so we describe it as a plausible future architecture rather than a current one.

Two things we could not find at all — which is itself a finding

First, no neutral definition of "card-linked offer" exists. No regulator, standards body or encyclopedia defines the term; the Consumer Financial Protection Bureau's 2024 credit card rewards issue spotlight does not mention card-linked offers at all. Every definition in circulation, including ours, is an industry definition. Second, no enforcement record exists. We found no FTC action, no CFPB action and no state attorney general action against a card-linked offer platform or against a bank for card-linked data sharing, and no reported breach at a major platform. The public record consists of journalism and advocacy, not regulatory findings. Absence of enforcement is not clearance.

Disclosure and limitations

PushNotice sells wallet marketing software, and Section 22 describes our own product. We have made that section unusually explicit about what PushNotice is not, including the complete absence of card linking, transaction matching, payment-network integration, reward settlement, POS integration, a public API and webhooks. The author is not a payments engineer, a card network employee, a compliance attorney or a data-protection specialist, and nothing here is legal, compliance or security advice. Payments standards, network rules and privacy regulation all change: PCI DSS is in a request-for-comments cycle for its next iteration, the US personal financial data rights rule is stayed and under reconsideration, and card-linked platform ownership has changed materially in the past eighteen months. Verify at the source before acting.

Primary sources

Networks and schemes: Visa Developer — Visa Offers Platform and Visa Offers Network capability documentation; Visa Merchant Data Standards Manual (April 2026); Visa Authorization and Reversal Processing Best Practices for Merchants (2024); Visa EMV Contact and Contactless Payment Acceptance for Restaurant Merchants (19 February 2018); Visa Core Rules and Visa Product and Service Rules (effective 18 April 2026); Visa transaction data enrichment / Merchant Search product documentation; Visa Token Service Payment Account Reference Inquiry fact sheet (2022); Visa SavingsEdge relaunch announcement (13 June 2024); Mastercard Commerce Media offers documentation; Mastercard Loyalty and Rewards Notice (effective 9 February 2026).

Standards bodies: EMVCo payment tokenisation documentation, including the Technical Framework (v2.4, July 2026) and A Guide to Use Cases; Secure Technology Alliance, EMVCo Payment Account Reference (PAR): A Primer (v1.1, April 2018); ISO 18245:2023, Retail financial services — Merchant category codes; PCI Security Standards Council — PCI DSS v4.0.1 (June 2024) publication announcements and future-dated requirement guidance, Information Supplement: PCI DSS Tokenization Guidelines (v2.0, August 2011), and Information Supplement: Third-Party Security Assurance (v1.1, March 2016).

Central bank and regulator publications: Federal Reserve Bank of Philadelphia, Herbst-Murphy, Clearing and Settlement of Interbank Card Transactions (October 2013); Federal Reserve Payments Study, 2025 triennial initial findings (1 July 2026); Consumer Financial Protection Bureau, Credit Card Rewards issue spotlight (May 2024); CFPB personal financial data rights rule status and reconsideration ANPR (August and October 2025).

Platform and program documentation: Fidel API developer documentation on card linking, transactions, MID management and locations, and its published FAQ; Kard developer quickstart and merchant offer documentation; Cardlytics Form 10-K for the year ended 31 December 2025 (filed 4 March 2026), Form S-1 (2018), quarterly results releases, published FAQ and privacy notice for bank customers; Chase Offers FAQs; Bank of America cash back deals resource documentation; American Express US and UK Amex Offers program terms and conditions; My Wells Fargo Deals terms and conditions; Capital One Offers explainer; MileagePlus Dining and AAdvantage Dining terms of use; Rewards Network program listings; Lloyds Bank and NatWest reward program pages; Commonwealth Bank Yello program change notice; MTA OMNY fare capping documentation.

Wallet platform documentation, consulted 18 September 2026: Apple Developer — Loyalty Passes, Wallet Passes framework, PassKit overview, Wallet pass type documentation; Apple Support — Apple Pay security and privacy overview (27 April 2026). Google — Google Wallet API Smart Tap overview and communication flow, loyalty card Smart Tap and push notification documentation, and developer FAQ.

Research: Sahni, N.S., Zou, D. & Chintagunta, P.K., "Do Targeted Discount Offers Serve as Advertising? Evidence from 70 Field Experiments," Management Science.

About the author

Sajid Ali is Founder and CEO of PushNotice, a wallet marketing platform for local and multi-location businesses. He writes about loyalty mechanics, wallet passes and customer communication from a product and business perspective. He is not a payments engineer, card network employee, compliance attorney or data-protection specialist, and the payments material in this article is a summary of publicly available primary sources, provided so that marketers, merchants and product teams can have a better-informed conversation with the people who are. Connect on LinkedIn · More about the team.

Related guides