Who Should Build a Digital Wallet?

Digital wallets manage digital credentials, assets, or authorizations. The most familiar digital wallet is probably Apple Wallet, which hundreds of millions of people use to store and use virtual credit cards and event tickets. For the growing number of states leading the shift towards digitizing identification documents, the most important role of digital wallets is storing and controlling users’ state-issued driver’s licenses and, soon, other state-issued identification, certifications, or licenses.

Digital wallets are primarily made for smartphones, where they interface with secure hardware and cryptographic software to ensure that credentials they store are secure and trusted. So it’s natural that the most widely-used wallet software is created by hardware and operating system creators (known as “original equipment manufacturers,” or OEMs) like Google and Apple, the driving forces behind most of the world’s smartphones. They know the hardware, and they have very smart teams.

However, default OEM digital wallets do have disadvantages. If you’re an enterprise or government hoping to give your users (or residents) the full benefit of the transition to digital identity, there are good reasons to build your own digital wallet software rather than relying on OEM wallets to have all the features you need. 

In brief, we believe there are two main reasons for an entity to build its own digital wallet. First, if your brand is highly trusted by end users, as might be the case for a state issuing digital driver’s licenses, building your own can dramatically impact adoption rates. The second major consideration is whether your in-house option would represent a big improvement in usability over the manufacturers’ default option, for instance, in applications requiring highly tailored features. 

The Off-The-Shelf Option

There are many benefits to using an existing OEM wallet. Most clearly, it requires fewer resources from your team, both for development and support. There is already an enormous user base with the Apple or Google Wallet already installed.

Even more importantly, users of the OEM wallets will already be familiar with how to use these wallets and the nuances of the user experience. By the time they use their wallet to present the credentials your organization creates, they will have already used these wallets in their day-to-day lives for shopping or tickets. The “tap to pay” user experience that’s now widespread with phone-based payment apps is a very accessible “on-ramp” for using digital identity credentials, but especially when dealing with vital interactions involving official documents used by nearly the entire population, accessibility is paramount.

Big-name wallets also have privileged access to some of a mobile device’s hardware capabilities.  These can unlock additional, and sometimes important, functionality. That includes advanced security features, such as Near Field Communication (NFC), which can make verification more streamlined. NFC functionality allows for a verification interface to quickly pop up as a user holds their smartphone close to a verifier’s reader device, rather than requiring the user to open a separate application to initiate a verification interaction. This can make certain user interactions faster and more seamless for end users. Currently, this functionality is only supported for OEM wallet implementations or those who receive special permissions from the OEM providers to implement them in applications.

There are also convenience or security features that might only be possible for software created by device manufacturers themselves, such as letting users present a credential when a phone is locked or making certain credentials usable even when a device battery is nearly empty. For credentials that might be vital in unexpected or unusual circumstances, such as medical certifications, these features could trump other considerations.

The Advantages of an In-House Digital Wallet Design

In some cases, the advantages of manufacturer software may be outweighed by the greater flexibility, hands-on support, and tailoring to specific use cases made possible by wallet software designed specifically for your users.

Above all, creating your own wallet software is the best way to ensure you can give users exactly the features and experience they want, quickly, in an appealing, easy to use, and trusted package. Longer term, controlling your own software also increases your ability to build a relationship with your end users and get the most out of advances in digital identity, instead of being beholden to the product roadmaps of large technology companies.

The biggest tech companies, remember, serve an immense user base, and outside requests for changes or updates are handled by a comparatively small product management team. If you find your wallet needs a specific feature not already offered by an off-the-shelf wallet, you and your users could be waiting for request updates behind hundreds of other priorities.

The ability of large tech companies to serve such a huge and diverse customer base relies on “App Stores” that offer independently-developed apps. The built-in assumption is that when a smaller group of users have highly specific needs, someone will build a tailored solution for them.

That matters because current OEM wallets are designed for a generic baseline user, and only have a fraction of the functionality that digital credential systems will make possible. Most notably, wallets from big tech companies currently only support a limited subset of the credentials that can be issued digitally.

There are also significant nuances to how a digital wallet communicates with credential providers, secures user information, and handles various identity formats, which have downstream impacts on security and user experience. In the case of government identity systems, that can impact the ability to link additional digital services to an identity credential, or to control processes like renewing digital credentials.

