Evaluation Framework · Updated August 2026

How to Evaluate Shopify Loyalty Software: The 2026 Framework

A weighted 7-criteria framework for choosing a Shopify loyalty app: with a hands-on test and a red-flag list for each criterion, a printable scorecard, 6 fintech capability checks for companies that need auditable balances, and 18 copy-pasteable RFP questions. Every claim is a number you can verify yourself.

TL;DR

Evaluate Shopify loyalty software on 7 weighted criteria: true cost at your order volume (25%: model the bill at current, 2x, and 5x volume; VIP-tier gates jump from $15 to $199/mo), storefront performance (20%: widget weight ranges 14–650 KB, measurable in DevTools), migration path in and out (15%: test CSV export before you buy), then admin-native operation, multi-language coverage, headless SDK support, and support model plus contract terms (10% each). Score each app 1–5 per criterion, multiply by the weights, and the spreadsheet, not the sales call, picks the winner.

Full disclosure: we build Anchor Loyalty, one of the apps this framework will score. That's exactly why every criterion here is a number you can measure yourself: DevTools, CSV exports, and vendor pricing pages don't care who wrote the framework. Judge the data, not us.

Install Anchor free on Shopify See the 8 apps we already scored

Why loyalty software needs a scoring framework

Loyalty apps are harder to compare than most Shopify software because the four dominant pricing models: flat, tiered, usage-based, and per-order, produce bills that differ by 10x or more at the same order volume. A feature checklist cannot catch that; only pricing modeled at your volume can.

The framework below assigns each criterion a weight reflecting how expensive that mistake is to reverse. Pricing errors compound monthly, so cost carries 25%. A locked-in migration path can hold customer points hostage, so exit carries 15%. Widget weight silently taxes every mobile visit, so performance carries 20%. The remaining four criteria carry 10% each. Score each candidate 1–5 on every criterion, multiply by the weight, and sum.

Everything here uses August 2026 market data, the same dataset behind our ranked comparison of 8 loyalty apps. Pricing figures come from published vendor pricing pages and App Store listings; widget weights are DevTools measurements on a stock Dawn theme.

The 7 evaluation criteria, weighted

Each criterion below includes a test you can run yourself during a trial, no vendor cooperation required, and the red flags that should cost an app points on your scorecard.

True cost at YOUR order volume

Weight: 25% of total score

The true cost of a Shopify loyalty app is what you pay at your order volume with the features you need enabled, not the entry price on the pricing page.

Loyalty pricing in August 2026 uses four distinct models, and they produce very different bills at the same order volume. Smile.io starts free with a $15/mo entry tier, but VIP tiers require the $199/mo plan. Rivo is usage-based: $15/mo at low volume, climbing to $499/mo as orders grow. Yotpo charges per order: $0.08 to $0.20 each: which reads cheap at 500 orders/mo ($40–$100) and expensive at 5,000 ($400–$1,000, and above that it goes quote-only). LoyaltyLion publishes no prices at all; every paid tier is a custom quote. Anchor is flat: $14.99/mo regardless of order count.

Model your bill at three volumes: current orders, 2x current, and 5x current. A plan that costs $15 today and $499 at 5x is a different product from one that costs $15 at both. The VIP-tier gate is the most common trap: merchants budget for the entry tier, launch, then discover the tier feature they planned the program around sits two plans up.

How to test it yourself

Build a three-column spreadsheet (current volume, 2x, 5x) and price every shortlisted app at each column with VIP tiers, referrals, and your integrations enabled. Ask each vendor for the exact plan name that includes every feature on your list, in writing.

Red flags

–The feature you are buying the app for (usually VIP tiers) is only listed on a plan 10x the entry price.
–Per-order or usage-based pricing with no published cap, your bill scales with your success.
–Quote-only pricing for a store under $5M GMV. Quotes exist to price-discriminate; small stores rarely win that negotiation.
–"Contact us" where a number should be, on more than one tier.

Storefront performance cost

Weight: 20% of total score

Loyalty widget weight in the current market ranges from 14 KB to roughly 650 KB of JavaScript, a 46x spread you can measure yourself in Chrome DevTools before installing anything.

Every loyalty app injects JavaScript into your storefront, and the spread is enormous: 14 KB (Anchor) to ~650 KB (Yotpo), with most incumbents between 95 KB and 420 KB. On a mid-range Android phone, the heavy end of that range costs measurable Lighthouse mobile points through parse and execute time, typically 8–15 points between the lightest and heaviest widgets on an otherwise identical theme.

