Your Merchant Boarding Process Should Live in the Software, Not in Someone's Head

The reality: a checklist is not a process

Here is what happens with process documents. They get written, they get read once, and then reality drifts. The document says nine steps. The veteran knows step four only matters for certain deal types. The new hire follows the document literally and ships equipment to a merchant whose account was never approved. Nobody did anything wrong. The process just lived in two places, paper and habit, and they disagreed.

So when our operations lead handed us his walkthrough, we did not turn it into a PDF. We built it as a guided flow inside our equipment tool, the same system that already runs the real work. To be clear about who did what: the boarding process itself is the team's. They designed it, they run it, they are the ones moving deals from paperwork to live equipment every day. The software did not invent their process. It just gave their process a place to live where it cannot drift, because every step in the guide is wired to the deal's actual state. The guide does not say "now the account should be approved." It reads the deal and knows whether the account is approved.

What we found when we walked it

This is the part most software companies will not tell you about. The first version passed every automated test we have, over a thousand of them, all green. Then I sat down and walked it the way a real person would, clicking what a new hire would click.

It broke. Eleven separate ways across six rounds of fixes.

A step showed nine completed checkmarks on a deal that did not exist yet. A gate listed everything still missing, then let you continue anyway. A boarded deal vanished into a state no screen could reach, born but invisible to the team that needed to pick it up next. Every one of those defects sat behind a fully green test suite, because automated tests check what engineers thought to check. Walking the software checks what actually happens.

The fixed version enforces at the control. A button that should not work is disabled with the reason written next to it, not enabled and apologizing after. Every "still needed" names an action you can take right now. If you sign out mid-walk, you come back to the same step with the same deal. The guide routes off what is true, never off what the script assumed.

The takeaway for anyone running an ISO

Two things we would tell any operator, because we run everything we build on our own book first.

First, your best people's process knowledge is an asset until it is a dependency. The day it lives only in their head, your throughput has a single point of failure with a vacation calendar. Getting it into the software your team already uses, not a document beside the software, is the difference between training people and losing weeks every time someone new starts. The people stay the experts. The software just makes sure their expertise is the version everyone runs.

Second, when you evaluate any software, ask the vendor one question: who walks it before it ships? Not tests it. Walks it. Clicks through it like a confused new hire on a Tuesday. If the answer is nobody, the green checkmarks are measuring the engineer's imagination, not your Tuesday.

Our answer is that the CEO walks every feature before it merges. Not because the CEO built it, the team did that, but because a second set of eyes clicking like a real person is the cheapest quality program that exists, and it found eleven things a thousand tests could not.

If you want to see what we are building and how we build it, the Field Notes list is where we tell the truth about both. Sign up at getvexis.ai for early access.