Enterprise Systems
Digital Wallet Development Services
A wallet holds money, and holding money is a regulated activity. We build the engineering (the ledger, the payment integration, the security), on top of a licensed provider, so you take payments without trying to become a bank. The licence and the financial advice come from elsewhere; we say so up front.
What Digital Wallet Development means in practice
Who it’s for: Fintech and platform teams building an e-wallet, stored-value or in-app payments product who want payment engineering done correctly and PCI-safely, built on a licensed provider so they take payments without becoming a regulated entity, with an honest account of where the engineering ends and the licence begins.
A digital wallet looks like a simple idea (a balance, a way to add money, a way to spend it), and it is one of the least forgiving things a team can build. Money is not like other data: a transaction that posts twice, a balance that drifts by a penny, a refund that fires against the wrong account, these are not bugs you patch quietly next sprint. They are money leaving the business, a regulator’s attention, and a customer who no longer trusts the app. We build wallets as if every one of those mistakes is irreversible, because most of them are.
The harder truth, and the one we lead with rather than bury, is that a wallet lives inside a heavy regulatory frame. Storing customer funds, moving money between people, issuing stored value: in the UK and EU these are regulated activities that require an e-money or payment-services licence, or a partnership with a firm that holds one. That means FCA authorisation or an authorised partner, KYC and AML checks, and safeguarding of customer money kept separate from your own. For almost every company we work with, the right answer is to build on top of a licensed provider or processor rather than to become a regulated entity yourself. We will tell you which side of that line your product sits on before we write anything.
What we do is the engineering: a correct, auditable ledger; integration with payment processors, card networks and banking rails; PCI-safe handling of card data through tokenisation and hosted fields so raw card numbers never touch your servers; strong authentication and encryption; and fraud controls that hold up under real traffic. What we do not do is give you the licence, act as your compliance function, or offer financial or legal advice: those come from your provider, your lawyers and your regulator. A wallet succeeds on the strength of the code and the partnerships together, and we are blunt that both have to be right.
What you get
- A double-entry ledger as the source of truth for every balance and movement, auditable, reconcilable and built so money can never be created or lost by a code path
- Integration with your chosen payment processor, card networks and banking rails for top-up, withdrawal, card and account payouts, and settlement
- PCI-safe card handling through tokenisation and hosted fields, so raw card data never lands on your infrastructure and your PCI scope stays small
- Peer-to-peer and in-app payment flows with idempotency and clear reversal paths, so a retry or a network drop never double-charges or double-credits
- QR payments, loyalty and stored-value mechanics where the product needs them, built on the same ledger rather than bolted on beside it
- Strong authentication, encryption at rest and in transit, and a key-management design that treats payment keys as the crown jewels they are
- Fraud detection and transaction monitoring wired to your risk profile, plus the audit logging KYC/AML obligations and any regulator will expect
What Digital Wallet Development does for you
Payments without becoming a bank
Built on a licensed provider, you take payments and hold value through a partner who carries the authorisation and safeguarding, so you ship a product without taking on the cost and burden of becoming a regulated entity yourself.
A ledger you can trust and audit
A double-entry ledger means every balance is explained by the movements behind it, reconciliation is a report rather than a panic, and no code path can quietly create or destroy money. When a regulator or an auditor asks, the answer is already written down.
Card data off your books
Tokenisation and hosted fields keep raw card numbers off your servers entirely, which shrinks your PCI DSS scope and your liability. You process payments without storing the thing that makes a breach catastrophic.
Why teams choose us for Digital Wallet Development
- We tell you where the licence line sits before the build starts, almost always that you should build on a licensed provider rather than seek authorisation yourself, instead of quietly engineering you into a regulated position you did not sign up for.
- Senior engineers who understand that money code is different: idempotent, reconcilable, auditable and defensive by default, not a CRUD app with a balance column.
- We are honest about the boundary: we provide the engineering, and the licence, the compliance function and the financial and legal advice come from your provider, your lawyers and your regulator. We will not pretend otherwise to win the work.
- We operate what we build, so the ledger, the reconciliation and the fraud tooling are our concern after launch, money systems are run, not shipped and forgotten.
What Digital Wallet Development includes
The concrete pieces of work this covers, scoped to what your problem actually needs.
Ledger and balances
A double-entry ledger as the authoritative record of every balance and movement, built so it reconciles against the payment provider’s view and so no operation can create or lose money.
Payment integration
Integration with processors, card networks and banking rails for top-up, withdrawal, payouts and settlement. Stripe, Adyen, open banking and the account-to-account rails as the product requires.
P2P and in-app payments
Person-to-person transfers and in-app purchases built with idempotency and explicit reversal paths, so retries, timeouts and dropped connections never double-move money.
QR and stored value
QR-based payments, closed-loop stored value and loyalty mechanics, implemented on the shared ledger so points, balances and spend all reconcile against one source of truth.
Card handling and tokenisation
Stored payment methods through the provider’s vault and hosted fields, so cards are tokenised and your systems hold references rather than card numbers, keeping PCI scope minimal.
Fraud and transaction monitoring
Risk scoring, velocity limits, strong customer authentication and the transaction monitoring and audit trails that fraud control and AML obligations depend on.
Where it fits
A fintech product with a balance
A consumer or business app where users hold funds, top up, pay and withdraw. We build the ledger and payment engineering on a licensed provider so the regulated parts sit with a partner and the product ships.
Closed-loop and stored value
A brand, marketplace or transit-style scheme issuing stored value or loyalty balance spendable within its own ecosystem, often lighter on regulation than open payments, but still built with a proper ledger and clear rules on what the balance is.
Payments added to a platform
A marketplace or SaaS platform adding wallets, split payments or payouts to sellers. We wire in the provider’s connected-accounts model so funds flow and settle correctly without the platform holding money it is not licensed to hold.
Peer-to-peer transfers
Sending money between users inside an app. We build the transfer flow idempotent and reversible, with the KYC, limits and monitoring the flow of money between people demands.
How we approach Digital Wallet Development
We start with the question that decides everything else: does your product require a licence, and if so, whose? Holding customer funds, issuing e-money and moving money between people are regulated activities, and the answer determines the entire architecture. For almost every company, the sound path is to build on a licensed payment or e-money provider who carries the FCA authorisation, the safeguarding of customer funds and the regulated obligations, while you build the product experience on top. We map that boundary explicitly: what your partner is responsible for, what you are, and where the engineering we build sits, so nobody discovers a regulatory gap after launch. This is the part we are most blunt about, because getting it wrong is not a bug, it is an unlicensed-activity problem.
With the regulatory shape settled, we build the money engine correctly from the first commit. The ledger is double-entry and authoritative; every operation that moves money is idempotent, so a retry cannot double-charge; every balance reconciles against the provider’s record on a schedule, so drift is caught in hours rather than in an audit. Card data goes through tokenisation and hosted fields so it never touches our servers, keys are managed as the sensitive assets they are, and fraud controls are tuned to your risk rather than left at a default. We treat every money-moving path as irreversible and build the guard rails accordingly.
How we deliver a wallet build
We begin with the regulatory and provider assessment, because it determines the architecture and it is where the real risk sits. We work through what your product does with money (holds it, moves it, stores value, pays out), and map that against what is a regulated activity in your market. In almost every case the outcome is a recommendation to build on a specific type of licensed provider, with the boundary drawn clearly: what the provider is authorised and responsible for, what your obligations are, and where our engineering fits. We are explicit that the licence, the safeguarding arrangement and the legal and compliance sign-off come from your partner and your advisers, not from us.
With that settled we build the ledger first, before any user-facing flow, because everything else posts against it. It is double-entry, authoritative and designed to reconcile against the provider’s records from day one. Then we build outward: top-up and withdrawal, stored payment methods through tokenisation, P2P and in-app payments, and any QR, loyalty or stored-value mechanics. Each built idempotent, each posting to the same ledger, each with an explicit reversal path. Everything is developed against the provider’s sandbox with real money flows, so the awkward cases surface in development.
Before launch we exercise the paths that cost money when they break: retries, timeouts, partial failures, refunds against the wrong state, concurrent transfers on the same balance, and reconciliation under a deliberately induced mismatch. We wire in fraud monitoring and audit logging, agree the reconciliation and dispute runbooks with you, and launch under close watch. Because we operate what we build, we stay on to run the ledger and the monitoring rather than handing over a wallet and walking away from the money.
Architecture, payment integration and the ledger
The heart of a wallet is the ledger, and we build it as a double-entry system rather than a mutable balance field. Every movement of money is recorded as balanced entries, so a balance is always the sum of the transactions behind it and can never be edited into a state the history does not justify. Every money-moving operation is idempotent, keyed so that a client retry, a network timeout or a duplicate webhook posts once and only once. This is the single most important architectural decision in a wallet: it is what makes the system auditable, reconcilable and safe against the double-spend and double-credit failures that a naive balance column invites.
Around the ledger sits the payment integration. Top-up, withdrawal, card payments, account-to-account transfers and payouts flow through your licensed provider and the underlying card networks and banking rails, and the provider’s record of what actually moved is treated as the external truth we reconcile against. We build automated reconciliation that compares the ledger to the provider on a schedule and flags any divergence immediately, because a drift between what your system thinks and what actually happened at the bank is the first sign of a real problem. Webhooks and callbacks from the provider are verified, idempotent and never trusted blindly, because a payment state that arrives out of order or twice must not corrupt a balance.
The rest follows the same discipline. Stored payment methods are held as tokens in the provider’s vault, so the wallet references a card without ever storing it. Stored value, loyalty and QR payments post to the same ledger rather than living in a parallel store that can disagree with it. State transitions on a transaction (pending, settled, failed, refunded), are modelled explicitly, so the system always knows what stage money is at and no flow can quietly skip a step. The architecture is built so that the correct answer to “where is this money” is always available and always provable.
Security. PCI, fraud, key management and irreversibility
The first rule of wallet security is to never handle raw card data. We integrate card payments through tokenisation and hosted fields, so the card number is captured directly by the payment provider and your systems only ever see a token. This keeps the sensitive data off your infrastructure entirely and collapses your PCI DSS scope to the simplest self-assessment tier instead of the full obligation that storing card data would impose. The principle generalises: we hold the minimum sensitive data the product actually needs, because the data you never store is the data that cannot be breached.
Payment keys and secrets are treated as the crown jewels. API keys to the provider, signing secrets for webhooks and any encryption keys are held in a managed secret store or key-management service, never in code or configuration, and scoped to least privilege so a compromised component cannot drain an account. Data is encrypted in transit and at rest, strong customer authentication guards sensitive actions, and every operation that touches money is written to an append-only audit log: both because fraud investigation and AML obligations require it, and because in a money system you must always be able to answer exactly who did what and when.
Fraud is a tuning problem that is operated over time, not a switch you flip once. We wire in risk scoring, velocity limits, device and behavioural signals and the provider’s fraud tooling, and calibrate the thresholds to your risk profile: too tight rejects good customers, too loose invites losses and chargebacks. Underlying all of it is the fact that money mistakes are largely irreversible: a payment sent to the wrong account or a balance credited in error cannot always be clawed back. So the system is built defensively (idempotency, confirmation steps on high-risk actions, limits, monitoring and reconciliation), on the assumption that a mistake that reaches production is a mistake that costs real money.
Signs it’s time
- You are building a fintech product where users hold a balance, top up, pay or withdraw, and you need the payment engineering done correctly and the regulatory boundary drawn honestly
- You want to issue closed-loop stored value or loyalty balance and need a proper ledger behind it rather than a number in a database that nobody can reconcile
- You are adding payments, wallets or seller payouts to an existing platform and need funds to flow and settle without your company holding money it is not licensed to hold
- You need peer-to-peer or in-app payments built to move money safely (idempotent, reversible, monitored), rather than a happy-path flow that breaks the first time a network call times out
How we work
We work in short, reviewable cycles against a system you can exercise, but with money code the emphasis is different from ordinary product work: correctness comes before surface area. The ledger and the core money flows are built and hardened first, against the provider’s sandbox with real payment behaviour, so the failure modes that matter show up in development rather than against customer balances.
Nothing about money is left to the happy path. Every money-moving flow is tested for retries, timeouts, partial failures, out-of-order webhooks, concurrent operations on the same balance, and reconciliation under an induced mismatch. We would far rather find a double-credit in a test than in a customer’s balance, so the awkward cases are written as tests and kept as tests, because a regression in payment code is money, not a cosmetic bug.
Because we operate what we build, the wallet ships with the reconciliation jobs, monitoring, alerting and runbooks needed to run a money system, not a handover document. When a reconciliation flags a mismatch or a payment provider has an incident, the people who built the ledger are the people who understand where to look, and they are still on the system.
Technologies we build it with
Chosen per problem, not per fashion. This is the stack we most often reach for on this work.
How we deliver
- 01
Discover
We map the system, the constraints and the business it serves, including the parts nobody documented.
Architecture brief
- 02
Architect
Decisions get made, written down and defended before a line of production code exists.
Decision records
- 03
Build
Short cycles against working software. You see progress in the product, not in a status deck.
Shipping increments
- 04
Operate
Monitoring, incident response and iteration. The system is alive, so the engagement is too.
Runbooks & SLOs
Want a straight answer on Digital Wallet Development?
A short call with a senior engineer, before you write a brief. If Digital Wallet Development is the wrong answer for your situation, we will say so and tell you what we think is right.
What changes
The right regulatory shape
A product built on a licensed provider so the authorisation, safeguarding and regulated obligations sit with a partner, and you take payments without becoming a regulated entity.
A ledger that always balances
A double-entry, reconcilable ledger where every balance is explained and no code path can create or lose money, so an audit is a report you already have, not a scramble.
Payments the PCI-safe way
Card data tokenised and kept off your infrastructure, fraud controls tuned to real traffic, and money-moving paths built to be irreversible-safe by design.
Industries we serve
Domain knowledge changes what gets built. A few of the sectors we know before the first meeting.
How pricing works
- The regulatory and provider shape is the largest driver, because it determines the architecture. Building on a licensed provider (the right path for almost everyone), is a very different piece of work from the (much heavier, and rarely advisable) route of engineering for your own authorisation. We scope the engineering against the shape your product actually needs, and we say plainly when the cheaper, sounder path is to build on a partner.
- The number of money flows moves the cost next. A top-up-and-spend wallet on a single provider is a smaller build than one adding P2P transfers, seller payouts, multi-currency, QR payments and stored-value loyalty: each flow carries its own ledger logic, reconciliation and failure handling. We price against the flows you genuinely need, not a generic tier.
- Fraud, monitoring and compliance-supporting engineering (transaction monitoring, audit logging, KYC/AML integration with your provider’s tooling), add scope in proportion to your risk and regulatory obligations. This is engineering to support your compliance function, not the compliance function itself, and we are clear about that boundary in the scope.
- Ongoing operation is priced separately and honestly, because a wallet is a running money system rather than a project that ends at launch. Reconciliation, fraud tuning, provider changes and incident support are continuous work, and pretending otherwise would be dishonest about what running a payments product costs.
Typical timeline
- 01
Regulatory and provider assessment (1–2 weeks)
We map what your product does with money against what is regulated, recommend the licensed provider model that fits, and draw the boundary between your obligations, the provider’s and our engineering, in writing, before any code.
- 02
Ledger and core flows (3–6 weeks)
The double-entry ledger first, then top-up, withdrawal and stored payment methods through tokenisation, built idempotent and reconciling against the provider’s sandbox from the start.
- 03
Payments, P2P and stored value (3–5 weeks)
Peer-to-peer and in-app payments, QR, loyalty and stored-value mechanics where needed, each posting to the shared ledger with explicit reversal paths and every failure mode tested.
- 04
Security, fraud, launch and operation (2–3 weeks, then ongoing)
PCI-safe configuration, key management, fraud monitoring and audit logging; reconciliation and dispute runbooks agreed; a watched launch, then ongoing operation of the money system.
What working with us actually means
We draw the licence line honestly
Before the build we tell you where regulation bites and, almost always, that you should build on a licensed provider rather than seek authorisation yourself. We will not quietly engineer you into a regulated position. The honest boundary is the most valuable thing we bring.
We build money code as money code
Idempotent, double-entry, reconcilable and defensive by default. Senior engineers who treat a wallet as an irreversible money system, not a CRUD app with a balance column.
Engineering, and we say where it ends
We provide the engineering; the licence, the safeguarding and the financial and legal advice come from your provider and your advisers. We are blunt about that boundary rather than pretending to be your compliance function.
We operate what we build
Reconciliation, fraud tuning and the ledger stay our concern after launch. When a mismatch flags at 2am, the people who built the money engine are the ones who understand it.
How to engage us
Three ways to work with us on this, chosen to fit the problem, not our margin.
- Dedicated team A standing team that works only on your product, in your rituals and your tooling. Best when the roadmap outlives the project. Ongoing product development
- Staff augmentation Named senior engineers embedded into your existing team, reporting into your leads. Best when you know what to build and need capacity. Filling a capability gap
- Software outsourcing A defined outcome delivered end-to-end by an accountable team. Best when you want the result owned, not just the hours filled. Outcome-owned delivery
Related services
Part of Digital Transformation. Other work we do alongside this.
- Digital Transformation (overview)
- ERP Development
- CRM Development
- Business Automation
- Blockchain Development
- IoT Development
- Call Center Setup
- Robotic Process Automation
- dApp Development
- Smart Contract Development
- NFT Development
- DeFi Development
- Augmented Reality
- Virtual Reality
- Metaverse Development
- Firmware Development
- FPGA Design
Common questions
Do we need an FCA licence to build a digital wallet?
Possibly. It depends on what your wallet does with money, and it is the first thing we work through with you. Holding customer funds, issuing e-money and moving money between people are regulated activities in the UK and EU that require FCA authorisation or an authorised partner, plus KYC/AML checks and safeguarding of customer money. For almost every company we work with, the right answer is to build on a licensed payment or e-money provider who carries the authorisation and the safeguarding, so you deliver the product without becoming a regulated entity yourself. We provide the engineering and draw that boundary clearly; the licence itself, and the legal and compliance advice, come from your provider and your advisers, not from us.
Why do you insist on a double-entry ledger instead of a balance field?
Because a wallet is a money system, and money systems have to be provable. A single balance field can be edited into a state its history does not justify, it offers no way to reconcile against what the bank actually did, and it makes double-credits and lost money easy to introduce and hard to detect. A double-entry ledger records every movement as balanced entries, so a balance is always the sum of the transactions behind it, every figure can be traced to its cause, and reconciliation against the payment provider is a routine report rather than a forensic exercise. When an auditor or a regulator asks where a balance came from, the answer is already written down.
How do you keep us PCI compliant when we store payment methods?
By never letting raw card data touch your servers. We store payment methods as tokens held in the payment provider’s vault, and card details are captured through hosted fields directly by the provider, so your systems only ever hold a token that references a card rather than the card number itself. This keeps the sensitive data off your infrastructure and collapses your PCI DSS scope to the simplest self-assessment tier instead of the full obligation that storing card data would trigger. On top of that we manage keys and secrets in a dedicated key store, encrypt data in transit and at rest, and log every action that touches money.
What happens when a payment is sent twice or a transfer fails halfway?
This is exactly the failure we design against from the start, because in a money system it is not a rare edge case, retries, timeouts and duplicate webhooks are normal. Every money-moving operation is idempotent, keyed so that the same request processed twice posts once and only once, and every transfer has an explicit state model and reversal path so a half-completed operation resolves to a correct, provable end state rather than a stuck or duplicated balance. We test these paths deliberately before launch (concurrent transfers, induced timeouts, out-of-order provider callbacks), because money mistakes are largely irreversible and the time to find them is in a sandbox, not against a customer’s balance.
Can you handle our KYC, AML and fraud obligations?
We build the engineering that supports them, and we are precise about the difference. We integrate the KYC/AML and identity tooling your licensed provider offers, wire in transaction monitoring, velocity limits, risk scoring and strong customer authentication, and produce the audit trails these obligations depend on. What we do not do is act as your compliance function or decide your regulatory obligations: those sit with your provider, your compliance team and your advisers. Fraud control in particular is tuned and operated over time rather than configured once, and because we operate what we build, we stay on to adjust the thresholds against real chargeback and dispute data after launch.
Thinking about Digital Wallet Development?
Tell us the problem in your own words, not in requirements. A senior engineer reads it and comes back with a straight view on whether Digital Wallet Development is the right answer here, or what would be.
- 01A senior engineer reads it. Not a form queue, and not an account manager.
- 02We reply either with questions or with a straight answer that we are not the right fit.
- 03If it looks like a fit, a technical call with the person who would actually run the delivery.
- 04Then scope, effort and risk in writing, before anyone signs anything.