EasyPark / ArriveApple Pay as a stored payment method

Context

EasyPark inherited different Apple Pay implementations after the EasyPark/ParkMobile acquisition. The same Apple Pay button meant different things depending on whether the user was in a subscription, a single session, or camera parking — and in the US app it was broken entirely, re-authorising on every transaction.

Challenge

The core trust problem: when a user has multiple cards in Apple Wallet, the build showed duplicate 'Apple Pay · Visa' rows with no card number. Users couldn't tell which card mapped to which entry. Trust breaks at the payment decision moment, and EU and US had diverging grace-period policies that couldn't be forced into a single flow.

My role

Senior product designer in #pay. I owned the payment-profile model redesign, the Maze testing methodology, and the EU/US policy split design.

What I changed

• Moved from hardcoded instant payment flows to a recurring MIT (Merchant Initiated Transaction) model. Once Apple Pay is enabled it behaves as a stored payment method — no re-authorisation across subscriptions, parking, and camera parking. Same logic, same component, same user expectation everywhere.
• Designed a 3-variant Maze test (single button / multi-entry / multi-entry with last-4 digits) plus a 5-question mental-model survey. Built specifically to separate stated preference from measurable selection accuracy — because those two things regularly diverge. 30 responses, 33/33/33 rotation.
• Designed two flows sharing the same component library but diverging on EU vs US grace-period policy. Cleaner to ship two truthful flows than one false harmony covering both.

Outcome

Apple Pay B2C moves from broken inconsistent to a single recurring MIT model. Q2 implementation target. Maze test: 30 responses collected — pull Maze report before quoting variant winner externally.