Retail
E-wallet for retail: which solution should you choose?
12 October 2026
7 min
Key Takeaways
To deploy an e-wallet in retail, four approaches are possible and the choice hinges less on features than on how the solution connects to your point-of-sale system.
- The native module, integrated into your existing point-of-sale solution, connects vouchers, CRM and loyalty engine without an integration project. It’s the most direct approach for a retailer already equipped.
- The specialist third-party wallet platform is independent of the point-of-sale system. It’s particularly suitable for retailers with a heterogeneous estate or whose provider doesn’t offer a wallet module.
- Custom development offers complete control of the journey, at the cost of an application project and ongoing maintenance.
- Continuing with physical supports remains viable for retailers without a loyalty programme or significant volume of gift cards.
The four criteria that really set these approaches apart are real-time synchronisation with the point-of-sale system and CRM, security of identifiers on digital channels, fluidity of customer enrolment and the existence of a communication channel controlled by the retailer.
Editorial transparency: Cegid publishes one of the solutions falling within the native approach. This article compares integration models and names no third-party publishers.
The question comes up consistently whenever a retailer decides to digitalise its gift cards and loyalty programme. It's rarely framed correctly, because it's treated as a product choice when it's actually an architecture choice.
An e-wallet for retail is not a standalone application. It's a layer that must read balances, statuses and customer records from where they actually live – in your point-of-sale system and your CRM. This logic is that of unified commerce.
It's this connection (not the way the pass appears on the customer's phone) that determines the quality of experience and the true cost of the project. This article compares the four possible approaches, sets out the risks of each and details the conditions under which the native approach prevails.
Methodology of this comparison. This article compares integration models, not publishers: no third-party solution is named. The market data cited comes from studies published by third parties, referenced in the text. Last update: 11 September 2026.
What you really expect from a retail e-wallet
Before comparing approaches, you need to know what to compare them on. Six capabilities structure the value of a digital wallet in retail:
- Pass generation and distribution in Apple Wallet and Google Wallet, from vouchers issued by your existing system, with distribution via email, SMS, QR code or in store.
- Real-time synchronisation of balance, status and expiry date. This is the most discriminating point: a pass showing an expired balance after a purchase destroys customer confidence more surely than the absence of a pass. It’s the condition for a unified shopping experience across all touchpoints.
- Security of identifiers, especially when the voucher is usable online.
- Customer enrolment, that is the ability to convert a till visit into loyalty programme registration, without entry and without friction.
- Outgoing communication channel: push notifications, expiry reminders, geo-targeted messages.
- An autonomous marketing back-office, enabling CRM teams to manage templates, campaigns and segmentation without calling on IT.
In summary. A retail e-wallet is judged by its ability to stay in sync with your point-of-sale system, not by the appearance of the pass. Real-time synchronisation and identifier security are the two most discriminating criteria. The same synchronisation requirement applies to your inventory: see why you should optimise your inventory management across all channels.
The four possible approaches to deploying a retail e-wallet
1 – The native e-wallet integrated into your point-of-sale solution
Your point-of-sale publisher offers a wallet module natively connected to your vouchers, CRM and loyalty engine. Deployment requires neither an application project nor transformation of your information systems and everything falls under a single contract.
This approach obviously assumes that your publisher offers this module. To locate the platforms concerned, see our comparison of unified commerce platforms for retail.
2 – The specialist third-party e-wallet platform
Specialist players offer wallet-as-a-service platforms independent of the point-of-sale system. They are often highly developed on the marketing side and have real experience of the wallet channel. Their advantage is precisely their independence: they work regardless of your equipment. In return, the connection to balances and customer records must be built and maintained.
3 – Custom development of a digital wallet
Apple and Google document their pass formats and an internal technical team can develop its own issuance chain. The approach offers complete control over the journey and appearance and is justified when the requirement really goes beyond market standards.
4 – Continuing with physical gift cards and loyalty cards
Doing nothing remains an option and it’s not absurd for all retailers. Plastic cards and paper vouchers work, are understood by everyone and require no project.
Comparison table of the four e-wallet approaches
| Criterion | Native module | Third-party platform | Custom development | Physical supports |
| Deployment timeframe | Short, configuration | Medium, integration project | Long, application project | N/A |
| Till and CRM integration | Native | To be built and maintained | To be built and maintained | Non-existent |
| Balance synchronisation | Real-time | Based on integration | Based on integration | None |
| Identifier security | Secure numbering integrated | Variable by publisher | To be designed internally | Printed identifiers |
| Customer enrolment | Mobile, feeds CRM | Mobile, remittance to interface | To be developed | Paper form |
| Communication channel | Push and geo-location included | Push and geo-location included | To be developed | None |
| Contracts and contacts | Single | At least two | Internal plus service providers | Printing suppliers |
| Maintenance and updates | Handled by publisher | Shared | Your responsibility | Logistics and restock |
The risk factors in each e-wallet approach
None of these four routes is without trade-off, including the first:
- Native module: it assumes you’re equipped with the point-of-sale solution in question and that your estate is homogeneous. A multi-brand retailer with several point-of-sale systems won’t get the same benefit.
- Third-party platform: the difficulty is not the platform itself, it’s the integration. Each evolution of your point-of-sale system can require a rework of the flows and you manage two contracts, two support teams and two roadmaps. It’s a recurring cost often underestimated when the decision is made.
- Custom development: Apple and Google evolve their standards regularly. The true cost is not the initial build, it’s the maintenance over five years, plus GDPR compliance and identifier security.
- Physical supports: the cost is invisible but very real. Unused balances typically represent between 4 and 7 per cent of value issued and no reminder is possible before expiry because there’s no contact channel after the support is handed over.
The four reasons why native e-wallet comes out ahead
If you’re already equipped with a point-of-sale solution offering a wallet module, four arguments tilt the balance.
Each answers a concrete and documented difficulty.
1 – A natively integrated e-wallet eliminates the integration project
The challenge. A wallet project usually involves assembling a service provider on top of the point-of-sale platform, with separate contracts, costs and data flows. This is the item that usually overruns timelines.
The native answer. Vouchers, CRM and loyalty engine are connected from the outset. Balances, statuses and customer records stay real-time synchronised without specific development.
The benefit. A single offering, deployed and supported by a single contact, with no integration project and reduced total cost of ownership.
2 – Secure numbering protects your gift cards online
The challenge. Sequential identifiers, without random code or confidentiality code, remain common in voucher systems. This numbering approach is acceptable in store, where the physical support provides proof. It becomes a risk as soon as the voucher is usable online.
The native answer. Secure numbering of passes replaces sequential identifiers, with integrity checking and secure display conforming to Apple and Google standards. This requirement sits within a broader framework of security and compliance in retail cloud.
The benefit. Secure omnichannel use, with a single view of balances and transactions, which reduces fraud and double use.
3 – Mobile enrolment feeds your loyalty programme
The challenge. In-store registration remains cumbersome. Paper forms and till-based entry cap the number of members and degrade the quality of data collected.
The native answer. The customer scans a QR code, their profile is pre-filled from their Apple or Google account, they give their consents on their own phone and their record is created in the CRM in real time. It’s a direct lever for personal shoppers and tailored relationships.
The benefit. About three times as many new customers recruited in store as with a paper form, with GDPR-compliant consents and no till entry.
4 – The digital wallet becomes a direct communication channel
The challenge. Once the voucher or card is handed over, the retailer has no way to re-engage its holder, neither before expiry nor at the right moment or place.
The native answer. Push notifications, expiry reminders and geo-targeted messages are controlled by marketing teams from an autonomous back-office, with no IT involvement. It extends in-store to the uses described in our article on mobile in store.
The benefit. A direct and personalised re-engagement channel. According to the 2025 Captain Wallet survey by Brevo and IFOP, 73 per cent of consumers are more inclined to shop with a brand when they receive an offer in their wallet.
This is the approach chosen by Cegid Retail Y2 e-Wallet, a module from the Cegid Retail range that digitalises gift cards, vouchers, credits and loyalty cards managed in Cegid Retail Y2 into Apple Wallet and Google Wallet. The offering starts with no licence cost for customer enrolment, up to 2,500 customers enrolled per year, allowing you to validate value before scaling.
When another e-wallet solution makes more sense
The native approach is not the right answer in every configuration and it would be dishonest to suggest otherwise:
- If your till estate is heterogeneous or your publisher doesn’t offer a wallet module, a specialist third-party platform is the rational choice. Its independence from the point-of-sale system becomes an asset rather than a constraint.
- If your requirement really goes beyond standards and you have a technical team capable of bearing the maintenance over time, custom development is defensible. This is notably the case for retailers that already have a highly adopted mobile app, into which the wallet must fit.
- If you have neither a loyalty programme nor significant volume of gift cards, the status quo remains viable. Digitalising a marginal device will not produce measurable return.
To place this choice within a broader approach, see our omnichannel strategies for growth.
Frequently asked questions about retail e-wallets
A digital wallet, or e-wallet, lets you store gift cards, vouchers, credits and loyalty cards directly in Apple Wallet or Google Wallet, on the customer’s smartphone. The balance, status and expiry date synchronise after each use and the retailer can communicate via push or geo-targeted notifications.
No. Apple Wallet and Google Wallet are already installed on almost all smartphones, eliminating the main barrier to adoption. The customer has nothing to download. That’s precisely one of the things that sets e-wallet use apart from a proprietary app project.
By replacing sequential identifiers with secure numbering, paired with pass integrity checking and secure display that meets Apple and Google standards. Real-time balance synchronisation between till, website and wallet completes the picture by making double use detectable.
It depends entirely on the approach chosen. Custom development involves a project budget then annual maintenance. A third-party platform adds a subscription to integration costs. A native module activates through configuration and some offerings provide a free entry point: Cegid Retail Y2 e-Wallet starts with no licence cost for customer enrolment, up to 2,500 customers enrolled per year. In all cases, reason on total cost of ownership over three years, including integration, maintenance and support.