Building a wallet people actually tap

What does mobile wallet app development actually involve?

Mobile wallet app development is mostly not app development. The user-facing build (card list, tap screen, transaction history) is the small part. What sets the budget and the schedule is credential handling: provisioning cards as network tokens, passing the certifications that let a phone speak to a payment terminal, and standing up the compliance perimeter (PCI DSS scope, KYC and AML checks, data residency rules) before a single live card is loaded.

The scale explains the interest. About 4.4 billion people now use a digital wallet, up from roughly 3.4 billion in 2023, with forecasts pointing to 6 billion by 2030.¹ Industry aggregators put mobile wallet payment value on track for USD 10 trillion, already carrying the majority of online purchase value.²

Two decisions set everything downstream: whether the wallet holds value or only holds credentials, and whether it is a product in its own right or a feature inside something larger. Both are answered below.

Digital wallet or mobile wallet: what is the difference?

A digital wallet is any software store of payment credentials, including browser and server-side wallets. A mobile wallet is the subset that lives on a phone and can pay in the physical world, normally over NFC. The distinction is not pedantic. The moment a wallet claims tap-to-pay it inherits secure hardware dependencies, scheme certification and an app store review path that a browser-only wallet never touches.

Three product shapes sit under the same label, and their cost profiles are not comparable.

Most teams who say they want their own Apple Pay mean the first row. It is the cheaper path, the faster path, and usually the correct one. The second row changes the company, not just the product: holding customer funds makes you a regulated entity in every market you serve.

Why tokenization, not encryption, is the core of wallet security

Tokenization replaces a card number with a surrogate value that has no mathematical relationship to the original. Encryption is reversible with the right key. A network token is not reversible at all, because the mapping between token and real account number lives only inside the card network’s vault. A complete breach of your database therefore yields strings that cannot be spent outside the device, merchant or transaction context they were minted for.

In practice the flow runs like this. The user adds a card. Your app, acting as a token requestor, asks the network’s token service to issue a device-bound token. The issuer approves, sometimes after a step-up check. Your systems then store the token reference and a set of keys, never the account number. That single architectural choice is what keeps most of your infrastructure out of PCI DSS scope, which is worth more than any point security control you could buy.

The volumes behind this are no longer experimental. Visa has issued more than 10 billion tokens since 2014, generating over USD 40 billion in incremental global e-commerce value, and reports USD 650 million of fraud avoided in a single year through tokenized transactions.³ Tokenized transaction counts are projected to roughly double, from 283 billion in 2025 to 574 billion in 2029.⁴

Tokenization is a revenue argument as much as a risk argument, which is how it should be sold internally. Network tokenization is associated with a 3% to 6% increase in authorization rates, and Visa has reported a 4.6% lift for tokenized card-not-present credentials against non-tokenized ones.⁵ Industry analysis credits EMV and tokenization with cutting card-present fraud by 87% and digital payment fraud by 67% since adoption became widespread.⁶ Coverage keeps widening: tokenization is expected to reach 85% of global ecommerce transactions by 2028.⁴

Successful wallets rarely try to replace the card rails. They win by being the best token requestor and the best interface on top of rails that already work, because replacing those rails means becoming a licensed money transmitter in every jurisdiction you operate in.

How does tap-to-pay work, and what actually slows it down?

Tap-to-pay is a short-range NFC exchange. The phone and the terminal establish a link within a few centimetres, the wallet presents a tokenized credential plus a one-time cryptogram, and the terminal routes that to the acquirer as an EMV contactless transaction. On iOS the credential is held in the Secure Element. On Android, Host Card Emulation lets the application present the credential from software, with keys protected by the platform and limited-use keys refreshed from your server.

The mechanism is well documented and rarely the problem. The schedule risk is procedural. In practice, Host Card Emulation certification and per-network token requestor onboarding with the card schemes routinely add eight to twelve weeks, and almost no published cost estimate accounts for that time. Teams who treat certification as a launch-week formality lose a quarter. Run it as an engineering workstream that starts in month one, in parallel with the mobile engineering build rather than after it.

