My Framer Site

WI Payments — Case Study

Fintech UX • Modular Checkout System

Modular Payment Experience for Modern Checkout

Systems

Modular Payment Experience for Modern Checkout

Systems

Modular Payment Experience for Modern Checkout

Systems

I redesigned WI Payments around speed, clarity, and trust. The goal

was simple: make repeated payments faster, keep the interface

scalable for new payment methods, and make every step feel less

risky.

I redesigned WI Payments around speed, clarity, and trust. The goal

was simple: make repeated payments faster, keep the interface

scalable for new payment methods, and make every step feel less

risky.

View Prototype

Contextual flows for cards, wallets, bank transfer, and regional methods.

15+ methods

Cards, wallets, bank transfer, express checkout, and regional payment systems.

Mobile First

One system. Two layouts. Same logic. Following the end customer usage pattern

Modular

Each method behaves like a

reusable component

Trust-first

Security cues are part of the UI, PCI DSS trust indicators placed near final actions.

Behavioural Hierarchy

Payment methods are categorised and placed based on user behaviour

Scalable

designed to cater requirements as business grows and add additional payment methods

Project context

What I was solving

The old gateway was functional, but it was hard to scan, hard to scale, and too fragmented for repeat users. The redesign focused on behavior, not just aesthetics. The screens you shared in the canvas already show the system direction: modular payment method handling, mobile-first saved cards, express checkout, security cues, and a desktop scale-up.

Constraints

No heavy research. Strong system thinking.

I did not run a large primary research program. Instead, I used a screen

audit, payment-method logic mapping, and flow analysis to rebuild the

experience from the inside out.

I did not run a large primary research program. Instead, I used a screen

audit, payment-method logic mapping, and flow analysis to rebuild the

experience from the inside out.

•

Understand what each method needs from the user.

•

Reduce repetition for returning customers.

•

Make the checkout feel safe before payment is submitted.

•

Keep the architecture open for future payment providers.

Design direction

Keep complexity in the system.

The interface should feel calm even when the payment logic is complex.

That meant one shared layout language, progressive disclosure, and a

stricter hierarchy between quick pay, saved cards, and long-form

regional flows.

The user should never feel the full weight of the payment infrastructure. They

should only see the next correct step.

The user should never feel the full weight of the payment infrastructure. They should only see the next correct step.

End Users • Hosted & Non-Hosted Merchant Checkout

Who the checkout is designed for.

WLPayments powers merchant checkout flows for both hosted and non-hosted customers. This page is for the end users of those merchants — the people who actually complete the payment. They may already know the merchant, or they may be buying for the first time.

Repeat

Already bought from the merchant

and want a fast return checkout.

First-time

New customers need clarity, trust,

and a low-friction start.

Mobile

>70% users complete payment on

a phone under time pressure.

>70% users complete payment on a phone under time pressure.

Trust

The checkout must feel safe,

familiar, and easy to verify.

The checkout must feel safe, familiar, and easy to verify.

Primary end-user personas

The checkout is designed for two major customer groups: returning customers of the merchant and new end customers discovering the merchant for the first time.

Persona 01

Returning customer

A person who has already bought from the merchant before.

They know the brand, trust the transaction path, and want the

fastest way to pay again.

Mindset

“I’ve bought here

before, so I just want

to finish quickly.”

Wants the checkout

to remember them

without forcing

repetition.

Is comfortable using

a saved card or

preferred payment

method.

Needs

✓

Saved cards and

express payment

shortcuts.

✓

A clear selected

state and visible

confirmation.

✓

Minimal typing and

the shortest possible

flow.

Pain points

•

Gets frustrated if

card details must be

re-entered.

•

Will abandon if the

flow feels slower

than expected.

Design response

•

Saved cards at the

top, express

methods nearby,

and a sticky CTA for

quick completion.

Persona 02

New end customer

A person who is buying from the merchant for the first time.

They do not know the flow yet, so the interface must reduce

uncertainty and build trust immediately.

