Payment UX · Product Design 2024

Integrating Apple & Google Pay into Allstate's checkout — without breaking what works

Company
Allstate
Role
Lead UX Designer · Researcher
Timeline
~3 months (MVP)
Tools
Figma · Mural · UserZoom
Allstate Apple / Google Pay Integration
Overview
The Problem
Allstate's checkout didn't support digital wallets — leaving modern payment methods off the table while competitors began offering them. Payment abandonment from inefficient flows was costing conversions.
Key Constraints
  • Legal/compliance requirements on payment flow sequencing
  • e-signature placement tied to backend billing calculations
  • Apple/Google Pay tokenization limits design flexibility
  • 3-month MVP timeline with live production impact
Approach
Minimally redesign the checkout flow to accommodate digital wallets while maintaining compliance, high usability, and user confidence. Map constraints with engineering before sketching a single screen.
Background
Business Challenge
Competitive pressure to support modern payment methods without disrupting existing workflows or legal compliance. Allstate needed to reduce payment abandonments from first-time users, reduce payment failures through existing gateway methods, and cut cancellations from delayed payments for service and existing customers.
UX Goal
Minimally redesign the flow and design to accommodate Apple/Google Pay while maintaining compliance, high usability, and high user confidence. Avoid disrupting the existing checkout for the vast majority of users who use legacy payment methods.
User Pain Points
First-time users: e-signature requirements ahead of payment authorization added unexpected friction. The current payment method didn't align with familiar digital wallet patterns, and users lacked trust signals for security.

Existing/service customers: Inefficient payment management flow didn't map to available modern methods, creating unnecessary re-entry friction.
Scope
Focused on minimal disruption to existing sales/service flows to meet legal/technical constraints. Prioritized web-view integration for native mobile apps due to development timelines. Explicitly scoped out full payment gateway redesign — deferred to future roadmap.
Research & Process
Map constraints before designing anything.
01 — Competitive Audit
Market Analysis
Analyzed insurance players like Progressive to understand how competitors handled 3rd-party wallets — identifying gaps Allstate could learn from and patterns to avoid.
02 — Technical Workshops
Engineering Alignment
Biweekly sessions with engineers and PMs to map front/backend flows and constraints — e-signature placement, billing calculation sequencing, and tokenization process — before any design decisions were made.
03 — Guidelines Research
Platform Standards
Deep dive into Apple/Google Pay HCI guidelines and technical requirements to understand what was mandated (paymarks, button styles, tokenization) vs. what could flex to fit Allstate's system.
Competitive Audit — Digital Wallet Support
Competitor
Wallet Support
Scope
Model
Progressive
Full Support
FTU + existing customers
Checkout model
GEICO
Not Offered
Farmers Insurance
Partial
Service (existing) only
Checkout model
State Farm
Partial
Service (existing) only
Checkout model
Competitive audit — only Progressive offered full digital wallet support across both FTU and service flows, confirming a market gap and validating the business case for Allstate's integration.
Design scope mapping — constraints and opportunities
Scope mapping — constraints, technical limitations, and design opportunities surfaced from workshops
Technical Collaboration
Workshops with engineering ran before any design work started.
Biweekly engineering workshops as a design tool
Rather than handing off designs to engineering, I ran biweekly workshops to align on API call sequences, backend processes (tokenization), and error-handling solutions before designing. This prevented late-stage rework and surfaced constraints that would have killed multiple design directions — including a tokenization sequence that locked the placement of payment method selection entirely.
Workshop Progression — How the Technical Understanding Evolved
01
Baseline
User Flow
Policies
selected
Select payment
method (list)
Enter Payment
information
Authorize
payment
e-sign
forms
Review /
checkout
Confirmation
Starting point: the existing 6-step payment flow mapped as a simple linear sequence — a shared baseline before any backend complexity was introduced.
02
Backend
Architecture
Backend processes
Payment Details page
We collect sent Payment method intent — apple pay
the CTA button will trigger the SDK to access the wallet
T&Cs
e-sign
review
"buy now" CTA
Confirmation Onboarding
we will not be able to reuse this payment for a new one time payment
consumer will need to select each and every time (FTU first time payment)
we need content to communicate
The ZTM session to trigger authentication should be in the payment/authorization detail view. The SDK already triggers the authentication prompt from that page
payments SDK facilitates the tokenization of the payment method
money ball token created
send actual transaction to Moneyball
payment processing (response to BPO)
Issue Policy + Billing Account
for auto pay and recurring payments, we will store the policy after what has been built
this should be seamless for the customer
Engineering workshops expanded each step to expose backend dependencies — SDK triggers, Moneyball tokenization, BPO processing, and billing account creation. This layer directly constrained design decisions.
Backend–UX
Layer Map
Select Payment
Method
Payment Details Page
SDK trigger
Token init
Enter Payment
Information
Token Creation
Moneyball SDK
Payment tokenized
Authorize
Payment
Transaction
Send to Moneyball
BPO response
e-Sign
Forms
T&Cs / Legal
e-Sign trigger
Review step
Review /
Checkout
"Buy Now" CTA
Issue Policy
Billing Account
Confirmation
Onboarding
Policy active
Receipt sent
Each user-facing step mapped to its backend dependencies — SDK triggers, Moneyball tokenization, BPO processing, and billing account creation. This layer directly constrained design decisions.
03
Dev
Validation
SDK Test Harness ✓ Passed
Apple Pay v1.0.9
🍎 Buy with Apple Pay
Token stored & passed
Payment authorized
Braintree gateway confirmed
SDK Test Harness ✓ Passed
Google Pay v1.0.4
G Pay VISA •••• 0076
Token stored & passed
Payment authorized
Braintree gateway confirmed
Both SDKs tested end-to-end in a dev environment before any design was finalized — confirming tokenization, payment authorization, and Braintree gateway response handling worked as expected.
04
Screen
Implementation
Payment Details
Select method (list)
Wallet Sheet
Modal (native OS)
Authorization
Payment confirmed
Legal Forms
e-Sign (may be multiple)
Review / Checkout
Confirm + complete
Technical constraints from phases 1–3 directly shaped the screen sequence — tokenization timing locked payment method selection to step one, and e-signature placement was resolved before authorization based on legal requirements.
Key Design Decisions
Four decisions that shaped the integration.
01
Minimal disruption over ideal-state redesign
The temptation was to fix everything at once — e-signature friction, payment sequencing, the entire checkout. Instead, we scoped tightly: add digital wallet support without touching what works. This required understanding backend constraints before sketching a single screen.

