Loyalty Card API: Issue and Update Wallet Cards From Your Own POS

You send card details through the API, and the customer receives a mobile wallet pass they can add to their phone.

See also: Free Loyalty Card Maker: Design Free, Pay When You Go Live · Punch Card App: Go Digital With Wallet Cards

This article covers the core endpoints for issuing a new loyalty card, updating points or tier levels after a sale, and removing a pass when a customer leaves your programme. You will also see how to connect the API to common POS workflows, handle barcode formats, and avoid sync issues between your database and the customer’s wallet.

Core Endpoints for Card Issuance

You call an endpoint, pass customer data, and the card lands in Apple Wallet or Google Wallet. The core endpoints cover four jobs: create a card, fetch its status, update points or stamps, and void a card when needed.

Create a Card

The create endpoint accepts a customer identifier from your POS, such as a phone number, email, or internal loyalty ID. You also send the card design reference, the initial balance, and any tier or member details. For a cafe, the request might include a customer name, a stamp count of zero, and a template ID for your standard coffee card. The API returns a wallet pass URL and a unique card ID you store against the customer record.

Use this endpoint at the moment of signup. If a customer gives their email at the till, your POS calls the create endpoint in the background. The customer receives an SMS or email with a link to add the pass to their phone. No separate app download, no printed card to laminate.

For salons, the create call often carries a prepaid balance or a visit count. A salon owner can issue a five-visit card at checkout and hand the customer a QR code on the receipt. Scanning that code opens the wallet pass. The API does the heavy lifting; the POS just triggers the call.

Fetch Card Status

The fetch endpoint returns the current state of a card: points balance, stamp count, expiry date, and whether the pass is installed on a device. Your POS uses this when a customer presents a card at the counter. The cashier scans the wallet pass, the POS reads the card ID from the barcode, and calls the API to confirm the balance before applying a discount.

For a car wash, this matters because prepaid washes often expire. The fetch response tells you if the card is still valid and how many washes remain. If the pass was deleted from the customer's phone, the status flag lets your staff offer a reissue instead of arguing about lost points.

Update Points or Stamps

The update endpoint changes the balance on an existing card. You send the card ID and the new balance or a delta value. For a restaurant, a lunch visit might add one stamp to a ten-stamp card. The POS calls update after payment completes, and the wallet pass refreshes automatically on the customer's phone.

The API should support idempotency for updates. If a cafe's internet drops after a sale, the POS can retry the same update without double-stamping. You pass an idempotency key, such as the POS transaction ID, and the API ignores duplicate calls with the same key.

For gyms, the update endpoint handles membership renewals. When a member pays for another month, the POS sends the new expiry date. The wallet pass updates without the member doing anything. The same endpoint can change tier status from basic to premium, which updates the card design on the phone.

Void a Card

The void endpoint marks a card as inactive. Use it when a customer requests account deletion, when a card is reported lost, or when you close a loyalty scheme. The pass remains on the phone but shows as expired or inactive. A gym might void a card when a membership is cancelled, preventing the old pass from scanning at the door.

The void call should accept a reason code. Your POS logs "customer request" or "fraud suspected" for your own records. The API keeps the card history for reporting but stops all updates. If a customer later rejoins, issue a fresh card rather than reactivating the old one.

Updating Existing Wallet Passes

A loyalty card API is not just for issuing new passes. It also handles changes to cards already sitting in a customer’s Apple Wallet or Google Wallet. When a balance changes, a membership tier upgrades, or a customer changes their phone number, the pass needs to reflect that without the customer doing anything.

How updates reach the phone

Most wallet pass APIs work through a push notification. Your POS or backend sends an update request to the API provider. The provider then contacts Apple’s or Google’s servers. The wallet app on the customer’s phone receives a silent notification and pulls the new pass data. The customer does not need to open an app, scan a QR code, or re-add the card.

