PlayStation · Store Payments
Localizing PlayStation checkout for how Brazil and the Netherlands actually pay
PlayStation Store served 300 million players with what was essentially one checkout. In markets where people don’t pay the way the checkout assumed — Brazil’s installment culture, the Netherlands’ bank-transfer habit — sales leaked at the last step. I designed the localized payment experiences that closed that gap, starting with the two markets where the mismatch was costing the most.
- Role
- Product Designer — payments & checkout
- Team
- Design · PM · payments engineering
- Duration
- Sep 2021 – Mar 2024
- Platform
- Web · PlayStation Store
2×
Brazil digital sales after installment support shipped*
6+
markets with localized payment methods and rules*
300M
players relying on the same core checkout*
* Brazil figure compares the quarters before and after installment launch; sales = PlayStation Store digital revenue in market. Player count is Sony’s published network scale at the time.
The problem: payment mismatch at 300M-player scale
When checkout serves a few thousand users, a poorly fitting payment method is a support ticket. At 300 million, single-digit percentage drop-off in one market is a number with commas that executives ask about. The funnel data showed the same pattern in both problem markets: players browsed, added to cart, reached payment — and left at the exact step where the store asked for a credit card.
The diagnosis wasn’t subtle once we looked locally. In Brazil, big purchases happen in installments — paying 12× for a console game is normal, and card credit limits make lump sums genuinely impossible for many players. In the Netherlands, iDeal bank transfers — not cards — are the default for online payment. We weren’t losing players at checkout. We were asking them to pay in a foreign language.
What made it hard
One store, many laws
Installments in Brazil are regulated consumer credit — pricing display, fee disclosure, and messaging all have legal requirements. Whatever we designed had to survive legal review in each market, not just usability testing.
A shared checkout core
The base checkout was shared infrastructure across all markets. Local payment flows had to fork from it without forking the codebase — every divergence needed a stronger reason than “it looks better.”
Irreversible transactions
Digital goods deliver instantly; most purchases can’t be quietly reversed. Any ambiguity about what the player would be charged, when, and in how many parts had to be resolved before the confirm button — not in support tickets after.
We weren’t losing players at checkout. We were asking them to pay in a foreign language.
Brazil: installments, not discounts
The obvious lever for weak sales was promotion — run discounts, lift the quarter, repeat. We considered it and killed it: discounting doesn’t fix a structural payment mismatch, it just subsidizes the players who could already pay. We shipped installment support instead, accepting real costs — reconciliation complexity for finance, longer settlement, and a checkout that had to explain consumer credit clearly enough to satisfy both a first-time buyer and a regulator.
The installment picker priced honestly
Per-installment amounts shown upfront, total cost alongside, no asterisks. Brazilian players are fluent in installments and immediately suspicious of hidden spread — the design’s job was to look as straightforward as the local e-commerce sites they already trusted.
Confirmation made the schedule concrete
The confirm screen restated what would be charged, in how many parts, on what cadence — because an irreversible digital purchase is exactly the wrong place for a player to discover their payment plan was misunderstood.
Digital sales in Brazil roughly doubled in the quarters after launch*. Installments didn’t make games cheaper — they made the existing prices payable the way that market actually pays.
The Netherlands: designing the iDeal handoff
iDeal flips the usual trust model: instead of typing card details into our checkout, the player leaves it — redirected to their own bank to approve the payment, then returned. The design problem isn’t the form; it’s the handoff. A redirect with no preparation reads as a phishing pattern, and a clumsy return reads as a failed payment.
I designed the seams: a clear pre-redirect moment naming the player’s bank and what would happen next, and a return state that confirmed the result instantly — including the pending case, where the bank has accepted but settlement hasn’t landed. Dutch players trust their bank more than any store. The job was to borrow that trust without the journey feeling broken.
Designing the failure states: declined, expired, pending
Most of the actual design hours went into states nobody screenshots for a portfolio: a declined installment after the first one succeeded, an iDeal session that expired mid-redirect, a wallet top-up that landed after the player gave up. Each one answers the same three questions — what happened, am I out money, what do I do now — and at this scale every percentage of confused players is a call-center budget. It's a lesson my later work at OKX would keep confirming: with payments, the unhappy paths are the product.
What this project recalibrated
Localization is payment behavior, not translation
The store was translated into Dutch and Portuguese long before it could be paid for in Dutch or Brazilian ways. Language was never the barrier; the payment method was.
Borrowed trust beats built trust
We could never make our checkout as trusted as a player’s own bank — iDeal worked because we stopped trying and designed a graceful handoff instead. Knowing when not to own the moment is a design decision.
Scale changes which problems are worth solving
Neither installments nor iDeal is a clever interface. They’re unglamorous structural fixes that moved revenue more than any visual redesign of the store could have. That recalibrated my sense of what high-impact design work looks like.