Chapter 38 — If You're a Consultant: Turning Payments Knowledge into a Practice

Part IX: How to Use This Knowledge

A founder friend sends you a PDF. "Our processor statement," she says. "Finance says it's fine. It doesn't feel fine."

It takes you forty minutes with a highlighter. There's the blended rate that was negotiated three years and one business model ago. There's a currency-conversion spread nobody ever agreed to out loud. There's a line item — literally labeled with an acronym the PSP never expanded — that turns out to be an optional fraud tool, enabled by default, that duplicates what her stack already does. None of it is scandalous. All of it is negotiable. You mark up the PDF, write four paragraphs about what to ask for and in what order, and send it back.

Two weeks later she's saved more than most consultants quote for a month. And here is the moment that matters: you didn't do anything hard. You did something scarce. Everything you found is in this book — most of it in Chapters 10, 13, and 15. What she paid for wasn't secret knowledge. It was the ability to read a document that one side of the table produces and the other side has never been taught to read.

This chapter is about that gap — and how to build a practice inside it, whether you're an engineer who wants independence, an operator who wants leverage, or the author of your own version of this book.

Why This Knowledge Is Consultable At All

Most expertise doesn't convert to consulting. It's either too available (anyone can search it) or too embedded (it only works inside one company's systems). Payments expertise converts unusually well, for three structural reasons — the same ones this book's introduction opened with.

The stakes are a percentage of revenue, forever. Payments is one of the few line items that scales with every sale a business ever makes. A basis-point improvement compounds indefinitely. That means even small engagements produce provable, recurring value — the easiest kind to sell and the easiest kind to price.

The knowledge is trapped in strange places. Scheme manuals written for banks. Whitepapers written to sell software. Booth conversations at industry festivals. What's freely available is too shallow to act on; what's deep is written for insiders. That asymmetry is the entire consulting opportunity: you are not selling information, you are selling the decoder ring.

Every business has the problem, and almost none has the specialist. A company needs to be surprisingly large before a full-time payments hire pays for herself. Below that line sits an enormous population of businesses with real payments losses — leaking auth rates, unread statements, failing retries, wrong rails for their markets — and nobody whose job it is to notice. Fractional expertise exists precisely for problems that are universal but not full-time.

The Four Shapes of a Practice

There are four ways to package what you now know. They differ in leverage, in how they sell, and in what they demand of you. Most durable practices end up blending two or three — but you start with one.

Fractional or embedded engineering is the most direct conversion: you build the thing. The PSP integration, the retry logic, the reconciliation pipeline, the migration Chapter 37 mapped out. It sells easily because the deliverable is legible — code that works — and your Rapyd-style scar tissue is the differentiator over a generalist dev shop. The trade-off is that it scales like a job: your hours are the product, and embedded work crowds out everything else. Best used as the trust-building entry into a client relationship, not the destination.

Payments consulting — diagnose and negotiate rather than build. Statement audits like the one that opened this chapter. Auth-rate teardowns segmented the way Chapter 36 segments them. Vendor selection and RFP support armed with Chapter 35's question table. Orchestration roadmaps from Part VIII. Dispute-program triage from Chapter 13. This is higher leverage than building: engagements are shorter, the value is quantifiable ("we found X in annual savings"), and the deliverable is a decision, not a system you must maintain. The trade-off: it requires proof of authority before anyone hands you their statement. Which is what the flywheel below is for.

AI consulting and selling is the newest shape, and it compounds with the other two. Payment operations are drowning in exactly the work current AI handles well: parsing statements and settlement files, drafting dispute representments against the evidence checklists of Chapter 13, tuning dunning copy and retry schedules, watching reconciliation exceptions and writing the first-pass diagnosis. A consultant who can both read a settlement file and build the agent that reads it every night is selling something neither a payments veteran nor an AI shop can match alone. And Chapter 33 showed the horizon: as software starts spending money, someone has to build the governance around it — mandates, spend policies, audit trails. That work sits precisely on the intersection of payments operating and AI engineering, and almost nobody stands there yet.

Productized offerings are how any of the above stops being pure hours. The pattern is the diagnostic-first ladder: a fixed-price, fixed-scope diagnostic at the bottom (a statement audit, an auth-rate teardown, a failure-mode review against Appendix E); a roadmap engagement in the middle; a retainer or implementation at the top. The diagnostic is small enough to buy without a committee, produces a concrete artifact, and — this is the point — its findings are the sales pitch for the next rung. You never pitch the retainer. The audit does.

Table 1: Four practice shapes. Start with one; blend deliberately. The diagnostic ladder is what connects them.

Positioning: Pick a Wedge You Can Diagnose in One Call

"Payments consultant" is not a position — it's a category, and categories don't get hired. What gets hired is a specific promise to a specific someone: involuntary-churn recovery for subscription companies. Statement audits for multi-market retailers. Payment-stack due diligence for investors. Rail selection for platforms entering Southeast Asia.

The test for a good wedge is brutal and simple: can you diagnose the problem in one conversation? If a fifteen-minute look at a statement, a decline-code breakdown, or a checkout flow lets you say something true and non-obvious — you have a wedge. If the honest answer is "it depends, I'd need three weeks" — you have a category. Every wedge in this book's table of contents passes the test: dunning (Chapter 15), 3DS tuning (Chapter 11), reconciliation breaks (Chapter 36), vendor lock-in (Chapters 12 and 25), pull-rail failure modes (Chapter 20).

Narrowness feels dangerous and isn't. The wedge is how you enter; nobody stays inside it. The statement audit becomes the orchestration roadmap becomes the fractional retainer. You are narrow in marketing and broad in delivery.

Lead Generation: Teach in Public, Prove with Artifacts

Payments consulting has an unusual property: the knowledge itself is the best advertisement for the knowledge. That inverts the instinct to guard expertise.

Teach in public. This book — and whatever your version of it is: the newsletter, the teardown series, the conference talk — is the lead engine. Publishing how interchange actually works doesn't cannibalize a statement audit; it creates the audit, because the reader now knows the fees are negotiable and knows exactly who understands them. You cannot Google your way to trusting someone. You can absolutely read your way there.

Diagnostic artifacts beat brochures. A one-page fee decomposition of a (anonymized) real statement. A decline-code taxonomy with the retry decision tree from Chapter 36. A pre-signature PSP question list. A failure-mode checklist from Appendix E. Artifacts do two jobs a brochure can't: they demonstrate the diagnosis instead of claiming it, and they travel — forwarded from the CFO to the founder with the note "we should run this."

Referral loops with adjacent professionals. Accountants see the processing fees but can't decompose them. Dev shops get asked payments questions they can't answer. PSP account managers meet merchants who need more help than support tiers provide. None of them compete with you; all of them meet your client before you do. A payments person who is known to be safe to refer — won't oversell, won't blame the referrer's work — becomes the default answer to a question these professionals get monthly.

Price to filter, not to fill. Fixed fees for diagnostics — priced so that saying yes is easy but tire-kickers say no. Value-anchored pricing for negotiation work, where the fee is framed against the recurring savings. And never hourly for advice: hourly pricing converts your scarcest asset — judgment — into a commodity measured in the one unit that has nothing to do with its value. (Hourly is defensible only for embedded engineering, where time genuinely is the deliverable.) The real-estate flagship rule applies here unchanged: the price is part of the positioning. A cheap audit reads as a cheap opinion.

The Flywheel

Here's how the pieces close into a loop — the same loop this book itself runs on:

Diagram 1: The practice flywheel. Every engagement produces patterns; the patterns feed the manual; the manual generates the next lead. The publishing is not marketing for the practice — the publishing and the practice are the same system.

The quiet advantage of the flywheel is that it compounds credibility in a field that changes constantly. Every statement you audit teaches you this quarter's fee games. Every migration you run surfaces this year's lock-in tactics. Every agentic-payments pilot you govern puts you a year ahead of the writeups. Part X — the change log, the reference library — is where that advantage is stored and displayed. The book stays alive because the practice feeds it; the practice stays booked because the book proves it.

What Not to Do

Three failure modes account for most dead payments practices.

Don't sell secrets. If your pitch depends on information asymmetry — "I know the thresholds, hire me to learn them" — you have a melting asset and an adversarial client relationship. Sell synthesis and execution: the client with the book still needs the judgment, the negotiation, the build. (You are holding the proof that giving the knowledge away works.)

Don't compete with PSP sales teams on price. The PSP will always offer the audit for free, because for them it's customer acquisition. Your differentiation is that you sit on the merchant's side of the table and have no rate to sell. The moment you take referral fees from a provider you also recommend, you've converted your only structural advantage into a disclosure problem.

Don't take success fees on outcomes you can't control. Fraud rates, auth rates, and dispute ratios move for reasons that have nothing to do with your work — issuer model changes, seasonal mix, one bad card-testing week (Chapter 36 showed how often the cause is external). Tie fees to delivered work and negotiated terms, which you control, not to metrics that the whole payment system votes on.

The Practice Is the Living System

One last connection, and it's the bridge out of this Part. A payments practice has a shelf life exactly equal to how current its knowledge is. Interchange rules shift, monitoring thresholds move, new rails go from pilot to default, agentic protocols consolidate — and last year's expert is this year's liability, unless the knowledge is maintained as deliberately as it was acquired.

That maintenance discipline is not an appendix to the practice. It is the practice. And it's what the final part of this book is for: what changes, what doesn't, and how to keep a living manual alive.