Google Wallet Pass Creator for Loyalty Cards

You can create Google Wallet loyalty cards with the Google Wallet Pass Creator, a tool that turns your customer rewards program into a digital card customers keep on their phone. The pass creator handles the technical setup so you do not need to code a solution from scratch.

See also: Google Wallet Loyalty Card: How Shops Issue Android Cards · Location-Based Lock-Screen Reminders for Wallet Cards

This article explains how to use the pass creator for a loyalty program. You will learn the basic steps: setting up API access in the Google Wallet console, defining a loyalty class for your brand, and issuing passes to individual customers. You will also see how the pass appears on Android devices and what information you can include, such as points balance, tier level, and your shop's contact details.

Core Features of a Wallet Pass Creator

A good Google Wallet pass creator does more than generate a barcode. It gives you control over how the pass looks, when it updates, and how customers use it at the till. Here are the features that matter most for a shop, cafe, salon, or gym.

Loyalty card templates built for your business type

You should not need a designer to launch a loyalty card. The creator should offer ready-made templates with fields that fit your trade. A cafe template might show a stamp grid for coffees, while a salon template could display a points balance for treatments. A car wash template might show a simple "5 washes, 6th free" counter. You adjust the colours, logo, and wording, then save.

The pass should carry your business name, a short offer line, and a clear barcode or QR code. Customers add it to Google Wallet from a link in an email, a text message, or a QR code at the counter. Once added, it sits next to their bank cards and boarding passes, so they find it quickly.

Point or stamp updates without a new pass

The most practical feature is the ability to update a pass after it is issued. A customer buys a coffee, you scan their pass, and the stamp count moves from three to four. With a Google Wallet pass creator connected to the Google Wallet API, this update happens through the loyalty class. The customer does not download anything new. Their phone shows the new balance the next time they open the pass.

This works well in a restaurant or gym where you track points per visit or per pound spent. Staff do not need a separate app. The point-of-sale system or a simple tablet can send the update. The key is that the pass creator supports a loyalty class, which links all issued passes to one template. When you change the template, every customer's pass reflects the change.

Location-based reminders

A useful feature for physical shops is a location trigger. You can attach your shop's address to the pass. When a customer walks near your salon or cafe, their phone can show a lock-screen notification with the pass. This is not a push notification you send manually. It is a setting within the pass itself. For a car wash on a busy road, this can remind a driver who passed by last week that they have one stamp left.

You set the location once in the pass creator. No extra app is needed on the customer's side. Google Wallet handles the rest.

Simple distribution options

The creator should let you share passes through several channels without technical work. A short link works in an Instagram bio or a printed receipt. A QR code on a table tent lets a diner add the pass before ordering. For a gym, you might email a link after a member signs up. The pass creator should generate these links and codes automatically.

Some creators also support a "Save to Google Wallet" button for your website. This is useful if you sell gift cards or run a booking page. The button is a small piece of code you paste once.

Basic analytics without guesswork

You need to know if the loyalty card is working. A practical pass creator shows how many passes were issued, how many are still installed, and how often they are opened or scanned. This is not advanced customer tracking. It is enough to see whether your cafe's stamp card is bringing people back or sitting unused in wallets. You can then adjust the offer or the design.

Setting Up Your Google Wallet API Access

Before you can issue a single loyalty card, you need access to the Google Wallet API. This is the technical foundation that lets your point-of-sale system or customer app push a pass to a phone. The setup process takes a few hours if you follow the steps in order, and you only need to do it once per business.

Start by creating a Google Cloud project. Sign in to the Google Cloud Console with the Google account you want to manage your passes. If you run a salon with a separate booking system, use the same account that owns that system. This avoids permission headaches later. Name the project after your business, for example "Bella Salon Loyalty" or "Corner Cafe Rewards". The project name is internal only, so customers never see it.

Next, enable the Google Wallet API for that project. In the Cloud Console, search for "Google Wallet API" and click Enable. You will be asked to agree to the Google Wallet API Terms of Service. Read the section on acceptable use carefully. Google restricts passes for things like government IDs, health insurance cards, and age verification. A cafe stamp card or a gym membership card is fine. A loyalty card that stores medical appointment details is not.

