Payment Experience Design
Overview
For most of the six years at CLIQ Digital I designed the payment pages. These were the last screen before someone handed over their card details, across six brands and markets in North America, Europe, Latin America and Asia Pacific. Subscription billing sits in one of the more heavily policed corners of consumer payments. A lot of what appeared on those pages was not a design choice. Card scheme rules, advertising platform policy and consumer protection law all had requirements, and my job was to fit every one of them onto the page without making it unusable, while still building enough confidence that someone would complete the payment. Note: This work is confidential, so the screens are not shown.
Project :
Payment Experience Design
Role :
Senior UX/UI & Product Designer
Project Type :
Payment Flow, Design System & Localisation
Platform :
Web, desktop and mobile
Focus :
Trust, Compliance & Conversion
The Challenge
The product was a free or low cost trial that converts into a monthly subscription. That model carries obligations: people have to know what they are agreeing to, what they will be charged, when, and how to stop it. Card networks, ad platforms and regulators all enforce this, and every market interprets it slightly differently.
So the page had to carry a lot of required content. Trial length and converted price. Renewal date and cancellation terms. Separate consent for optional add-ons. Pre authorisation amounts. Accepted payment methods.
It also had to convert, because this was the final step of a paid acquisition funnel. And it had to hold across multiple brands and languages, and pricing in a dozen currencies.
Required content should not be seen as an obstacle, but rather a challenge to overcome. Instead of shrinking it, greying it, pushing it below the fold, you can get creative with it.
Objectives
Business. Hold conversion at the last step of a paid funnel. Launch into new brands and markets without rebuilding.
User. Understand what you are agreeing to before agreeing. Feel safe entering a card number. Know what will be charged, when, and how to stop it.
Compliance. Satisfy card scheme rules, ad platform policy and consumer law in every market, on every device, without the user having to go looking for it.
Trust Architecture
The moment someone types a card number is the highest anxiety point in the flow. I came to think about reassurance in three layers, each doing a different job.
- Before the form. A band at the top carrying the security signalling, doing its work before the user looks at a single field.
- Inside the form. Card scheme logos placed within the card number field rather than in a footer. The doubt happens at the moment of typing, so the reassurance belongs there.
- After the button. A clear account of what will be charged and when.
Separating them matters because they are not interchangeable. A padlock in a footer is decoration. The same signal placed where hesitation actually occurs is design.
One Template, Many Markets
I wasn't just designing payment pages on their own, I designed the entire system behind them.
The same structure carried multiple brands across the US, Canada, Europe including France, Italy and Spain, Latin America and Asia Pacific, in multiple languages. I built it as a template with a component library behind it, so a new market could just easily be configured, instead of having to be designed from scratch.
Localising a payment page is rarely about translation. What actually breaks is structural. Price strings are wildly different lengths, so a figure in USD or Argentine pesos occupies a much different space than a euro figure does. Number and date formats change. Required legal copy expands, running close to half again as long in some languages. And trust signals do not travel, because the payment methods people expect differ by market.
I collaborated closely with the engineers to create the responsive front ends for many of these pages in HTML, CSS and JavaScript, which meant I found the breakpoint problems while designing rather than after handover.
When Compliance Became a Design Problem
At one point our payment pages were flagged by Google. Paid advertising was effectively the whole acquisition channel, so a flag meant the traffic stopped.
The cause was small. On mobile, not all of the accepted card logos were visible. On desktop they all were, so nobody had spotted it.
People are entitled to know which payment methods are accepted before they commit, and the policy treats that as required information. So a page that was compliant at one breakpoint was not compliant at another, purely because of how the layout collapsed.
We redesigned so every accepted method was visible on both mobile and desktop, and the pages were approved again.
Two things stayed with me. A trust element can also be a compliance element. And something can be entirely compliant on desktop and not compliant on mobile, which is easy to miss if you design desktop first and treat mobile as a resize.
Outcomes & Reflections
The template carried multiple brands across four continents and made launching into a new market a configuration rather than a design cycle. Pages ran as matched A/B variants, with an email field and without, with the optional add-on and without, so we were learning from the differences rather than guessing.
The thing I would change is the legal text. It was too low in contrast, and it would be better for the accessibility standards. At the time it felt like a reasonable compromise between the volume of required content and the space available. Looking back, that was solving the wrong problem. The answer was not to shrink the content until it fit. It was to argue harder for the space.
That is what I carry forward. In a payment flow the disclosure is not the thing getting in the way of the design. It is part of the design, and if nobody can read it, it is not doing its job whatever the compliance checklist says.
