Making the relationship between a crypto wallet,
a new card, and money ready to spend easier to understand.
Your money.
Your next move.
I designed 28Pay over three months outside my day job. As the sole designer, I owned the brand and logo, end-to-end UX and UI, marketing materials, App Store launch screenshots, and the landing page for app downloads.
I handed off the completed design to the client and engineering team for development. My engagement ended at that handoff.
This case study focuses on one part of that broader scope: defining the relationship between the crypto wallet and the payment card, then making the path from funding to spending clear.
The challenge started during product definition. The relationship between the wallet and the card was still an open requirement, including for the stakeholder. As the UX/UI designer, I had to work through that ambiguity before turning it into a coherent experience.
One balance—or a wallet and a card
that each hold money?
How should wallet funding, card issuance, and card spending connect? We needed to define whether there should be two balances, what each represented, and how money would move between them.
For 28Pay, funds entered through the wallet; the card could not receive an external deposit directly. The resulting model kept separate balances, with a manual transfer from wallet to card.
The model for 28Pay separates where funds arrive from where they become available for card spending. This relationship became the basis for the navigation, balance labels, and next actions.
Crypto held in the wallet
Deposit into walletFunds allocated to the card
Available for card spending*Application and identity checks establish card access.
They are separate from putting money on the card.
Add money to the wallet.
Wallet balance changesComplete the card application.
Card status changesMove money from wallet to card.
Card balance changesCard funding models differ. Crypto.com documents topping up a prepaid card from a token wallet, cash, or a debit/credit card in the US. Bybit describes card payments using assets in its Funding Account. These examples do not establish 28Pay’s technical requirements.
For this case study, the wallet-first, manual-transfer model comes from the project’s requirements. The references below were checked while refining this case study; they are not presented as research conducted during the original project.
Follow the original top-up designs: choose the card to fund, review the amount, select a wallet asset, and see the arrival confirmation.
The card picker distinguishes virtual and physical cards and identifies each card by name and its last four digits. Select the destination before continuing.
Choose the destination before committing funds.
Click the selected card to continue.
A walkthrough of original design states. Card details and sample amounts vary between screens; they do not represent one completed transaction.
The walkthrough starts with an issued card. Other entry states need their own guidance.
Acknowledge the successful deposit and explain the next step without suggesting that the wallet balance is already spendable by card.
Lead with funding the wallet before offering a transfer.
Distinguish a funded wallet from a card that is ready for use.
Explain where the money is, whether balances have changed, and the next safe action.
Explain spending restrictions and the available recovery or return-of-funds path.
Proposed coverage. Confirm behavior against product and operational rules.
Getting a card and funding it are separate steps. These original screens show the choices, details, and status changes that lead to the next top-up action.
Funding, verification, and application are shown as distinct stages.
A selection sheet makes the chosen card type visible before confirmation.
Country, city, address, and postal code form a dedicated step.
The payment sheet brings the amount and selected wallet asset into focus.
A processing state explains that the application is still underway.
The completion screen leads into top-up, continuing the money journey.
Scroll or use the arrows to explore all six pages. Click any screen to enlarge. Original designs with sample data.
Balance labels, transfer confirmations, and transaction activity make the funding model visible. Card customization brings the brand into the everyday experience.
Wallet and card live in separate destinations. The wallet uses “錢包餘額,” while the card view uses “帳戶餘額” and offers “充值卡片.”
Can someone tell which balance funds a card purchase? Test a more explicit “Card balance” label and distinguish wallet deposit from card funding.
The confirmation identifies a source card and a destination wallet. That direction is a critical part of the transaction, not a secondary detail.
Identify both accounts, including the specific card.
Explain any conversion or deduction before confirmation.
Show when the destination balance is actually ready to use.
The main card screen brings the selected card, its account balance, and recent activity into one destination.
The card stays visible above the account balance, giving the amount a clear context.
“充值卡片” sits beside transaction history, connecting the current balance to the next money action.
A dated activity list pairs transaction labels with amounts and currencies. It gives the balance a history that people can review.
Original interface · sample transaction data
The card selection experience extends the 28Pay identity into a range of expressive colors, while keeping the same card layout and selection pattern.
Original card selection screens · tap a screen to explore
The following tasks outline how I would evaluate understanding of the funding model. They are a proposed validation plan, not completed research or measured outcomes.
| User task | What to observe | Evidence |
|---|---|---|
| Identify spendable fundsShow a funded wallet and an unfunded card. | Can the person explain why a card payment is not yet ready? | To validate |
| Fund the right cardStart from the wallet overview. | Correct destination, task completion, wrong turns and need for help. | To validate |
| Explain a transferShow the confirmation screen. | Can the person identify source, destination, received amount and any cost? | To validate |
| Read recent activityReview the card’s transaction history. | Can the person identify a transaction’s amount, currency and direction? | To validate |
My first design challenge was helping clarify an ambiguous requirement with the stakeholder. Once the wallet–card relationship was defined, I could translate it into a journey from receiving funds to spending them.
Explain how accounts and states connect before optimizing individual screens.
Deposit, apply, transfer, and exchange each need a clear purpose and destination.
Help users move from their current balance and card state toward their goal.