For example, a cafe runs a buy-ten-get-one-free scheme. A customer buys a latte. Your POS records the transaction and calls the loyalty card API with the new stamp count. The API updates the pass. The next time the customer glances at their wallet, the card shows nine stamps instead of eight. If the customer has notifications enabled, they may see a lock-screen alert such as “Loyalty card updated.”

Common update scenarios

A salon might change a client’s loyalty tier from Silver to Gold after a certain number of visits. The update includes a new background colour, a new tier label, and perhaps a new barcode value. The API call replaces the relevant fields on the existing pass. The customer keeps the same card in their wallet. There is no second card, no confusion.

A car wash selling prepaid washes needs to decrement a balance after each visit. The POS reads the pass’s serial number from the customer’s phone, deducts one wash, and sends an update. The wallet pass then shows the remaining balance. The same logic applies to a restaurant with a stored-value gift card inside a wallet pass or a gym updating a membership expiry date.

What can be updated

Typical fields you can change through a wallet pass API include:

• Point balances, stamp counts, or stored value
• Membership tier names and colours
• Expiry dates and validity periods
• Customer name, phone number, or member ID
• Barcode or QR code values
• Relevant locations shown on the back of the pass

Some fields are harder to change than others. The pass type, for instance, is usually fixed at creation. You cannot turn a loyalty card into a boarding pass. But the visual design, text, and most dynamic fields are straightforward to update.

Linking the update to your POS

The cleanest approach is to trigger updates from the same place you record a sale. When a cashier taps “complete sale” for a customer linked to a wallet pass, the POS should automatically call the loyalty card API. If your POS does not support direct API calls, a small middleware script can watch for new transactions and send the update.

One practical detail: store the pass identifier with the customer record. That identifier, often called a serial number or pass ID, is what the update call uses. Without it, you cannot target the right pass. When you first issue the card through the loyalty card API, save the returned identifier in your customer database.

Handling failed updates

A customer may have removed the pass from their wallet, changed phones, or disabled notifications. The API response will usually tell you if the pass is no longer valid. Your system should handle that gracefully. Mark the pass as inactive in your database, but keep the customer’s points or balance. Next time they visit, you can reissue a fresh pass with the correct balance. Do not silently lose their loyalty data because a phone-side pass disappeared.

Updates should feel invisible to the customer. The card in their wallet simply shows the right number at the right time. That reliability is what makes a loyalty card API worth integrating into your own POS rather than relying on a separate third-party app.

Apple Wallet Loyalty Card Setup

Setting up an Apple Wallet loyalty card through an API takes a few concrete steps. You create a pass template, configure the card fields, then link the pass to customer records in your POS. Once that link exists, you can update balances, stamps, or tier status without asking the customer to download a new card.

Start with the pass type. For loyalty, you want the storeCard style. It shows a barcode or QR code on the front, plus room for a points balance, membership level, and a few custom labels. A cafe might display "Rewards balance" and "Free drink earned". A car wash could show "Washes until free detail". A gym might show "Classes remaining this month".

Next, decide how the customer gets the card. Most shops add a "Add to Apple Wallet" button to their booking confirmation page, email receipt, or a screen on the customer-facing tablet. The API generates a signed pass file on the fly. The customer taps the button, Apple Wallet opens, and the card installs in seconds. You do not need a separate app for this. A salon can include the button in the appointment reminder email. A restaurant can show it on the printed receipt via a QR code that points to the pass download URL.

The real value comes after installation. The API lets your POS push updates to the card whenever something changes. A customer buys a coffee, your POS adds a stamp, and the card in their Apple Wallet updates automatically. The pass can also trigger a lock-screen notification when the customer walks near your shop, if you enable location alerts. A car wash near a busy intersection might use this to remind regulars that they are one wash away from a free rinse.

Authentication matters here. Each pass is tied to a unique serial number and an authentication token. Your POS stores those two values against the customer profile. When the customer presents the card at the till, you scan the barcode. The scanner reads the serial number, your POS looks up the profile, and the balance on screen matches the balance on the phone. No separate loyalty terminal needed.