Wallets may also need different security standards depending on their application – a pass to a secure corporate facility is generally more sensitive than a concert ticket. So a highly secure corporate entity is likely to want to build its own wallet, with more rigorous onboarding. A consumer-focused app for concert tickets, by contrast, might want a less rigorous process that prioritizes ease of use. Some digital wallets may even want to incorporate “decentralized” identity signals like social media accounts for lower-security or community-based verifications.

Data policy is another reason to consider a home-grown wallet solution. The State of California collaborated with SpruceID to create its own digital wallet software, which, among other benefits, allowed them to create a user privacy policy different from the big tech companies’ standard agreement. In some cases this might be necessary to fully comply with local privacy regulations. It may also have benefits for user adoption: some users may be skeptical of the privacy practices of large conglomerates and more likely to trust a wallet created by an official body.

Many of these nuances must be implemented in the wallet software itself, whether specific user-facing interactions or back-end architecture. However, it’s difficult to push for any specific changes or features from a big tech company. Even if you’re representing the government of a sizable state, it's like trying to steer a massive aircraft carrier; it takes significant effort and time to change direction even if there is mutual interest.

Flexibility for a Dynamic Ecosystem

The direct advantages of building your own digital wallet are significant and can be expected to lead to better features, higher trust, more adoption, and more satisfied users than relying on OEM software. However, owning the development process grants another, potentially even more important advantage: helping ensure that your team and users can support the latest advancements in digital credential technologies across different industries, and not just the ones that make it to mass-market deployment via OEM wallets.

For example, state DMVs largely favor the “mobile driver’s license” family of digital credential standards (ISO/IEC 18013-5 mDL), and OEM wallets also privilege the mDL standard. But many educational institutions, for example, prefer the OpenBadges standard by the 1EdTech educational consortium, an alternative format built on the W3C’s Verifiable Credentials. Numerous other use cases are built using W3C Verifiable Credentials, such as Microsoft’s Entra Verified ID product, C2PA for content authenticity (a specification supported by Adobe, OpenAI, and Google), and GS1’s digital supply chain integrity efforts. Further, the EU Digital Identity efforts include SD-JWTs.

The downsides are on the other side of the coin: it is not the most economical nor convenient option for the organization to own the development of a digital wallet. Today, it takes managers with an understanding of emerging digital credential technologies, and vendors with specialized skill sets to make it happen well. This is one reason why we build open source software to allow any organization to build a wallet on a strong base set of lego blocks.

It’s still early in the development of these tools, and a plethora of solutions are emerging simultaneously. The ability to tailor your in-house wallet to a non-mDL standard is just one example of the flexibility that doing it yourself allows.

Different industries will prefer different ways to handle their exchanges of authentic data, and we believe that the market has progressed to the point where bottom-up development is more likely than “one format to rule them all.” Therefore, those looking to enable functionalities across different industries may need to consider building their own wallets to ensure support for their own use cases, especially if they are cross-vertical. For instance, a shipping authorization that refers to both a cargo truck (supply chain) and its driver (personal identity) could require tailored features. Providing strong support for end-to-end use cases may require integrating many different technologies, something custom software excels at but is less common for stock OEM capabilities.

Setting the Right Priorities

We believe that, ultimately, the decision to use an OEM wallet or to build (or enhance an existing app into) a new one should be based on a few specific factors.

First, program leaders should decide which option provides the most value to end users. So for instance, if a home-grown wallet has the potential to make the end-to-end experience ten times better than an OEM wallet's, that would be a major reason to build your own.

Second, ask which approach best meets expectations for usability, security, and privacy. That can include nuanced technical considerations but also the more basic question of branding. If your user base is more likely to trust a wallet carrying your brand, such as a state government, that might suggest an in-house wallet will drive better adoption.

The third big-picture consideration is whether your solution is sustainable in the long term. For instance, building your own wallet might be a mistake if you can’t guarantee an ongoing budget not only for development, but support and updates for, quite likely, many years to come. When vendors work on the same set of technology standards, there is less lock-in, more competitive pricing, and better parallelization without sacrificing overall interoperability.

At SpruceID, we help governments and enterprises navigate these complex considerations, and our products simplify this whole process. If you’d like to discuss a specific use case for digital wallets, and would like us to weigh in on using OEM or building your own, please schedule a chat.

About SpruceID: SpruceID is building a future where users control their identity and data across all digital interactions.