Payment & metering
A full e-commerce billing system, built to feel like nothing at all.
Built on HP’s existing payment back-end, so app costs routed to the right place invisibly. No employee ever stopping to “buy” a tool they need for their job. Setup happens once (an HP Web ID sign-in, account creation, terms, and a first billing method) so a purchase later is a single tap. The craft was in the parts users never think about: this, and everything that can go wrong.
HP Secure Pay, sign in / create account
The happy path, and the spec behind it.
The purchase itself is deliberately unremarkable: confirm, done. What isn’t visible on the happy path is the full error-messaging spec sitting underneath it, every card and currency failure state, numbered and written, so nothing shipped as an afterthought.
the happy path, sign in → pay method → card → confirm → download
Designing the failure states, not just the success one.
Enterprise billing crosses cards, accounts, and countries, so the edge cases are the product. Two got dedicated flows.
A dead end that isn’t one.
When a card fails at confirmation, the flow doesn’t strand the user. It routes straight into adding a new credit card or billing account, so a failed purchase becomes a two-tap recovery instead of a restart.
invalid card, declined at confirm, routed straight to adding a new card
The quietly hard one.
A card issued in one currency against a purchase in another is exactly the kind of failure that erodes trust. The flow catches the mismatch, walks the user to add a card of the right currency, and adds a tooltip showing which countries a given card accepts, turning a confusing rejection into a legible next step.
mismatched currencies, add a card of the right currency
First payment method, the second time around.
For an account that already exists, adding a first payment method branches cleanly to either a credit card or a PayPal account, the same two rails, without re-walking sign-up.
existing account, add a first payment method (card or PayPal)
This whole individual-checkout model was later rethought.
Everything above is a consumer-style individual checkout, the right reference for iOS or Android, and the direction the wireframes took. As my contract ended, the model began pivoting to team-based accounting: charges assigned to a person’s team, not paid individually.
Read the full pivot, why the right consumer pattern was the wrong enterprise one