For developers, the flow looks like this:

1. Create a pass type identifier in your Apple Developer account.
2. Generate a certificate for signing passes.
3. Build a JSON template with your branding, colours, and field labels.
4. Use the API to create a pass for each customer and store the serial number.
5. Call the update endpoint when a transaction changes the customer's balance or tier.

One practical tip: test the update path before launch. Run a dummy transaction in your POS, then check that the card on a test iPhone shows the new balance within a few seconds. If the push notification does not arrive, check that the pass has the changeMessage field set. That is the line of text Apple Wallet shows on the lock screen when the card updates, such as "Stamp added — 4 more until a free coffee".

Salons and gyms often use tier-based cards. The API supports changing the card's colours and labels when a customer moves from "Bronze" to "Gold". The customer does nothing. The card simply changes appearance and shows the new benefits next time they open it.

Google Wallet Pass Integration

A loyalty card API that supports Google Wallet lets your business put a digital loyalty card directly into a customer’s Android phone. The card sits alongside their credit cards, event tickets and boarding passes. They tap to open it, show the barcode at your counter, and you scan it with the same scanner you use for paper cards or phone screens.

What the integration actually does

When your POS issues a loyalty card, the API creates a Google Wallet pass and sends it to the customer’s phone via a link, QR code or in-app button. The pass contains the customer’s name, membership number, current points balance and a barcode — usually Code 128 or QR. Each time the customer earns or redeems points, your POS calls the API again. The pass on their phone updates automatically, as long as the phone has an internet connection.

You do not need a separate Google Wallet app on your POS. The API handles the communication. Your POS just needs to send the right data at the right time: card creation, balance changes, and expiry or removal if a customer leaves your loyalty programme.

A typical cafe flow

A customer orders a flat white and gives their phone number at the till. Your POS finds their loyalty profile and sees they have no wallet card yet. The cashier taps “Send to Google Wallet” on the POS screen. The customer receives a link by SMS or scans a QR code on the customer-facing display. They tap “Add to Google Wallet” once. The card appears with your cafe’s logo, their name, and a barcode showing their current stamp count.

On their next visit, they open Google Wallet, tap your card, and hold the barcode under your scanner. The POS reads the membership number, adds a stamp, and the API pushes the updated card to their phone. The customer sees the new stamp count before they have even picked up their drink.

Why salons and gyms benefit

A salon using a wallet pass API can send a loyalty card when a client books their first appointment online. The card shows their visit count and any prepaid balance. After each appointment, the receptionist updates the booking system, which triggers a card update. The client sees the new balance without opening a separate app or receiving an email.

Gyms can use the same approach for membership cards. The pass shows the member’s name, membership tier and expiry date. If a member upgrades from monthly to annual, the POS updates the pass and the new tier appears on their phone within minutes. No plastic card reprint, no front-desk queue.

Practical points to check before you build

• Barcode compatibility. Most Android barcode scanners read phone screens without extra settings, but test with your specific scanner model. Screen brightness and cracked screen protectors can cause misreads.
• Pass updates. Google Wallet passes update through the Google Wallet API. Your POS must store the pass ID for each customer so you can send updates later. If you lose the pass ID, you cannot update that specific pass.
• Customer permission. You need the customer to actively add the pass to their wallet. You cannot push a pass onto a phone without their action. Make the add step obvious at the till or in your booking confirmation.
• Branding assets. Prepare a square logo, a wide banner image and your brand colour hex code. These appear on the pass and make it look like your card, not a generic template.
• Fallback for iPhone users. Google Wallet works on Android only. For iPhone customers, you need a separate Apple Wallet integration. Many loyalty card APIs support both, but you must configure each one.

A Google Wallet integration works best when your POS treats the pass as the primary card, not a duplicate. If a customer already has a plastic card or an app account, link the wallet pass to the same loyalty profile. That way, a scan from the phone and a scan from the plastic card both update the same points balance. The customer sees one consistent number everywhere, and your staff never has to reconcile two different totals.

