← Back to work
Case study · Client engagement

MSD Partner Portal

Multi-tenant payments platform that consolidates six processor portals and the GoHighLevel CRM into one operational platform for an agent-driven payments business. Built and shipped v1 with the engineering team at Merchant Service Depot; portal is now in v2.

RoleProduct Manager · led development across product, design, and engineering
DatesSeptember 2024 – May 2026
StackNext.js · React · TypeScript · Supabase · 6 processor APIs
Statusv1 shipped · v2 in active development
The problem

An agent-driven payments business held together by six processor portals and a stack of spreadsheets.

MSD's business is independent agents bringing merchants in, underwriters approving them, and processors deploying them — and everyone needs visibility into what's happening at every stage. Before the Partner Portal, that work was spread across six processor portals, two CRMs in cutover, a stack of spreadsheets, and a manual document workflow that asked underwriting to re-key the same merchant data into three or four different systems. Every stage was friction.

The brief was to unify it. One portal that handled five distinct jobs at once — agent management, pipeline reporting layered on top of the GoHighLevel CRM, merchant onboarding integrated to multiple processor APIs, helpdesk and chat for live collaboration during applications, and a versioned repository of sales collateral that agents could access from anywhere.

Approach

Treat every processor as an adapter.

The architectural decision underneath everything was to treat each processor — Pulsepoint, Valmar, EMS, Mentom, North, Poynt — as an adapter pattern. Each processor has its own data adapter and integration edge function pair that normalizes the processor's quirks into a common interface the rest of the portal consumes. Add a new processor; write a new pair of adapter functions; the rest of the portal stays the same.

Same pattern for application initiation. Merchants, agents, and internal staff can each start an application from the path that suits them — public link, agent-side form, internal-side form — and the back end converges them into one workflow. Same pattern for documents: secure storage with role-based access enforced at the database level via Row Level Security, regardless of who uploaded what.

The architecture's job was to absorb the messiness of six legacy processor systems and present a single clean interface to the people doing the work.

MSD Partner Portal home dashboard showing processing volume and application status across stages.

Portal home — at-a-glance status across the application pipeline, processing volumes, and onboarding queue.

What I built

Five operational areas, one platform.

01

Agent management.

Agents are MSD's distribution channel. The portal handles their lifecycle from onboarding through ongoing operations — application provisioning, document signing for the agent agreement (DocuSeal-powered), permission-scoped access to the right merchants and reports, and admin-side tooling for the internal team to manage agent records, impersonate when needed for support, and adjust access.

MSD agent onboarding flow with DocuSeal-signed agreement and permission scoping.
MSD internal user management view for agent records, permissions, and admin actions.

Agent onboarding (DocuSeal-signed agreement, permission scoping) and internal user management (records, permissions, audit-trailed admin actions).

02

Pipeline reporting layered on GHL.

MSD runs its CRM on GoHighLevel, and GHL is excellent at showing current status — what's in the pipeline right now, which deals are at which stage today. What it doesn't do well is show change over time, which is exactly what the business needed to manage internal staff productivity and agent activity.

The reporting layer pulls GHL's pipeline and opportunity data through the integration edge functions, normalizes it, and visualizes it across weeks and months — pipeline movement, agent activity trends, conversion velocity at each stage. The agent-side view surfaces each agent's own merchant portfolio through the same change-over-time lens, so agents can see where they're winning, where they're stalling, and what's worth a follow-up.

MSD volume reporting dashboard with processing volumes normalized across six processors.
Agent's view of their merchant portfolio with status, volume, and residual visibility.

Pipeline reporting (business-side change-over-time view layered on GHL opportunity data) and the agent's view of their merchant portfolio.

03

Unified merchant onboarding.

The hardest part of the platform. A single application workflow had to serve four distinct entry points (merchants, agents, internal staff, sales-led intake), feed underwriting without re-keying, integrate to six processor APIs on the back end, and keep secure documentation organized and accessible the whole time.

The flow: an application starts from any of the entry points and lands in a unified pipeline. Underwriting works it through structured stages — Pre-Vet → Document Collection → Sent for Signature → Submitted to Underwriting → File Pended → Approved → Deployed. Each stage's data normalizes through the processor adapter layer so by the time underwriting hits submit, the receiving processor's API gets exactly what it expects. No re-keying. No copy-paste. No second system.

Secure document storage with Row Level Security at the database layer means a merchant's banking documents are only visible to the people authorized to see them. Audit trails on every state change. Role-based access enforced at the DB layer rather than the app layer, because the cost of a payments-platform access leak is too high to trust application code alone.

MSD applications pipeline showing unified view of every application across stages.

Applications pipeline — unified view of every application across stages, regardless of entry point.

MSD processor queue showing applications routed to the receiving processor's adapter.
MSD application archive with completed applications and full audit trail.

Processor queue (applications routed through adapter pipelines) and application archive (completed records with full audit trail).

04

Helpdesk and in-application collaboration.

Onboarding a merchant is a multi-party conversation. The portal includes both a structured ticketing system — where the operations team triages issues across applications and merchants — and an in-application chat-and-alert interface so agents and underwriters can collaborate on a specific application without context-switching to email or a separate tool. State changes generate alerts on the relevant record; comments persist with the application history.

MSD helpdesk ticket queue with operations-side triage across applications and merchants.
MSD in-application chat and alerts for agent and underwriter collaboration.

Helpdesk (operations-side triage) and in-application chat and alerts (agents and underwriters collaborating without leaving the record).

05

Centralized sales collateral.

Agents need access to current sales materials, processor-specific collateral, and operational documentation, with version control so nobody pitches a deprecated product or uses an out-of-date rate sheet. The document library handles upload, categorization, version history, and permission scoping — replacing scattered Dropbox links, Drive folders, and email threads with one searchable place.

MSD document library with versioned sales collateral and operational documentation.

Document library — versioned sales collateral and operational documentation, searchable and permission-scoped.

The AI lens

Where AI accelerated, and where it couldn't.

Where AI accelerated the work: Claude Code and Cursor carried the bulk of the form scaffolding, the Deno edge functions that handle processor adapter integrations, the data hooks, and the migration writing. A repo-level CLAUDE.md context file, custom Claude skills (including a QA checklist skill that ran before every commit), and pre-commit hooks gating AI-written code kept output quality consistent across the team.

Where AI couldn't do the work, and shouldn't: the adapter-pattern architectural decision. The choice of what to normalize across processors vs. what to keep processor-specific. The decision to enforce access at the database layer with RLS rather than in application code. The shape of the application pipeline stages and the data model underneath. Those came from product judgment, payments domain understanding, and working closely with Seth Medina's engineering team and the MSD operations team to design something that matched how the business actually runs.

The pattern I bring to every project: AI does the work that benefits from speed and pattern-matching, judgment does the rest, and the combination ships faster and sharper than either could alone.

Where it stands

v1 shipped and in production. v2 (Agent Portal 2.0) currently in active development. The portal handles agent onboarding, application workflows, pipeline reporting, and helpdesk operations as MSD's primary operational platform.

Jim played a pivotal role in building version one of our Partner Portal — a product that helped our sales team and agents onboard merchants through one portal rather than many. He brings a product mindset that keeps the user experience center stage. Jim is also a skilled AI power user. He actively leverages AI tools to accelerate his work and improve output quality. He also always reviews AI work to ensure it is done properly, not just quickly.— Seth Medina, VP of Engineering, Merchant Service Depot
Talk about your product

Book a 30-min call.

If you're building something that needs a senior generalist who ships, the fastest way to find out if I'm a fit is a short conversation. No pitch deck.