When to Build a Payments Strategy for Vertical SaaS

A few weeks ago, a platform I have known for years wrote back with something refreshingly honest: they had no idea where to start on payments. Not “we are evaluating vendors.” Not “we have a committee.” Just, plainly, we do not know what we do not know.

I appreciated it, because most platforms do not say that part out loud. They just quietly pick whatever is easiest to integrate, ship it, and move on. And that is the moment I want to talk about, because it is the moment most platforms get it wrong, not through a bad decision, but through not treating it as a decision at all.

The controversial part

Here is my actual position, and I know it goes against how most people think about this: your payments strategy starts the moment you decide to embed payments into your platform. Not at some future volume threshold. Not once you can justify a hire. From day one.

I am not saying you need a dedicated person from the start. Most platforms genuinely cannot justify that yet, and that is fine. What I am saying is that you need to put real thought into your long term direction before you pick whatever is easiest or cheapest to ship this quarter.

The reason this is controversial is that it cuts against how payments actually gets treated inside most companies. In the early days, payments is just necessary functionality, a checkbox to get a product live. It only becomes a company strategy and monetization question later, once volume makes it impossible to ignore. The problem with waiting for that moment is that you are often stuck with decisions you made when you were not thinking about them as decisions. Unwinding them later causes real friction, and I have seen that pattern play out more times than I can count.

Why this stays invisible until it isn’t

Part of why platforms wait is that payments is a genuinely hard cost to define. It is not a line item that shows up cleanly on a P&L the way a SaaS subscription cost does. It is spread across interchange, processor markup, chargebacks, and whatever margin you are or are not capturing, and none of that is visible unless you go looking for it. So it gets treated as a rounding error, right up until volume makes it impossible to ignore, because the more you process, the more that invisible cost actually costs you.

That is a version of the same blind spot we have written about before on the margin side. Payments does not announce itself as a cost the way other line items do, and waiting until it is big enough to notice is waiting until you have the least room to do anything about it.

What “stuck with it” actually looks like

One version of this I keep running into: a platform becomes a merchant of record early, because it is simpler to set up and easier to forecast against, and later has to migrate off that model. It has come up twice recently with platforms I have advised.

That migration is not one clean problem you can hand to one team. It is technical, since you are rebuilding payout and reporting infrastructure that a processor used to handle for you. It is contractual, since you are renegotiating terms you signed when your volume and risk profile looked completely different. And it is merchant facing, since you have to tell your own customers something about their payments experience is changing, which is never a comfortable conversation. All three at once, not in sequence.

To be clear, becoming a merchant of record is not automatically the wrong call. It can genuinely simplify your setup and make forecasting easier in the early days. But that is a different thing from a margin advantage, and conflating the two is part of what leads platforms into it without weighing the exit cost. That distinction, and the fuller tradeoffs across the different ownership models, is worth its own post, which I will link here once it is live.

Where I actually see this go wrong

Here is something I do not think gets discussed enough: platforms tend to assume the value of adding payments is the payment moment itself, ease of checkout, one less redirect, whatever reduces friction at the point of sale.

Sometimes that is true. But often the real value sits somewhere adjacent, and it is easy to miss if you never went looking for it. I have seen platforms discover, after the fact, that the thing their merchants actually cared about was being able to reconcile all their payments in one place instead of stitching together three different sources. I have seen the opposite too, where the real win was that end customers wanted to pay in installments, and offering that turned into a genuine appeal for the platform’s own merchants, not because payment got easier, but because a new way to pay unlocked demand that was not there before.

If you only ever ask “how do we make paying easier,” you will miss both of those. Proper discovery on the payments side means asking what your merchants are actually struggling with day to day, not just how the transaction itself feels.

The thresholds, and why they matter less than people think

I want to be straightforward here, because vague guidance is not useful, but I also don’t want to hand you a number that does not actually hold for your situation. Based on conversations we have had across a range of platforms, cost sensitivity around payments tends to show up once a platform crosses somewhere in the 100 to 200 million dollar range in annual processing volume. That part is fairly consistent.

What is not consistent is exactly when a move to something like interchange plus becomes worth the operational lift. I have seen that number swing widely depending on how complex your merchant mix is, how much dev and support capacity you actually have free, and what your current processor is willing to negotiate before you even get to that stage. Rather than give you a single figure that will not hold for everyone, the honest answer is that it is a moment you recognize by the tradeoffs, not by a line on a spreadsheet: you feel it when the operational lift of managing it yourself starts to look smaller than the cost of not doing it. A dedicated payments hire usually does not make sense before roughly 500 million, and a full team, customer support plus product, tends to form somewhere between 500 million and a billion. Those two are more stable, since they track headcount economics rather than processor-specific negotiation dynamics.

Go back to my first point regardless. These are thresholds for when payments becomes hard to ignore, not for when you should start thinking about it. If you wait for the threshold, you are thinking about strategy at the exact moment you have the least flexibility to act on it.

What this actually looked like for one platform

Volume is not the only variable either. We have worked with a platform whose processing volume was genuinely too small to justify a full deployment of what we do. Instead of turning them away, or telling them to come back once they hit scale, we paired the platform with monthly consulting sessions, walking their team through payment metrics, the different ecosystems and models available, and how to actually run product discovery on the payments side. It was a real commitment on both sides, and it doubled as some of the best discovery we have done, since it forced us to explain our own thinking in plain language, repeatedly, to a smart team encountering it for the first time.

That platform now processes a meaningfully larger volume than when we started, and the strategy work they did early, on volume that would not have justified it on its own, is exactly why they were ready to fold payments into company strategy once the volume caught up, instead of scrambling to build that thinking from scratch under pressure.

That is the model I would point to if you are early and do not have the volume to justify a dedicated hire. Waiting is not your only option, and neither is a full build.

Where this leaves you

If you are early, do not wait for a volume threshold to start thinking about your payments strategy. Start now, with whatever level of resourcing makes sense for where you are. If you are approaching one of the thresholds above, do not assume the model you picked on day one still fits. And if you are weighing referral, PayFac, or merchant of record specifically, that decision deserves more than a paragraph, which is why I am covering it separately.

If any of this sounds like where you are right now, I would like to talk. Reach out and we can walk through what your specific volume, model, and stage actually mean for you.