Wallet Passes for Agencies: Reselling and Building for Clients

An agency can add Apple Wallet and Google Wallet passes to client work in two ways: build the passes yourself with Apple's and Google's developer tools, or resell and configure a wallet pass platform under your own service. For most agencies, reselling a platform is the lower-risk choice because it avoids certificates, signing and update servers; building makes sense when passes are a core product feature or the client needs full control. This guide helps you decide, scope the work, set up ownership and billing, and run client programmes after launch, without promising anything your supplier has not confirmed in writing.

Why clients ask for wallet passes

Clients usually arrive with one of these problems:

• A paper stamp card or plastic loyalty card that tells them nothing about customers.
• A membership scheme where the proof of membership is an email.
• An event or venue that wants tickets or passes on the phone.
• A loyalty app quote that is bigger than the business can justify. See wallet pass vs mobile app for the comparison you can walk them through.

A pass is a good fit when the customer shows a code in person and the client wants to update what it shows. It is a weak fit when the client wants a full shopping experience.

Option 1: Resell a platform

You sign up with a wallet pass platform, build and manage clients' cards in it, and bill the client for the service and your work.

What you get

• No certificate or signing work. On Shakewell Wallet, Apple passes are signed with Shakewell's own certificate, so neither you nor the client needs an Apple Developer account on standard plans (Apple Wallet setup).
• A visual builder, hosted signup links and QR codes, and push messages, so a first programme can be configured without engineering (features).
• Integrations with tools clients already use: Shopify and Shopify POS, Square, Klaviyo, WooCommerce and Zapier (integrations).
• A REST API for custom flows, on Growth and above (docs).

What to check with any supplier

• How client workspaces are separated, and who the account holder is.
• What branding appears on the pass and the signup page, and on which plan.
• Partner terms: volume arrangements and resale rules, in writing.
• Data export and what happens to the client's customers' passes if the client or the agency leaves.

Shakewell's agencies page describes sub-accounts per client, signup pages and passes branded to the client, and partner pricing, and the partners page explains the programme. White-label signup pages are also listed on the Scale plan in pricing, so confirm with us which arrangement applies to your agency before you promise it to a client. We would rather you ask than assume.

Option 2: Build with Apple and Google directly

You write the integration: a Pass Type ID and certificate for Apple, a signing service, an update web service and push sender, and a Google Wallet issuer with service account.

When it makes sense

• Passes are part of a product you sell, not a campaign.
• The client needs the pass identity (Apple Team ID, Google issuer) to be theirs.
• You already have engineers who will own it long-term.

What it costs you in effort

• Certificate management and renewal for every client's Pass Type ID (certificates explained).
• An update service that stays up, and monitoring for it (how updates work).
• A Google Wallet integration (Laravel tutorial).
• Support when a customer cannot add a pass.

If you choose to build, use the pkpass validator while developing Apple passes.

A hybrid: platform API behind your own front end

You can keep your client's own signup page and system, and call a pass API to issue and update passes behind it. With the Shakewell REST API, one call creates a pass for both wallets and returns an install link (quickstart), and webhooks tell your system about loyalty events. You keep the customer experience; the platform handles signing and delivery.

Build versus resell at a glance

Scoping a client engagement

A clear scope protects both sides. A sensible first project covers:

1. Goal and scheme. What is the pass for, and what is the earn and redeem rule?
2. Design. Logo, colours, copy and the one field the customer needs to see.
3. Signup journey. QR code, link or embedded form; which details to collect and why.
4. Staff process. How stamps or points are added, and training for the team.
5. Integrations. Till, e-commerce store, email platform.
6. Privacy and consent. What the client collects, how consent is recorded and what they promise customers. Check the rules that apply in the client's market; for Australian clients, see the Australian small business guide.
7. Launch and review. A test on real iPhones and Android phones, then a review after a set period.

Put in writing who is responsible for what: who holds the platform account, who updates the programme, and who answers customer support questions.

Pricing your service

We cannot tell you what to charge, and it would be wrong to guess for your market. Some structures agencies use:

• A one-off setup fee for design, configuration and training.
• A monthly management fee that covers reporting, small changes and campaigns.
• The platform cost passed through at cost, or bundled into the monthly fee.

Whichever you choose, make sure the platform cost is covered in your agreement, including what happens if the client grows beyond the plan's limits. On Shakewell Wallet, plans have set pass limits and we talk to you about moving up rather than charging overage automatically (pricing).

Running a client programme after launch

The work does not end at launch:

• Report monthly: installs, active passes, redemptions and messages sent. Keep to numbers the platform shows you.
• Run small campaigns: a message when a reward is ready, or a seasonal offer. Keep messages rare.
• Review the scheme: adjust the reward or the prompt if sign-ups are slow.
• Maintain: watch for pass limits, certificate renewals if you built it yourself, and platform changes.

Questions to ask a supplier before you sign

1. Are client workspaces fully separated, and who owns each account?
2. Can the pass and signup page carry the client's brand, and on which plan?
3. What are the partner terms for resale, in writing?
4. Who holds the Apple certificate, who renews it, and can a client use their own?
5. Can a client export their customers and move to another provider?
6. What support do you get when a launch goes wrong?
7. What does the supplier not do? For example, Shakewell Wallet does not support Samsung Wallet yet.

Our comparison of wallet pass platforms lists what other providers say publicly, with sources, so you can compare terms side by side.

Next steps

If you want to try it on a pilot client, start with a free trial and build the client's first card before you commit to a partner arrangement (agencies). If you want to discuss partner terms, get in touch through the partners page or contact us.