Back to Work

Credit Card Servicing Integration

Oportun

Post-acquisition UX overhaul for a fintech lender serving 2M+ members

Credit Card Servicing Integration

Executive Summary

Following Oportun's acquisition of Hello Digit, the company faced a structural integration problem: credit card servicing needed to live inside an existing lending app with no shared design language, no unified component system, and no established mobile pattern for blended financial products. In a two-week sprint, I led the credit card servicing workstream - defining end-to-end servicing architecture, building the regulated payment status hierarchy, and extending the design system with native iOS and Android components - establishing the structural and visual foundation the broader team built the March 2023 unified app launch on.

Measured Impact

Unified credit card servicing within a multi-product mobile ecosystemEnabled seamless post-acquisition integration across lending and banking

Native iOS and Android flow standardizationEstablished consistent servicing architecture across native apps

Design System (DSM) extension for credit workflowsImproved scalability and reduced implementation ambiguity

4.7/5 App Store rating (289K+ ratings)*Sustained post-launch rating reflecting member trust in the unified mobile experience following the March 2023 relaunch

4.0–4.1/5 Google Play rating | 1M+ downloads*Broad adoption across both native platforms, supporting the viability of the cross-product integration at scale

* These ratings reflect the full unified app following the March 2023 relaunch, not the credit servicing module in isolation.

Overview

As senior designer on the credit card servicing sprint, I owned the credit card module end-to-end - flow mapping, information architecture, status hierarchy, wireframing, high-fidelity execution, and design system extension - while parallel workstreams covered personal loan and banking surfaces. The core constraint was integrating a new product type without creating redundant complexity or diverging from existing loan servicing architecture, while simultaneously satisfying regulated payment state requirements and native platform behavior across iOS and Android.

  • Supported Devices: iOS and Android (native apps)
  • Timeline: July 2022 sprint (full app launch: March 2023)
  • Primary Audience: Existing Oportun members, potential users seeking accessible credit tools, internal stakeholders

Discovery

Exploration & Wireframing

  • Benchmarked Capital One, Discover, and Chase to map how leading apps handled payment status visibility, scheduling flows, and funding source setup - establishing a baseline for what members would expect from a regulated credit servicing experience.
  • Partnered with research to run user interviews and usability testing. Key findings: payment status was the highest-anxiety touchpoint, scheduling friction caused drop-off, and funding source setup lacked clarity around timing and confirmation. Each finding mapped directly to a design decision in the status hierarchy and payment flow architecture.

Flow Diagram

End-to-end servicing architecture mapping account setup, payment flows, transaction history, status handling, and support - used to align product and engineering on shared infrastructure versus credit-specific flows, and to identify where existing loan servicing patterns could be reused without duplication.

Diagram mapping out the various functions of the credit card section.

Diagram mapping out the various functions of the credit card section.

Research Insights

Validated core flows against internal usability testing, agent manuals, and competitor benchmarks. Three high-priority friction points emerged: ambiguous payment status labeling, unclear date constraints in scheduling flows, and insufficient feedback on funding source linkage - each shaping specific design decisions in the status card system and auto-pay enrollment flow.

Design

Exploration & Wireframing

  • Built low-fidelity wireframes to establish navigation structure, information hierarchy, and core layout patterns across account overview, payment flows, and transaction detail - prioritizing structural clarity before moving to visual resolution.
  • Explored three credit card offer treatments (dismissible card stacks, minimal persistent banners, full-screen empty states) to evaluate the tradeoff between monetization visibility and task-flow continuity - keeping offers accessible without disrupting primary payment and balance management tasks.
Diagram mapping out the various functions of the credit card section 1
Diagram mapping out the various functions of the credit card section 2

Sketches exploring layout hierarchy, information structure, and credit card offer treatments.

Status Card Scenarios

Regulated payment states carry legal and behavioral implications - an ambiguous "due soon" state can result in missed payments and downstream member harm. The status hierarchy was designed to make each state immediately distinguishable through restrained color differentiation, typographic weight, and spatial hierarchy rather than relying on color alone, which would fail accessibility requirements. The three states - payment current, payment due, and auto-pay active - each communicate a distinct urgency level and required next action without requiring the member to navigate away from the account overview.

Payment current

Auto pay enabled

Payment due

Scalability & Efficiency

Identified gaps in the existing DSM where native credit card servicing patterns had no precedent, then built out iOS and Android component extensions covering status cards, payment confirmation states, funding source UI, and auto-pay enrollment. Facilitated cross-functional reviews with product and engineering to validate that extended components were implementable within the sprint timeline and compatible with the existing loan servicing architecture.

Auto-Pay Enrollment Flow

One production-ready servicing workflow within the broader credit module, demonstrating structured decision design, state management, and constrained scheduling logic. The sequence reflects a complete recurring payment path built on the same architectural foundation used across all servicing scenarios.