Webhook Events and Notifications

A loyalty card API that only pushes cards to wallets is only half the story. The real value comes when your POS, CRM or booking system receives events back from the wallet. Webhooks are the mechanism for that. They are simple HTTP callbacks: when something changes on a loyalty pass, the wallet provider sends a POST request to a URL you control, with a JSON payload describing the event.

The most common event is card.installed. This fires when a customer taps "Add to Apple Wallet" or "Save to Google Wallet" and the pass lands on their device. Use it to mark the customer as "card active" in your database. A cafe can stop printing physical stamp cards for that customer. A salon can switch its reminder flow from SMS-only to include a wallet lock-screen notification.

card.updated fires when the pass content changes on the device. This usually happens because your system pushed a new version of the pass through the API. For example, a car wash issues a loyalty card with eight stamps. After the ninth visit, your POS calls the update endpoint to add a stamp and change the relevant text to "Free wash unlocked". The wallet provider then notifies your webhook that the update was delivered. This lets you keep an audit trail without polling the wallet provider.

card.removed is the event you do not want to ignore. It fires when a customer deletes the pass from their wallet. A gym might use this to trigger a re-engagement email: "Your membership card is no longer in your wallet. Tap here to re-add it." A restaurant could pause push notifications for that customer until they reinstall the card, avoiding wasted sends.

Some wallet APIs also send card.voided when you invalidate a pass server-side. This is useful for loyalty programmes that expire. A coffee shop running a seasonal promotion can void all cards from the spring campaign and rely on the webhook to confirm removal.

Practical setup

Point the webhook at an endpoint on your own server or a service like Zapier or Make. The endpoint must return a 200 status quickly, ideally within a few seconds. If it does not, the wallet provider may retry, and duplicate events can occur. Make your handler idempotent: check whether you have already processed an event with that ID before updating your database.

For a small shop with no developer, a no-code bridge works well. When card.installed arrives, append a row to a Google Sheet or add a tag to the customer in your email tool. When card.removed arrives, send a Slack message to the front desk. The goal is not to build complex logic. It is to keep your own records in sync with what customers actually have on their phones.

Test with a sandbox or test card before going live. Simulate install, update and removal events. Confirm your endpoint logs the raw payload, because debugging a missed notification is much easier when you can see exactly what was sent.

POS System Authentication Methods

Your POS system needs a way to prove it is allowed to create and update wallet cards for your customers. The loyalty card API accepts a few different authentication approaches, and the right one depends on how your POS is built and who controls the code.

API keys for server-to-server calls

Most modern cloud POS systems use a simple API key. You store one key in your POS backend, never in the customer-facing app or terminal. Each request to create or update a wallet card includes that key in a header. The key ties the request to your loyalty account, so the API knows which loyalty program the card belongs to.

The key should be rotated if an employee with admin access leaves. Keep the key out of log files and never print it on receipts.

OAuth for multi-location or franchise setups

If you run several locations or a franchise network, a single shared key can become a security problem. One leaked key exposes every store. OAuth works better here. Each location or franchisee gets its own credentials and requests a short-lived access token. The token expires, usually within an hour, so a stolen token has limited use.

A salon chain with five branches can give each branch manager a separate OAuth client ID. The central office can revoke one branch without affecting the others. This also lets you track which location issued or updated a specific wallet card, useful when a customer complains about missing points after visiting a particular store.

Signed requests for legacy or offline POS systems

Some older POS terminals do not have reliable internet access or cannot handle OAuth token refreshes. For those, the loyalty card API may support request signing with a private key. The POS software creates a signature for each request using a secret stored locally. The server verifies the signature before accepting the change.

A car wash with a basic on-site terminal can use this method. The terminal signs a request to add a stamp to a customer's wallet card after each wash. Even if the internet drops for a few minutes, the signed request can be queued and sent later. The private key stays on the terminal, and the public key sits on the API server.

