The infrastructure decision behind a more flexible payments stack

‍

A regular look at the decisions, trade-offs, and compromises behind building payments.

When you're managing payments, it's easy to justify a new payment method as a way to unlock a market. Or a second acquirer to improve acceptance. Or even a new fraud tool to help reduce losses. 

The harder decision is knowing when you've added enough things that the way you're building them starts to become the problem. 

At some point, it can make more sense to invest in the infrastructure that connects everything than to keep adding another integration every time the roadmap changes. But making that case internally is not always easy, especially when the existing setup still works.

When the roadmap outgrows the stack

I remember experiencing this during my time at Rail Europe. We had one payment service provider (PSP), and for a long time, that worked well.

As the business started asking payments to do more, we started running into the limits of that setup. We wanted to add a fraud tool, bring on a second acquirer, and support new payment methods in specific markets. None of those requests was particularly unusual, but each one meant engineering work to integrate and maintain another part of the payments stack.

That raised a question that I think a lot of payments teams eventually have to grapple with: when does it make more sense to change the way you're building payments rather than keep adding to the existing setup?

Making the case for infrastructure

We weren't trying to fix a broken payments setup. We were looking at several things the business wanted to do and recognizing that continuing to integrate each payment capability separately would become increasingly costly and time-consuming.

At that point, the question became how we could build payments in a way that let us work more intelligently as the roadmap evolved. We needed to think beyond the next integration and consider what kind of infrastructure would give the team more flexibility to respond to what the business wanted to do next.

So I took the conversation to our executive committee. Payments touched product, tech, and finance, and I wanted to get everyone aligned on the strategy before we started talking about the implementation.

The conversation wasn't about "here's why we should use an orchestration layer." It was "here's where our payments strategy is going, and here's what we need our infrastructure to support it."

We were growing into new markets and segments, and even relatively small improvements in acceptance could matter. We wanted more flexibility in how we responded to new opportunities, rather than having every new requirement turn into another integration project.

What changes once the decision is made

Once the orchestration layer was in place, adding a new provider or payment method became much more straightforward. We also had more flexibility in how we worked with our existing providers.

But what I found more interesting was what that flexibility allowed us to do.

We could test new ideas without every experiment becoming a major engineering project. We could explore providers, payment methods, and approaches that might not have been worth pursuing when each one required a separate integration. Some opportunities that would previously have been too inefficient to test became realistic options.

That gave us more room to experiment and see what worked, rather than only pursuing the opportunities we already knew were worth the investment.

There was also a change internally. Once the strategy had been approved, we didn't have to keep reopening the same conversation every time the business wanted to explore a new opportunity. We'd already agreed on the direction we wanted payments to take, so the team could focus on making those opportunities work rather than repeatedly making the case for the infrastructure behind them.

I think this is one of the harder decisions for a payments manager. You have to look at where the business is going and decide whether the way you're building payments will give the team enough flexibility to keep up with it.

When individual requests start becoming a pattern, it can be worth stepping back from the next integration and asking a different question: Are we still solving individual payment problems, or is it time to solve the infrastructure problem underneath them?

Ready to evaluate your payments setup? Get your Payment Orchestration Buyer’s Guide.

‍