This is the one criterion where you never need to trust a vendor claim. Widget weight is directly observable on any live store running the app.

How to test it yourself

Find a live store running the app (vendor case studies list them). Open Chrome DevTools → Network → filter JS → hard-reload, and sum the transferred size of every request from the vendor domain. Repeat on your own store during the trial and compare Lighthouse mobile scores with the app embed on and off.

Red flags

–The vendor publishes no bundle-size figure and the marketing page says "lightweight" without a number.
–The widget loads more than 200 KB of JavaScript before any user interaction.
–Multiple render-blocking requests from the vendor domain in the DevTools waterfall.

Admin-native vs external dashboard

Weight: 10% of total score

An admin-native loyalty app runs inside Shopify Admin with Shopify sessions and permissions; an external-dashboard app is a separate website with separate logins that your team must learn and secure.

This sounds cosmetic and is not. External dashboards mean separate credentials to manage, staff permissions that do not map to your Shopify roles, and one more place where an ex-employee login lingers. Admin-native apps inherit Shopify staff accounts and permissions automatically, and daily operations (adjusting a customer balance, checking program stats) happen where your team already works.

How to test it yourself

During the trial, complete three routine tasks: adjust a customer balance, edit an earning rule, export program data, and note whether each happens inside Shopify Admin or on an external site with a separate session.

Red flags

–Separate username and password for the loyalty dashboard.
–Staff permissions configured in the vendor dashboard rather than inherited from Shopify roles.
–Customer data views that exist only outside Shopify Admin.

Multi-language coverage

Weight: 10% of total score

Shipped locales are languages the widget displays automatically; "translatable" means your team writes and maintains every string in every language yourself; the two are routinely conflated on pricing pages.

If you sell in non-English markets, ask exactly one question: how many locales ship in the box, auto-detected? The market answer in August 2026 ranges from English-only through 4 (BON), roughly 10 (Growave), to 32+ (Anchor). "Supports translation" without shipped locales means a translation-file project for your team on day one, and again after every widget update that adds strings.

How to test it yourself

Install the trial, switch your browser locale to each market language you sell in, and load the widget. Count the languages that render correctly with zero configuration. That number, not the pricing-page claim, is the shipped coverage.

Red flags

–"Multi-language support" that turns out to mean a CSV of strings you translate yourself.
–Language switching requires a paid tier or an add-on app.
–Right-to-left languages untested or visibly broken in the widget.

Headless and Hydrogen support

Weight: 10% of total score

A real headless SDK ships typed methods and prebuilt components for Hydrogen, Next.js, or Remix; a JSON-only API means your team rebuilds the entire loyalty UI from raw endpoints.

Most loyalty vendors answer "yes" to the headless question because a REST API technically exists. The practical difference is 60+ hours of engineering: with a JSON-only API you rebuild points display, redemption flows, referral links, and tier logic yourself, then maintain that code through every API change. A real SDK gives you components and typed client methods and keeps that maintenance on the vendor.

Even if you are on a Liquid theme today, a storefront rebuild inside a 3-year horizon makes this criterion worth its weight, migrating loyalty apps mid-rebuild is the worst possible timing.

How to test it yourself

Ask for the SDK repository or npm package, not the API docs. Check for a quickstart that renders a points balance in under an hour, published TypeScript types, and a changelog with commits from the last 90 days.

Red flags

–"Headless-ready" backed only by REST API documentation.
–No published SDK package, or one with no commits in six months.
–Redemption and referral flows that only work through the vendor-hosted widget.

Migration path in AND out

Weight: 15% of total score

Evaluate the exit before the entrance: if a loyalty app cannot export customer points balances to CSV on demand, your customers’ earned value is hostage to that vendor.

Points balances are a liability you owe your customers. Coming in, you need CSV import matched on customer email so balances from your previous app carry over. Going out: and you should check this while you are still a prospect, when the answers are honest: you need self-serve CSV export of balances, tier assignments, and referral history. Vendors that require a support ticket for exports control the timeline of your own migration.

The mechanics of switching are well understood; our migration guides cover Smile.io, Yotpo, and LoyaltyLion step by step, and a typical migration completes in one afternoon with balances preserved.

How to test it yourself

During the trial, run the export yourself: create test customers with points, then export to CSV without contacting support. Then import that same CSV back. If either direction needs a ticket, you have your answer.

Red flags

–Export available only "on request" or via support ticket.
–Exported data omits tier assignments or referral attribution.
–Import exists but is gated behind onboarding services or a paid tier.
–Contract language claiming ownership or deletion of program data at termination.

