> For the complete documentation index, see [llms.txt](https://docs.thewalletcrew.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.thewalletcrew.io/configure/advanced-configuration/wallet/import-and-export/pass-migration/export-passes-from-twc-to-another-provider.md).

# Export Passes From The Wallet Crew to Another Provider

Export Apple Wallet and Google Wallet passes so a new provider can take over updates, with the constraints that apply on each platform.

Leaving The Wallet Crew is possible at any time. 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 the brand as the issuer of record. It also prevents vendor lock-in.

Customer data belongs to the brand, which stays the data controller. In practice, the source of truth stays in the brand's CRM and internal systems.

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

{% hint style="info" %}
If a blocker is the reason for leaving, tell us early. We can often fix it without requiring a migration.
{% endhint %}

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 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:

1. Export each pass **serial number** and **authentication token**.
2. Update the `webServiceURL` to the 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**.

Passes cannot be "transferred" to a different issuer account. The 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

{% stepper %}
{% step %}

### Export pass data from The Wallet Crew

Open the passes list in the admin console:

<p align="center"><a href="https://admin.thewalletcrew.io/tenant/~/passes/" class="button secondary" data-icon="chevrons-right">The Wallet Crew Administration Console - Pass List</a></p>

Export the full list.

Make sure the export includes, at minimum:

* Apple: **serial number** and **authentication token**
* Google: **resource ID** (or object ID)
* The brand's external identifiers (so the new provider can map passes back to customers)
  {% endstep %}

{% step %}

### Give the export to the new provider

Send the exported file to the new provider. It is needed 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.
{% endstep %}

{% step %}

### Switch Apple passes to the new update endpoint

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

Then ask The Wallet Crew team to:

1. configure the target `webServiceURL` for the tenant, and
2. run a bulk "push update" so installed passes pick up the new URL.

{% hint style="warning" %}
Switching the `webServiceURL` without a working endpoint on the new provider can stop Apple passes from updating.

Plan a short validation window and test on a small sample first.
{% endhint %}
{% endstep %}

{% step %}

### 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.
{% endstep %}
{% endstepper %}

## FAQ

<details>

<summary><strong>Do end-users need to reinstall their pass?</strong></summary>

Usually no.

When the Apple `webServiceURL` is switched correctly, existing passes keep updating without reinstall.

For Google, when the same issuer account and object IDs are kept, end-users typically keep the same pass.

</details>

<details>

<summary><strong>Can we move Google Wallet passes to a different issuer account?</strong></summary>

Not in-place.

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

</details>

<details>

<summary><strong>What’s the minimum data we must export?</strong></summary>

For Apple, the serial number and authentication token.

For Google, the resource ID.

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

</details>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.thewalletcrew.io/configure/advanced-configuration/wallet/import-and-export/pass-migration/export-passes-from-twc-to-another-provider.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
