Digital Wallet and Virtual Currency for a Network of Consumer Websites
How Business Analysis Canada defined the MVP for a closed-loop digital wallet with virtual currency, single sign-on and one checkout across a network of sites.
- ~3 months of analysis to an agreed MVP scope
- 10 wallet areas defined for the MVP
- 6 touchpoints between the wallet and each site
- 1 account and one balance for every site
Project at a glance
- Client
A European company that runs a network of consumer websites, such as community, marketplace and e-commerce sites. The client's name and product names stay under NDA. - Solution
A closed-loop digital wallet with a dedicated virtual currency. Users buy currency in prepaid packs by card, then spend it on memberships, credits, listings, goods and vouchers anywhere in the network, signing in once with a single account. - Engagement
Business analysis to define the minimum viable product: scope and features, the integration model with every connected site, administration, and compliance requirements - Duration
About 3 months of analysis to a signed-off MVP scope, followed by support during development - Our role
Lead business analysis: stakeholder workshops, glossary, benchmarking, feature definition, integration and impact analysis, non-functional requirements, user stories and acceptance criteria - Confidentiality
Product names, commercial terms, pricing, and the details of the client's network stay confidential. This case study describes the approach and the type of solution, not the client's specific product.
The challenge
What problem was the client trying to solve?
The client's sites had grown up separately. Each one had separate accounts, logins and payment flows, so the network behaved like several unrelated businesses.
- Many logins
Users had to register and sign in separately on every site, with no shared identity. - Card fees
Each site took card payments separately, so small purchases carried card fees and checkout friction every time. - Payment trust
Some users preferred not to enter card details on several sites. A single wallet would hold the payment relationship in one place. - Split revenue
The client wanted to sell memberships, credits, listings, goods and vouchers through one checkout and see all revenue together. - Uneven refunds
Refunds were handled differently on each site, with no single record of what a user had paid or been refunded. - No central admin
Administrators had no central way to suspend accounts, correct balances, review activity or change prices. - Regulatory risk
Holding prepaid value for users raised regulatory questions, so the MVP needed a clear boundary before any build started.
Our business analysis approach
How did we approach the engagement?
How did we approach the analysis?
- Stakeholder workshops
We ran sessions with the founders, the product manager and the teams running each connected site, covering business goals, revenue streams, user journeys and constraints. - Shared glossary
Each site used different words for similar things, so we agreed a glossary first: the currency unit, prepaid packs, vouchers, credits, memberships and the wallet itself. Every later document used those definitions. - Benchmarking
We reviewed established prepaid voucher, game store top-up and gift card models to see how top-up, redemption, balances and refunds usually work, and which patterns users already understand. - Feature definition
We broke the wallet down into a feature tree covering account management, balance, top-up, checkout, transaction history, refunds, account deletion and administration, and agreed which features belonged in the MVP. - MVP boundaries
We agreed what the MVP would not do, such as cash withdrawal and peer-to-peer transfers, and recorded each exclusion with its reason so it could be revisited later. - Integration model
We defined how every connected site would use the wallet for account creation, sign-in and payment, and modelled each flow as a sequence diagram. - Impact analysis for each site
We documented the changes each connected site would need, even though those changes sat with the site teams rather than the wallet team, so no dependency was hidden. - Administration requirements
We specified the back-office functions the operations team would need from day one. - Non-functional and compliance requirements
We set requirements for security, payments, privacy, ledger integrity and auditability, and listed the regulatory questions to confirm with payments counsel. - User stories and sign-off
The MVP was broken into user stories with acceptance criteria, prioritized with MoSCoW and signed off by the product manager as the baseline for development.
Wallet MVP
What did the wallet MVP include?
Account creation
Sign-up with a unique email and username, with options to sign up through an external identity provider.
Single sign-on
One account for every connected site, with sign-in verified by the wallet.
Balance
A real-time view of the user's currency balance.
Top-up
Buying prepaid currency packs by card through the wallet's payment gateway.
Checkout
One wallet checkout for every purchase type in the network: currency packs, memberships, credits, listings, goods and vouchers.
Insufficient balance
A prompt to buy one or more packs when the balance does not cover an order, with the order completing once the top-up succeeds.
Vouchers
Status of vouchers bought and received, showing which have been used and which remain.
Transaction history
A full record of top-ups, purchases and refunds.
Refund requests
Users can request a refund of unused currency from a recent top-up. Refunds are paid back only to the original card, within a set window, and reviewed before approval.
Account deletion
Users can request deletion, with their remaining balance handled under the refund policy first.
Network integration
How did the wallet connect to the rest of the network?
The wallet became both the identity provider and the payment gateway for the network. Each connected site handed users to the wallet for account creation, sign-in and payment, then received a confirmation back.
Touchpoint
What happens
Who changes what
Account creation
A user signing up on any site is sent to the wallet's account creation page, then returned to the site
Each site replaces its existing sign-up with the wallet flow
Sign-in
Sign-in on any site is verified against the wallet's single sign-on
Each site adopts the wallet's sign-in methods, including the external identity provider
Purchase
The user is sent to the wallet checkout with the order details. The wallet checks the balance, takes payment from the balance or offers a top-up, and confirms the result
Each site sends orders to the wallet and waits for confirmation before fulfilling
Entitlement update
After payment, the site updates the user's membership status, credits, listing or order
Each site applies the confirmation from the wallet
Voucher redemption
The participating site applies the voucher as a discount before passing the order to the wallet checkout, and the wallet marks the voucher as used once payment succeeds
Each participating site adds the redemption step, and the wallet records voucher status
Returns
A return on the online store sends the refund back to the wallet balance
The store triggers the refund in the wallet
Changes on the connected sites were documented separately and marked as outside the wallet team's scope, each with a named lead. Features that already existed on those sites and did not touch payments stayed out of scope.
Administration
What did administrators need?
User maintenance
Suspending or banning accounts, with a recorded reason
Activity review
Viewing logs and activity for any user
Refunds
Approving or rejecting refund requests, linked to the original transaction and paid only to the original payment method
Manual adjustments
Correcting balances and memberships, with every adjustment logged and large adjustments needing a second approver
Exchange rate
Updating the currency's euro rate, applied to new pack purchases only and never to existing balances
Pack management
Creating, changing and retiring prepaid packs and their prices
Account deletion
Deleting accounts manually on request, with financial records kept as long as required
Reconciliation
A daily report comparing the ledger with payment provider settlements and connected sites' orders, with an exceptions queue for finance
Payments and compliance
How did we handle payments, ledger integrity, availability and compliance?
A wallet holds users' money in another form, so mistakes cost real money and trust. These requirements were set before any screen was designed.
- Ledger. Every movement of currency is recorded as an immutable ledger entry. Balances are calculated from the ledger, never edited directly.
- Idempotent confirmations. Payment confirmations to connected sites can be retried safely, so an order is never fulfilled or charged twice.
- Card payments. Card data is handled only by the payment provider's hosted fields, keeping the wallet out of PCI DSS card-data scope. Card top-ups use strong customer authentication, such as 3-D Secure.
- Fraud controls. Limits on top-up amounts and frequency, alerts for unusual activity, and the ability to freeze an account while it is reviewed. Refunds go only to the original payment method, which closes the route of topping up with a stolen card and taking the refund elsewhere.
- Privacy. GDPR requirements for consent, data minimization, access requests and deletion, balanced against the need to keep financial records.
- Audit trail. Every admin action, rate change and manual adjustment is logged with who made it and when.
- Daily reconciliation. Each day the ledger is reconciled against payment provider settlements and the connected sites' orders. Any mismatch goes to an exceptions queue for finance to resolve.
- Availability. The wallet sits in every connected site's checkout, so an outage would stop sales across the network. Requirements set an availability target, a status check that sites can call, and what each site does when the wallet is unavailable: orders are held rather than lost, and users see a clear message.
- Regulatory boundary. The MVP was kept closed-loop: the currency can only be spent within the client's network and cannot be withdrawn as cash. The only way value leaves the wallet is a refund of an unused top-up to the card that paid for it. Whether that keeps the wallet within an exemption, such as the limited network exclusion under the EU Payment Services Directive, was listed as a question for the client's payments counsel before launch.
Which BA techniques and tools did we use?
Techniques
- Stakeholder workshops
- Glossary development
- Competitive benchmarking
- Feature decomposition
- MVP scoping
- MoSCoW prioritization
- Context and sequence diagrams
- BPMN process modelling
- Impact analysis
- Business rules analysis
- Non-functional requirements
- User stories with Given/When/Then acceptance criteria
- Requirements traceability
Tools
- Jira
- Confluence
- Miro
- Lucidchart
- Microsoft Word
- Microsoft Excel
Acceptance criteria
What did the acceptance criteria look like?
Insufficient balance at checkout
- Given a signed-in user's balance is lower than the order total
- When they confirm the purchase
- Then the wallet offers packs that cover the shortfall
- And the order completes once the top-up succeeds
- And the connected site receives exactly one payment confirmation
Retried confirmation
- Given a connected site has already been told a payment succeeded
- When the wallet retries the same confirmation
- Then the site does not fulfil the order a second time
Refund of an unused top-up
- Given a user requests a refund of currency from a recent top-up
- And that currency has not been spent
- When the refund is approved
- Then the amount is returned only to the card used for the top-up
- And the currency is removed from the user's balance
Exchange rate change
- Given an administrator updates the currency's euro rate
- When the change is saved
- Then new pack prices use the new rate
- And existing balances and past transactions are unchanged
- And the change is logged with the administrator's name and the time
Account deletion with a balance
- Given a user with a remaining balance requests account deletion
- When they confirm the request
- Then they are shown their balance and the refund options under the policy
- And the account is deleted only after the balance has been handled
Results
What were the results?
- ~3 months of analysis to an agreed MVP scope
- 10 wallet areas defined for the MVP
- 6 touchpoints between the wallet and each site
- 1 account and one balance for every site
A signed-off baseline for the first release, which the development team built from.
A design for one account and one balance across the network, to replace separate logins and payment flows on each site.
- One checkout model for every purchase type, designed to cut the number of card transactions on small purchases.
- A clear MVP boundary, with each exclusion recorded and its reason explained.
- Every change needed on the connected sites documented with a named lead, so the wallet and site teams could plan together.
- Administration, ledger, reconciliation and audit requirements in place before development started.
- Regulatory questions listed for counsel before development, not discovered after launch.
- A prioritized, estimable backlog with acceptance criteria, signed off as the development baseline.
“
Lessons learned
What can other product teams learn from this project?
- Agree the glossary before the features. In a wallet, words like credit, voucher and balance must mean one thing across every site.
- Make the wallet the identity provider as well as the payment gateway. Single sign-on is what makes one balance feel like one network.
- Document changes outside your team's scope. Dependencies on other teams are where wallet launches slip.
- Write ledger rules before screens. Balances calculated from an immutable ledger are far easier to trust, audit and fix.
- Draw the regulatory boundary at MVP. Leaving out cash withdrawal and transfers kept the first release simpler and the compliance questions clearer.
Planning one wallet or checkout across several sites?
Talk to a senior business analyst about MVP scope, ledger rules and integration requirements, before development starts.
Digital Wallet and Virtual Currency for a Network of Consumer Websites
