An eight-year-old payment processor onboarding workbook, rebuilt from scratch — as a white-label Excel template, a Notion workspace, and a live React app.
“A workbook built in 2016, last meaningfully updated in 2019 — with the company name hardcoded in hundreds of cells.”
Payment processor onboarding is one of those operational processes that can make or break a client relationship in the first 45 days. The original workbook was thorough and functional — eight tabs covering everything from merchant banking to IVR configuration. But after 18 revisions across three authors, it had become an institutional knowledge trap.
Every implementation team maintained a slightly different version. No phase structure. No master checklist. No way to hand it to a new engagement without an hour of find-and-replace.
Eight years of accumulated operational knowledge, carried forward.
Three formats, each chosen for a specific user and use case — not interchangeable, deliberately distinct.
This document had two distinct jobs — and was doing both poorly by trying to do them in the same format. Task management (who does what, by when, in what order) and reference documentation (what are the settings, what are the rules, what does the client need to provide) need different tools. The rebuild separated them.
A Config & Branding tab became the single source of truth. Change one cell — every tab updates. Processor names, URLs, the company name in phase banners, the checklist subtitle — all formula-linked. A new master Onboarding Checklist structures 60+ tasks across eight sequential phases with status dropdowns and conditional formatting. A README tab documents the system for anyone who opens it cold.
The eight phases aren't arbitrary: Discovery, Treasury Setup, Product Configuration, Branding, File Integration, Portal Access, Testing, Go-Live. They reflect how implementations actually sequence. You can't configure channels before processors are live. You can't run UAT before branding is approved. The dependencies are built into the order.
Excel, Notion, and React aren't interchangeable. The implementation manager lives in spreadsheets. The cross-functional team collaborates in Notion. The prospect or hiring manager sees it first in a browser. Knowing which tool fits which job is a different skill than knowing how to use all three — and building the same content three ways shows both.
This is an eight-year document. v1.0 through v3.10 represent the accumulated operational knowledge of everyone who worked on payment processor implementations during that period — DNAC file specs, real-time remittance API support, consumer portal configuration, the shift between gateways, the standardization of portal roles. v4.0 didn't throw that away. Every version note lives in the Revision History tab.
“Making something work for one company is a starting point. Making it work for any company requires stepping back from the specific case and designing for the general one.”
This template reflects how payment processor portals have traditionally worked — manual role configuration, static permission matrices, rules defined once during onboarding. That's the operational reality it was built for.
AI-assisted tooling is increasingly embedded directly into merchant and biller portals, particularly around the areas this template covers most — permission management, velocity rule configuration, blacklist automation, and fraud pattern detection.
What that means for this template depends on the company using it. For a modern, AI-native portal, sections like Portal Roles & Blacklist and Payment Velocity Rules may overlap with functionality the platform already handles. For a processor running an older system, the full template applies.
What this project demonstrates.