The Payments Decision Your Board Doesn't Know It Made

A few years ago, on an unremarkable day, your company made one of its most consequential infrastructure decisions. Except nobody called it that. Most likely, it was a project management ticket for a busy engineer, made with good intentions and sound logic: integrate our new payments provider.

This has happened to more companies than you’d believe. Infrastructure decisions can be difficult to undo. I can explain the process for unwinding this one.

How a sprint ticket becomes load-bearing infrastructure

For most companies, the decision to onboard a payment provider is rarely made in ideal conditions. They face a tight deadline, work with incomplete information, and are driven by the need to get revenue flowing.

Your team chooses a provider, usually prioritizing speed of implementation, and they do a fine-enough job. The integration gets woven into the deeper fabric of your infrastructure and the business grows around it. Dependencies build, familiarity smooths it all out, and before you know it you have massive technical debt being held up by a completely inappropriate pillar.

Deloitte’s CTO, Bill Briggs, explains the insidious nature of technical debt succinctly. “There’s usually a commitment to come back and fix it in the next release or the next budgeting cycle, but priorities shift while the interest from technical debt grows.”

Apt as Bill’s statement is, there’s another consideration with the technical debt carried by your payments team. Resolving it isn’t purely a technical challenge, there’s a commercial imperative that attracts the whole board’s attention.

The three moments when the constraint becomes visible

You don’t notice the issues for a while. They emerge and compound little by little. Then, as if out of nowhere, they surface in three key moments and what was a footnote in your original buildout becomes a blaring siren in the business.

1. The market expansion meeting: When someone from Growth or Business Development asks you how long go-live will take in a new geography. They’re hoping to hear days, but you tell them months.
2. The contract renewal: The provider knows how embedded they are in your business. The technical, financial, and commercial costs of switching are high and you haven’t got a leg to stand on.
3. The board meeting: When the CFO has clocked an extortionate line item called ‘processing fees’ and you have to explain why the stack you’re responsible for is falling short of expectations.

What compounded over time wasn't just the technical decision

This all started with one technical decision, but it didn’t exist in a vacuum. As time went on, unique challenges grew around it and changed a plug-and-play provider into a fused and soldered single point of failure in your business.

Token lock-in

Tokenization is a critical part of customer data protection, but it’s also a data risk for vendors. Each customer’s payment credentials are tokenized in your provider’s proprietary format. And they are the only ones who can access that payment data vault. Transferring these tokens to a new provider’s vault is a huge technical undertaking.

As a result, if you try to migrate to a new provider, you’re faced with two equally challenging options:

1. Engineer a complex, high-risk migration over an entire quarter (or longer).
2. Ask customers to re-enter their payment details with a new provider.

You’re being asked to choose between eating into your engineering resources or your revenue retention.

Feature dependency

To reach this point, you will have built a detailed checkout and technical backend process. That’s impressive – and a litany of dependencies and entanglements with your provider. You’ve built custom fraud rules, retry logic, reporting hooks, subscription billing flows – they’re all powering your revenue. They’re also binding you closer to a single provider.

When the time comes that you want to build or integrate a new feature that they can’t tool, what happens? Suddenly, your trajectory depends on a third-party provider’s product roadmap. Businesses don’t grow when they’re beholden like that. By the time they’ve either built the feature or you’ve engineered a workaround, you’ve lost all-important time in the market or missed the opportunity entirely.

Stablecoins are a perfect example of this in action. At the end of 2024, the trading volume of the two biggest stablecoins topped $23 trillion – the kind of scale reserved for major card networks. Yet, today, some of the biggest players in payments are still working out how to integrate them at checkout. 18 months is a lot of advantage for your competitors – can you afford to wait that long?

Negotiating leverage, or the lack of it

I touched on this earlier, but it’s worth repeating: the more you rely on a single vendor, the worse your negotiating position is with them. They’ll be well aware of how deep their integration runs with your business and that knowledge shows up in every commercial conversation you have.

Negotiations on fees, terms, and SLAs are all held under the shadow of their grip on your revenue. They can afford to play hardball; you can afford to nod along politely.

As your switching costs rise, your provider’s incentive to compete for your business falls in lockstep.

Organizational knowledge

Technical debt doesn’t only exist in your infrastructure, it runs through your entire org chart. 

Deep knowledge of your payment stack is either siloed in the brains of a few engineers or it disappears entirely as your engineering team evolves. Things keep running and everyone keeps the checkout live, but the why and how of your payments stack gets lost and you’re left with nothing more than the what.

From that position, you can no longer build strategically. Engineers become maintenance staff, desperately trying to plug leaks in what has, effectively, become a black box.

The governance gap that lets this happen

I’m not writing this to stoke fear or alarm. I’m writing this because this situation plays out every day in boardrooms across your industry. If you had seen the number of migrations and new businesses we’ve supported, you’d know why I say that with such confidence.

When you first built your payment stack, it fit on a Jira ticket. Today, when you commit to rebuilding it, it’s an agenda item for a board meeting. 

I want to be really clear on one thing: this isn’t a failure from you or your team. Businesses are not structured to run this process as they should. Organizationally, this is seen as a technical implementation. In practice, you and I know that this is actually a revenue, market-entry, vendor cost, and retention issue.

A great payments leader can explain what’s outlined in this article and help them close the governance gap. You can shape the solution, rather than defend the problem.

How to bring this conversation to the board

Each board and business is unique, so I won’t pretend I know exactly what you should say. Instead, I can give you the guardrails for the conversation to make sure you hit the all-important points. The rest is on your internal knowledge and expertise.

Firstly, you need to lay out the merits and drawbacks of the current system – framed in business, not technical, terms. Where you’d discuss local rails, make expansion opportunities the focus.

Secondly, an honest take on the risks of payments vendor lock-in. Forecast cost increases, contextualize outage risks, and share the risks of changing data legislation in different regions.

Thirdly, bring this to the table as an infrastructure review, not a problem to flag. Explain your case clearly and make your request even clearer. You’re reviewing your payments architecture to seize opportunities, mitigate risks, and fuel the next phase of growth.

The decision worth making deliberately

To me, this problem is the archetypal growing pain of a successful e-commerce business. If you’re at this point, you’ve done a lot more right than wrong. Now, you have the opportunity to change everything.

Opting for a provider that can offer agnostic vaulting, flexible orchestration, and open architecture gives you a platform to scale beyond this initial growth spurt. If you do, you’ll see the business mature into an agile, technically robust force in the market.

Building for optionality is the hallmark of businesses that compound their growth. If you can be the person to set that standard, your next boardroom appearance will be on very different terms.