Workshop finding: tokenization required a specific API call sequence that locked the placement of payment method selection — this single constraint shaped the entire integration.
Constraint-first Design
02
Text-based wallet branding, no inline paymarks
Apple and Google require branded affordances. Initial designs embedded paymarks (logo icons) inline in the payment selector. Testing showed this created a 12% accuracy drop — users confused the logos with action items rather than payment identifiers.

Solution: Use branded button language ("Buy with Apple Pay") without inline icon marks. Cleaner, compliant, and validated to outperform non-branded CTAs by 20%.
Branding vs. Clarity
03
Error handling designed before happy path
Payment integrations between Allstate's gateway and third-party wallet systems create a new category of failure states. Fraud prevention, token expiry, and declined authorizations needed clear, recoverable error messages that respected both systems' requirements.

Process: Mapped every failure mode with engineers in workshops before designing the success state — ensuring recovery flows were native to the checkout, not bolted on.
Error-first Approach
04
Web-view first for mobile to hit the timeline
Native mobile development timelines made a full native implementation infeasible for MVP. A web-view integration approach let us ship to iOS and Android users without parallel native development sprints.

Design implication: All error states and payment selectors were designed for constrained mobile viewports, with tap targets and information hierarchy optimized for thumb navigation.
Platform Strategy
Design Work
From concepts to a constrained, tested solution.
Initial design concepts for Apple/Google Pay integration

Initial Design Concepts

Explored multiple approaches for payment selector integration, balancing Apple/Google Pay guidelines with Allstate's existing design system.

  • Mapped 3 distinct layout approaches for payment method selection
  • Stress-tested how digital wallet buttons coexist with legacy card entry
  • Evaluated paymark placement options against Apple/Google compliance requirements
Design iterations and refinement

Iterative Refinement

