Build vs buy in payments: There is no silver bullet

Every few months, a new article makes the rounds arguing that the only credible path is to build your payments stack in-house. A few months later, another one argued the opposite with equal certainty. Both are wrong because both are answering the wrong question.

Build vs buy is not the objective. It is an input. The objective is the business outcome a company is trying to drive: faster growth, higher authorization, lower cost, better customer experience, and scalability. The right answer depends on what is core to the business, what the technology organization can credibly sustain, and how payments connect to the wider strategy. A decision that is right for a global marketplace can be wrong for a fashion brand, and a decision that is right today can be wrong in three years as the company and the landscape change.

The debate also tends to flatten payments into a single decision, when in reality it is a stack of decisions. Connectivity, orchestration, tokenization, risk, reporting, and reconciliation each have their own economics and their own strategic weight. Treating them as one block is where most build-vs-buy conversations go off the rails.

Three companies, each of which we have either worked inside or worked with closely, illustrate the point.

Delivery Hero: Build, because payments were strategic

At Delivery Hero, the payments stack was built in-house. The business operated in roughly 70 countries, each with its own local payment methods, regulatory quirks, and fraud profile. Off-the-shelf coverage did not exist at that depth, and outsourcing the pace of expansion to a third-party roadmap was not a risk the company could accept.

Payments were also core to the business. Marketplace economics are payment economics. Owning the stack meant owning the margin, the data, and the experiments. For a company in that position, building was the right call, provided it was willing to fund a permanent payments engineering organization to match.

Puma: Buy, because payments were not the differentiator

Puma's competitive advantage is in design, brand, and product. Not in payment connectivity. They bought Payrails because building would have required staffing and sustaining a payments engineering organization for a problem that does not move the needle on their brand. Their growth engine sits elsewhere, and pulling engineering talent toward a payments build would have come at the direct expense of the work that compounds the business. For a company in that position, buying was the right call.

Vinted: Hybrid, because not every layer is the same

Vinted illustrates the case most companies actually fall into. They kept their existing acquirer integrations, because those were working and represented years of accumulated optimization. What they bought from us was the token vault: the abstraction layer that lets them switch, route, and orchestrate without rebuilding card storage every time.

The token vault was not core to their business value. The marketplace experience is. They kept what differentiated them and bought what did not. For a company in that position, the hybrid approach was the right call, provided the integration points between owned and bought components stay clean enough to survive future changes on either side.

The principles behind the decision

Three questions cut through most of the build-vs-buy debate.

1. Is this layer of the stack core to the business model and differentiation? If yes, lean towards building. If no, lean towards buying. Apply the question one layer at a time, not to the whole stack at once.
2. Can the company sustain the engineering organization required to keep building, year after year, as the payments landscape changes? Building is not a one-time cost. It is a permanent staffing commitment, and the talent market for payments engineering is competitive enough that the cost only goes up.
3. What is the cost of slowness? If a third-party roadmap dependency would block a growth strategy or a market entry, that changes the maths. Speed has a price, and so does the lack of it.

A fourth question is worth adding for any company past a certain scale: what does the exit look like? Whether the choice is to build, buy, or run a hybrid, the stack should be designed so that a future decision to swap a component is a project, not an existential migration. Lock-in, in either direction, is a tax on optionality.

Modularity is what makes the hybrid path realistic. A company does not have to pick one answer for the entire stack. The strategic layers can be built, and the undifferentiated ones can be bought, as long as the layers plug into each other cleanly. That is the design point we built Payrails around because it is the one most operators wish they had inherited.

A note on the total cost of ownership

Build-vs-buy comparisons almost always understate the real cost of building and overstate the real cost of buying. The build side tends to count headcount in year one and forget the compounding cost of retention, on-call, vendor management, scheme updates, regulatory change, and the slow accumulation of platform debt. The buy side often focuses on licence fees. It overlooks the savings from not running that organization, not maintaining those integrations, and not absorbing the opportunity cost of pulling senior engineers off the product roadmap.

A serious comparison looks at five years, not one. It includes the cost of standing still, the cost of falling behind, and the cost of catching up. Done honestly, the numbers usually point to a clearer answer than the original instinct.

If you are running this decision today

• If you are a CTO, separate the question per layer of the stack: token vault, orchestration, risk, reporting, and connectivity. The answer is rarely the same for all of them, and forcing a single answer usually produces the worst of both worlds.
• If you are a CFO, ask for the total cost of ownership over five years, including hiring, retention, scheme and regulatory change, and platform debt. The build option often looks cheaper in year one and very different in year four.
• If you are a CEO, make sure the team is answering the right question. Build vs buy is a means. The end is competitive advantage in the actual market, and that advantage rarely comes from where the build-vs-buy debate is loudest.

The companies that get this right are not the ones with the strongest opinions on building or buying. They are the ones that understand which parts of their payment stack actually create value, properly fund those parts, and refuse to spend scarce engineering time on the parts that do not.

That clarity, more than any single technology choice, is what compounds.

Trying to figure out the best decision for your payment setup? Request an ROI analysis today.