Mindset

“Is this merchant

legit, and is my

payment safe?”

Looks for signs of

security, clarity, and

professionalism.

Needs guidance

because they do not

know the checkout

yet.

Needs

✓

Simple hierarchy and

easy-to-scan

payment options.

✓

Trust signals such as

PCI DSS and secure

checkout indicators.

✓

Clear transaction

summary and low-

risk interaction

design.

Pain points

•

May hesitate if too

many methods look

equally important.

•

May leave if the

page feels outdated

or confusing.

Design response

•

Use clear grouping,

concise labels, and

strong trust cues

near the action.

Persona summary

The checkout is designed for end users of merchant stores — people who either already know the merchant or are discovering it for the first time.

Fast

Returning customers want minimal

effort and quick completion.

Clear

New customers need easy scanning,

simple copy, and a trustworthy

layout.

Safe

Both groups need visible security

and low-risk interactions.

Flexible

The checkout must support different

payment habits without becoming

cluttered.

Audit

Old UI audit

The legacy experience had too many visible states at once. It lacked clear grouping, the field patterns changed from method to method, and trust indicators were weak or buried.

What the audit showed

•

Payment methods were mixed without clear prioritization.

•

Users had to read too much before they could act.

•

Repeat payment paths were not clearly optimized.

•

Desktop and mobile felt like two different products.

•

Security and summary information were visually secondary.

Why it mattered

In payments, clarity is conversion. Every extra second creates doubt.

Every confusing choice creates drop-off. The redesign made hierarchy

visible, reduced scanning effort, and made the payment type obvious

before the user committed.

The old UI worked as a container for payment methods. The new UI works as a guided payment system.

PicPay

Legacy payment method screen

Venus Point

Legacy account login flow

Neteller

Legacy wallet authentication

Pay N Play

Legacy redirected payment flow

SEPA

Legacy direct debit flow

Desktop

Legacy desktop checkout shell

Sofort

Legacy regional bank checkout

Skrill

Legacy wallet entry flow

Bank selector

Legacy country selector interaction

Approach

The design process

The system was rebuilt with four rules: show less, group better, stay

consistent, and make security visible.

Progressive disclosure

Only the fields needed for the

chosen payment method

appear. This lowers cognitive

load and keeps the page

readable.

Behavior-based grouping

Saved cards, express payments,

and all methods are separated.

That makes the mental model

obvious.

Trust-first layout

Security badges, safe-hand

messaging, and clear CTA states

were added close to the action

point.

Reusable components

The design system supports

future methods by reusing the

same payment shell, states, and

summary behavior.

hierarchy Baked by data

The design Hierarchy

Payment methods were prioritized by user behavior, speed, familiarity, and trust—surfacing express and regional payments first while progressively revealing complex international flows later.

Saved Cards

Available on top , as this being the most used method of payment

Preferred Payments

Last mode of payment and saved methods for future usage, for quick discovery.

Express Payments

Designed around accelerated decision-making
fastest possible transaction with minimal form interaction, authentication friction, or cognitive effort.

Regional Payments

Influenced by familiarity, local trust systems, and geographic adoption patterns.

UPI users in India expect UPI early in the flow
iDEAL users in the Netherlands actively look for iDEAL
SEPA users in Europe recognize direct debit patterns instantly

International Payments

Placed later in the hierarchy because they typically represent lower-frequency, higher-complexity payment behaviors compared to local or express methods.

Saved Cards

Available on top , as this being the most used method of payment

Preferred Payments

Last mode of payment and saved methods for future usage, for quick discovery.

Express Payments

Designed around accelerated decision-making
fastest possible transaction with minimal form interaction, authentication friction, or cognitive effort.

Regional Payments

Influenced by familiarity, local trust systems, and geographic adoption patterns.

UPI users in India expect UPI early in the flow
iDEAL users in the Netherlands actively look for iDEAL
SEPA users in Europe recognize direct debit patterns instantly

International Payments

