Local entity
BRL wallet
Pix, local deposits and withdrawals, and licensed local merchant payments.
Paysafe · Skrill and Neteller · Brazil onshore launch · 2025
Rebuilding Skrill and Neteller for Brazil across two regulated entities
Paysafe became a licensed Payment Institution in Brazil, allowing users to hold BRL and pay with Pix. However, the Central Bank required local and international funds to sit in separate legal entities without free movement between them. I led the UX across onboarding, verification, Pix payments and management, exchange, crypto, P2P and migration, to maintain a seamless experience under one app and login. When plan A turned out too complex to develop ahead of the regulatory deadline, I reshaped the experience into a scoped MVP, designing a frictionless flow driven by conditional visibility, preventative messaging, and clear next actions that guided users around backend friction before it impacted the experience.
Role
Senior Product Designer leading UX architecture and end-to-end design across both wallets, while guiding and overseeing the work of a supporting product designer.
Product and scope
Skrill and Neteller digital wallets, iOS, Android and web, Brazil. Onboarding, verification, Pix payments and management, exchange, crypto, P2P and migration.
Challenge
Two legal entities behind one brand and one login, a hard wall between their balances, and a launch date set by the regulator.
My contribution
Local competitor review, stakeholder interviews, entity mapping, IA, flows and edge cases, usability testing, preventative messaging, CS education content and delivery scoping with Engineering.
Impact
Expected: +40% TTV, 50% fewer support contacts and +30% FTD conversion. In testing, 9/10 completed core Pix tasks.
01 · The problem
One app, one login, two pockets that could not touch
Paysafe’s onshore expansion added a local BRL account and Pix alongside the existing international account. The Central Bank of Brazil framework required these assets to stay separate. Users still saw one brand and one login, but their balances could not be used interchangeably. The design had to make that boundary clear without making users learn the legal structure.
Funds do not cross directly
International entity
Global wallet
Foreign-currency balances, international services and crypto.
User problem
Users expect one wallet to behave like one pot of money
If BRL cannot buy crypto, or USD cannot go out through Pix, users only find out at the final step, with a failed transaction and money that looks frozen.
Business problem
A fixed launch date and a new market to win
The licence opened BRL, Pix and licensed betting merchants. Missing the regulator's date meant stopping operations in Brazil. Every failed cross-entity transaction would turn into a support contact and lost trust.
Design challenge
Make a legal constraint visible without splitting the app
The wall lived in the backend and in the regulation. It had to show up in the interface clearly enough to prevent errors, without making Skrill feel like two separate apps and without frustrating returning users.
02 · Discovery
Map local mental models before deciding the IA
Pix is the everyday way Brazilians pay, and they already have strong expectations of how it works. I needed to know those expectations before deciding where each feature lived, how the payment journey should work and what would make it feel local.
Competitor review
PicPay, Mercado Pago, Mercado Libre, Revolut's Pix management and local banks. How the payment flows work, where entry points sit and what the features are called locally.
Stakeholder interviews
Mapped the local journey and the priorities: which features must be as visible as possible, which can come later, and which frequent, speed-sensitive actions need extra entry points on the home screen.
Local Pix use cases
Everyday Pix use spans instant peer-to-peer transfers, utility bills, e-commerce checkouts, and contactless store payments. For betting and digital platforms, users deposit via dynamic QR codes and withdraw directly to verified Pix keys matching their legal identity.
Entity scenarios
I mapped two models: every currency enabled in every flow with automatic conversion (which was our plan A), or each flow limited to its own entity (plan B).
Competitor flows
Key insight
Users will not learn our legal structure. The interface has to know it for them
Every flow needed to know which entity it belonged to before the user started it. That became the principle for the whole release: prevent, don't explain afterwards.
03 · The initial proposal
Swipe the balance, change the dashboard - plan A
My first proposal tied the home screen to the balance carousel. Swiping from BRL to USD (or a foreign currency balance) would change features, quick actions and content modules to what that entity can provide.
Why it works
No impossible actions
When a user switches to USD (or a foreign currency balance), they’ll never see Pix, so they cannot start a transfer the regulation will block.
Why it works
A gesture users already know
Swiping between balances is standard in wallets. Users don't need to learn a new two-account taxonomy.
Why it works
Two ecosystems, one roof
The BRL view feels like everyday Brazilian banking, the USD view feels global. The separation is felt, not explained.
04 · The constraint
The constraint that led to plan B
In technical grooming, Engineering showed that a fully state-driven dashboard would delay launch by several months. The launch date was not negotiable: missing it meant shutting down in Brazil. We pivoted to a scoped MVP with one shared dashboard.
That created the exact risk the initial proposal was meant to remove. With one dashboard, a user on the foreign currency balance could tap Transfer, pick Pix, and only then discover it cannot work.
I moved the protection from the structure of the app into every flow.
Conditional visibility
If a currency or payment method was not allowed in the context of that entity, it got hidden or disabled before a user invested effort in a journey.
Why: prevention reduced the need to explain a failure after the fact or manage CS contacts.
Progressive disclosure
A short message at the start of the flow, when the user reached actions affected by the two-entity model, not an error screen at the end of it.
Why: users could get the needed support and information at the point of contact with the issue, avoiding tedious out-of-context explanations during onboarding.
Next best actions
Every message links to what the user can do instead of being stuck at that step of the journey: exchange, transfer money through a merchant or use the right account.
Why: allowing payment flows to hit a dead end would cause massive user drop-off and risk complete abandonment of the app.
The empty state: a newly migrated user often has R$0,00 and a USD balance on day one. That is exactly when they try to withdraw or buy crypto, so every guardrail was designed first for a zero BRL balance.
The trade-off: guardrails prevent failed transactions, but users still carry the mental work of two pockets. The dual-state dashboard stays the better long-term answer.
05 · Pillar 1 · Onboarding and migration
New users hit a legal gate. Existing users got a choice
The Brazilian entity needs more data before it can open an account. Existing international users also needed a way into the new model without losing trust in money they already held.
What we cut
Try the app before verifying
My proposal let new users look around before giving all the regulatory data, to protect sign-up conversion.
Cut: the timeline forced a strict gate upfront, before users see any value.
KYC
CPF, intent of use, monthly income
I designed the full verification funnel for the data the Central Bank requires: CPF tax ID, how the user intends to use the wallet and their estimated monthly income.
Migration
Opt in, with the full picture
Migration for the existing users was voluntary. I worked with Customer Support on FAQ topics, education pages and emails covering benefits and limitations, so users could decide whether they'd transition, knowing what changes.
Signal from testing: one participant said they once had a Skrill account that was never approved because their documents were never accepted. I flagged KYC approval as a risk for the local launch, beyond the screens.
06 · Pillar 2 · Pix
Pix functionalities, designed with limitations in mind
My role was to mentor another designer and further iterate on the payment flows. I designed an additional communication layer to clarify the limitations between BRL and international accounts, while streamlining and simplifying the overall payment journeys to align with local users’ mental models. Additionally, I designed the payment details, scanning errors, and error recovery states. Finally, I architected the comprehensive Pix payments hub (the "Plan A" mentioned above), which we strategically replaced with in-flow guardrails to meet our strict regulatory timeframes.
Naming
Pay with Pix QR code
The competitor review showed how local apps name QR payments. The label covers both scanning and copy and paste, which Brazilians use for online checkout.
Mental model gap
Constraints in adding funds with Pix
While Pix normally allows anyone to send you money, our initial release only supported deposits from accounts under the user's own name. I integrated explicit messaging right at the payment method selection to prevent users from sharing unusable codes.
BRL only
Money in and out only in BRL
Since Pix deposits and withdrawals operate strictly in BRL, users with a USD balance are alerted on this currency restriction at the very beginning of the flow. The interface immediately provides clear next actions.
Pay with Pix QR code
Pix QR codes are Brazil’s dominant payment method, powering both physical in-store and virtual POS transactions. To match native speed and expectations, I designed a streamlined flow that resolved critical edge cases. This involved aligning the UI structure with local naming conventions, mapping journeys for both static (manual amount) and dynamic (pre-loaded amount) codes, and designing clear recovery states for insufficient funds, entry errors, and expired codes.
Add money with Pix
Pix is Brazil’s dominant method for funding digital wallets, traditionally allowing instant transfers from a user's own bank or from third-party accounts. However, our initial release deviated from this standard behavior by restricting inflows strictly to accounts matching the user’s legal name. To reconcile this technical constraint with local mental models, I implemented proactive guardrails directly at the payment method selection screen. This upfront communication managed user expectations, saved time, and successfully intercepted failed transaction errors before they occurred.
Pix keys management in one place
Concept
To meet local expectations, I designed a Pix Keys Management area allowing users to view, copy, share, name, receive from and delete their keys. To maximize efficiency, I placed the most high-frequency actions on the Home screen within a dedicated widget.
Release one
The timeline cut key management to the basics: a random key users could copy, add or delete. Testing later showed users wanted the parts we cut.
07 · Validation
9 out of 10 local users found and completed the core Pix tasks
I tested the Pix area with ten Brazilian Pix users in remote sessions on Userlytics, including three sports bettors. Four sessions ran in Portuguese. The hypothesis: one Pix area makes these features easy to find, and the flows are clear. Targets were 7/10 completion and 4.5/5 for discoverability, ease and clarity.
9 / 10
Receive money with Pix. Ease 4.7/5. Four users first tried Transfer → Send to yourself before finding Pix → Receive.
9 / 10
Pay with QR code in a store. Clarity 4.8/5. The home widget was noticed and liked: “you don't need to click Pix first and then QR Code.”
8 / 10
Deposit to a betting merchant. Discoverability 5.0/5. Two users tapped the merchant's “Share payment request” and stopped there.
8 / 10
Withdraw from a merchant to your Pix key. Most copied the key from the home widget. Discoverability 4.4/5, just under target.
What didn't work: “Send to yourself” under Transfer pulled users away from Pix, so the wording was too broad. Two users were confused by the Pix fee, “Usually Pix has no fee because it's free.” Several expected to receive money from other people and share their QR code on WhatsApp, which release one did not allow.
Research card and learning card Pix area test
08 · Pillar 3 · Exchange and crypto
The only way that allowed funds to cross entities
Exchange was the only legal way for users with local currency to transact with foreign currency and vice versa, with the IOF tax applying to every transaction. Crypto sits entirely on the international side and is one of the primary flows utilizing this Exchange functionality.
Exchange
IOF tax at the input
The Tax on Financial Transactions (IOF) remained visible at the point of entering the amount, with a clear explanation distinguishing between the 3.5% tax for converting BRL to foreign currency and the 0.38% tax for converting foreign currency back to BRL.
Crypto
A one-time notice on entry
When a user enters Trading or chooses to Withdraw to a crypto wallet, they are warned that their BRL balance cannot be used for crypto transactions and are immediately offered the next best actions.
Next best action
A how-to guide for BRL holders
Users holding only BRL balances get a dedicated info screen highlighting the two possible routes: convert BRL to USD, or receive USD from a merchant directly into their wallet.
Withdrawing USD to a Brazilian bank: two flows tested
Content creators in Brazil get paid in USD, for example from Adobe Stock, but Pix only sends BRL. I tested two prototypes with four creators: in Flow 1 the exchange happens inside the withdrawal, in Flow 2 the user leaves to exchange, then comes back.
4 / 4
completed Flow 1 and rated it very easy and very clear. Three of four preferred it for their own needs: fewer steps, one transaction.
3 / 4
completed Flow 2. One stopped after the exchange. Yet three of four called Flow 2 clearer, because they saw each step of the conversion.
2 / 4
were confused by the amount in Flow 1. $500 became less after fees and conversion, and the reason only showed on the summary screen.
Flow 2 shipped for launch: the withdrawal states that only BRL is supported and links straight to Exchange. [ASK: what made Flow 2 the launch choice, for example engineering effort?] Flow 1 is on the roadmap, and the test told us what it needs first: show the conversion and fees at the amount step, not only on the summary. One participant also thought Flow 2 was cheaper because only the withdrawal fee showed, so Flow 2 needs the full cost visible too.
09 · Pillar 4 · P2P
Sending money between users on different sides of the migration
Migration was voluntary, so for a long time some users were on the new dual-entity model and some were not. Skrill to Skrill had to work between them without a single failed transfer.
I mapped six scenarios by each person's migration status and the selected currency. For transfers on the international side, the app preselected a funded balance in that currency, or fell back to the funded primary international balance.
P2P transfer scenarios 6 scenarios
| Sender → recipient · currency | What the user sees | Why |
|---|---|---|
| Migrated → migrated · BRL | BRL balance selected | Both use the Brazilian entity; local → local. |
| Migrated → migrated · non-BRL | International balance | Both use the international entity; international → international. |
| Migrated → not migrated · non-BRL | BRL unavailable | The recipient has no Brazilian account; the transfer stays international → international. |
| Not migrated → migrated · BRL | International balance | Even in BRL, the unmigrated sender transfers international → international. |
| Not migrated → migrated · non-BRL | International balance | The transfer stays international → international. |
| Not migrated → not migrated · any currency | International balance | Neither user has migrated; international → international. |
10 · Outcome
Driving Pix adoption and minimizing support volume
The design proposals connected each UX decision to an expected behaviour change. Local Pix flows aimed to shorten time to first transaction and encourage repeat use. Preventative guardrails aimed to reduce failed attempts and support contacts. Upfront IOF disclosure aimed to reduce exchange abandonment. Live figures are confidential, so these are the expected shifts the release was designed to move, alongside what testing showed.
+40%
Expected increase in Total Transaction Volume. Instant Pix deposits, QR payments and withdrawals replace multi-day offshore wires.
−50%
Expected reduction in cross-entity compliance support contacts. Users are stopped before a blocked transaction, instead of asking why it failed.
+30%
Projected lift in First-Time Deposit conversion. Pix QR and copy and paste shorten the time from sign-up to first deposit.
Beyond screens
An entity-by-feature map the team designed against, a reusable guardrail pattern (inline notice plus next best action), the six-scenario P2P matrix, and CS education content for migration.
What I would repeat
Map your legal and entity rules before sketching a single screen. Securing early stakeholder alignment on these backend rules is a practice I will always repeat to keep projects on track.
What I would do differently
Run every local test in Portuguese from the start. The one participant who struggled most did so with the English prototype, not with the flows.