Choosing the right method

Start with an API key if you have a single cloud POS and one location. Move to OAuth when you have multiple locations, staff turnover, or a franchise model. Use signed requests only when your hardware or network setup makes token-based auth impractical.

Whichever method you choose, test the failure path. Revoke a key and confirm the POS shows a clear error instead of silently failing to update cards. A restaurant that loses card updates for a week because of an expired key will face angry regulars who expect their free coffee or dessert. Authentication is not just a technical detail; it is the gate that keeps your loyalty program trustworthy.

Barcode and QR Code Standards

A loyalty card is only useful if the scanner at your counter can read it quickly. When you issue wallet cards through a loyalty card api, you control the code format. Get this wrong and staff end up typing numbers by hand while a queue forms. Get it right and check-in takes under a second.

Code 128 for standard barcodes

Code 128 is the workhorse for loyalty cards. It encodes letters and numbers densely, scans reliably from phone screens, and works with almost every USB or Bluetooth scanner sold in the last decade. If your POS already reads barcodes from plastic cards, Code 128 is the safest drop-in choice.

A typical loyalty card payload is the customer ID plus a check digit. For example, if your customer ID is 104829, you might encode 1048293 where the final digit is calculated from the first six. The check digit catches manual entry errors and stops a smudged screen from crediting the wrong account.

Keep the payload short. Ten to twenty characters is plenty for most shops. A cafe using a wallet pass api might encode C104829 where C marks the store location and the number is the customer record. A gym with three branches could use G2-104829 to show branch and member ID. Short codes render as crisp bars on small phone screens. Long codes force the barcode to shrink, which makes scanning slower.

Set the barcode height to at least 15 mm on the wallet pass. Many wallet pass api platforms let you specify this in the pass template. Thin barcodes are hard to hit with a scanner at arm's reach. A car wash attendant holding a scanner through a car window needs a tall, bold code, not a thin strip.

QR codes for camera-based scanning

QR codes make sense when staff use a phone camera or a tablet app instead of a dedicated laser scanner. Salons and small cafes often run their POS on an iPad. A QR code is easier for a camera to lock onto than a Code 128 barcode, especially in dim lighting.

A QR code can also carry more than an ID. You can encode a short URL that opens the customer's profile in your POS web app, or a JSON string with customer ID and loyalty tier. For example, a restaurant loyalty api might generate a QR payload like https://pos.example.com/loyalty/104829. When the server scans it, the POS opens the member's points balance directly.

Keep QR payloads under 100 characters. Longer payloads increase the number of modules in the code, which makes it denser and harder to scan from a phone screen at an angle. A car wash with outdoor scanners in bright sunlight should use a simple numeric ID in the QR code, not a long URL.

Error correction matters

Wallet passes let you set the error correction level for QR codes. Choose medium or high. A scratched screen protector or a low-brightness display can obscure parts of the code. Higher error correction lets the scanner reconstruct missing modules. The trade-off is a slightly denser code, but for short loyalty IDs that is rarely a problem.

Whitelist the code format in your POS

Before you roll out wallet cards, test the exact payload format against every scanner and POS version you use. A loyalty card api can generate a valid pass that still fails at the counter because your POS expects a 10-digit number and the pass sends a 12-character string with a prefix. Strip prefixes, pad with zeros, or add a mapping layer in your loyalty api for developers so the code on the phone matches what the POS expects.

For most shops, the practical choice is simple: Code 128 with a short customer ID for laser scanners, or a QR code with a short URL or ID for camera-based POS setups. Test both with the actual phone models your staff and customers use most.

Location Based Pass Triggers

A loyalty card API can push location-based notifications to a customer's phone when they enter or leave a defined area. This is not about tracking someone continuously. It works through geofences, which are virtual circles drawn around a physical address. The wallet pass sits quietly on the lock screen until the phone crosses that boundary. For a shop owner, this turns a forgotten plastic card into a gentle nudge at the exact moment the customer is nearby.