Support model and contract terms

Weight: 10% of total score

Month-to-month billing with self-serve support suits stores under roughly $5M GMV; annual contracts with account managers only pay for themselves when you actually use the account manager.

Support models split cleanly: self-serve (docs, chat, email, typical at the $15–$50/mo price point) versus account-managed (named contact, onboarding calls, typical on $199+/mo or quote-based plans). Neither is wrong, but paying for account management you will not use is the quiet way loyalty budgets double. The contract term matters more than the support tier: annual lock-in removes your leverage exactly when a pricing change or a feature regression would otherwise make you leave.

How to test it yourself

Email support with a real technical question during the trial and time the first substantive (non-canned) response. Ask sales directly: is monthly billing available on the plan I need, and what is the cancellation notice period? Get both answers in writing.

Red flags

–Annual prepay is required for the plan tier that has the features you need.
–Trial-period support noticeably faster than the documented post-sale SLA, you are seeing the sales-window service level rather than the real one.
–Auto-renewal with a 60- or 90-day cancellation notice window buried in the terms.

The scorecard

Score each candidate app 1–5 per row, multiply by the weight, and sum for a total out of 5. Print it, or rebuild it in a spreadsheet with one column per app. The point is that the same rows get filled in for every vendor.

Criterion	Weight	What good looks like	Score (1–5)
1. True cost at your volume	25%	Flat or predictable pricing; every needed feature priced at your volume, 2x, and 5x in writing	___
2. Storefront performance	20%	Under 50 KB of JavaScript measured in DevTools; no render-blocking requests	___
3. Admin-native operation	10%	Daily tasks inside Shopify Admin; permissions inherited from Shopify staff roles	___
4. Multi-language coverage	10%	Your market languages shipped and auto-detected, verified in the trial, on every plan	___
5. Headless support	10%	Published SDK with TypeScript types, components, and commits within 90 days	___
6. Migration in and out	15%	Self-serve CSV export and import of balances, tiers, and referrals: tested, not promised	___
7. Support and contract	10%	Monthly billing available; documented response SLA; no long cancellation notice window	___
Weighted total	100%	Sum of (score × weight) per row, out of 5	___

Interpretation guide: a weighted total above 4.0 is a safe pick; 3.0–4.0 means workable with known trade-offs; below 3.0, keep looking. A score of 1 on criterion 1 or 6, cost or exit, should veto an otherwise high total, because those two mistakes are the expensive ones to reverse.

What fintech capabilities should a Shopify loyalty evaluation cover?

Six capabilities decide whether a loyalty program produces auditable financial records: the reward instrument it writes to, how balances are scoped to currency, whether expiry is a recorded event, whether outstanding balances can be exported as of a past date, whether credentials separate reading from moving value, and what happens to points on a refunded order. Each one is verifiable during a trial.

These are capability questions, distinct from the vendor-diligence questions further down. Every Shopify behaviour described here comes from the Admin GraphQL API reference for version 2026-01, so you can check each claim against Shopify's documentation instead of ours.

Reward instrument: store credit or discount code

Does redemption create a ledger entry or a coupon?

This single choice decides whether your loyalty balances are auditable. Shopify store credit accounts record every movement as a transaction carrying the amount, the balance after the transaction, and a timestamp, which is a ledger you can query. A discount code produces a discount application that captures the intent of the code, while the money that actually came off sits in the per-line discount allocations. Reconciling a points program built on codes means reassembling balances from order-level allocations after the fact.

How to verify: Ask which Shopify object the app writes on redemption. If the answer is a discount code, ask how you produce a per-customer statement of issued and redeemed value for a closed period.

Currency scoping of balances

What happens when a customer earns in one currency and redeems in another?

Shopify store credit accounts are currency-specific, and one customer can hold several accounts in different currencies at the same time. A points balance held in an app database usually has no currency at all until the moment it converts. Selling into multiple markets means deciding whether a point is pinned to your shop currency or floats with the presentment currency, and the two produce different redemption values on the same order.

How to verify: Run a trial redemption in a second market currency and compare the value the customer receives against the same redemption in your home currency.

Expiry as a recorded event

When points expire, does anything record it?

Shopify credits can carry an expiry date, and when one lapses the platform creates an expiration transaction that debits exactly the remaining amount of that credit. Expiry inside an app database is often a field update with no corresponding record. If your finance team releases breakage to revenue, the difference matters: one produces a dated, per-customer trail, the other produces a balance that quietly changed.

