Export passes from The Wallet Crew to another provider

Export your Apple Wallet and Google Wallet passes so a new provider can take over updates, with clear constraints for each platform.

If you ever decide to stop using The Wallet Crew, you can do it anytime. This page explains how to migrate without breaking pass updates for customers.

This is also why we ask Brands to use their own Apple and Google Wallet accounts. It keeps you as the issuer of record. It also prevents vendor lock-in.

Your customer data is yours. You stay the data controller. In practice, your source of truth stays in your CRM and internal systems.

To switch providers, you export the operational pass identifiers from The Wallet Crew. You give them to your new provider so they can take over updates.

If you’re considering leaving because of a blocker, tell us early. We can often fix it without requiring a migration.

Apple Wallet and Google Wallet do not behave the same. Apple passes fetch updates from a webServiceURL. Google passes are tied to a Google Wallet issuer account.

What you need to plan (Apple vs Google)

Apple Wallet

Apple passes installed on devices keep calling the webServiceURL embedded in the pass.

To move to a new provider, you need to:

1. Export each pass serial number and authentication token.

2. Update the webServiceURL to your new provider endpoint.

3. Trigger an update so devices download a pass version pointing to the new provider.

Google Wallet

Google Wallet passes are tied to a Google Wallet issuer account.

You cannot "transfer" passes to a different issuer account. Your new provider must either:

• operate under the same issuer account, or

• re-issue passes under a new issuer account (new save links, new objects).

Step-by-step

1

Export pass data from The Wallet Crew

Open the passes list in the admin console:

The Wallet Crew Administration Console - Pass List

Export the full list.

Make sure the export includes, at minimum:

• Apple: serial number and authentication token

• Google: resource ID (or object ID)

• Your external identifiers (so the new provider can map passes back to customers)

2

Give the export to your new provider

Send the exported file to your new provider. They need it to attach to existing passes.

For Apple, they will typically import serial + auth token to be able to sign and serve updates.

For Google, they will typically use resource IDs to update the existing objects.

3

Switch Apple passes to the new update endpoint

Agree on the new Apple Wallet web service endpoint with your new provider.

Then ask The Wallet Crew team to:

1. configure the target webServiceURL for your tenant, and

2. run a bulk "push update" so installed passes pick up the new URL.

If you switch the webServiceURL without a working endpoint on the new provider, Apple passes may stop updating.

Plan a short validation window and test on a small sample first.

4

Validate the migration

Pick 2–3 test passes (Apple and Google).

Ask the new provider to:

• update a visible field (example: points balance, status, or event gate)

• confirm the update is visible on devices within a few minutes

For Apple, also confirm that updates still work after reinstalling the pass.

FAQ

Do end-users need to reinstall their pass?

Usually no.

If you switch Apple webServiceURL correctly, existing passes keep updating without reinstall.

For Google, if you keep the same issuer account and object IDs, users typically keep the same pass.

Can we move Google Wallet passes to a different issuer account?

Not in-place.

Google Wallet passes are tied to the issuer account. If the issuer changes, plan a re-issuance flow.

What’s the minimum data we must export?

For Apple, you need the serial number and authentication token.

For Google, you need the resource ID.

External identifiers are strongly recommended. They let the new provider keep pass-to-customer mapping.