Why most wallet projects fail (and it’s not a technology issue)
Most wallet projects don’t fail because the technology is complex. They fail because they are mispositioned from the start.
The wallet is often treated as a marketing topic, a distribution channel or a product feature. When in reality, it is an architecture topic.
The result: passes are distributed… but barely used, no usable data is collected, and most importantly, there is no measurable business impact.
This gap is critical, especially in a context where 71% of consumers expect personalized experiences, while only 15% of companies believe they are actually delivering them.
The problem is not the wallet. The problem is how it is integrated.
The 3 architectural mistakes that limit 80% of wallet projects
Treating the wallet as a standalone project.
The typical approach: generate a pass → send it → project done.
No connection to the rest of the IT system. No continuity of usage. Result: the wallet becomes a dead object from day one.
Duplicating data
Some architectures create a dedicated “wallet” database.
Bad idea:
- data duplication
- desynchronization
- increased GDPR complexity
The principle of data minimization (at the core of GDPR) recommends limiting unnecessary storage and duplication.
Duplicated data is data that eventually diverges.
Thinking distribution instead of usage
Many projects focus on number of passes created and add-to-wallet rate. But pay little attention to: actual usage, interactions and activation. Result: a “cosmetic” success, not a business one.
Underestimating real user adoption
This is a more subtle, but very common, mistake on the IT side. The wallet is often seen as a “nice to have,” a low-impact business feature. As a result, architectures are not designed to handle real adoption.
In reality, the opposite often happens:
- some retail brands have seen volumes multiplied by 5 on day one, far exceeding initial forecasts
- others have reached their annual adoption targets within days, with very high add-to-wallet rates
The problem is not adoption. The problem is being ready for it.
When the architecture doesn’t keep up: latency, bugs and degraded experiences. And the entire promise collapses.
The 4 building blocks of a successful wallet integration
Source systems (single source of truth)
The wallet must rely on your existing systems:
- CRM
- POS
- ticketing
- loyalty
It replaces nothing. It connects to them.
Orchestration (APIs & connectors)
This is the core of the system.
- real-time APIs
- native connectors
- event-driven logic
This is where experience fluidity is determined.
Activation
Once data is connected, it becomes actionable:
- marketing scenarios
- notifications
- benefit triggers
Examples include Salesforce Marketing Cloud or Klaviyo
The wallet becomes an entry point into your customer journeys.
Reporting
All interactions must be captured:
- data warehouses like Snowflake
- BI tools
- business tools (ticketing, POS, etc.)
The goal is to measure real usage, not just distribution.
The real differentiator: storing no data
The most effective architectures share one key principle: the wallet does not store data.
Benefits:
- simplified GDPR compliance
- enhanced security
- always up-to-date data
The wallet becomes a real-time interface, not a secondary database.
At The Wallet Crew, this choice has been foundational from the start. We chose openness: connecting instead of storing.
Concretely: connectors to existing systems, data used where it already lives and no unnecessary duplication. The wallet becomes an invisible but essential layer.
And that’s the paradox: the better the integration, the more the wallet disappears… in favor of the experience.
Integrating a wallet: standalone project vs connected approach
In many projects, the wallet is still treated as a simple digital support: a pass is generated, distributed, and the project is considered “done.”
But this approach misses the point. A wallet only creates value when it is connected to your IT system.
To understand the impact, let’s compare both approaches across different use cases.
Wallet: a marketing project… or an architecture project?
The wallet works in both cases. But the difference is radical.
Without integration:
- a digital support
- a limited experience
With a connected architecture:
- a touchpoint
- a data source
- a business driver
The real question is not “Should we use a wallet?” but “How do we integrate it into our architecture?”