After enabling the API, create a service account. This is a technical identity your POS or booking software uses to talk to Google. Go to IAM & Admin, then Service Accounts, and click Create Service Account. Give it a descriptive name like "loyalty-pass-issuer". Skip the optional role assignments for now. After creation, open the service account and go to the Keys tab. Create a new JSON key and download it to a secure location on your office computer or server. This file contains credentials. Treat it like a password. If a car wash has a Windows PC at the front desk running the pass software, store the JSON key in a folder that only staff with admin rights can open.

Now you need to grant the service account permission to issue passes. Go back to the Google Wallet API page in the Cloud Console and click Credentials. You will see a section for the service account you just created. Click the toggle or checkbox to grant it access to the Wallet API. Without this step, your software will get a "permission denied" error when it tries to create a pass.

The final step is to verify your business identity with Google. Open the Google Wallet Business Console. Enter your business name, website, and a contact email. Google reviews this information. A restaurant with a live website and a matching domain email gets approved faster than a pop-up shop using a free email address. Approval usually takes one to three business days. You can still build and test passes in the meantime using the demo issuer ID, but you cannot send real passes to customers until verification completes.

Once you have the service account JSON key and your issuer ID from the Business Console, you are ready to create your first loyalty class. Keep both pieces of information in your password manager or a locked document. You will need the issuer ID every time you create or update a pass, and the JSON key whenever your software authenticates with Google.

Understanding the Loyalty Class Structure

When you create a Google Wallet pass for a loyalty program, you are not building a single file from scratch each time. You are defining a reusable template, then stamping out individual passes from it. Google calls this template a Loyalty Class. The pass a customer stores on their phone is a Loyalty Object.

Think of the class as the master design for your cafe's stamp card or your salon's points programme. It holds everything that stays the same across all customers: your brand name, logo, colours, terms and conditions, and the type of loyalty scheme you run. The object holds what changes per person: their name, current points balance, membership tier, and a unique barcode or QR code.

A car wash running a "buy nine washes, get the tenth free" scheme would set the class to a points-based system. The class defines how points are displayed and what the programme is called. Each customer's object then tracks their individual points. If you later rebrand the car wash with a new logo, you update the class once, and every stored pass updates automatically. You do not need customers to download anything new.

For a restaurant with a simple visit counter, the class can be configured for a stamps or visits model. The object then increments each time the customer dines. The class also controls whether you show a barcode, a QR code, or both. A gym might use a QR code that scans at the front desk. A cafe might prefer a barcode that works with an existing point-of-sale scanner. That choice lives in the class, not in each individual pass.

The google wallet pass creator workflow typically involves setting up a class first, then issuing objects against it. If you use the google wallet pass api directly, you send a JSON definition for the class to Google's servers. You then send a separate JSON definition for each object. Many small-business tools hide this complexity behind a simple form, but the underlying structure remains the same.

One practical detail: the class includes a reviewStatus field. Before any pass can be issued to the public, Google must approve the class. This is not a lengthy manual review in most cases. It is a technical check that your images meet size requirements, your text fields are filled correctly, and your branding does not violate Google's guidelines. Plan for this approval step when you create google wallet pass templates for the first time.

The class also carries your loyalty programme's programName and programLogo. These appear prominently on the pass. A salon might use "Glow Rewards" as the programme name, while the business name stays separate. The class lets you set both, so customers see the loyalty scheme name and the salon's brand on the same screen.

Finally, the class holds the locations array. If you run three coffee shops, you can attach all three addresses to one class. When a customer is near any of your locations, Google Wallet can surface the pass on their lock screen. This works without any additional app installs. The class is the single place where you manage that location-based behaviour across every loyalty pass you have issued.

Generating a Loyalty Object for Users

A loyalty object is the digital record that connects a specific customer to your rewards programme. When you create a Google Wallet pass for a member, you are not building a static coupon. You are generating a unique object that can change as the customer earns points, reaches a new tier, or redeems a free item.

The process starts after you have already defined your loyalty class in the Google Wallet API. The class holds the shared details: your shop name, logo, brand colour, programme title, and the default terms. The object holds the individual details: the customer name, their current points balance, their membership ID, and any tier label such as Silver or Gold.

For a cafe running a simple stamp card, the object might start with zero stamps. When a barista scans the pass at the till, your point-of-sale system sends an update. The object now shows one stamp. After the sixth stamp, the object can change its state to show a free coffee is available. The customer sees this immediately on their phone lock screen if they have enabled notifications.

A salon can use the same logic for visit-based rewards. Each completed appointment adds one visit to the object. After five visits, the pass updates to show a discount on the next haircut or colour service. The salon does not need to print a new card or ask the customer to remember a code. The pass on the phone is always current.

