Digital Wallet App Development

iOS and Android wallet apps with the core payment capabilities: wallet funding via bank transfer (ACH pull via NACHA ACH network or real-time push via The Clearing House RTP network or FedNow), debit card top-up (via Stripe or Adyen card processing), and balance management with a ledger that records every credit and debit with idempotency keys to prevent duplicate transaction records.

Peer-to-peer payments via phone number, QR code, or wallet ID settle against the internal ledger and, where the counterparty is on the same platform, complete in real time without touching an external payment rail. For cross-platform P2P, the disbursement goes out via RTP for near-instant settlement (typically under 30 seconds) or ACH for next-business-day settlement when the recipient's bank isn't on the RTP network.

NFC contactless payments at the point of sale are handled via Apple Pay (Apple Pay JS and PassKit on iOS) and Google Pay (Google Pay API on Android), which tokenise the underlying card or wallet balance using the device's secure element so the merchant's terminal never sees the actual card number. Biometric authentication (Face ID, Touch ID, or Android BiometricPrompt) is required for payment confirmation, with cryptographic keys stored in the iOS Secure Enclave or Android StrongBox hardware security module -- not in app memory or file storage. Spending analytics powered by Plaid Transactions API categorise transactions automatically so users see their spending by category without manual tagging.

Wallets that hold and transact in multiple currencies: multi-currency ledger design with separate balance buckets per currency, real-time FX rate feeds from the European Central Bank (ECB) reference rate API or Open Exchange Rates API, with your configured spread applied on top. Currency conversion can happen at the moment of transaction (live rate shown to the user before confirmation) or held at the time of deposit and converted on withdrawal -- the model depends on your FX risk management approach.

Cross-border payment rails include SWIFT for international wire transfers, SEPA Credit Transfer and SEPA Instant for euro-zone payments, and local real-time payment systems (Faster Payments in the UK, UPI in India, PIX in Brazil) where your payment provider supports them. FX spread management is configured per currency pair and per customer tier if you offer preferential rates to premium users.

Transparent FX pricing shows the mid-market rate, your spread, the resulting exchange rate, and the total amount the recipient will receive before the user confirms the transfer -- a regulatory requirement in many jurisdictions and a trust signal that reduces transfer abandonment. For BaaS-based implementations, multi-currency accounts are typically provided through partners like Synapse, Treasury Prime, or Unit, which offer FDIC-insured pass-through accounts that hold customer funds at partner banks while your platform manages the multi-currency layer above them. Compliance with cross-border payment regulations -- including FinCEN money transmission rules in the US and EMI regulations in the UK and EU -- is documented during the architecture stage.

Digital wallets linked to prepaid card programmes are built through card programme managers (CPMs) that hold the card network relationships and issuing bank licences. We integrate with Marqeta (preferred for flexible spend control APIs), Lithic (strong for developer-first card issuance), Stripe Issuing, Galileo, or i2c depending on your jurisdiction and programme complexity. The CPM provides BIN (Bank Identification Number) sponsorship through a partner issuing bank.

Virtual card issuance delivers card credentials -- PAN, CVV, expiry -- to the wallet app in seconds after onboarding, encrypted and stored using PCI DSS-compliant tokenisation so the actual card number is never stored in the wallet app's local storage. Physical card ordering triggers the CPM's card manufacturing and fulfillment flow. Card controls exposed in the wallet app include spend limits per transaction and per period, merchant category code (MCC) blocking to restrict spend by category, geographic restrictions, and card freeze and unfreeze.

Real-time card transaction authorisation works via a webhook from the CPM to your backend for each card-present and card-not-present transaction. Your backend applies your own spend control rules and returns an approve or decline response within the authorisation timeout window (typically 2 seconds). This is the mechanism for enforcing complex spend rules that go beyond what the CPM's native controls support. PCI DSS card data handling compliance is maintained throughout: card data is never written to your servers, all tokenisation uses the Stripe/Marqeta/Lithic token vault rather than custom encryption, and card display in the wallet app uses the CPM's secure card display SDKs.

