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:

  1. Discovery (choosing the right provider)

  2. Setup (connecting accounts)

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

Read more of my case studies