Apple Pay as a stored payment method

Context

Arrive is the group brand unifying EasyPark (90 countries, 20,000+ cities) and ParkMobile (50M+ users, 550 US cities). After the acquisition, the two products inherited different Apple Pay implementations. The same Apple Pay button behaved differently depending on whether the user was starting a subscription, a single parking session, or a camera parking session. In the US app, Apple Pay was broken entirely, re-authorising on every transaction rather than behaving as a stored payment method.

Challenge

Two separate problems that shared a root cause. First: the trust problem at the payment decision moment. When a user has multiple cards in Apple Wallet, the existing build showed duplicate 'Apple Pay · Visa' rows with no card number. Users couldn't tell which card mapped to which entry. Trust breaks exactly here, at the moment of payment confirmation. Second: EU and US had diverging grace-period policies on failed payments. EU blocks the account; the US had no policy. Forcing a single flow to cover both policies would have produced a flow that was accurate for neither.

My role

Lead product designer in the payments team. I owned the payment-profile model redesign, the Maze testing methodology for the duplicate-card trust problem, and the EU/US policy split design. I worked directly with iOS and Android engineering, UX research, and the PM across both markets.

What I changed

• Redesigned the Apple Pay layer around a recurring MIT (Merchant Initiated Transaction) payment-profile model. Once Apple Pay is enabled, it behaves as a stored payment method across all product types, no re-authorisation per session, no inconsistency between subscriptions and single sessions. Same logic, same component, same user expectation everywhere.
• Designed a 3-variant Maze test to resolve the duplicate-card trust problem: Variant A (single Apple Pay button with card picker inside), Variant B (multiple entries, current behaviour, no card number), Variant C (multiple entries with last-4 digits shown). Added a 5-question mental-model survey to run in parallel. The test was explicitly designed to separate stated preference from measurable selection accuracy, because those two signals regularly diverge, and making a decision based on only one of them is a known failure mode.
• Designed two flows sharing the same component library but diverging on grace-period policy. EU flow: intercepts the user before the parking flow, not after confirmation, shows the exact outstanding amount with a direct recovery action. US flow: hard vs soft decline split, progressive in-app banners over 3-5 days, web-managed fallback for the 30% of US users who only have Apple Pay and cannot update payment details in-app.

Outcome

Apple Pay B2C moves from broken and inconsistent to a single recurring MIT model across subscriptions, parking, and camera parking. Q2 implementation target. The Maze test collected 30 responses, results available in the Maze report. The EU and US flows diverge on policy while sharing component infrastructure, which makes each one accurate without requiring a single policy compromise.