How geofences work with wallet passes

You define a radius around your shop, usually between 50 and 500 metres. The wallet pass stores that location rule. When the phone's GPS or Bluetooth beacon confirms the customer has entered the zone, the pass appears on the lock screen with your message. No app needs to be open. The customer does not need to tap anything first.

A cafe on a busy high street might set a 150-metre geofence. A customer who walks past on the way to work sees a lock-screen notification: "Your loyalty card has 8 stamps. One more coffee today earns a free drink." That is far more useful than an email sent at 9am that gets buried.

A car wash on the edge of town might use a wider 400-metre fence. Drivers approaching on the main road get a reminder that their wash credit expires this weekend. The timing matches the decision point, not a random hour in the afternoon.

Practical scenarios for different businesses

Salons and barbershops. A client who booked a haircut six weeks ago may not remember when to return. Set a geofence around the shopping centre where the salon sits. When the client walks past a nearby shoe shop or pharmacy, the pass can show: "Your last visit was 6 weeks ago. Tap to book your next cut." The loyalty card API handles the location trigger; your booking link sits inside the pass.

Gyms and fitness studios. Members often stop coming after a few weeks. A gym can set a fence around the car park or the building entrance. When a lapsed member drives into the car park for another reason, the pass appears: "You have 2 personal training sessions left this month." This works because the person is already on the premises. The barrier to walking inside is much lower.

Restaurants. A restaurant with a lunchtime rush can set a geofence that only triggers between 11:30 and 14:00. Office workers walking within 200 metres see their loyalty balance and a note about today's special. After 14:00, the trigger switches off. The same pass can have a second fence around the evening delivery zone if you run a separate takeaway counter.

Cafes with multiple branches. A chain with three locations can attach a different geofence to each store. The pass shows the nearest branch's stamp balance and opening hours. A customer who usually visits the north-side cafe but walks near the south-side one sees that their card works there too. This is useful for businesses that want to shift foot traffic between sites.

What to avoid

Do not set the radius too small. A 20-metre fence around a shop door may not trigger until the customer is already inside, which defeats the purpose. Test the area yourself. Walk the route a customer would take from the nearest bus stop, car park or train station. The trigger should fire when the person still has a decision to make.

Do not send the same message every time. If a customer walks past your salon twice a day, a repeated "Come in now" alert becomes noise. Use the loyalty card API to vary the message based on balance, last visit date or time of day. Some platforms let you set a cooldown period, such as one notification per day per pass.

Location triggers work best when the message is specific and tied to the customer's own data. "You have 3 points" is weak. "You are 2 visits away from a free smoothie, and you are 100 metres from the shop" is strong. The location does the heavy lifting. Your message just closes the gap.

Testing Your Loyalty Card API

Set up a sandbox environment before you touch live customer data. Most wallet pass platforms give you a test issuer ID, test certificates, and a way to push passes to a development device. Use that. A loyalty card that fails in production annoys the exact customers you are trying to keep.

Test the full lifecycle in one quiet shift

Run your first end-to-end test during a slow Tuesday afternoon, not a Saturday lunch rush. Pick one staff member as the test customer. Have them make a real purchase, earn a stamp or point, and check that the pass updates on their phone within a few seconds. Then redeem a reward and confirm the pass shows the new balance. This catches the most common failure: a POS that records a sale but never triggers the API call.

Test from the customer’s side too. Open the pass. It should still display the last known balance. When they reconnect, the next update should overwrite the stale data. If your API only updates passes when the phone is online, you need a fallback: print the balance on the receipt or let staff check it in the POS.

Simulate the awkward real-world cases

Cafes and salons deal with refunds, split payments, and wrong-item voids. Your API needs to handle all of them. Create a test card, add three stamps, then void one transaction. Does the API subtract a stamp or does it leave the pass unchanged? Decide the rule before you go live. For a car wash with a “buy five, get one free” card, a voided wash should remove one stamp. For a gym that awards points per visit, a late cancellation might not remove points. Write the rule down and test it.