How to verify: Ask whether expiry emits a transaction or a webhook, and request a sample export showing expired value for one closed month.

Outstanding balance at a point in time

Can you export what you owe as of a given date?

Unredeemed points and unspent credit are an obligation to your customers, and period-end reporting needs the figure as of a date rather than as of today. Many loyalty apps expose a current balance per customer and nothing historical, which makes a prior period impossible to restate without a snapshot you thought to take at the time.

How to verify: Ask for the outstanding balance across all customers as of the last day of the previous month. If the vendor can only produce today, take the snapshot yourself on a schedule from day one.

Scope separation on credentials

Can the integration read balances without being able to move them?

Shopify treats writing store credit transactions as its own access scope, separate from reading account data, so an integration that only needs to display a balance never needs the permission to change one. Ask which scopes the app requests on install and whether any credential you generate can be issued read-only. An app that asks for write access to everything gives you nothing to revoke when a key leaks.

How to verify: Read the permission list on the app listing before installing, then check whether the vendor lets you mint a read-only key for your own reporting.

Refunds, returns, and clawback

What happens to points earned on an order that gets refunded?

Shopify keeps discount allocations for refunded and removed quantities on the order, so the record of what was discounted survives the return. The loyalty side is not automatic: points awarded on a refunded order may stay awarded unless the app reverses them. Both answers are defensible as policy, but you should choose deliberately, and the reversal itself should leave a record.

How to verify: During the trial, place an order, let points post, refund it in full, and check both the customer balance and whether any transaction records the reversal.

For fintech and regulated-commerce companies

Companies operating under financial or data-protection regulation should add five vendor-diligence criteria to the standard seven. The standard framework still applies, but a loyalty vendor becomes part of your data-processing chain the moment it ingests customer PII.

These are questions to ask every shortlisted vendor in writing, not properties you can test in a trial. None of this constitutes compliance advice; your own counsel and compliance team own the final call on whether a vendor’s answers meet your obligations.

Data residency

Ask where customer PII is stored and processed, region by region, and whether you can pin storage to a specific region. If your compliance program requires EU or UK data residency, "we use AWS" is not an answer: you need the region and the sub-processor list in writing.

PII handling and minimization

Ask exactly which customer fields the app ingests and why. A points program needs an email, an order total, and a customer ID; it does not need full address books or payment details. Ask how deletion requests propagate: when a customer is erased in Shopify, confirm the loyalty vendor erases its copy, and on what timeline.

API auditability

Every balance adjustment should be attributable: who or what changed a customer’s points, when, and via which credential. Ask whether the API writes an audit log you can export, and whether API keys can be scoped read-only. If adjustments are anonymous, reconciling a disputed balance becomes guesswork.

Webhook reliability

If downstream systems consume loyalty events, ask three questions: what is the retry policy on failed deliveries, are events signed so you can verify origin, and is delivery at-least-once or best-effort? A webhook that silently drops events during a vendor incident becomes a data-integrity problem on your side of the fence.

Uptime and SLA questions

Ask for the status page URL, 12 months of incident history, and whether any plan carries a contractual uptime commitment with remedies. Most loyalty vendors publish a status page but no SLA; that is normal at self-serve price points: the point is to know which one you are buying before an outage, not after.

The RFP question checklist

Send these 12 questions to every shortlisted vendor and require written answers. A vendor that answers all 12 in writing has already outperformed most of the market on transparency. Copy-paste them as-is; questions 10–12 cover the regulated-commerce criteria and can be dropped if they do not apply to you.

1What is the total monthly price at our current order volume, at 2x, and at 5x, with VIP tiers, referrals, and our listed integrations enabled? Name the exact plan for each.
2How many kilobytes of JavaScript does your widget load on a stock Dawn theme, measured as transferred size? May we verify on a reference store you name?
3Which routine operations (balance adjustments, rule edits, exports) happen inside Shopify Admin, and which require your external dashboard?
4How many locales does the widget ship with, auto-detected, on the plan we are evaluating? Which languages require manual translation files?
5Do you publish a headless SDK (npm package name, please) with TypeScript types, or is headless support a JSON API only?
6Can we self-serve export all customer points balances, tier assignments, and referral history to CSV at any time, without a support ticket?
7Can you import points balances from our current provider matched on customer email? What fields survive the import?
8Is monthly billing available on the plan we need? What is the cancellation notice period, and does the contract auto-renew?
9What is your documented support response SLA on our plan, not the sales-period response time?
10Where is customer PII stored (regions and sub-processors), and how do Shopify customer-deletion requests propagate to your systems?
11Do API-driven balance adjustments write an attributable audit log we can export? Can API keys be scoped read-only?
12What is your webhook retry policy, are payloads signed, and where is your public status page with incident history?
13On redemption, which Shopify object does the app write: a store credit transaction, a discount code, or something in your own database only?
14Are balances scoped per currency, and what value does a customer receive when they earn in one presentment currency and redeem in another?
15When points or credit expire, is an expiry record created that we can export and reconcile, or is the balance simply reduced?
16Can we export the total outstanding points and credit liability across all customers as of an arbitrary past date, without having taken a snapshot in advance?
17Which Shopify access scopes does the app request on install, and can we issue a read-only credential for our own reporting?
18When an order is refunded, are the points earned on it reversed, and does the reversal itself create an exportable record?

