EZ-Pay+
Payment flows, and the configuration that builds them
Role
Product Designer
Summary of the project
EZ-PAY+ was built for recurring account balances. For the February 2026 launch it was extended to one-time payments such as invoices, orders and open amounts. I designed the order flow and the configuration that generates it.
The why
An account balance tells you what you owe. An order doesn’t. Someone buying a licence has no account, no history and no balance just an item, a price, and one question: did it go through?
Tools used
Userflow & Information Architecture
A payable type is a template. Someone configures it once in ConfigHQ, setting business units, items and prices, quantity limits and the details to capture. The checkout is built from that.
Design systems
Forge is KUBRA’s shared design system, used across both the products clients pay through and the internal tools that configure them. A checkout wants one decision per screen; a configuration tool wants density and speed.
I built the components this launch needed, kept others local to the product where generalising would have cost the system more than it returned, and decided which was which.
Outcome
4
payable types designed end to end: account, invoice, order, freeform
8
payment obligation types now supported
6
payment methods including Apple Pay, Google Pay and PayPal
Feb 2026
shipped across utilities, government and municipalities
shipped February 12, 2026 · expanded from account balances to invoices, orders and open amounts · live across utilities, government and municipalities covers taxes, permits, licences, tickets, fines, fees, donations and purchases. Apple Pay, Google Pay and PayPal supported (PCI Level 1).
Three billion interactions a year and 40% of U.S. and Canadian households.