Restaurants often use points instead of stamps. A customer spends £40 and earns 400 points if you set one point per ten pence. The object stores the point balance as an integer. Your till or booking system calculates the new balance and pushes it to Google Wallet. The customer opens the pass and sees the updated number. You can also include a secondary field for the cash value of those points, for example 400 points equals £4 off the next meal.

Car washes and gyms can add a membership ID to the object. The ID can be encoded as a barcode or QR code on the pass. A staff member scans it at the entrance or payment terminal. This replaces a plastic fob or a keyring card. The object remains valid even if the customer changes phones, as long as they are signed into the same Google account.

When you generate the object, you must set a unique object ID. Use a format you can match to your internal customer database, such as CUST-10482 or MEMBER-7731. Do not reuse the same ID for different customers. The ID is how you find the object later when you need to update points, change the tier, or expire the pass.

The object also carries a state field. Use active for a normal member. Use expired if the membership has lapsed. Use inactive if the customer has requested a pause, for example a gym member freezing their account for a month. The state controls whether the pass shows as valid when scanned.

You can include a message field on the object. A car wash might set the message to "Two washes until a free exterior clean." A restaurant might show "You are 120 points away from a free dessert." Keep the message short. It appears on the pass detail screen and gives the customer a clear next action.

Generating the object is a server-side task. You send a signed request to the Google Wallet API with the object data. Google returns a link that you can embed in an email, SMS, or a button on your website. The customer taps the link and the pass is added to their Google Wallet app. You do not need to build a mobile app for this to work.

After the object exists, the real value comes from updating it. Each purchase, visit, or redemption should trigger an update. A loyalty pass that never changes feels like a static card and gets ignored. A pass that updates after every interaction gives the customer a reason to check their phone and return to your shop.

Designing the Visual Card Layout

Keep the Card Layout Simple and Recognisable

A loyalty card inside Google Wallet has limited space. The card face shows the business name, the loyalty programme name, the current points or visits, and a barcode or QR code. The back can hold terms, contact details, locations and links. The layout must stay readable on a phone screen that is often viewed in bright daylight or while the customer is queuing.

Start with the front of the card. Choose a strong brand colour for the header. A cafe might use its existing cup colour, a salon its appointment-book accent, a car wash its bay signage colour. The logo should sit top-left or top-centre at a size that does not push the points balance off the visible area. Avoid busy patterns behind text. A plain or lightly textured background keeps the points number and barcode easy to scan.

Front-Facing Details That Matter in Daily Use

The most important element is the points or visit balance. For a coffee shop, this could read "7 of 10 stamps". For a gym, it might show "12 visits this month". Place this near the centre of the card, in a large enough type that staff can read it from across the counter. Do not hide it behind a logo or a promotional banner.

The barcode or QR code should sit below the balance. Test it at the till before going live. Some barcode formats render too small on certain Android screen sizes. If the scanner struggles, switch from a linear barcode to a QR code, or reduce the amount of empty space around the code. A restaurant using table-service scanning may prefer a QR code that opens the loyalty sign-up page, while a quick-service counter may need a barcode that scans directly into the POS.

Use the back of the card for information that does not need to be seen on every visit. A salon can list booking details, cancellation rules and a link to rebook. A car wash can show opening hours and the location of the nearest branch. Keep the back text short. Three or four lines are enough. Long terms and conditions belong on the website, not inside the pass.

Practical Layout Choices for Different Businesses

A cafe with a simple "buy 9 get 1 free" programme needs a very clean front: logo, stamp count, barcode. Nothing else. A multi-location restaurant may add the branch name under the logo so staff can spot passes used at the wrong site. A gym with tiered membership can use a small coloured strip to show silver, gold or platinum level, but the strip should not take space from the scan code.

Test the card on at least two phone sizes, one small and one large, before sending it to customers. Check how the card appears when the phone is in dark mode. Some background colours become too dark or too bright. Adjust the contrast rather than changing the brand colour completely.

The Google Wallet Pass Creator handles most layout decisions automatically based on the template you choose. Your main job is to supply a clean logo, a short programme name and a clear points format. Avoid uploading a logo with a white box around it. Use a transparent PNG so it sits properly on the coloured header. A poorly cropped logo makes the whole card look unprofessional, even if the programme itself works well.

Adding Barcode and QR Code Support