Wallets for digital assets split into two custody models with very different security and regulatory profiles. Non-custodial wallets generate and store private keys client-side using the iOS Secure Enclave or Android StrongBox hardware security module, with the 12 or 24-word BIP-39 seed phrase as the backup mechanism. The user has full self-sovereign control of their assets; the platform operator cannot access or freeze funds. Multi-chain support covers Ethereum and all EVM-compatible chains (Polygon, Arbitrum, Base, BNB Chain), Bitcoin via native SegWit addresses, and Solana, with token portfolio display assembled from on-chain balance queries.

Custodial wallets use institutional key management infrastructure: HSM (Hardware Security Module) custody for smaller programmes or MPC (Multi-Party Computation) custody via Fireblocks or Copper for institutional-grade key security where no single party holds a complete private key. This model is required for regulated custodial asset service providers and is operationally simpler for consumer products where users are unlikely to manage their own keys safely.

Send and receive flows include address validation against the target network's address format, transaction fee estimation from the current network gas price or fee market, and swap integration via DEX aggregator APIs (0x, 1inch) for EVM chains. Fiat on-ramp integration uses providers like MoonPay, Transak, or Ramp Network for card-to-crypto purchases without building a fiat processing relationship. Off-ramp to bank account uses the provider's off-ramp API. Regulatory compliance covers VASP registration requirements in your operating jurisdiction and FATF Travel Rule compliance for transfers above the reporting threshold (typically 1,000 USD equivalent).

Wallet KYC onboarding that meets regulatory requirements without killing conversion is built around tiered verification: a light KYC tier (name, email, phone number) allows access up to a low transaction limit, while full KYC (government ID document + liveness check) is required to unlock higher limits. This tier structure means the majority of new users can transact immediately while the compliance team completes enhanced verification in the background for users who need full limits.

Document verification and identity proofing uses Jumio, Onfido, or Persona -- all three support government ID OCR, document authenticity checks, and biometric liveness detection via a selfie video or challenge-response test that defeats photo and video spoofing. The selected provider depends on your geographic coverage requirements and budget. Verification results are returned via webhook with the decision and the specific failure reason when a document is rejected.

OFAC sanctions screening and PEP (Politically Exposed Person) screening runs at onboarding against the identity data collected during KYC, and on a scheduled re-screen basis for existing users as sanctions lists update. Risk scoring assigns each user a risk tier based on their verification data, transaction patterns, and geographic location. High-risk users trigger enhanced due diligence workflows. Ongoing transaction monitoring applies velocity rules and pattern detection to flag anomalous activity for review. SAR (Suspicious Activity Report) workflow handles the regulatory filing process when a flagged transaction requires reporting to FinCEN (US) or the relevant equivalent authority in your jurisdiction.

Wallet security beyond authentication starts with device binding: the wallet is associated with specific registered devices, and a new device login triggers a re-verification step (SMS OTP plus biometric re-enrollment) before payment capabilities are available. Private keys for biometric authentication are stored in the iOS Secure Enclave or Android StrongBox and are bound to the device hardware -- they cannot be extracted and used on a different device even if the device storage is compromised.

Transaction velocity rules enforce limits per day, per transaction, per merchant category, and per counterparty, with separate limits per KYC tier. These rules are configurable by the operations team without a code deployment. Behavioural analytics build a baseline of normal transaction patterns per user (typical transaction amounts, common counterparties, usual time-of-day) and trigger step-up verification when a transaction deviates significantly from that baseline.

Real-time fraud scoring via Sardine, Sift, or Stripe Radar evaluates each transaction and onboarding event against cross-platform fraud signals, device fingerprints, and velocity data before the transaction is authorised. Sardine is particularly well-suited to fintech wallets given its focus on financial fraud patterns including account takeover and payment fraud. Dispute management workflow handles the customer-initiated dispute process: the transaction is flagged, the details are captured, and the dispute is routed to the operations team for review and to the payment processor for chargeback initiation if warranted. The security layer is designed to keep the wallet safe for legitimate users rather than maximising friction across all transactions -- the goal is accurate fraud detection, not blanket restrictions.