Placed later in the hierarchy because they typically represent lower-frequency, higher-complexity payment behaviors compared to local or express methods.

New system

Mobile-first payment

experience

Mobile-first payment

experience

The new mobile interface behaves like a payment hub. It places the most likely action first, and pushes secondary work behind a clean disclosure pattern.

What changed on mobile

•

Saved cards appear as a high-priority card stack.

•

The active payment method is obvious at every state.

•

Express checkout is separated from longer method forms.

•

Bank and regional methods open as focused overlays.

•

Cancelation is handled with a clear confirmation modal.

Interaction logic

The selected method determines what users see next. Card flows ask for CVV. Bank flows ask for bank selection and consent. Regional methods ask for the correct localized identifier. That keeps each path short and context-specific.

One shell. Many methods. Different inputs. Same structural language.

What changed on mobile

•

Saved cards appear as a high-priority card stack.

•

The active payment method is obvious at every state.

•

Express checkout is separated from longer method forms.

•

Bank and regional methods open as focused overlays.

•

Cancelation is handled with a clear confirmation modal.

Interaction logic

One shell. Many methods. Different inputs. Same structural language.

Add card

Bottom-sheet form for adding a new card without leaving

checkout.

Card + express

Selected card state with preferred methods and express

checkout visible.

Express payments

Google Pay, PayPal, and Apple Pay are separated into a fast

lane.

Selected card

Saved card selected state with CVV field revealed inline.

Mobile overview

The main checkout shell with saved cards, preferred

methods, express methods, and the sticky payment bar.

Trust and compliance

Security is part of the UX

Users hesitate at the moment of payment. The interface needs to answer that hesitation with visible trust, not just compliance paperwork.

What I added

•

PCI DSS and Secured badges below the checkout area.

•

“On Safe Hand” and “Your Information Is Safe” trust cards.

•

Clear destructive confirmation for cancel payment.

•

Better CTA contrast to keep the final action obvious.

Security cues should appear where users make a decision, not hidden in the

footer.

Security cues should appear where users make a decision, not hidden in the footer.

Trust in the new UI

The design uses calm surfaces, soft borders, consistent iconography,

and clear action states. That makes the payment page feel controlled

instead of crowded.

Desktop

Built for scale on desktop

The desktop version was treated as an operator-friendly payment hub. It gives the merchant and the user more visibility without making the page feel heavier.

Desktop structure

•

Left rail for category navigation and quick entry points.

•

Central column for the payment method list and forms.

•

Right rail for summary, profile context, and payment breakup.

•

Persistent bottom actions to reduce missed confirmation states.

Why this matters

Desktop payment flows often fail because they try to copy mobile

exactly. This version scales the logic while giving each panel a distinct

job. That makes the checkout easier to manage when many methods

coexist.

Same payment engine. Different information density.

Desktop overview

Merchant dashboard-style view with payment method list and summary.
Quick Navigation to payments methods , available as an overview
Close-up desktop checkout state showing modular method layout.

Scalability

How the system scales

The design is built as a framework. That means new payment methods can be added by following the same rules instead of rebuilding the UI each time.

Payment method shell

Every method uses the same structural

pattern: icon, label, description, selection

state, and dynamic fields.

State-driven forms

The form content changes by method, not by

page. This keeps the checkout frame stable

while the inputs change.

Trust layer

Security messaging and compliance badges

can be reused across product lines without

redesigning each payment page.

What this means for future work

•

New payment methods can be added faster.

•

Method-specific forms stay consistent.

•

Support for regional expansion becomes easier.

•

The design system stays coherent as the product grows.

Product principle

The checkout experience should not become more confusing as the

business grows. The interface should get smarter, not busier.

The user sees a simple checkout. The system handles the complexity in the background.

Final note

This project was about more than cleaner screens. It was about turning a technically complex gateway into a structured checkout system that can grow with the product. The same framework now supports saved cards, express payments, regional methods, trust cues, and desktop scale without breaking the experience.