Focused on optimizing user feedback mechanisms through visual and microcopy refinements. Collaborated with the design system team and engineering partners to ensure each iteration was technically feasible.

  • Removed paymarks after discovering 12% accuracy drop in testing
  • Refined button copy to balance Apple/Google branding with Allstate's voice
  • 3 full iteration rounds with engineering review between each
Additional user flows and case scenarios

Flow Mapping: All User Scenarios

Mapped user flows for new customer journeys, service flows, and payment updates — ensuring consistent experience across web, mobile web-views, and native app contexts.

  • New customer (FTU) with e-signature gate before payment authorization
  • Existing customer updating payment method in service flow
  • Failed payment and retry scenarios with wallet fallback
Error state designs

Error States & Edge Cases

Designed comprehensive error handling for the intersection of Allstate's payment gateway and third-party wallet systems — a new failure mode category that didn't exist in the previous checkout.

  • Fraud-prevention messaging co-designed with engineering
  • Token expiry and declined authorization states with clear recovery paths
  • Wallet unavailable fallback to legacy payment method
Mobile error implementation on iPhone

Mobile Implementation

All error states were optimized for native mobile web-view constraints — constrained viewport, thumb navigation, and no keyboard accessibility assumptions.

  • Tap targets sized for mobile interaction patterns
  • Error messages legible at mobile text sizes without truncation
  • Quick recovery actions visible above fold on small viewports
Final Payment Architecture
The integrated flow, without disrupting the existing checkout.
Final payment flow architecture
Final payment flow — Apple/Google Pay integrated without disrupting existing checkout sequencing or legal requirements
Usability Testing & Validation
Heatmap analysis surfaced the paymarks decision.
Checkout page heatmap
Checkout Page — Attention Distribution Without paymarks, user attention concentrated on the payment selector CTA — reducing misclicks on adjacent legal text
Payment selector heatmap
Payment Selector — Interaction Hotspots Users fixated on branded button text rather than inline icons, confirming the no-paymark design direction
Test results — impact of design changes
Test results — branded buttons vs. no-paymark design across task success and user confidence metrics
Key Insight
"Branded payment buttons (e.g., 'Buy with Apple Pay') outperformed non-branded CTAs by 20% — but paymarks confused users when embedded inline in the selector, dropping accuracy by 12%."
Testing Takeaway
Branded payment buttons significantly outperformed non-branded CTAs by 20% in task success. Removing inline paymarks improved accuracy by 12% — confirming that users prefer text-based branded affordances over embedded icons, particularly in insurance checkout flows where trust signals matter more than visual shorthand.
Outcomes & Impact
Shipped in 3 months. Built the case for what comes next.
92%
Transaction success rate
6/7
User confidence rating
50%
Fewer steps for wallet users
25%
Expected time reduction
<3mo
MVP to production
What we proved
Rapid research cycles validated the design before launch — preventing a sprint of post-release rework.
The paymarks finding alone — discovered in testing, not after launch — saved the team an estimated sprint of redesign. The ROI of short research cycles was concrete and measurable.
Strategic Impact
  • Exposed design system limitations for scaling 3rd-party integrations (PayPal, Visa)
  • Sparked leadership discussion about overhauling the payment gateway for future flexibility
  • Mentored a junior designer in cross-functional UX strategy
  • Demonstrated ROI of rapid research cycles — findings validated before launch, not after
New payment method, live
Launched Apple/Google Pay to Allstate's web and mobile web-view checkout with 92% task success rate and 90% usability success rate in post-launch monitoring.
User confidence maintained
Achieved 6/7 user confidence rating for digital wallet transactions — on par with existing credit card checkout — despite adding a new payment system and authentication layer.
Design system conversations unlocked
The project exposed design system limitations for scaling 3rd-party integrations. Findings were presented to leadership and sparked active conversations about payment gateway modernization.
Research ROI demonstrated
Rapid research cycles (competitive audit → workshops → usability testing) prevented post-launch rework. The paymarks finding alone saved an estimated sprint of redesign.
Future Roadmap
Design System Update
Advocate for a design system update to support 3rd-party schema — branded elements, error states, and token-based UI patterns for future integrations like PayPal and Venmo.
Payment Flow Overhaul
Explore phased overhaul of payment flows to reduce e-signature friction for first-time users — the constraint that limited this project's scope but consistently surfaced as the top pain point.