Re-architecting payments at scale
This project focused on rebuilding the payments integrations experience as a cohesive system, spanning discovery, provider setup, and configuration, while modernizing existing screens and introducing one net-new capability.
Date
August, 2025
Role
Product Designer, Leading Payments
Company
HighLevel
Service
B2B SaaS Fintech
Overview
HighLevel’s payments ecosystem had grown rapidly, supporting multiple providers (Stripe, PayPal, Square, NMI, GoCardless, manual methods) but the experience of discovering, configuring, and managing these integrations had not kept pace. Users struggled to understand which payment methods were supported, where they were available geographically, and how to configure them per product area (Invoices, Subscriptions, Orders, etc.).
This project focused on rebuilding the payments integrations experience as a cohesive system, from the landing page to deep configuration screens, so businesses could confidently choose, enable, and manage payment methods without friction.
Problem
Payments setup had become difficult to reason about as the platform scaled.
Core user problems
Users could not quickly understand which payment methods a provider supported
Geographic availability was unclear and often discovered late
Configuration logic was fragmented across providers and product areas
Adding new providers increased UI and mental complexity instead of clarity

Legacy screens
Goals
Create a single, scalable system for payment discovery and configuration
Reduce decision paralysis during provider selection
Enable configuration directly inside HighLevel
Design for future expansion (methods, regions, providers)
Solution overview
This initiative was designed as a multi-layered system, not a collection of isolated screens.

The solution spans three layers:
Discovery (choosing the right provider)
Setup (connecting accounts)
Configuration (controlling where and how providers are used)
1. Payments integrations landing page (revamp)

Before: legacy integrations list

After: new payments integrations landing page (card + table views)
What changed
Introduced provider cards with clear payment method signals
Added geographic availability indicators
Enabled filtering by method and region
Supported both visual (cards) and analytical (table) scanning modes
Why it matters: This reduced cognitive load during provider selection and made tradeoffs visible upfront.
2. Manage provider configuration (new feature)

Problem: Provider usage across product areas such as invoices, forms, orders, and subscriptions was implicit and hard to control.
Solution: Introduced a centralized provider-to-channel mapping layer that allows users to:
Assign one or more providers per product area
Control defaults without breaking live flows
Manage live and test environments safely
Impact: This unlocked flexibility without increasing risk and created a foundation for future automation and recommendations.
3. Stripe integration (revamp)

Stripe integration empty state

Connected account state (Live / Test)

Stripe payment method configuration
What changed
Clarified setup states (not connected vs connected)
Supported multiple Stripe accounts
Reduced dependency on Stripe dashboard for core configuration
4. PayPal integration (revamp)

PayPal integration empty state

Connected account state (live / test)
What changed
Moved beyond credentials-only setup
Centralized visibility and control of PayPal payment methods
Enabled safer configuration by product area
Introduced PayPal payment method configuration
5. Manual payment methods (revamp)

Manual payment method landing, empty state

Enabled state with instructions and channel selection
What changed
Unified offline methods into a structured configuration flow
Clarified where manual payments are applicable
Brought parity with online payment methods
6. GoCardless integration (new provider)

Why it mattered: Strong demand from UK/EU users for direct debit payments with lower fees and higher reliability.
Design focus
Clear positioning as "pay by bank / direct debit"
Geo-aware availability
Transparent payment states
Constraints & tradeoffs
Maintained backward compatibility with existing merchants
Provider capabilities varied by region and account state
Avoided exposing edge-case configuration upfront
Sequenced rollout: core providers first, newer providers after
Outcomes (initial)
Shipped a unified payments integrations system
Reduced fragmentation across providers
Established a scalable foundation for future expansion
Quantitative metrics will be layered in post-launch as adoption matures.
Learnings
Payments UX requires clarity and trust more than surface-level polish
Aligning with external provider mental models reduces friction
Designing the system upfront prevented repeated rework
What I'd Improve next
Smart provider and method recommendations by region
Inline validation for incompatible configurations
Surfacing performance analytics directly in configuration views