Step 1 - Activation Nudge

Step 1 - Activation Nudge

Account overview surfaces a recurring payment prompt within the primary status hierarchy. The placement preserves balance visibility and next-action clarity while introducing enrollment at a moment of decision.

Step 2 - Recurring Amount Configuration

Step 2 - Recurring Amount Configuration

Members define a scheduled amount with clear state confirmation and required disclosures. The configuration layer prioritizes transparency and prevents ambiguity in recurring financial commitments.

Step 3 - Statement Aligned Date Selection

Step 3 - Statement Aligned Date Selection

Date selection is constrained to valid billing cycles to prevent scheduling errors. Guardrails reinforce statement timing and reduce the risk of missed or misaligned payments.

Step 4 - Linked Account Entry

Step 4 - Linked Account Entry

Funding source connection is embedded directly within the enrollment flow. Maintaining context reduces drop-off and streamlines completion of the recurring setup.

Production

  • Sequenced handoff by flow priority - account overview and payment flows first, followed by edge states and advanced features - maintaining delivery velocity without sacrificing quality on high-traffic, regulated interactions.
  • Resolved platform parity by building against native iOS and Android constraints simultaneously rather than adapting one platform from the other, reducing implementation drift in regulated payment states across both ecosystems.
  • Core account overview, payment flow, and status hierarchy shipped first; auto-pay enrollment, secure payment, and transaction detail were scoped as a second layer using the DSM extension as a shared foundation.

Decisions & Trade-offs

  • Advanced servicing: anchored status card as persistent entry point - advanced features one tap away, invisible during primary review
  • Cross-platform parity: DSM extensions respected platform-native behavior (bottom sheets iOS, dialogs Android) while maintaining visual consistency across credit elements
  • Sprint prioritization: ordered by member frequency and regulatory risk - payment and status first, edge cases second - reusable patterns reduced per-screen design time
  • Credit integration: mapped shared vs. credit-specific structures upfront - one design system, no parallel patterns, no inconsistent shared components

Synthesis

The sprint constraint forced a clarity that longer timelines often erode. By anchoring every decision to either member trust (status hierarchy, payment clarity) or system scalability (DSM extension, shared flow architecture), the servicing module landed as a coherent, extensible foundation rather than a bolt-on feature. The March 2023 launch validated that the patterns held - credit servicing, loan servicing, and banking operating within a single navigation structure without requiring members to context-switch between product-specific mental models.

Next Project

Back to Work

Credit Card Servicing Integration

Oportun

Post-acquisition UX overhaul for a fintech lender serving 2M+ members

Oportun Financial Credit Card Servicing Integration

Executive Summary

Following Oportun's acquisition of Hello Digit, the company faced a structural integration problem: credit card servicing needed to live inside an existing lending app with no shared design language, no unified component system, and no established mobile pattern for blended financial products. In a two-week sprint, I led the credit card servicing workstream - defining end-to-end servicing architecture, building the regulated payment status hierarchy, and extending the design system with native iOS and Android components - establishing the structural and visual foundation the broader team built the March 2023 unified app launch on.

Overview

As senior designer on the credit card servicing sprint, I owned the credit card module end-to-end - flow mapping, information architecture, status hierarchy, wireframing, high-fidelity execution, and design system extension - while parallel workstreams covered personal loan and banking surfaces. The core constraint was integrating a new product type without creating redundant complexity or diverging from existing loan servicing architecture, while simultaneously satisfying regulated payment state requirements and native platform behavior across iOS and Android.

  • Supported Devices: iOS and Android (native apps)
  • Timeline: July 2022 sprint (full app launch: March 2023)
  • Primary Audience: Existing Oportun members, potential users seeking accessible credit tools, internal stakeholders

Discovery

Exploration & Wireframing

  • Benchmarked Capital One, Discover, and Chase to map how leading apps handled payment status visibility, scheduling flows, and funding source setup - establishing a baseline for what members would expect from a regulated credit servicing experience.
  • Partnered with research to run user interviews and usability testing. Key findings: payment status was the highest-anxiety touchpoint, scheduling friction caused drop-off, and funding source setup lacked clarity around timing and confirmation. Each finding mapped directly to a design decision in the status hierarchy and payment flow architecture.

Flow Diagram

End-to-end servicing architecture mapping account setup, payment flows, transaction history, status handling, and support - used to align product and engineering on shared infrastructure versus credit-specific flows, and to identify where existing loan servicing patterns could be reused without duplication.

Diagram mapping out the various functions of the credit card section.

Diagram mapping out the various functions of the credit card section.

Research Insights

Validated core flows against internal usability testing, agent manuals, and competitor benchmarks. Three high-priority friction points emerged: ambiguous payment status labeling, unclear date constraints in scheduling flows, and insufficient feedback on funding source linkage - each shaping specific design decisions in the status card system and auto-pay enrollment flow.