A loyalty card that cannot be scanned at the till creates friction. Staff end up typing long member numbers by hand, queues grow, and customers start leaving the card in a drawer. When you create a Google Wallet pass, the barcode or QR code is the piece that connects the digital card to your existing point-of-sale system.

Google Wallet supports several barcode formats. The most common for loyalty programmes are Code 128, EAN-13, QR, and Aztec. Code 128 works well for member IDs that mix letters and numbers, such as CUST-00482-AL. EAN-13 suits shops that already use 13-digit barcode numbers on physical cards. QR codes are useful when your till software reads a URL or a short text payload rather than a numeric string. Check what your POS or scanner app accepts before you pick a format.

Matching the code to your existing system

The barcode on the Google Wallet pass should carry exactly the same value as the barcode or magnetic stripe on your old plastic card. If your salon software looks up customers by a ten-digit number, put that ten-digit number in the pass. Do not add a prefix or wrap it in a URL unless your software expects that.

A practical example: a car wash chain issues physical cards with a Code 128 barcode containing the member number WASH-77821. When they create Google Wallet passes, they use the same Code 128 format and the same value. The scanner at the entrance reads the phone screen exactly as it reads the plastic card. No changes to the till, no new hardware, no extra staff training.

If you do not have an existing barcode system, start with a simple rule. Generate a unique member ID for each customer in your CRM or spreadsheet, then encode that ID as a Code 128 barcode on the pass. Most barcode scanners in shops and gyms read Code 128 without any configuration.

QR codes for app-less check-in

QR codes make sense when the code needs to open a link or trigger an action beyond a simple ID lookup. A gym might put a QR code on the member pass that opens a check-in URL. The front-desk tablet scans the QR code, the browser opens, and the check-in is recorded. The same pass can also carry a Code 128 barcode with the member number for the older scanner at the turnstile.

Restaurants and cafes often use QR codes to link a loyalty pass to an online ordering profile. The QR payload might be https://orders.example.com/loyalty/48291. When scanned from the phone screen, the customer lands directly on their account. Keep the URL short. Long URLs produce dense QR codes that are harder to scan from a dimmed phone screen.

Practical display tips

Set the barcode value as the primary display field on the pass. Google Wallet shows it prominently, so staff can scan it without the customer opening a separate screen. Ask customers to turn their screen brightness up before scanning. A barcode rendered at full width on a modern phone screen scans reliably at normal till distances, but a cracked screen protector or very low brightness can cause misreads.

Test with the actual scanner at your counter, not just a phone camera. Some older laser scanners struggle with phone screens, while most modern imagers read them without issue. If your scanner is older, test a QR code as an alternative, since QR codes are often easier for older hardware to decode than dense linear barcodes.

When you create a Google Wallet pass through the Google Wallet API, you define the barcode inside the loyalty class. The barcode object includes the type, value, and optional alternate text. The value must match what your scanner expects, and the alternate text is what staff see if the barcode cannot be scanned, so keep it human-readable, such as Member ID: 48291.

Testing Passes in the Wallet App

Before you hand a single loyalty card to a customer, test the pass on your own phone and on at least one other device. A broken pass looks worse than no pass. The good news is that testing a google wallet pass creator output is quick, and you can do it without publishing anything to your live customer list.

Start by creating a test pass with the same google wallet pass api or no-code tool you plan to use for production. Most tools let you mark a pass as a draft or test object. That draft still opens in Google Wallet, but it carries no real customer data and cannot be confused with a live card. Use a test email address linked to the Google account on your phone.

Open the test link on your phone. If you are using a cafe loyalty card, check that the pass shows the right store name, logo, and member number. Tap the pass to expand it. Look at the barcode or QR code. Then scan it with the same scanner or point-of-sale app you use at the till. This is the step most shops skip. A pass can look perfect on screen and still scan as the wrong value if the barcode format does not match your POS.

For a salon or barbershop, test how the pass behaves after a visit. If your loyalty program adds a stamp or point after each appointment, update the pass through your google wallet loyalty class and open it again on the phone. The change should appear without the customer reinstalling anything. If your POS writes points back to the pass, run one dummy transaction and confirm the new balance shows up.

Restaurants and gyms should test the location-based notification. Add a test pass with your venue’s address attached. Walk or drive near the front door with the phone unlocked. The pass should appear on the lock screen or in the wallet’s “nearby” section. If it does not, check that the address is precise and that location permissions are enabled for Google Wallet on the test phone.

