If your customer engagement platform has no native wallet passes, you have 2 routes. Connect a pass tool and keep 2 systems in sync, or move to a platform that issues Apple and Google Wallet passes on the same customer profile. The first is faster to start. The second is simpler to run once wallet is part of your journeys.
We wrote this for teams on platforms like Braze, OneSignal or CleverTap who want wallet passes without tearing everything up. For a vendor-level view, see the Wallet passes comparison.
Where you’re starting from
Wallet support varies a lot between engagement platforms. Braze adds wallet through partners such as PassKit. OneSignal has no native wallet passes. Check your own platform’s current docs before you plan, because this changes.
Without native support, the pass lives in 1 system and the customer in another. Every pass you issue, update or target needs data from both.
Route A: keep your CEP and add a pass tool
You keep your current platform for push, email and segments and connect a standalone pass tool for Apple and Google Wallet.
Here’s how it usually works. Your CEP or backend calls the pass tool’s API to issue passes, often through webhooks. If the pass tool exposes events, they flow back into your CEP so you can segment holders.
The upside is real. Nothing migrates. Your team keeps its tools and journeys, and you can start with 1 use case, like a loyalty card.
The downside builds up over time. 2 databases to sync, 2 subscriptions, 2 security and GDPR reviews. Every scenario that combines a pass update with a message, like “your points expire soon”, gets built across 2 tools.
Route B: move to a platform with native wallet
You move messaging to a platform that issues wallet passes natively, on the same profile as push, in-app, email and SMS.
Passes are issued by User ID inside the platform. Segments, journeys and channels all see the pass holder as 1 customer. 1 journey step issues the pass, and the next one sends the link.
You get 1 profile, 1 journey and 1 contract. Pass updates and messages come from the same trigger, and there’s no sync layer to babysit.
The cost is the migration itself: SDK changes, data import, rebuilding journeys and templates. It pays off when wallet is a long-term channel, not a one-off campaign.
| Route A: CEP + pass tool | Route B: native wallet | |
|---|---|---|
| Time to first pass | Fast | Depends on migration |
| Systems to maintain | 2 plus a sync layer | 1 |
| Journeys with pass updates | Built across 2 tools | 1 journey |
| Segmenting pass holders | Via synced data | Same profile |
| Contracts and vendor reviews | 2 | 1 |
| Best for | A single wallet use case | Wallet as a retention channel |
Decision framework
Score yourself on 4 questions.
-
Scope
Is wallet 1 campaign, or a channel you'll run for years? 1 campaign points to Route A.
-
Channels
How many scenarios combine a pass with push, email or SMS? Many points to Route B.
-
Team
Do you have developers to build and maintain a sync layer? If not, Route A gets expensive over time.
-
Data residency
Do you need EU hosting and fewer processors for GDPR? Every extra vendor is 1 more processor to review.
If 2 or more of your answers are “long-term”, “many”, “no developers” or “fewer processors”, look hard at Route B. If none are, Route A is a perfectly good choice, and you can revisit it in a year.
Counting the cost of 2 tools
Route A looks cheaper on day one, because nothing moves. Over a year, add the parts that never show up on the pass vendor’s invoice: building the integration, maintaining the sync, duplicated journey work and a second vendor review.
Route B front-loads the cost: migration work, then 1 platform fee. Compare both over 12 to 24 months, not 1.
Migration checklist
If you pick Route B, plan the move around the customer, not the tool.
- Audit what you send. List the push, email, SMS and in-app campaigns, journeys and segments that have to move.
- Map your data. User IDs, tags, events and consent records. The User ID is what ties a pass to a customer.
- Set up wallet once. An Apple Pass Type ID certificate (Apple Developer account, $99 a year) and a Google Issuer ID with the Pushwoosh service account invited to your issuer.
- Integrate the SDK. Replace the old SDK in your app and test push before you move traffic.
- Rebuild key journeys first. Welcome, abandoned cart, win-back, then the new wallet scenarios.
- Plan the pass launch. Issue passes from a journey step and send the link by email, SMS or push.
- Run in parallel briefly. Keep the old platform for a short overlap, then switch it off.
During the move, use the API to issue passes from your own backend.
Simplify your stack with Pushwoosh
Pushwoosh issues native Apple and Google Wallet passes on the same User ID, segments and journeys as push, in-app, email, SMS and WhatsApp. It’s 1 platform, hosted on its own infrastructure in Germany and the US, with GDPR compliance and SOC 2 Type 2. See where Pushwoosh fits among wallet options.
Adding wallet shouldn’t mean bolting on 1 more tool. It should mean 1 customer profile that every channel can act on.