Design

Exploration & Wireframing

  • Built low-fidelity wireframes to establish navigation structure, information hierarchy, and core layout patterns across account overview, payment flows, and transaction detail - prioritizing structural clarity before moving to visual resolution.
  • Explored three credit card offer treatments (dismissible card stacks, minimal persistent banners, full-screen empty states) to evaluate the tradeoff between monetization visibility and task-flow continuity - keeping offers accessible without disrupting primary payment and balance management tasks.
Sketches exploring layout hierarchy, information structure, and credit card offer treatments - image 1
Sketches exploring layout hierarchy, information structure, and credit card offer treatments - image 2

Sketches exploring layout hierarchy, information structure, and credit card offer treatments.

Status Card Scenarios

Regulated payment states carry legal and behavioral implications - an ambiguous "due soon" state can result in missed payments and downstream member harm. The status hierarchy was designed to make each state immediately distinguishable through restrained color differentiation, typographic weight, and spatial hierarchy rather than relying on color alone, which would fail accessibility requirements. The three states - payment current, payment due, and auto-pay active - each communicate a distinct urgency level and required next action without requiring the member to navigate away from the account overview.

Payment current

Auto pay enabled

Payment due

Scalability & Efficiency

Identified gaps in the existing DSM where native credit card servicing patterns had no precedent, then built out iOS and Android component extensions covering status cards, payment confirmation states, funding source UI, and auto-pay enrollment. Facilitated cross-functional reviews with product and engineering to validate that extended components were implementable within the sprint timeline and compatible with the existing loan servicing architecture.

Auto-Pay Enrollment Flow

One production-ready servicing workflow within the broader credit module, demonstrating structured decision design, state management, and constrained scheduling logic. The sequence reflects a complete recurring payment path built on the same architectural foundation used across all servicing scenarios.

Step 1 - Activation Nudge

Account overview surfaces a recurring payment prompt within the primary status hierarchy. The placement preserves balance visibility and next-action clarity while introducing enrollment at a moment of decision.

Step 2 - Recurring Amount Configuration

Members define a scheduled amount with clear state confirmation and required disclosures. The configuration layer prioritizes transparency and prevents ambiguity in recurring financial commitments.

Step 3 - Statement Aligned Date Selection

Date selection is constrained to valid billing cycles to prevent scheduling errors. Guardrails reinforce statement timing and reduce the risk of missed or misaligned payments.

Step 4 - Linked Account Entry

Funding source connection is embedded directly within the enrollment flow. Maintaining context reduces drop-off and streamlines completion of the recurring setup.

Production

  • Sequenced handoff by flow priority - account overview and payment flows first, followed by edge states and advanced features - maintaining delivery velocity without sacrificing quality on high-traffic, regulated interactions.
  • Resolved platform parity by building against native iOS and Android constraints simultaneously rather than adapting one platform from the other, reducing implementation drift in regulated payment states across both ecosystems.
  • Core account overview, payment flow, and status hierarchy shipped first; auto-pay enrollment, secure payment, and transaction detail were scoped as a second layer using the DSM extension as a shared foundation.

Decisions & Trade-offs

  • Advanced servicing: anchored status card as persistent entry point - advanced features one tap away, invisible during primary review
  • Cross-platform parity: DSM extensions respected platform-native behavior (bottom sheets iOS, dialogs Android) while maintaining visual consistency across credit elements
  • Sprint prioritization: ordered by member frequency and regulatory risk - payment and status first, edge cases second - reusable patterns reduced per-screen design time
  • Credit integration: mapped shared vs. credit-specific structures upfront - one design system, no parallel patterns, no inconsistent shared components

Synthesis

The sprint constraint forced a clarity that longer timelines often erode. By anchoring every decision to either member trust (status hierarchy, payment clarity) or system scalability (DSM extension, shared flow architecture), the servicing module landed as a coherent, extensible foundation rather than a bolt-on feature. The March 2023 launch validated that the patterns held - credit servicing, loan servicing, and banking operating within a single navigation structure without requiring members to context-switch between product-specific mental models.

Next Project

Measured Impact

Unified credit card servicing within a multi-product mobile ecosystemEnabled seamless post-acquisition integration across lending and banking

Native iOS and Android flow standardizationEstablished consistent servicing architecture across native apps

Design System (DSM) extension for credit workflowsImproved scalability and reduced implementation ambiguity

4.7/5 App Store rating (289K+ ratings)*Sustained post-launch rating reflecting member trust in the unified mobile experience following the March 2023 relaunch

4.0–4.1/5 Google Play rating | 1M+ downloads*Broad adoption across both native platforms, supporting the viability of the cross-product integration at scale

* These ratings reflect the full unified app following the March 2023 relaunch, not the credit servicing module in isolation.