Build versus buy: Should your business become a payments company?

Most businesses don't set out to become payments companies. But as they grow, many gradually take on the responsibilities of one.

One payment service provider becomes two, then three. A fraud tool gets added. Expansion into a new market brings another payment method.

None of this is unusual. It's a natural response to the needs of a growing business. But every new provider, payment method, and tool increases the amount of infrastructure your team is responsible for operating.

I've seen businesses reach a point where a significant amount of engineering effort is no longer going into the product they're trying to build. It's going into the infrastructure required to keep payments running.

Which raises a question: How much of your payments infrastructure should you really own?

What it takes to build and run payments infrastructure yourself

For some businesses, building and owning that infrastructure themselves is a deliberate strategic choice.

Uber is a good example. It has built large internal payments and fintech teams because payments are strategically important to how it operates. And because, when it was building those capabilities, there weren't solutions on the market that could meet its needs at the scale it required.

There are paralles here with how businesses once thought about servers. Companies bought the hardware, hired infrastructure teams, and operated their own data centres because that was the only way to run critical infrastructure.

Cloud providers like AWS created another option: access to that infrastructure without having to own and operate every layer underneath it.

Payments are moving in a similar direction. 

Of course, “build versus buy” is something of a misnomer. Even when you build in-house, you are not building the entire payments ecosystem yourself.

You still rely on PSPs, acquirers, fraud providers, payment methods, banks, and other specialist services. The real build decision is whether your team wants to own the layer that connects those services together: the integrations, routing, data, reconciliation, compliance, and operational logic that make the stack work as one cohesive system.

Initially, that may not seem like a heavy lift. But the responsibility expands as your business grows.

You’ll need to maintain integrations as APIs change, manage data and payment flows across multiple systems, support new markets and payment methods, and develop capabilities such as network tokenisation.

In other words, the more of the stack you own, the more your ability to make changes is tied to engineering capacity, and the greater the long-term maintenance burden becomes.

Then there’s the data disadvantage. Your view is limited to your own transactions, while providers operating across many businesses and markets can see patterns that you can’t (more on this later).

Compliance is another consideration. PCI DSS, PSD2, and local market requirements all demand ongoing maintenance and re-certification. Shuttle data also shows that PCI DSS Level 1 compliance alone costs between £500,000 and £1.1M to implement, with ongoing annual costs of £100,000 to £200,000. 

If you are prepared to make that long-term investment and operate payments as a capability in its own right, then building your own infrastructure is an option. If not, payments gradually becomes a constraint on growth with every new market, provider, or optimization competes for scarce engineering time, while the cost and complexity of the stack continue to grow.

Can you vibe code your payments infrastructure? 

One could argue that AI changes this equation; indeed, some in the industry now even suggest that you can "vibe code" your payments infrastructure. 

I think AI will absolutely reduce the effort involved in some of this work we discussed in the previous section. But it doesn't remove the underlying problem. 

Writing an integration faster is very different from operating it reliably, understanding how it performs, maintaining it as providers change, and knowing how to optimize it in the context of the wider payments ecosystem.

And we'll come back to that distinction later.

Build vs. buy: what you are really taking on

‍

Using a platform doesn't mean giving up control over how your payments operate.

You can still choose which providers to use, change routing logic, add payment methods, optimize performance, and adapt payment flows as the business evolves.

The difference is that you don't have to build and maintain all of the infrastructure required to make those changes possible.

The cost of fragmented data

One of the strange things about payments is that you can have an enormous amount of data and still struggle to answer relatively simple questions about your business.

Every PSP gives you data. You can see transactions, fees, settlements, authorization rates, and declines. But each provider presents that information in its own way, using its own definitions and reporting structures. The challenge is making sense of all of it together.

If you're running several providers, you need to bring those different datasets into one place, normalize them, reconcile the inconsistencies, and create a common way of looking at performance and cost.

Otherwise, questions I think every payment team should be able to answer become much harder than they need to be.

What did this payment actually cost us? Why is authorization performance changing in this market? Which provider is performing best for this type of transaction? Are we routing volume to the right place?

I've seen teams with huge amounts of payments data spend an extraordinary amount of time just trying to establish what is actually happening.

And that has consequences beyond reporting.

Take your PSP relationships. Having multiple providers should give you leverage. But that leverage depends on being able to compare them properly.

If you can't clearly see how one provider performs against another, it becomes much harder to challenge pricing, identify underperformance, or make a case for moving volume. And even when you can see the problem, acting on it may still require engineering work to change how traffic is routed.

Your own data can only tell you so much

Even with a perfect view across your own payment stack, there is still a limit to what your data can tell you.

Your transaction data reflects your business, your customers, your markets, and your provider mix. It can tell you what happened. It is much less reliable at telling you whether what happened is normal.

That distinction matters.

If authorization rates fall, is the problem in your checkout, your routing, a specific PSP, or something happening more broadly across the market? If declines suddenly increase for a certain issuer or payment method, is that unique to you or part of a wider pattern?

Those are difficult questions to answer when the only dataset you can see is your own. And this is where I think the value of a platform starts to compound.

When you normalize payments data across many businesses, providers, markets, and transaction types, you can start to add context that no individual merchant can create alone.

You can distinguish between an issue that is specific to one business and one that is affecting the wider ecosystem. You can spot patterns earlier, or identify opportunities that would otherwise be invisible.

Think of it like Google Maps. Every driver contributes data to the network, allowing everyone else to benefit from better predictions. You don’t need access to every driver's journey history. You simply benefit from the intelligence created by the network.

Intelligent payments can’t be built on fragmented data

I also think that this is also where some of the discussion around AI in payments misses the point.

AI will make it easier to query data, write code, automate analysis, and operate parts of the stack more efficiently. I have no doubt about that. But AI doesn't somehow remove the limitations of the data underneath it.

If all it can see is your own transaction history, then it is still reasoning from one business, one provider mix, and one set of customer behaviors. It may help you get to an answer faster, but it doesn't necessarily give you a better reference point for deciding whether that answer is meaningful.

The more interesting opportunity is what happens when AI has access to well-structured payments data with much richer context behind it.

Then it can start to help answer the questions that are genuinely difficult in payments: Is this change specific to us? Is it happening elsewhere? Is this performance actually unusual? Where should I be looking next?

And the truth is you'll never be able to answer that with your own data alone. If you want to learn more about this I went into more detail in this blog post.

Do you really want to become a payments company? 

I don't think the answer is that businesses should never build payments infrastructure themselves.

For some, it absolutely makes sense. If payments are deeply embedded in your competitive advantage, you operate at enormous scale, or you have requirements that existing platforms genuinely can't meet, then investing in a large internal payments organization can be the right decision.

The important thing is to be clear-eyed about what that choice involves.

Payments are heading toward a model where businesses can use critical infrastructure without having to own every layer underneath it.

They are critical infrastructure. But for most businesses, the advantage comes from what they can do with payments, not from building and maintaining everything required to make them work.

And that doesn't mean giving up control. With a payments infrastructure platform like Primer, you can still choose your providers, decide how transactions are routed, optimize performance, add payment methods, and evolve your payment flows as the business changes. 

The difference is that you don't have to build and maintain all of the infrastructure required to make those services work together yourself.

Which brings us back to the important question: Do you want to focus on building your business, or do you want to become a payments company?