Mobile Wallet App Development

A mobile wallet app is not simply a digital card holder. At the engineering level it is a payment credential management system, a tokenisation client, an NFC communication stack, and a transaction processing interface, all wrapped in a consumer UX that needs to work reliably in high-latency mobile environments where users expect payments to clear in under a second.

The market is dominated by Apple Pay, Google Pay, and Samsung Pay for device-level tap-to-pay. But the meaningful engineering work in this space is being done by banks, FinTechs, and marketplaces building proprietary mobile wallet products: stored-value accounts with P2P transfer capability, branded wallets embedded in super-apps, and digital-first payment experiences for underbanked populations who never had plastic cards to begin with.

Scrums.com provides dedicated engineering squads for mobile wallet development. Our teams have built payment credential management systems, contactless payment integrations, and wallet-embedded P2P transfer flows for regulated financial institutions and FinTech companies. Read about the digital investment platform we built for JamiiPesa in Kenya as a reference point for wallet-embedded financial products in emerging markets.

Mobile Wallet Architecture

A production mobile wallet involves several distinct technical layers that need to be designed as an integrated system, not as separate features bolted together:

Payment Credential Management

The wallet's core function is managing payment credentials: card numbers (PANs), network tokens, stored-value account balances, and loyalty card identifiers. Network tokenisation (Visa Token Service, Mastercard MDES) replaces PANs with device-specific tokens that can't be replicated on another device, reducing card-not-present fraud significantly. Token provisioning flows require integration with card issuer APIs and network token service providers, which involves asynchronous flows, identity verification steps, and yellow path handling for cases where provisioning fails.

NFC and Contactless Payment Stack

For tap-to-pay functionality, the wallet needs to communicate with NFC readers via HCE (Host Card Emulation) on Android or through the Secure Element on iOS (via Apple Pay NFC passthrough). HCE wallets implement the EMVCo contactless specification directly in software. The cryptographic operations required for each tap (generating Application Cryptograms, handling Card Verification Methods) need to execute in under 500ms for a smooth tap experience, which creates strict performance requirements on the cryptographic library and key management layer.

P2P Transfer Engine

Peer-to-peer payment flows in a mobile wallet require account validation (is the recipient a valid wallet user?), transaction limit enforcement (daily/monthly caps for AML compliance), balance management across funding sources (stored value balance, linked bank account, card on file), and real-time notification to both sender and recipient. Idempotency is critical: a user who taps 'Send' twice during a network delay should not end up sending the payment twice.

Funding Source Integration

Wallets need to support multiple funding sources: bank account via ACH/Open Banking, debit/credit card via card processor, and stored value top-up. Each funding source has different latency (card top-ups are instant; ACH takes 1 to 3 business days), different failure modes (card declined, bank account insufficient funds), and different regulatory treatment for AML purposes. The wallet UI needs to handle all these cases without confusing the user.

Mobile Wallets in Emerging Markets

The most technically interesting mobile wallet engineering problems are being solved in markets where cards were never the primary payment method. In Sub-Saharan Africa, South and Southeast Asia, and parts of Latin America, mobile wallets are primary financial accounts rather than a card replacement layer. Users store wages, receive remittances, pay utility bills, and access credit entirely through wallet apps.

These wallets have different engineering requirements: offline transaction queuing for low-connectivity environments, USSD fallback for feature phones, interoperability with mobile money schemes (M-Pesa, MTN Mobile Money) via API bridges, and regulatory compliance with central bank e-money regulations rather than card scheme rules. The fraud and AML patterns are also different: SIM swap fraud and agent network abuse are more prevalent than the card-not-present fraud patterns that dominate European wallet risk models.

Our work on the JamiiPesa digital investment platform and experience with financial institutions regulated by the Central Bank of Kenya and South African FSCA gives Scrums.com teams direct experience with these engineering and regulatory requirements. Explore our broader FinTech engineering capabilities for context.

Mobile wallet apps like these are built and delivered by dedicated engineering teams through our mobile app development service.

Mobile Wallet Platform Types We Build

