Wallet to Wallet:
Instant payments in PaysafeCard
Context, Team & my role, Who it was for, Scope, GoalsPaysafeCard's Wallet had no way for users to send money directly to each other, despite it being the most requested feature from users. I led the design of an MVP peer-to-peer send feature within Wallet, from initial flow through usability testing and accessibility sign-off, delivered across two sprints.
ā Team & my roleI was the lead product designer, working alongside a product manager, product owners, a product design manager, developers, and a UX writer. I owned the end-to-end flow design and ran usability testing myself. Copy was shaped in close collaboration with the UX writer. I wasn't involved in the legal negotiations directly, but I led the scope discussions with the PM and PO, including pushing back on parts of the original scope.
ā Who it was forAll PaysafeCard users with a Wallet membership. The primary segment was gamers aged 20ā50, based across Europe; a smaller secondary segment was content creators using the app to receive income with less bureaucracy than traditional banking.
ā ScopeThe MVP was scoped to instant transfers between Wallet members only ā phonebook contact syncing and sending to phone numbers outside Wallet were explicitly excluded. That boundary also set the legal constraint we designed around: entering a phone number or email could surface information about an existing user, so what a sender could see about a matched recipient had to be carefully limited.
ā GoalsThe feature needed to move four metrics: P2P transactions per month, P2P adoption rate among monthly active users, displacement of low-value SEPA OPP transfers, and uplift in wallet top-up frequency and volume.
PaysafeCard is a prepaid payment method that lets people pay online without a bank account or credit card. 'Wallet' is its subscription-based upgrade, giving users a regular IBAN and a physical card, features that aren't available to non-subscribed PaysafeCard users by default. This 'Wallet-to-Wallet' feature was built specifically for the subscribers, so they could send each other money instantly rather than relying on a traditional bank transfer.
Persona 1: The GamerLukas Weber
Quote: "I just want to send my share the second we're all talking about it ā not open my banking app and wait until tomorrow."
Age31
Lives inBerlin, Germany
JobFront-end developer in a start-up company
GoalsKeeps "fun money" separate from his real money; plays games and is active in Berlin's gaming community
FrustrationsSplits gaming subscriptions and payments with people he mostly knows through online communities and may never meet in person; finds German banks too bureaucratic for this kind of casual, recurring split. This is a friction he already feels more acutely navigating financial admin as a newcomer to the system
BehaviorPays for shared subscriptions (Discord Nitro, co-op game passes, LAN event tickets) in small, recurring amounts, often split three or four ways
Persona 2: The Content Creator
Giulia Ferrari
Quote: "I don't want to open three different apps just to pay someone back for an hour of editing."
Age
26
Lives inParis, France
JobFreelance content creator
GoalsWants a dedicated place to keep her side-project income separate from her main finances
FrustrationsShe collaborates with other creators in her work and wants one place to manage payments, instead of scattering them across different apps
FrustrationsFrequently pays small, one-off amounts to editors, photographers, or other creators she collaborates with on a project basis. This comes often on short notice, right after a shoot or edit is delivered
How might we...
...let Wallet members like Kacper and Giulia settle a shared subscription or pay a collaborator the moment it comes up ā without waiting on a bank transfer, syncing a phonebook they don't trust, or juggling yet another app just to move money between people they may never meet in person?
Key decisions
I. Phonebook contact sync (explored, deferred to Phase 2)
We planned to sync a user's phone contacts so they could find PaysafeCard users without typing details. Legal refused any display of synced user data, even contact names. That left a plain contact list with no way to know who used PaysafeCard. I warned this would confuse users, so we removed it from the MVP and deferred it to Phase 2.
II. Recipient field validation & error feedback
The product's existing pattern for an invalid recipient entry was to give no feedback at all, the field wouldn't react and the action button just stayed disabled. I made the case to the PO that this needed real, in-the-moment feedback instead, and we worked through two validation-timing models, live/on-keystroke vs. on-blur/on-continue, landing on different timing per error type and field (email vs. phone), since some errors are wrong the instant they're typed and others only become wrong once the user stops typing.
This wasn't just a hunch either: usability testing surfaced two High-severity issues tied to exactly this gap, unnoticed inline errors and unclear failure messaging, confirming that silent, disabled-button feedback wasn't good enough for release.
Our methodology unites scientific instructional design with operational precision, delivering measurable return on participation.-
Pre-event diagnostics determine baseline competencies, aligning content with identified gaps.
-
Module sequencing flexes to varying time horizons and sector requirements.
-
Internal audits examine pedagogical coherence and logistical efficiency.
-
Single-sign-on access streamlines user experience across devices.
-
Multimodal content accommodates visual, auditory, and kinesthetic preferences.