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

Senior 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.