Back to Work
Credit Card Servicing Integration
Oportun
Post-acquisition UX integration for a fintech lender serving 2M+ members
Executive Summary
Following Oportun's acquisition of Hello Digit, the company needed to integrate credit card servicing into an existing lending app without a shared design language, a unified component system, or an established mobile pattern for blended financial products. The risk was not just a poor user experience. It was a fragmented integration that would make the March 2023 unified app launch untenable and require members to navigate incompatible mental models across products in the same app.
In a two-week sprint, I led the credit card servicing workstream, defining the end-to-end servicing architecture, building the regulated payment status hierarchy, and extending the design system with native iOS and Android components that became the foundation for the March 2023 unified app launch.
Measured Impact
4.7/5 App Store rating (289K+ ratings)*Sustained post-launch rating reflecting member trust following the March 2023 relaunch.
4.1/5 Google Play rating | 1M+ downloads*Broad adoption across both platforms at scale.
Credit card servicing integrated into a multi-product mobile ecosystemUnified lending, banking, and credit under a single app without fragmenting the member experience.
Native iOS and Android design system extension establishedReduced implementation ambiguity and prevented platform drift across both native platforms.
*These ratings reflect the full unified app following the March 2023 relaunch, not the credit servicing module in isolation.
Overview
Each member at Oportun was already served through a native app with established loan servicing patterns. The Hello Digit acquisition added a credit card product with no design precedent in the existing system: different payment behaviors, different regulatory requirements, different status states, and different user mental models around balance management versus loan repayment.
The integration required mapping where the credit architecture could share infrastructure with the existing loan servicing system and where it needed its own patterns - without creating parallel component systems or breaking the existing navigation structure.
The sprint timeline forced this mapping to happen upfront rather than iteratively. That constraint shaped every decision in the workstream.
- Supported Devices: Native iOS and Android
- Timeline: Jul 2022 sprint (full app launch: Mar 2023)
- Primary Audience: Existing Oportun members, potential users seeking accessible credit tools
Discovery
Competitive Benchmarking and Workflow Mapping
I benchmarked leading consumer credit card apps to establish a baseline for what members would expect from a regulated credit servicing experience, specifically around payment status visibility, scheduling flows, and funding source setup. This identified the conventions members would arrive with before interacting with Oportun's implementation.
I partnered with research to run user interviews and usability testing. Three friction points emerged as highest priority: payment status was the highest-anxiety touchpoint in the member experience, scheduling flows caused drop-off due to unclear date constraints, and funding source setup lacked clarity around timing and confirmation. Each finding mapped directly to a design decision: the status hierarchy, the date constraint model in scheduling, and the inline funding source connection within auto-pay enrollment.
Flow Architecture
I defined the end-to-end servicing architecture across account setup, payment flows, transaction history, status handling, and support before moving to interface design. This aligned product and engineering on the boundary between shared loan servicing infrastructure and credit-specific flows, and identified where existing patterns could be reused without duplication. This was the primary mechanism for keeping the integration coherent rather than bolt-on.
I also reviewed agent manuals alongside user testing results. Agent data surfaced edge cases in payment scheduling and status labeling that users did not surface in testing: cases where technically accurate labels produced member confusion in practice. This informed the status hierarchy wording specifically.
Diagram mapping out the various functions of the credit card section.
Design
Exploration & Wireframing
- Developed low-fidelity wireframes to explore layout hierarchy, information groupings, and content density across account overview and payment flows.
- Mapped the auto-pay workflow through sketched states to establish step sequencing, decision points, and disclosure placement before moving to high fidelity.
Sketches exploring layout hierarchy, information groupings and density, and auto-pay workflow structure.
Status card and Payment status hierarchy
Payment status in a regulated product carries legal and behavioral implications. An ambiguous label such as 'due soon' without date specificity, or 'processing' without a confirmation timestamp, can lead to missed payments with credit reporting consequences. The status hierarchy was designed so each state is immediately distinguishable using typographic weight, spatial hierarchy, and restrained use of color, ensuring accessibility compliance without relying on color alone.
The three primary states (payment current, payment due, and auto-pay active) communicate urgency and required action without requiring the member to leave the account overview. The status card was anchored as the persistent entry point for the account view because it is the primary trust surface in a regulated payment product. Every other feature is built relative to it.
Payment current
Auto pay enabled
Payment due
Auto-Pay Enrollment Flow
A production ready servicing workflow within the credit module, demonstrating structured decision design, state management, and constrained scheduling logic. The flow represents a complete recurring payment path built on the same architectural foundation used across all servicing scenarios.
Step 1 - Activation Nudge
The account overview surfaces a recurring payment prompt within the primary status hierarchy. Placement preserves balance visibility and next-action clarity while introducing enrollment at a moment of decision rather than as a separate settings task.
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.
Design System Extension
I identified gaps in the existing system where native credit card servicing patterns had no precedent, then created iOS and Android component extensions covering status cards, payment confirmation states, funding source UI, and auto-pay enrollment. The extension used the existing system as its base, adding credit-specific components without duplicating or overriding shared ones.
Production
Handoff
Handoff was sequenced by flow priority: account overview and payment flows delivered first, followed by edge states and advanced features. This maintained delivery velocity while protecting quality on the highest-traffic, regulated interactions.
I built against native iOS and Android constraints simultaneously rather than adapting one platform from the other. Platform parity in regulated payment states, where the legal and behavioral requirements are identical across iOS and Android, required this approach. Adapting from one platform introduces drift at the points where native behavior diverges, which in payment flows creates inconsistent state handling.
Core account overview, payment flow, and status hierarchy shipped first. Auto-pay enrollment, secure payment, and transaction detail were scoped as a second layer built on the design system extension as a shared foundation.
Decisions & Trade-offs
- One design system vs. parallel credit system: A parallel credit-specific component system would have been faster to build in the sprint and would have isolated risk from the existing loan servicing architecture. Extending the existing system was chosen because a parallel system creates a long-term maintenance problem. Two systems diverge, and members experience the inconsistency directly. The sprint constraint made this the harder choice, but the right one for the March launch and for everything built afterward.
- Status card as persistent anchor vs. contextual surfacing: The status card could have been a contextual element surfaced only when a payment was due or overdue. It was anchored as the persistent primary entry point because the member's primary job in a credit servicing app is understanding their payment position at any moment, not just when the system determines it is relevant.
- Simultaneous iOS and Android build vs. platform adaptation: Building both platforms simultaneously required more coordination but prevented the implementation drift that adaptation produces. In regulated payment states, drift creates inconsistent member experiences in legally significant interactions.
- Sprint prioritization: payment flows first: Work was ordered by member frequency and regulatory risk. Payment and status flows were highest on both dimensions. Edge cases and advanced features were sequenced second, built on the component foundation established in the first phase.
- Embedded funding source vs. separate settings flow: Funding source connection during auto-pay enrollment, rather than routing to a separate settings section, was a deliberate continuity decision. Interrupting the enrollment flow to set up a funding source is a known drop-off pattern in recurring payment products. Embedding it kept the task atomic.
Synthesis
The sprint constraint forced a level of clarity that longer timelines often erode. Because there was no time to iterate on the integration model, the mapping of shared versus credit-specific infrastructure had to happen in discovery rather than design. That upfront mapping (determining what the credit module inherited from the existing system and what it needed to own) is what kept the servicing module cohesive rather than fragmentary.
The hardest problem in the project was not designing new patterns. It was determining which existing patterns were reusable without modification, which needed extension, and which would break if applied to credit card behavior. Getting that boundary right in a two-week sprint required the flow mapping and agent manual review to be more rigorous than they would have been with more time. That rigor in discovery is what made the sprint deliverable rather than fragile.
Next Project
Back to Work
Credit Card Servicing Integration
Oportun
Post-acquisition UX integration for a fintech lender serving 2M+ members
Executive Summary
Following Oportun's acquisition of Hello Digit, the company needed to integrate credit card servicing into an existing lending app without a shared design language, a unified component system, or an established mobile pattern for blended financial products. The risk was not just a poor user experience. It was a fragmented integration that would make the March 2023 unified app launch untenable and require members to navigate incompatible mental models across products in the same app.
In a two-week sprint, I led the credit card servicing workstream, defining the end-to-end servicing architecture, building the regulated payment status hierarchy, and extending the design system with native iOS and Android components that became the foundation for the March 2023 unified app launch.
Overview
Each member at Oportun was already served through a native app with established loan servicing patterns. The Hello Digit acquisition added a credit card product with no design precedent in the existing system: different payment behaviors, different regulatory requirements, different status states, and different user mental models around balance management versus loan repayment.
The integration required mapping where the credit architecture could share infrastructure with the existing loan servicing system and where it needed its own patterns - without creating parallel component systems or breaking the existing navigation structure.
The sprint timeline forced this mapping to happen upfront rather than iteratively. That constraint shaped every decision in the workstream.
- Supported Devices: Native iOS and Android
- Timeline: Jul 2022 sprint (full app launch: Mar 2023)
- Primary Audience: Existing Oportun members, potential users seeking accessible credit tools
Discovery
Competitive Benchmarking and Workflow Mapping
I benchmarked leading consumer credit card apps to establish a baseline for what members would expect from a regulated credit servicing experience, specifically around payment status visibility, scheduling flows, and funding source setup. This identified the conventions members would arrive with before interacting with Oportun's implementation.
I partnered with research to run user interviews and usability testing. Three friction points emerged as highest priority: payment status was the highest-anxiety touchpoint in the member experience, scheduling flows caused drop-off due to unclear date constraints, and funding source setup lacked clarity around timing and confirmation. Each finding mapped directly to a design decision: the status hierarchy, the date constraint model in scheduling, and the inline funding source connection within auto-pay enrollment.
Flow Architecture
I defined the end-to-end servicing architecture across account setup, payment flows, transaction history, status handling, and support before moving to interface design. This aligned product and engineering on the boundary between shared loan servicing infrastructure and credit-specific flows, and identified where existing patterns could be reused without duplication. This was the primary mechanism for keeping the integration coherent rather than bolt-on.
I also reviewed agent manuals alongside user testing results. Agent data surfaced edge cases in payment scheduling and status labeling that users did not surface in testing: cases where technically accurate labels produced member confusion in practice. This informed the status hierarchy wording specifically.
Diagram mapping out the various functions of the credit card section.
Design
Exploration & Wireframing
- Developed low-fidelity wireframes to explore layout hierarchy, information groupings, and content density across account overview and payment flows.
- Mapped the auto-pay workflow through sketched states to establish step sequencing, decision points, and disclosure placement before moving to high fidelity.
Sketches exploring layout hierarchy, information groupings and density, and auto-pay workflow structure.
Status card and Payment status hierarchy
Payment status in a regulated product carries legal and behavioral implications. An ambiguous label such as 'due soon' without date specificity, or 'processing' without a confirmation timestamp, can lead to missed payments with credit reporting consequences. The status hierarchy was designed so each state is immediately distinguishable using typographic weight, spatial hierarchy, and restrained use of color, ensuring accessibility compliance without relying on color alone.
The three primary states (payment current, payment due, and auto-pay active) communicate urgency and required action without requiring the member to leave the account overview. The status card was anchored as the persistent entry point for the account view because it is the primary trust surface in a regulated payment product. Every other feature is built relative to it.
Payment current
Auto pay enabled
Payment due
Auto-Pay Enrollment Flow
A production ready servicing workflow within the credit module, demonstrating structured decision design, state management, and constrained scheduling logic. The flow represents a complete recurring payment path built on the same architectural foundation used across all servicing scenarios.
Step 1 - Activation Nudge
The account overview surfaces a recurring payment prompt within the primary status hierarchy. Placement preserves balance visibility and next-action clarity while introducing enrollment at a moment of decision rather than as a separate settings task.
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.
Design System Extension
I identified gaps in the existing system where native credit card servicing patterns had no precedent, then created iOS and Android component extensions covering status cards, payment confirmation states, funding source UI, and auto-pay enrollment. The extension used the existing system as its base, adding credit-specific components without duplicating or overriding shared ones.
Production
Handoff
Handoff was sequenced by flow priority: account overview and payment flows delivered first, followed by edge states and advanced features. This maintained delivery velocity while protecting quality on the highest-traffic, regulated interactions.
I built against native iOS and Android constraints simultaneously rather than adapting one platform from the other. Platform parity in regulated payment states, where the legal and behavioral requirements are identical across iOS and Android, required this approach. Adapting from one platform introduces drift at the points where native behavior diverges, which in payment flows creates inconsistent state handling.
Core account overview, payment flow, and status hierarchy shipped first. Auto-pay enrollment, secure payment, and transaction detail were scoped as a second layer built on the design system extension as a shared foundation.
Decisions & Trade-offs
- One design system vs. parallel credit system: A parallel credit-specific component system would have been faster to build in the sprint and would have isolated risk from the existing loan servicing architecture. Extending the existing system was chosen because a parallel system creates a long-term maintenance problem. Two systems diverge, and members experience the inconsistency directly. The sprint constraint made this the harder choice, but the right one for the March launch and for everything built afterward.
- Status card as persistent anchor vs. contextual surfacing: The status card could have been a contextual element surfaced only when a payment was due or overdue. It was anchored as the persistent primary entry point because the member's primary job in a credit servicing app is understanding their payment position at any moment, not just when the system determines it is relevant.
- Simultaneous iOS and Android build vs. platform adaptation: Building both platforms simultaneously required more coordination but prevented the implementation drift that adaptation produces. In regulated payment states, drift creates inconsistent member experiences in legally significant interactions.
- Sprint prioritization: payment flows first: Work was ordered by member frequency and regulatory risk. Payment and status flows were highest on both dimensions. Edge cases and advanced features were sequenced second, built on the component foundation established in the first phase.
- Embedded funding source vs. separate settings flow: Funding source connection during auto-pay enrollment, rather than routing to a separate settings section, was a deliberate continuity decision. Interrupting the enrollment flow to set up a funding source is a known drop-off pattern in recurring payment products. Embedding it kept the task atomic.
Synthesis
The sprint constraint forced a level of clarity that longer timelines often erode. Because there was no time to iterate on the integration model, the mapping of shared versus credit-specific infrastructure had to happen in discovery rather than design. That upfront mapping (determining what the credit module inherited from the existing system and what it needed to own) is what kept the servicing module cohesive rather than fragmentary.
The hardest problem in the project was not designing new patterns. It was determining which existing patterns were reusable without modification, which needed extension, and which would break if applied to credit card behavior. Getting that boundary right in a two-week sprint required the flow mapping and agent manual review to be more rigorous than they would have been with more time. That rigor in discovery is what made the sprint deliverable rather than fragile.
Next Project
Measured Impact
4.7/5 App Store rating (289K+ ratings)*Sustained post-launch rating reflecting member trust following the March 2023 relaunch.
4.1/5 Google Play rating | 1M+ downloads*Broad adoption across both platforms at scale.
Credit card servicing integrated into a multi-product mobile ecosystemUnified lending, banking, and credit under a single app without fragmenting the member experience.
Native iOS and Android design system extension establishedReduced implementation ambiguity and prevented platform drift across both native platforms.
*These ratings reflect the full unified app following the March 2023 relaunch, not the credit servicing module in isolation.