A related question comes up in every kickoff: is Apple Pay or Google Pay integration required? No. A wallet can run independently for online payments, in-app payments and closed-loop acceptance. But for broad in-store acceptance on iOS, going through Apple’s payment framework is the practical route, and that constraint belongs in the roadmap before the design phase rather than after it.

Which digital wallet features matter in 2026?

Feature checklists age badly. The ones that still separate wallets are tied to trust and to frequency of use.

• Instant provisioning. A card that takes three screens and an SMS code to add loses users at the first step. Push provisioning from the issuer app is the benchmark to design against.
• Biometric entry, correctly framed. Around 80% of digital wallets globally used biometric authentication in 2025⁷, and biometrically authenticated remote mobile payments are forecast to grow 383% between 2022 and 2027, reaching 39.5 billion transactions.⁸ Treat biometrics as a speed layer on top of tokenization and device attestation, not as a security control in itself. The match normally happens locally on the device and the biometric never travels.
• Spend controls and instant freeze. The cheapest trust feature in the product. Users judge safety by what they can switch off themselves.
• Passes beyond payment. Tickets, loyalty and access credentials raise open frequency without adding licensing. Wallet passes have become a standard channel for ticketing and venue access.
• Real-time fraud scoring. Device, velocity and location signals scored at authorization catch what static rules miss. This is where applied AI earns its place in a wallet, well ahead of any chat interface.
• Honest failure states. Declines, weak connectivity and expired tokens are the moments that decide retention. Design those screens first, not last.

Should the wallet be standalone or a super-app module?

The super app market was estimated at USD 114 billion to USD 127 billion in 2025, with projected growth of 20% to 30% a year into the early 2030s.⁹ Gartner has estimated that by 2027 more than half the global population will use multiple super apps daily.¹⁰ Numbers like those pull a lot of roadmaps toward bundling.

Read the super app question as a distribution decision before a product decision. Super apps work where one platform already owns daily-habit traffic: messaging, ride-hailing, food delivery, marketplace commerce. The wallet monetizes attention that exists already. Bolting wallet features onto a low-frequency application, an annual insurance renewal or a quarterly B2B portal, does not reproduce that effect. It only adds a compliance surface to a product that was never built to carry one.

A workable test: if your app is not opened at least weekly by a majority of active users, build the wallet as a focused standalone product, or embed it with a partner who already has the traffic.

What does mobile wallet app development cost, and how long does it take?

Development agency estimates put a basic mobile wallet at roughly USD 25,000 to USD 60,000, with mid-market and enterprise builds running USD 70,000 to USD 250,000 or more, over a 3 to 12 month timeline.¹¹ Treat those figures as the software line only.

Four costs sit outside almost every quote.

1. Certification and network onboarding, the eight to twelve week lead time above, which is priced in team months rather than as a fee.
2. PCI DSS assessment, plus the architecture work needed to keep card data out of scope in the first place.
3. KYC and AML tooling and the operations people who work the alerts. This is a recurring cost, not a project cost. Teams who have shipped under HIPAA will know the pattern from building compliant apps in healthcare, where control design, not feature count, sets the timeline.
4. Support and dispute handling. Payments generate contact volume that unfunded roadmaps quietly ignore.

The global mobile wallet market itself was valued near USD 12.85 billion in 2025, with forecasts around USD 104.69 billion by 2034.¹² Capital is rarely the constraint on these programmes. Sequencing is.

A build sequence that removes the usual surprises

Order the work so the slowest external dependency starts first.

1. Decide the wallet type and the jurisdiction map. Licensing scope follows from this and from nothing else.
2. Open token requestor conversations with the card networks in week one, before the design sprint.
3. Set the token and key architecture before any screen design, so PCI scope is chosen deliberately rather than inherited.
4. Build provisioning and authentication end to end on one card scheme, prove it, then add schemes.
5. Certify contactless while the rest of the application is still in build.
6. Instrument declines, provisioning drop-off and fraud outcomes from day one. In month two these are the only metrics that matter.

Most teams weighing a full wallet against a lighter payments integration are better served by a two-week architecture review than by a discovery phase. If that is where you are, talk to our engineering team.

Written by the group's editorial team with the practice leads who run these builds. Reviewed before publish. Spotted an error? Tell us and we will fix it.