Skip to main content

Switch wallet providers without losing your card holders

· 6 min read
eldo wallet team
Product & engineering

Already running Apple Wallet and Google Wallet cards with another provider, and want to move to eldo wallet? Good news: your members keep their card number and their points balance, and in many cases they don't have to reinstall anything. Here's how it works, and the steps for a switch without bad surprises.

Your data belongs to you​

In a loyalty or wallet card program, your brand is responsible for its card holders' data. The wallet provider only processes it on your behalf. When the contract ends, it must give it back to you: this is set out in the GDPR (Article 28), in the EU Data Act for online services, and usually in the reversibility clause of your contract.

In practice, you can always get back your member list, their identifiers, their points balances and their tiers. That's all eldo wallet needs to take over your program.

Good to know

This is general information. For a specific case, have your legal counsel confirm your rights based on your contract.

What decides whether a card stays on the phone​

A card installed on a phone remains tied to the account that issued it:

  • Apple Wallet: the card is signed with a certificate tied to an Apple Developer account, and it contacts a web service to get updates.
  • Google Wallet: the card belongs to a Google Wallet issuer account, and is updated through the Google API.

So it all comes down to one simple question: who owns these accounts?

Two ways to migrate​

1. Seamless takeover: nothing changes for your card holders​

If your brand owns its accounts (Apple Developer account and Google Wallet issuer account in your name), eldo wallet can take over the cards already installed. Your card holders do nothing: their card stays on their phone, with the same number, and gets its updates from eldo wallet (points, offers, visuals).

This requires:

  • giving us access to your Apple certificate and authorizing eldo wallet on your Google Wallet account;
  • routing card updates to eldo wallet: a simple DNS change if the service address is on your domain, otherwise one last update pushed by your previous provider;
  • an export of your cards and members.

2. Re-issuing: a new card, the same points​

If the accounts belong to your previous provider, the installed card can't be taken over for the long term. In that case, eldo wallet imports your data and issues a new card for each member, with the same number and the same balance. Your card holders add it in one tap, from an email, a text message or an in-store QR code.

This option works in every case, because it only depends on your data.

And often, a mix of both​

It's common to own your Google Wallet account but not the Apple one, or the other way round. We then combine both approaches: seamless takeover on one side, re-issuing on the other.

Our recommendation​

  1. Always secure the re-issuing path: request your data export as early as possible. It's your safety net, and it depends on no one but you.
  2. Aim for the seamless takeover when you own your accounts: it's the best experience for your card holders, with nothing lost.

Step by step​

  1. Review your setup togetherBack office

    A few questions are enough: who owns your Apple Developer and Google Wallet accounts, which domain your cards use, what your current contract says, how many cards are active, and how you reach your members (email, SMS, app, store).

  2. Request your data exportBack office

    You send your current provider a data return request (member list, numbers, balances, tiers), based on your contract and the GDPR. If possible, also ask for one last update of the old cards with a link to the new one.

  3. Import and checkeldo wallet

    eldo wallet imports your members into a test environment and checks that every number, balance and tier matches. Your team can review the result before switching.

  4. Prepare the cardseldo wallet

    Seamless takeover: setting up your accounts and testing on a few pilot cards. Re-issuing: creating the new cards and a personal add link for each member.

  5. Switch on an agreed dateBack office

    Balances are frozen at a common cut-off date, then eldo wallet becomes the only source of updates for your cards. For re-issuing, you launch your campaign (email, SMS, QR code) with the add links.

  6. Track adoptionEnd customer

    Your card holders find their card and their points. You track installs and, at the end of the transition, ask your previous provider for a data deletion certificate.

Frequently asked questions​

Will my members lose their points? No. With both approaches, balances and tiers are carried over from your data export, at a common cut-off date.

Will my members have to reinstall their card? Not if you own your Apple and Google accounts (seamless takeover). Otherwise, they add their new card in one tap, with the same number and the same points.

Do I need my current provider's agreement? Not to get your data back: that's your right. Their cooperation does make the transition smoother, for example to send one last message on the old cards.

Why isn't redirecting the cards' address always enough? Because an Apple Wallet card can only be updated with the certificate that signed it. Without that certificate, a redirect alone can't change the card.

How long does it take? It mostly depends on how quickly your current provider returns your data and on the approach chosen. We set the timeline with you from the first conversation.

Let's talk about your migration​

Every situation is a bit different. Tell us about yours and we'll tell you, from the first conversation, which approach is possible for your Apple Wallet and Google Wallet cards.

Contact the eldo wallet team →

Developer? Explore bulk customer import and CSV import, or request test access.

API news, once a month

New endpoints, upcoming changes, guides and use cases. No spam, one-click unsubscribe.

Report a technical problem

An API error, a pass that does not update, an email that does not arrive? Describe the problem: our technical team will answer.

For a fast answer, include:

  • The method and endpoint (e.g. POST /clients)
  • The error code returned (errorCode) and the body sent
  • The date and time of the call
  • The identifiers involved (customer, template, pass)

Never include an API token or a password.

AI assistant

Beta

Loading…

AI-generated answers (Claude): double-check important details.

Sign in to use the assistant