Different business models need different wallet architectures. Scrums.com engineering teams have delivered across five platform categories:

Bank-Issued Digital Wallet

A bank's proprietary mobile wallet: payment card tokenisation (Visa/Mastercard network tokens), NFC tap-to-pay via HCE or Apple/Google Pay passthrough, P2P transfers between bank customers, and bill payment integrations. PSD2 SCA-compliant authentication. Integration with the bank's core banking system for real-time balance and transaction data. Key compliance: PCI-DSS for card credential storage, PSD2 for payment initiation, GDPR for biometric authentication data.

Standalone FinTech Wallet

Stored-value wallet regulated as an e-money product (FCA EMI licence, EU PSD2 e-money licence). Open banking-powered bank account top-up, card top-up via Stripe or Adyen, and wallet-to-wallet P2P transfers. Debit card issuance via Marqeta or Galileo. AML/KYC onboarding integrated with identity verification providers (Jumio, Onfido). This is the architecture behind challenger bank-adjacent products.

Super-App Embedded Wallet

Payment wallet embedded within a non-payment host app (ride-hailing, e-commerce, food delivery). The wallet holds user balance for in-app purchases and enables P2P splitting of shared costs. Regulatory challenge: the host app company typically needs a payment institution licence to hold stored value on behalf of users. BaaS infrastructure (Railsbank, Modulr, Solarisbank) is commonly used to provide the regulated e-money infrastructure without the host company needing its own licence.

Merchant-Branded Loyalty Wallet

Closed-loop wallet that holds a single brand's stored value (gift card balance, loyalty points, prepaid credit). Lower regulatory burden than open-loop e-money wallets in most jurisdictions. Integration with POS systems for in-store redemption, QR code payment, and push notification campaigns for promotional balance top-ups. Explore our dedicated engineering team model for how we staff these builds.

Emerging Market Mobile Money Wallet

Wallet designed for mobile-first markets: USSD fallback for feature phone access, offline transaction queuing, agent network cash-in/cash-out integration, and interoperability with mobile money schemes via API. Compliance with central bank e-money regulations. Our payments compliance platform case study and JamiiPesa case study cover this territory.

Technology Stack for Mobile Wallet Development

Mobile wallet development requires deep integration between mobile platform APIs, payment network SDKs, and backend financial services. The stacks our teams deploy:

Mobile Layer

React Native for cross-platform consumer wallets where shared codebase reduces maintenance overhead. Swift (iOS) and Kotlin (Android) for native builds where NFC performance, Secure Enclave access, and biometric authentication integration require platform-native APIs. The HCE (Host Card Emulation) payment stack on Android is Java/Kotlin; React Native bridges to native modules for this. iOS NFC passthrough (for Apple Pay integration) uses PassKit framework.

Tokenisation and Credential Management

Visa Token Service (VTS) and Mastercard MDES APIs for network token provisioning and lifecycle management. Token cryptogram generation using EMVCo contactless cryptographic specs. Key management via HSM (Hardware Security Module) in a PCI-DSS-compliant CDE. HashiCorp Vault for application-layer secret management outside the CDE.

Backend Services

Spring Boot (Java/Kotlin) for wallet core services (balance management, transaction ledger, token lifecycle). Node.js for BFF (Backend for Frontend) services and real-time notification routing. Apache Kafka for transaction event streaming to downstream services (AML monitoring, analytics, push notification pipeline). PostgreSQL for OLTP wallet data; Redis for balance cache and idempotency key storage.

Infrastructure

AWS or Azure in multi-AZ active-active configuration. AWS SQS/SNS or Azure Service Bus for push notification fan-out to APNs and FCM. WAF and DDoS protection via Cloudflare or AWS Shield: consumer-facing wallet APIs are high-value targets for credential stuffing and enumeration attacks. Explore the FinTech platform reliability case study for the infrastructure patterns our teams apply.

Compliance and Integration Considerations

E-Money Regulation