Apply the framework

The fastest path through this framework is to start from data someone has already collected and verify the rows that matter most to your store.

Start from the scored list

Our 8-app ranked comparison already contains the criterion-1 and criterion-2 data, pricing at multiple tiers and measured widget weights, for the most-installed apps.

Model the cost delta

The savings calculator prices your current loyalty bill against alternatives at your actual order volume, criterion 1 as a two-minute exercise.

Check the exit before entering

The migration guides document what moving off Smile.io, Yotpo, or LoyaltyLion actually involves, useful for scoring criterion 6 on any app, including ours.

Going headless?

The headless page shows what a real SDK looks like versus a JSON-only API: the criterion-5 benchmark for Hydrogen, Next.js, and Remix builds.

Frequently asked questions

How long should a Shopify loyalty software evaluation take?

Two to three weeks is realistic for a rigorous evaluation: one week to shortlist three apps and model pricing at three order volumes, one week of parallel trials running the hands-on tests (widget weight in DevTools, CSV export, locale check), and a few days for RFP answers in writing. Solo merchants can compress this to a weekend by testing only the top two criteria, true cost and widget weight, which together carry 45% of the framework weight.

What is the most common mistake when evaluating loyalty apps?

Budgeting from the entry price instead of the feature-complete price. The pattern repeats across vendors: entry tiers at $15/mo, with the feature merchants actually plan programs around, VIP tiers, gated behind plans at $199/mo (Smile.io) or usage-based pricing reaching $499/mo (Rivo). The fix is mechanical: price every app with your full feature list enabled, at your order volume and at 5x, before comparing anything else.

How do I measure a loyalty widget’s performance cost myself?

Open Chrome DevTools, go to the Network tab, filter by JS, hard-reload a store running the widget, and sum the transferred size of every request from the vendor’s domain. No vendor cooperation is needed: any live store running the app is a test bench. Market range in August 2026 runs from 14 KB to roughly 650 KB, and the gap between the light and heavy end typically costs 8 to 15 Lighthouse mobile points on the same theme.

What should a fintech company evaluate in Shopify loyalty software?

A fintech company should evaluate two layers on top of the standard seven criteria: capabilities and diligence. Capabilities are what the software does with money-like objects, which reward instrument it writes to, how balances scope to currency, whether expiry is recorded, whether outstanding balances export as of a past date, whether credentials separate reads from writes, and what happens to points on a refund. Diligence covers data residency, PII handling, API auditability, webhooks, and SLA terms. Capabilities are testable in a trial; diligence questions go in the RFP.

Should a loyalty program issue store credit or discount codes?

Store credit if you need auditable balances, discount codes if you do not. Shopify store credit accounts record each movement as a transaction with the amount, the resulting balance, and a timestamp, and accounts are currency-specific. Discount codes leave a discount application capturing intent, with the actual money in per-line discount allocations, so reconstructing a customer statement means reassembling order-level allocations after the fact. Store credit also supports an expiry date that automatically writes an expiration transaction for the unused remainder.

Do fintech and regulated companies need different loyalty evaluation criteria?

They need five additional criteria on top of the standard seven, not a different framework: data residency (which regions store PII), PII minimization (which fields the app ingests and how deletions propagate), API auditability (attributable balance-adjustment logs), webhook reliability (retries, signing, delivery guarantees), and uptime/SLA terms. These are vendor-diligence questions to ask in writing during the RFP stage: most self-serve loyalty vendors can answer them, but few volunteer the answers unprompted.

Run the framework on Anchor first

The trial is free, the widget is 14 KB, VIP tiers cost $14.99/mo flat, and the CSV export works without a ticket, all seven criteria are testable in one afternoon. If we score badly on your scorecard, the framework did its job.

Install Anchor free on Shopify