Car washes and multi-location businesses need one extra test: the same pass on two different devices. Create one test pass and open it on an Android phone and an iPhone. Google Wallet passes render slightly differently across screen sizes and operating systems. Check that the logo is not stretched, the barcode is fully visible without scrolling, and the text does not overflow. If you use a custom image, test it in both light and dark mode.

Finally, test the “remove pass” flow. Delete the test pass from the wallet. Then try to re-add it from the same link. Some google wallet pass creator tools issue a one-time link by default. If a customer removes the pass and later taps an old email or SMS, they may get an error. For loyalty cards, you want a link that can be reused or a fresh link generated on demand. Confirm this behaviour before you send the first batch of real invites.

A practical testing routine takes under an hour. Use a checklist: scan the barcode, update a point, trigger a location notification, check two devices, and re-add a deleted pass. Fix any issue before you promote the loyalty card at the counter or on your receipts.

Managing User Permissions and Sign-In

When you set up a Google Wallet pass creator for your loyalty cards, sign-in and permissions determine who can issue passes, edit templates, and view customer activity. Most small businesses need two or three roles, not a complex hierarchy. A cafe owner might issue passes from the counter, while a salon manager edits the design and a gym receptionist only scans existing passes.

Start by mapping each task to a person. Issuing a pass means creating a new loyalty card for a customer who signs up in person. Editing a pass template covers changes to your logo, colours, offer text, or expiry rules. Viewing analytics includes checking how many passes were saved, how many were added to Google Wallet, and which locations issued the most. If one person does all three, a single owner sign-in with full access is enough. If staff share a tablet at the till, create a restricted role that can issue passes but cannot delete templates or change billing details.

Google Wallet pass creation typically runs through a Google Cloud project or a third-party pass management platform. The sign-in method depends on which route you use. If you build directly with the Google Wallet API, you manage access through Google Cloud IAM roles. Grant the Wallet Objects Editor role to staff who issue passes and the Wallet Objects Viewer role to staff who only need to check pass status. Do not share the project owner account. A shared owner password on a sticky note behind the counter creates more risk than any loyalty programme is worth.

Many support Google Workspace single sign-on, so staff use their existing business email. This is easier to audit. Without single sign-on, you must remember to delete a separate login for each tool, and forgotten accounts often remain active for months.

A shift manager at one site should not edit the loyalty template used by all sites. Give branch staff a role that lets them issue passes and view only their own location's activity. The head office or owner account keeps template editing and global analytics. This prevents a well-meaning employee from changing the reward threshold from eight visits to five without approval.

Salons and barbershops often run loyalty through a receptionist's phone or a front desk tablet. Set up a dedicated staff sign-in rather than using the owner's personal Google account. A dedicated account means you can reset the password without locking the owner out of their email, and you can see which staff member issued a specific pass. If a customer disputes a loyalty balance, the audit log shows who created or updated their pass and when.

Gyms face a different challenge: front desk staff change frequently. Use individual staff accounts, not one shared login. Shared logins make it impossible to trace errors or misuse. When a new receptionist starts, create their account with the minimum role needed. When they leave, revoke access the same day. If your pass creator supports pass rotation or re-issuance, also check that former staff cannot export customer email lists. Restrict data export to owner or manager roles only.

Review permissions every quarter. A cafe that started with one owner account may now have three staff issuing passes. Check that each person still needs access and that no account has more rights than necessary. Remove unused accounts. This takes ten minutes and prevents most permission problems before they happen.

For customer sign-in, keep it optional. Google Wallet passes do not require customers to create a separate account with your business. The pass itself lives in their Google Wallet. If you want to link a pass to an online booking or ordering account, ask for sign-in only when the customer needs to view their balance online. Forcing account creation before issuing a loyalty card slows down the queue and loses sign-ups. Issue the pass first, then invite the customer to link an account later if they want extra features like online top-ups or appointment history.

Common Integration Mistakes to Avoid

Most loyalty card failures trace back to integration choices, not the Google Wallet Pass API itself. A shop owner who avoids these common mistakes will save hours of troubleshooting and prevent customers from abandoning the pass before the first visit.

Skipping the test pass on a real phone

A cafe owner creates a pass, checks it on a desktop browser, and assumes everything works. Desktop previews hide issues with tap targets, font sizes, and how the pass behaves in the wallet carousel. Always create a test pass and load it on at least one Android phone. Walk through the full flow: tap the link, save the pass, open it from the wallet, and show it at the counter. If the barcode is too small to scan or the pass title truncates, fix it before sending to customers.