Test duplicate requests. A common POS bug is sending the same “add stamp” call twice because the cashier tapped the button twice. Your API should reject the second call or make it idempotent. If it adds two stamps, you will give away free coffees by accident.

Test a card that moves between devices. A customer gets a new phone, removes the pass from the old one, and installs it on the new one. The API should recognise the same loyalty account and restore the correct balance. If your system ties the pass to a device ID instead of a customer ID, the balance resets to zero. That is a fast way to lose a regular.

Check the failure messages your staff will see

Staff do not read API logs. They see whatever your POS screen shows. Test what happens when the wallet service is down for five minutes. Does the POS freeze? Does it print an error code nobody understands? Does it silently skip the update? The best behaviour is to queue the update and retry it automatically, while showing a simple message like “Card update pending – will sync shortly.”

Test a card that has been deleted from the customer’s phone. The API call to update it will fail. Your POS should not crash or block the sale. It should record the loyalty activity locally and flag the card for re-issue next time the customer visits.

Use a small table for your test checklist

Run this checklist once before launch and again after any POS software update. A loyalty card API is only as reliable as the weakest link between your till, your server, and the customer’s phone.

How PassHive handles this

PassHive is built for exactly this job. It lets a shop, cafe, salon, car wash, restaurant or gym issue its own branded loyalty cards that customers save to Apple Wallet and Google Wallet. No app download. The customer scans a QR code at the counter or opens a link, and the card lands in their wallet. From then on, the shop controls the card through a public REST API.

How the API works

The API is designed for developers and agencies who want loyalty cards to come from the same system that already runs the till. You create an API key in PassHive, then use it to issue cards, add stamps, add points, or send a message. The endpoints are documented in the API docs.

A typical flow looks like this:

• PassHive updates the card in Apple Wallet or Google Wallet.
• The customer sees the new stamp next time they open their wallet.

The same call can add points instead of stamps, depending on the card type. You can also send a push notification to a saved card, such as “Your free coffee is ready” or a short offer. Google limits roughly three messages per card per day, so the API is built for occasional, useful updates rather than constant marketing.

What you control

PassHive is not a POS and does not replace your till. It sits beside it. PassHive only handles the wallet card and its updates.

You can design the card with your own name, colour and logo, and preview it on iPhone and Android before paying. You pay when you go live. The card types are simple: a stamp card (buy nine, get the tenth free) or a points card. If you turn a branch off, its cards stop updating at once.

Location reminders are available but the phone decides when to show them. On Apple, you can set up to ten locations per card, each with roughly a 200-metre radius. Google uses merchant locations. This means a customer near your shop can be reminded of the card on their lock screen, but PassHive cannot force that reminder to appear.

What this costs

The smallest plan is $10 per month for up to 100 branches. Larger plans go up to $100 per month for up to 1,250 branches. Yearly billing gives two months free.

This matters because most wallet loyalty services charge per pass. PassKit, for example, starts at $39.50 per month and includes 250 passes, then adds per-pass fees. A cafe with 1,000 customers would pay about $73 per month on PassKit. The same cafe pays $10 on PassHive. A shop with 10,000 customers would pay about $341 per month on PassKit. Still $10 on PassHive. Those are simple examples from published pricing, not a survey.

This site is published by the team that builds PassHive, so you should know we have a clear interest here. But the pricing model is easy to check. You can start designing your card free and see the full PassHive pricing before you commit.

PassHive is a flat monthly plan for the whole business, not a fee per branch. The plan sets the maximum number of active branches you can run: $10 a month for up to 100 branches, $25 for up to 275, $50 for up to 600 and $100 for up to 1,250. Yearly billing gives two months free ($100, $250, $500 or $1,000 a year). A cafe with one branch pays $10 a month in total, whatever the number of cards or customers. That is what "pay for your branches, not your customers" means: the plan size follows how many branches you run, never how many people save your card.