VeloBank Highway Payments
Bringing automatic highway toll payments into a banking app used by over a million customers.
Scale
1M+
mobile app customers
Role
Product Designer
Timeline
6 mo.
design to launch
Overview
VeloBank customers can now drive through motorway gates without stopping. I designed the service that connects their bank account to AutoPay, from activation to unpaid-toll recovery, and it shipped to over a million mobile app users.
Context: tolls lived outside the app where the money was
VeloBank is one of Poland's largest retail banks. To pay for a motorway, its customers had to stop at a booth or manage a separate AutoPay account.
AutoPay already charged nearly 2 million drivers automatically by reading licence plates at the gate.[1]
The goal
Bring that service where money already lives, without breaking the app's design system or its trust.
Constraints: an external backend and a design system I didn't own
- Someone else's design system.
Every component needed VeloBank's approval. - AutoPay owned the backend.
Their specs defined much of the product logic. - One designer, two organisations.
VeloBank and AutoPay, at the same time.
Approach: locking scope before opening Figma
With a bank and an external payment provider involved, unclear boundaries would have cost weeks. So before designing a single screen, I mapped the full service and agreed with VeloBank and AutoPay what the feature would and would not do. AutoPay's data model then directly shaped vehicle management and trip history.
Research with drivers grounded the flows in how they actually pay for motorways today, and I validated the key paths (activation, adding a vehicle, paying an unpaid toll) in usability tests with users, iterating on the designs before handoff.
Key decisions
1. Four entry points, not one
A dashboard banner for discovery, a shortcut for repeat trips, a full section under Services and a shortcut before login, rather than a single menu item. A new service has to be found once, then reached fast every time.
2. Unpaid tolls are fixed inside the bank
Instead of sending users to AutoPay or support, every passage shows its status and an unpaid one can be paid in place. If the user waits, AutoPay retries the charge and the service stays limited until it's paid.
3. Reuse before adding
I adapted existing VeloBank components first and proposed new ones only with written rationale. It kept the service native and sped up the bank's approvals.
Solution: one journey, including when payments fail
The service covers activation with AutoPay consent, vehicle management, trip history with payment status, and settings for the linked account, invoices and complaints.
I also designed every unhappy path a driver could hit, from failed activation to an unpaid passage. Each one tells the user what happened and what to do next.
Impact: shipped on schedule and still growing
Launched to over a million mobile app users with no critical bugs.[1]
The service is still live and has grown since: in April 2025 the A2 (Poznań–Konin) joined the A1 and A4.[2]
Reflection: what I learned
- An external backend is a design material. Reading AutoPay's specs early told me what was possible faster than any workshop, and turned their constraints into design input instead of late surprises.
- Two organisations need one shared artefact. The service map became the reference both teams argued over, so disagreements surfaced in a diagram, not in finished screens.
- Tests catch what reviews don't. Stakeholder reviews checked compliance and consistency; only sessions with users showed where the wording and order of steps actually confused people.
- Plan for measurement from day one. Next time I'd agree on success metrics and analytics events before launch, so the impact could be shown in numbers, not just in shipping.