Key Takeaways
Merchant rewards are three-sided. The side that decides survival is the merchant, who will eventually ask whether the customers were incremental.
Card-linked offers are the strongest model where you hold payment data, because there is nothing to activate and attribution is clean.
Without transaction-level targeting an offer feed is a coupon book, and customers learn to ignore the whole section.
Every activation step between seeing an offer and benefiting from it removes a meaningful share of participants.
Settlement is where these programmes become expensive. Define the billable event, refund claw-back and disputes before launch.
Give merchants aggregate performance, not customer identity. It is usually unnecessary, often non-compliant and corrosive to trust.
A merchant rewards programme sits in an unusual position: the business running it is not usually the business the customer is loyal to. A bank, a payment provider, a marketplace or a network offers rewards funded by merchants who want reach, to customers who belong to none of them exclusively.
That three-sided structure is what makes these programmes commercially attractive and operationally difficult. Get it right and the rewards cost the operator almost nothing while generating revenue. Get it wrong and you have an offer feed customers ignore and merchants stop paying for.
This guide covers what merchant rewards programmes are, the models in use, what each side needs, how to build one, the fraud and settlement problems, and how to measure it.
What a merchant rewards program is
A merchant rewards programme delivers offers, cashback or points funded by participating merchants, through a platform that owns the customer relationship. The platform provides targeted reach and attribution; the merchant provides the reward value; the customer gets a benefit for buying something they may have bought anyway.
The three sides and what each one wants
| Party | What they want | What kills it for them |
|---|---|---|
| The platform | Engagement and a revenue line at near-zero reward cost | Low relevance, so customers stop opening the offers |
| The merchant | Incremental customers at a measurable cost | Paying for customers who were already theirs |
| The customer | Relevant value with no extra steps | An irrelevant feed and offers that fail to apply |
The second row is the one that determines whether the programme survives. A merchant who cannot distinguish an incremental customer from an existing one will eventually stop funding the offers, and the programme loses its economics.
3
Parties to satisfy
platform, merchant, customer
1
Thing that kills it
paying for customers the merchant already had
0
Extra steps the customer should take
activation friction is the main leak
The models
| Model | How it works | Strength | Weakness |
|---|---|---|---|
| Card-linked offers | Offers attached to a registered card, applied automatically | No codes, no steps, clean attribution | Needs payment data access and card coverage |
| Cashback marketplace | Customer clicks through and earns cashback | Simple to operate, broad merchant base | Attribution is fragile and depends on tracking |
| Points earning at partners | Spend at merchants earns the platform's currency | Makes the currency more useful | Settlement complexity rises with partner count |
| Voucher and discount catalogue | Merchant-funded codes redeemed at checkout | Easy to launch with no payment integration | Code leakage, and the customer has to do something |
| In-app merchant marketplace | A storefront of offers inside the platform's app | High engagement when relevance is good | Requires real data to be relevant at all |
Card-linked offers are the strongest model where the operator has payment data, because there is nothing for the customer to activate and attribution is clean for the merchant. Everything else trades some of that for easier implementation.
What the merchant needs to fund it
- Incrementality evidence: Proof the customers were new or lapsed, not existing regulars. This is the whole commercial argument.
- Targeting control: The ability to exclude existing customers, target a category, a geography or a spend band.
- Predictable cost: Cost per acquired customer or per incremental transaction, capped.
- Reporting a finance team will accept: Redemption volume, incremental spend and cost, in a format that reconciles.
- Clean settlement: Clear terms on when the merchant pays, for what, and how disputes are resolved.
- Brand control: Which offers appear, how the brand is presented, and the ability to pause.
Offers the merchant will renew
Transaction-level targeting, automatic application and incrementality evidence built in.
Book a demoTrusted by 5,000+ companies
What the customer needs
- Relevance: An offer feed that reflects what they actually buy. Irrelevant offers train people to ignore the whole section.
- No activation steps where avoidable: Every click between seeing an offer and benefiting from it loses a share of users.
- Reliable application: An offer that fails to apply at checkout is worse than no offer, because it creates a complaint.
- Clear terms: Expiry, minimum spend and exclusions stated up front rather than discovered at the till.
- Privacy they understand: Transaction-data targeting needs a consent position customers can actually see and control.
How to build a merchant rewards program
Eight steps, and the first two determine whether merchants renew. Everything else is easier to fix later than attribution is.
1. Decide what you are selling to merchants
Reach, incrementality or data. These are different products with different prices and different proof obligations, and a programme that is vague about which it sells struggles to renew merchants.
2. Solve attribution before recruiting merchants
The merchant's question is always whether the customer was incremental. If you cannot answer it with evidence, you will win the first contract and lose the renewal.
3. Build relevance from transaction data
Merchant offer feeds work in proportion to targeting quality. Without transaction-level data, you are serving a generic coupon book inside an app, which performs accordingly.
4. Minimise activation friction
Card-linked where possible, automatic application at checkout, no codes. Each additional step removes a meaningful share of participants.
5. Design the settlement model early
Who pays whom, when, on what evidence, and what happens on a refund or a dispute. Settlement is where these programmes become operationally expensive, and it is far easier to design than to retrofit.
6. Build fraud controls for all three sides
Code leakage, self-referral, transaction manipulation and collusion between a customer and a merchant's staff. Our guide to loyalty program fraud covers the common patterns.
7. Set the privacy position explicitly
Transaction data used for targeting needs a lawful basis, a consent flow customers can see, and a defined position on what the merchant learns about the customer. In most markets the merchant should receive aggregate performance rather than identity.
8. Give merchants self-service
Offer creation, targeting, budget caps and reporting that merchants can operate themselves. Programmes requiring account management for every change do not scale past a few dozen partners.
Settlement and operations
The unglamorous half of a merchant rewards programme, and the half that decides whether it is profitable.
- Define the billable event precisely: Qualifying transaction, verified redemption or attributed acquisition. Ambiguity here produces disputes at scale.
- Handle refunds and chargebacks: A rewarded transaction that is later reversed must claw back cleanly on both sides.
- Agree dispute resolution up front: Who adjudicates when the merchant disputes attribution, and on what evidence.
- Reconcile continuously: Monthly reconciliation of a high-volume offer programme is how discrepancies become unresolvable.
- Cap merchant exposure: Budget caps per offer and per period, so a viral offer does not produce an invoice nobody approved.
Measuring a merchant rewards program
| Metric | Why it matters |
|---|---|
| Offer activation and redemption rate | Whether customers engage, and whether friction is costing you |
| Incrementality per merchant | The commercial proof the merchant is paying for |
| Merchant renewal rate | The clearest signal that the value is real |
| Revenue per active member | The platform's return on the programme |
| Relevance score or offer dismissal rate | Early warning that the feed is training people to ignore it |
| Failed application rate | Offers that did not apply at checkout, which generate complaints |
| Settlement dispute volume | Operational health, and the usual source of margin leakage |
| Fraud and leakage rate | Code sharing and collusion, which scale quickly |
Common mistakes
- Selling reach and being asked for incrementality: Decide which product you are selling and prove it from the start.
- A generic offer feed: Without transaction-level targeting it is a coupon book, and customers treat it as one.
- Activation friction: Every step between seeing and benefiting costs a share of participants.
- Retrofitting settlement: It is the operationally expensive part, and designing it late makes it worse.
- No budget caps: A successful offer can produce an invoice the merchant never approved, and that merchant does not renew.
- Sharing customer identity with merchants: Usually unnecessary, frequently non-compliant, and corrosive to customer trust.
- Requiring account management for every offer change: It caps the programme at a few dozen merchants.
Merchant rewards on Loyalife
01 · Offers
Card-linked and catalogue models
Automatic application where payment data allows, with voucher and marketplace models alongside.
02 · Targeting
Relevance from transaction data
Offer targeting built on what members actually buy, which is what separates a feed from a coupon book.
03 · Merchants
Self-service offer management
Offer creation, targeting, budget caps and reporting that merchants operate themselves.
04 · Proof
Incrementality reporting
Evidence that rewarded customers were new or lapsed, which is the commercial argument merchants are buying.
05 · Operations
Settlement and reconciliation
Defined billable events, refund claw-back, continuous reconciliation and dispute handling.
06 · Control
Privacy and fraud
Aggregate reporting to merchants rather than identity, plus leakage, collusion and velocity controls.
You can also explore coalition loyalty programs and the Loyalife platform.
A merchant rewards programme lives or dies on one question the merchant will ask at renewal: were these customers incremental. Build the answer before you build the offer feed.
Book your Loyalife demo
Frequently asked questions
A programme that delivers offers, cashback or points funded by participating merchants, through a platform that owns the customer relationship. The platform supplies targeted reach and attribution, the merchant supplies the reward value, and the customer receives a benefit. It is a three-sided arrangement, which is both its commercial appeal and its operational difficulty.
Five. Card-linked offers attached to a registered card and applied automatically. Cashback marketplaces where the customer clicks through. Points earning at partner merchants. Voucher and discount catalogues with merchant-funded codes. And in-app merchant marketplaces. Card-linked is strongest where the operator holds payment data, because nothing needs activating and attribution is clean.
Evidence of incrementality above everything, because paying for customers who were already theirs is the thing that stops renewals. Then targeting control including the ability to exclude existing customers, predictable capped cost, reporting a finance team will accept, clean settlement terms, and control over how their brand appears.
Almost always relevance. Without transaction-level targeting the feed is a generic coupon book, customers learn to ignore it, engagement falls, and merchants stop funding offers that reach nobody. The secondary cause is activation friction: each step between seeing an offer and benefiting from it removes a share of participants, and codes are the worst offender.
Offers attached to a customer's registered payment card and applied automatically when they transact with the merchant. The customer does nothing beyond paying as usual, which removes activation friction entirely, and the merchant gets clean attribution because the transaction itself is the evidence. The requirements are payment data access and sufficient card coverage.
The billable event has to be defined precisely, whether that is a qualifying transaction, a verified redemption or an attributed acquisition. Then refunds and chargebacks need to claw back cleanly on both sides, dispute adjudication has to be agreed in advance, reconciliation should be continuous rather than monthly, and merchant exposure needs budget caps per offer and period.
Code leakage where merchant-funded codes escape the intended audience, self-referral, transaction manipulation, and collusion between a customer and a merchant's staff. All three parties can be the source, which makes velocity limits, anomaly detection and reconciliation between claimed and settled transactions necessary rather than optional.
Offer activation and redemption rate, incrementality per merchant since that is the commercial proof being sold, merchant renewal rate as the clearest signal of real value, revenue per active member, offer dismissal rate as an early relevance warning, failed application rate, settlement dispute volume, and fraud and leakage rate.
![Diversity and Inclusion in the Workplace: Why It Drives Success [Activities + Survey Tips]](/Blog-cover-light/inclusion-and-diversity-in-the-workplace.avif?dpl=dpl_8fJikYxuCmYv3RQT1yaE4Git6nzR)
![How to Run an Effective Employee Commitment Survey [+ Sample Questions]](/Blog-cover-light/employee-commitment-survey.avif?dpl=dpl_8fJikYxuCmYv3RQT1yaE4Git6nzR)