Hard-coding a single barcode value

Some shops generate one loyalty pass template and reuse the same barcode for every customer. This means every customer shares one loyalty account. When one person redeems points, everyone’s balance changes. Instead, use the Google Wallet loyalty class to define the program structure, then create a unique object for each customer with their own barcode value. A car wash can issue pass number 1001 to one customer and 1002 to the next, each linked to a separate record in the point-of-sale system.

Forgetting to update the pass after a purchase

A salon issues a loyalty pass showing zero visits. The customer visits three times, but the pass still shows zero. The next time they open the wallet, they assume the salon does not track visits and stop using the pass. The Google Wallet Pass API allows updating an existing pass without asking the customer to reinstall it. After each transaction, push a new balance or points total to the customer’s pass object. A gym can update a member’s check-in count after each visit so the pass always reflects the current status.

Using a static image instead of a dynamic barcode

A restaurant creates a loyalty pass with a QR code image embedded in the design. The image never changes, so the pass cannot track individual visits or update balances. The correct approach is to use the barcode field in the loyalty class, not an image. The barcode field generates a scannable code that the point-of-sale system can read and link to the customer record. A static image forces manual lookups and defeats the purpose of a digital loyalty card.

Ignoring the save-to-phone confirmation flow

A shop adds a “Save to Google Wallet” button on their website but does not test what happens after the customer taps it. If the link expires, the customer sees an error and never tries again. If the pass saves but the confirmation screen is blank, the customer wonders whether it worked. Test the full flow on a phone and provide a clear follow-up: a confirmation page, an email with the pass link, or a text message. A cafe can send a text with the pass link after a customer signs up, so the pass appears in the wallet without extra steps.

Not setting an expiry or refresh policy

Some loyalty passes are created once and never touched again. If a customer changes phones or reinstalls the wallet app, the pass may disappear or show stale data. Decide how long a pass link should remain valid and how often the pass should sync with your system. A car wash might set pass links to expire after 30 days and re-send the link if a customer requests it. A salon might refresh balances nightly so the pass always matches the booking system.

How PassHive handles this

PassHive is built by the team that publishes this site, so we will be direct about what it does and does not do. It is a Google Wallet pass creator for loyalty cards, but it also creates the Apple Wallet version of the same card. You design one card, preview it on iPhone and Android for free, and pay only when you go live.

The card itself carries your shop’s name, colour and logo. Customers save it by scanning a QR code at the counter or opening a link. There is no app to download. Once saved, the card sits in Google Wallet or Apple Wallet like any other pass.

What the card does

PassHive supports two card types. A stamp card works for “buy 9, get the 10th free” style offers. A points card works when you want to add points per visit or per amount spent. When you add a stamp or points at the counter, the card updates itself on the customer’s phone. You do not need to re-issue the card or ask the customer to scan anything again.

You can also send push notifications to saved cards. A message might say “double stamps this Thursday” or “your reward is ready”. Google limits roughly 3 messages per card per day, so this is for occasional, useful updates rather than constant marketing.

Location-based reminders can appear on the lock screen when a customer is near your shop. Apple supports up to 10 locations per card with a radius of about 200 metres. Google uses your merchant locations. The phone decides when to show the reminder, so the honest wording is “can remind”, not “will remind”.

Pricing and limits

Plans are $10/month up to 100 branches, $25/month up to 275 branches, $50/month up to 600 branches, and $100/month up to 1,250 branches.

Compare that with PassKit, a known competitor. PassKit starts at $39.50/month and includes 250 passes, then charges per extra pass. A cafe with 1,000 customers would pay roughly $73/month on PassKit. The same cafe pays $10/month on PassHive. At 10,000 customers, PassKit is about $341/month; PassHive stays at $10. Those figures come from PassKit’s published pricing pages, and they show why the pricing model matters more than the feature list for most small shops.

You can turn any branch off at any time. Its cards stop working immediately. If you close a location or pause a promotion, you do not keep paying for that branch.

What PassHive does not do

PassHive is not a POS. It is not an e-commerce plugin. It has no named integrations with Shopify, Square, Toast or similar systems.

What PassHive does offer is a public REST API with API keys. Documentation is at passhive.app/docs. That is the integration path, but it requires development work.

You can start designing your card free and preview it on iPhone and Android before paying. Full details are on the PassHive pricing page.

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.