I led the design of Zipcar’s multi-card wallet across the app and Member Web. A single failed card could interrupt service. We introduced payment choice and backup payments, with clear rules for which card gets charged and what happens when it fails.

A wallet needs rules, not just more cards

I defined how default, alternative, expired, and removable cards behaved across app and web. When Edit was removed from scope, a default card had no remaining actions. I removed the empty menu instead of leaving an affordance that went nowhere, and worked through the matching app behavior with engineering.

Give payment management a home in the app

Wallet brought payment management into the app. You could see your cards, identify the default, and find only the actions available for each card’s state.

Use the same payment model across app and web

We considered keeping payment tools on the web Overview page. A dedicated Wallet gave the growing set of cards and backup controls a clearer home, with the same rules as the app.

Explain backup payments when a second card makes them useful

After you add a card, I placed an explicit choice to turn on backup payments. The promise is plain: if a payment fails, Zipcar can retry another payment method on your account. You can choose Not Now instead. This connects recovery to consent, rather than making fallback charging a surprise.

Change payment without abandoning checkout

I reviewed familiar payment selectors in other apps and proposed a vertically stacked list of saved cards and digital wallets. It made the default visible and left room to add a card during checkout. This was pattern research, not a moderated usability study.

One default rule is clearer than two competing promises

We dropped “Save for future bookings” because it competed with choosing a default card. Fewer controls made it easier to understand which payment method would be used next.