A mobile wallet that holds user balances is an e-money product in most jurisdictions and requires e-money institution (EMI) authorisation (FCA in the UK, NCB in each EU member state under PSD2). EMI authorisation requires safeguarding of customer funds in segregated accounts, operational resilience policies, and AML/KYC programme documentation. The engineering implications: your wallet ledger needs to support the reconciliation of safeguarded float against aggregate customer balances at all times.

AML and Transaction Monitoring

Mobile wallets are high-risk channels for money laundering: anonymous top-ups, rapid P2P transfers, and cash-out via ATM or agent networks. Transaction monitoring rules need to cover velocity checks, structured transaction patterns, and unusual geographic patterns. Sanctions screening on P2P transfers needs to cover both sender and recipient. SAR filing workflows integrated with your national FIU. These are engineering deliverables built into the transaction pipeline, not compliance documents created after launch.

PCI-DSS for Credential Storage

Any wallet component that stores or processes PANs or network tokens with cryptographic key access falls within PCI-DSS scope. The scope reduction strategies that matter most: network tokenisation (so your wallet stores network tokens, not PANs), Secure Enclave storage for cryptographic keys on the device (so PAN-equivalent data never leaves the device), and the HCE architecture pattern. See our PCI-DSS software delivery guide for full engineering detail.

GDPR and Biometric Data

Biometric authentication data (fingerprint hashes, face geometry) used for wallet authentication is special category data under GDPR. It must be processed under explicit consent, stored only on-device (not in your backend), and subject to a DPIA (Data Protection Impact Assessment). The engineering pattern: biometric verification happens on-device via the Secure Enclave and the result (authenticated/not authenticated) is what your backend sees, not the biometric data itself. Connect with our team via the FinTech solutions page.

Frequently Asked Questions

How long does mobile wallet app development take?

A consumer mobile wallet with stored value, P2P transfers, and card top-up typically takes 9 to 14 months to build and launch, including the EMI authorisation process (which runs in parallel). Adding NFC tap-to-pay via network tokenisation adds 3 to 5 months for Visa/Mastercard token service integration and certification. Scrums.com dedicated teams mobilise within 21 days.

Do we need an e-money licence to build a mobile wallet?

If your wallet holds user balances (stored value that users can spend), you need an e-money institution (EMI) licence in the UK and EU, or equivalent authorisation in other markets. If your wallet only passes payments through in real time without holding balances, a payment institution (PI) licence may be sufficient. If you're building a closed-loop branded wallet (gift cards, loyalty points in your own ecosystem), the regulatory requirements are typically lower but vary by jurisdiction. We'll advise on the right structure before starting the build.

How does network tokenisation work in a mobile wallet?

Network tokenisation replaces a card's PAN (Primary Account Number) with a device-specific token issued by Visa Token Service or Mastercard MDES. The token is bound to a specific device and merchant (or wallet) and can't be used on another device or for a different merchant. When a user taps to pay, the wallet generates a one-time cryptogram using the token and a transaction-specific key, which the card network validates. The PAN never leaves the issuing bank's systems, so a token compromise doesn't expose the underlying card.

Can you build for both Apple Pay and Google Pay integration?

Yes. Apple Pay integration uses PassKit for card provisioning and NFC passthrough, where Apple handles the NFC communication and your wallet provides the credential via Apple's Wallet API. Google Pay uses HCE (Host Card Emulation), where your wallet app directly handles the NFC communication stack. They require separate integration paths, separate scheme certification, and different UX patterns. Both can be supported in the same product, which is standard for bank-issued digital wallet apps.

How do you handle fraud in a mobile wallet?

Mobile wallet fraud patterns cluster around account takeover (credential stuffing, SIM swap), P2P payment fraud (social engineering the legitimate user), and card-not-present fraud using enrolled compromised cards. Mitigations include: device fingerprinting and anomaly detection on new device registrations, velocity checks on P2P transfers, step-up authentication for high-value or high-risk transactions, and card verification at enrolment (Visa Account Verification, Mastercard Identity Check). Explore our dedicated engineering model for how we embed these controls from day one.