Credit Card Voucher
Credit Card Voucher
Designed a new payment method that shifted external credit card usage to voucher-based payments.
Timeline
2024 Q4 - 2025 Q1
My Role
End-to-end design, user research, usability testing
Team
Designer (me), PM, Engineering, Legal, Business
Background
PayPay is Japan's largest mobile payment platform with over 65 million users. At that scale, even small inefficiencies become expensive problems. One of them: users could link their external credit cards to pay through PayPay. Convenient for users, but every transaction came with a processing fee to the card networks. At 65M users, that adds up fast.
Leadership decided to phase it out with a sunset date. My job was to figure out how.
The real problem was not removal
Before jumping into design, I wanted to understand why users were linking their credit cards in the first place. So I talked to users who were paying with credit cards through PayPay.
The answer reframed everything. Most of them weren't loyal PayPay users. They were using PayPay as a payment interface to earn airline miles and credit card rewards. PayPay just happened to be accepted everywhere in Japan.
That meant we weren't removing a feature. We were about to eliminate the main reason these users opened the app. So the question I brought back to the team wasn't "how do we remove credit card support?" It was "how do we let users keep earning rewards without routing through the card network?" Getting the team aligned on that framing early shaped every decision after it.
Adapting when the obvious solution got blocked
The most obvious answer was a top-up flow: users charge their credit card to load balance, then pay from that. Clean, familiar, and it would have solved the cost problem too.
Then the blocker surfaced. Adding a new stored-value type would classify it as e-money under Japan's Payment Services Act, requiring a separate license and AML compliance work we couldn't absorb on our timeline.
We didn't have time to fight the regulation, so I looked for a path inside it. PayPay's existing voucher system sat outside those rules: vouchers are non-transferable, which keeps them clear of Japan's AML requirements. We proposed a new type: Credit Card Vouchers. Users buy the voucher with their credit card, keep all their miles and rewards, then pay through PayPay as usual.
To get buy-in, I framed the idea around what each stakeholder cared about. For legal, it stayed inside the existing voucher framework, so no new license was needed. For business, users keep their rewards, which meant we keep the users we were most at risk of losing. For engineering, it built on a voucher system we already had instead of standing up new infrastructure. Once each team could see their own risk was covered, the direction was approved without another round of debate.
Credit card charges convert into vouchers, same purchase, different route.
Hard cutoff vs. transition: disagreeing with data
Engineering preferred a hard cutoff: set a date, kill the feature, send a notification. I understood why. Minimal conditional logic, clean implementation, faster to ship.
Before agreeing, I reviewed CS data to see where payment failures actually hurt users. One pattern kept showing up: unexpected errors at checkout. Users would retry again and again, get frustrated, and lose trust in the app. In Japan, a failed payment at the register is more than friction. It's embarrassing.
I brought that data back and proposed a transitional phase instead: users get advance notice of the cutoff date and are guided through buying their first Credit Card Voucher before direct card payment disappears. Once engineering saw the trust cost laid out, we committed to the phased plan together.
In Japan, an unexpected error at checkout is more than friction. It's embarrassing.
Translating decisions into screens
The experience came down to three design problems.
Where and when users see the sunset notice
Rather than placing the notification everywhere, I used CTR data to find where users were most likely to see it. The payment flow and post-payment receipt screen came out on top, so those became my primary placements.
Then I caught a gap. Users adding a credit card for the first time would skip both of those and land straight on a feature that was about to disappear. We added the notification to that flow too, before it became a problem in production.
Teaching a new concept without losing users
These users had been paying with their credit card through PayPay for months, sometimes years. Now we were asking them to stop and learn something new.
The risk wasn't confusion, it was abandonment. If onboarding felt like work, they'd switch to a different payment tool and we'd lose them. So the onboarding had one job: make this feel smaller than it actually was.
Japanese users in particular want context before taking action, so I added a buffer page explaining what was changing and why before asking them to do anything.
The biggest open question was the purchase screen. Should it feel like buying a product with fixed amounts, or like topping up where you type in a number? Get the mental model wrong and users hesitate, or drop off, right at the step we most needed them to complete.
I explored three directions: adapting the existing Gift Voucher pattern, a top-up style input, and a scroll-based amount selector.
I also studied how other apps handle amount input.
Each pattern had a reasonable case behind it, and I didn't want to settle this by opinion. So I ran two quick studies: a bilingual survey on how users understood the voucher concept, and concept testing of the three prototypes with 8 users.
Survey
Concept testing
I prefer the top-up–style screen since I already know how to use it.
I don't like having fixed amounts. I want to decide how much I put in myself.
I like the preset amount buttons, they save time.
The research pointed clearly to the top-up pattern. Users already knew how it worked, and that familiarity mattered more than conceptual accuracy. It also gave me a concrete answer when stakeholders asked why we chose it: not my preference, but what users showed us.
One constraint remained: legal required amounts in ¥10,000 increments. Instead of a hard error state, I added a floating quick-fix button that corrects the amount in one tap, keeping the flow moving.
When an invalid amount is entered, a floating quick-fix button appears, auto-correcting to the nearest valid increment without interrupting the flow.
Closing the loop back to payment
Purchase done, but I didn't want to leave users there. The confirmation screen shows the voucher status with a single CTA that takes them straight to payment, voucher pre-applied. No matter when someone found out their card was being cut off, they could recover and complete their payment without hitting a dead end. Start to finish, about 10 seconds.
Once the purchase is done, users see a status screen confirming their voucher. One tap at the bottom CTA and they're at the payment screen, voucher applied, ready to go.
I also walked through every granting scenario with backend engineers (granted, pending, error) to make sure nothing unexpected slipped through after launch.
Granted
Pending
Error
When the CEO joined the design review
During a design review, PayPay's CEO asked us to use the voucher purchase page to promote PayPay's own credit card.
I understood the goal: this project was the perfect moment to move card users onto our own card. But turning the purchase page into an ad would add friction exactly where drop-off risk was highest.
Instead of pushing back with a flat no, I mapped out the full transition journey and showed there was a better moment for that message: the sunset announcement itself, where users are already deciding what to do about their card. On the purchase page, I made the PayPay Card option more visually prominent in the payment method selection, so the promotion happened through the interface, not through ad content.
The CEO approved the approach, and it's now in development. The lesson wasn't about winning the argument. It was that senior stakeholders respond to the same thing users do: show the journey, show where the message lands best, and let the logic speak.
Designing for the next bank, not just this one
The sunset didn't apply to every card. Credit cards from partner banks, starting with SMBC, could still be used directly in PayPay, no voucher needed. I designed how these partner cards appear in the app, and my first design was a one-off: custom card icon and background for SMBC.
Then the business team mentioned they were exploring more bank partnerships. Rather than designing each new bank by hand, I turned the one-off into a rule system: each bank's primary color applied through defined icon and card rules. New partners now get a consistent card treatment without new design work.
Beyond the handoff
To improve implementation quality, I set up a formal design QA process and built an annotation tool for handoff. Other designers started using it on their own projects, and it became the team's standardized process.
Annotation tool I built
Where it stands now
The feature is in beta with a limited group of users. I'm monitoring voucher purchase success rate and payment success rate as primary signals, with support inquiry volume as a secondary indicator of friction. Findings from this phase will shape adjustments before full rollout.
Learning
The biggest thing I took away was how much late misalignment costs in a compliance-heavy environment. When legal requirements shift after you've designed something, you're the one who absorbs it. I got much better at pulling legal and business into the conversation earlier.
The other thing: research under pressure is still worth doing. A survey and 8 concept tests aren't rigorous, but they moved a major decision from opinion to evidence, and gave me a clear rationale to stand on in every review after. I'd make that call again.
Next
Cardless ATM
Expanded ATM features to eliminate the need for debit cards, resulting in a 12% increase in service adoption.
Credit Card Voucher
