Free resource · use it on this page
Retail Loyalty Vendor Evaluation Scorecard
Thirty questions that predict regret — scored across three vendors, with data export, portability, and exit ranked above features.
1. Data export and ownership
Most buyers evaluate features first and treat data and exit as the fine print. This scorecard reverses that on purpose: it opens with what you own and how you leave, because those are the parts you come to regret. Score each vendor 0 (no, vague, or 'on the roadmap'), 1 (partial, with caveats), or 2 (a clear, contract-backed yes). Ten points per section, sixty in total. PushNotice publishes this as a vendor-neutral tool on purpose — put the same questions to us, too.
| Ask — and what a regret-free answer sounds like | Vendor A | Vendor B | Vendor C |
|---|---|---|---|
| Can you self-serve export the full customer list — including wallet pass serial numbers and install dates — to CSV or API? Good answer: any field, any time, no support ticket and no fee. | 0 · 1 · 2 | 0 · 1 · 2 | 0 · 1 · 2 |
| In the contract, who owns the customer records — us or your platform? Good answer: we are named the data owner/controller and you are the processor. | 0 · 1 · 2 | 0 · 1 · 2 | 0 · 1 · 2 |
| Is scan, tap, and redemption history exportable at the individual event level, or only as dashboard charts? Good answer: timestamped, row-level events, not just aggregates. | 0 · 1 · 2 | 0 · 1 · 2 | 0 · 1 · 2 |
| Does data we push in by API or integration come back out in the same shape? Good answer: it round-trips cleanly and no fields are trapped in the UI. | 0 · 1 · 2 | 0 · 1 · 2 | 0 · 1 · 2 |
| Is there any per-record, per-export, or volume fee to get our own data out? Good answer: export is free and unmetered. | 0 · 1 · 2 | 0 · 1 · 2 | 0 · 1 · 2 |
2. Portability and lock-in
Wallet passes live on the customer's phone but depend on certificates and accounts that someone controls. These five decide whether your program can move — and whether passes survive if you do.
| Ask — and what a regret-free answer sounds like | Vendor A | Vendor B | Vendor C |
|---|---|---|---|
| If we leave, do passes already in customers' wallets keep working or go blank? Good answer: passes stay valid — we can take the signing certificate, or they live out their natural expiry. | 0 · 1 · 2 | 0 · 1 · 2 | 0 · 1 · 2 |
| Can we export the wallet pass templates and design assets in a usable form (source files / .pkpass), or are they locked in your builder? Good answer: templates and assets download cleanly. | 0 · 1 · 2 | 0 · 1 · 2 | 0 · 1 · 2 |
| Who holds the Apple Pass Type ID and Google Wallet issuer account — us or you? Good answer: registered under our accounts, or transferable to us in writing. | 0 · 1 · 2 | 0 · 1 · 2 | 0 · 1 · 2 |
| Can the install links and in-store QR codes be re-pointed to a new provider without reprinting everything in-store? Good answer: links resolve through a domain we control, or a documented redirect exists. | 0 · 1 · 2 | 0 · 1 · 2 | 0 · 1 · 2 |
| Is there a written migration path to another provider, and have you done one before? Good answer: a real offboarding document, not 'we'll figure it out.' | 0 · 1 · 2 | 0 · 1 · 2 | 0 · 1 · 2 |
3. Exit terms and offboarding
The terms you never read until you are leaving. Read them before you sign, not after.
| Ask — and what a regret-free answer sounds like | Vendor A | Vendor B | Vendor C |
|---|---|---|---|
| What is the cancellation notice period, and does the contract auto-renew? Good answer: short notice and no silent auto-renewal. | 0 · 1 · 2 | 0 · 1 · 2 | 0 · 1 · 2 |
| After we cancel, how long do we have to retrieve our data before it is deleted? Good answer: a defined, generous retrieval window stated in writing. | 0 · 1 · 2 | 0 · 1 · 2 | 0 · 1 · 2 |
| Are there early-termination fees, or any fee triggered by exporting and then leaving? Good answer: none, or clearly bounded and disclosed up front. | 0 · 1 · 2 | 0 · 1 · 2 | 0 · 1 · 2 |
| On exit, will you delete our data on request and confirm it in writing within a stated timeframe? Good answer: a documented deletion timeframe and a certificate of deletion. | 0 · 1 · 2 | 0 · 1 · 2 | 0 · 1 · 2 |
| If you are acquired or shut down, what happens to live passes and our data? Good answer: continuity or data-escrow terms are addressed in the contract, not left unsaid. | 0 · 1 · 2 | 0 · 1 · 2 | 0 · 1 · 2 |
4. Customer identification workflow
The workflow that decides whether you have customers or just scans. This is where most demos shine and where day-two reality most often disappoints.
| Ask — and what a regret-free answer sounds like | Vendor A | Vendor B | Vendor C |
|---|---|---|---|
| How is a returning customer recognized — by scanning their existing pass, or does every visit create a new record? Good answer: one durable identity per customer; re-scans update it and never duplicate it. | 0 · 1 · 2 | 0 · 1 · 2 | 0 · 1 · 2 |
| Can staff credit a customer at the till from the wallet pass alone, with no separate app to install? Good answer: yes — the pass is the identity and no app download is required. | 0 · 1 · 2 | 0 · 1 · 2 | 0 · 1 · 2 |
| When a customer changes phones or reinstalls, do they keep their history and balance? Good answer: identity and history survive the device change. | 0 · 1 · 2 | 0 · 1 · 2 | 0 · 1 · 2 |
| Across multiple locations, is a customer one identity or one record per store? Good answer: a single cross-location identity if we run more than one site. | 0 · 1 · 2 | 0 · 1 · 2 | 0 · 1 · 2 |
| How are duplicate or mistaken records merged? Good answer: a merge tool exists, so duplicates are fixable rather than permanent. | 0 · 1 · 2 | 0 · 1 · 2 | 0 · 1 · 2 |
5. Notification limits and deliverability
Reach is easy to inflate and easy to abuse. These five separate honest deliverability from vanity numbers, and surface the real cost of sending.
| Ask — and what a regret-free answer sounds like | Vendor A | Vendor B | Vendor C |
|---|---|---|---|
| Is there a monthly cap on lock-screen messages, and what does exceeding it cost? Good answer: a clear limit and overage price, or genuinely unmetered — wallet pushes do not carry the per-message carrier fees that SMS does. | 0 · 1 · 2 | 0 · 1 · 2 | 0 · 1 · 2 |
| Do wallet pushes bill as messages we pay for per send, or are they included? Good answer: included, with the pricing unit stated plainly. | 0 · 1 · 2 | 0 · 1 · 2 | 0 · 1 · 2 |
| What stops us from over-messaging customers — frequency caps, quiet hours? Good answer: built-in guardrails, because over-messaging drives OS-level throttling and uninstalls. | 0 · 1 · 2 | 0 · 1 · 2 | 0 · 1 · 2 |
| How is delivery reported — per campaign and at the individual level, or only as an estimated 'reach'? Good answer: honest per-campaign delivery, not an inflated audience number. | 0 · 1 · 2 | 0 · 1 · 2 | 0 · 1 · 2 |
| Do you respect Apple and Google limits on how often a pass can update? Good answer: yes, and you can explain those limits without hand-waving. | 0 · 1 · 2 | 0 · 1 · 2 | 0 · 1 · 2 |
6. Consent and compliance handling
The questions your future self, and possibly your regulator, will ask. Get them answered in writing.
| Ask — and what a regret-free answer sounds like | Vendor A | Vendor B | Vendor C |
|---|---|---|---|
| How is consent to message captured and stored, and can we prove it per customer? Good answer: a timestamped, exportable consent record for each customer. | 0 · 1 · 2 | 0 · 1 · 2 | 0 · 1 · 2 |
| Can a customer unsubscribe from messages while keeping their pass, and is that honored immediately? Good answer: message opt-out is independent of the pass and enforced in real time. | 0 · 1 · 2 | 0 · 1 · 2 | 0 · 1 · 2 |
| Who is the controller and who is the processor, and is there a DPA we can sign? Good answer: the roles are defined and a standard DPA is available. | 0 · 1 · 2 | 0 · 1 · 2 | 0 · 1 · 2 |
| What personal data is collected by default, and can we minimize it to what we actually need? Good answer: capture is configurable and data minimization is supported. | 0 · 1 · 2 | 0 · 1 · 2 | 0 · 1 · 2 |
| Where is our data stored and processed, and does that meet our region's rules (GDPR, CCPA)? Good answer: the hosting region and legal basis are documented. | 0 · 1 · 2 | 0 · 1 · 2 | 0 · 1 · 2 |
Tally: total each vendor out of 60
Add each section (max 10) and total out of 60. If two vendors finish close, let the first three sections break the tie — a program you can export and leave is worth more than one extra feature.
| Section | Max | Vendor A | Vendor B | Vendor C |
|---|---|---|---|---|
| 1. Data export and ownership | 10 | ____ | ____ | ____ |
| 2. Portability and lock-in | 10 | ____ | ____ | ____ |
| 3. Exit terms and offboarding | 10 | ____ | ____ | ____ |
| 4. Customer identification workflow | 10 | ____ | ____ | ____ |
| 5. Notification limits and deliverability | 10 | ____ | ____ | ____ |
| 6. Consent and compliance handling | 10 | ____ | ____ | ____ |
| Total | 60 | ____ | ____ | ____ |
From the guide: In-Store Marketing: Wallet Loyalty for Retail Stores
This resource accompanies the full article — worth reading before you commit to a tool.