Key Insights
- Unlike LEGO, most payment systems weren’t designed to fit together. They’ve been assembled over time, which is why even small changes turn into complex projects.
- Modularity in payments depends on consistent ways for components to connect, so change becomes a design decision rather than a rebuild.
- Modern payment estates struggle because there’s no shared foundation tying vendors, devices and services into one system.
- Simplicity works until it doesn’t. As businesses expand across markets, channels or use cases, rigid setups start to limit what’s possible.
- Orchestration creates the connections that make the pieces work together, so payment systems can be built, changed and rebuilt without starting from scratch.
Don't have time to read more now? Sign up to our newsletter to get the latest insights directly in your inbox.
Remember your first LEGO set?
Did the excitement come from unwrapping the box, or the seriously satisfying sound of rattling the bricks? Or, was it the feeling of “Wow, I can actually build anything with this”?
Now, imagine if payments felt like that…
For most teams though, they don’t. They don’t get a new box; they inherit a half‑finished model that’s been tweaked and extended by different people over years. It runs, but nobody is completely sure which piece is holding it together, or what might break if they move it.
And right now, that’s more important than ever.
The last few years have brought more new devices, local payment types, regulations and use cases than the decade before. So, instead of feeling “I can build anything with this”, many estates are creaking under the weight of “we’ll just bolt on one more brick” again and again and again.
Aevi’s team of payments experts have been exploring that idea, and let’s just say, if you work in payments, you might just find the outcome pretty interesting…
If LEGO works because the connection never changes, what’s the equivalent in payments?
For a long time, in-person payments felt like buying a LEGO kit and following the instructions. One provider, one terminal estate, one acquirer, a familiar set of reports. Follow the steps and you end up with something predictable.
“I describe that era as ‘building whatever was on the picture’, as in you bought a standard setup, used it as-is, and got on with running the business.”
Victor Padee, CRO, Aevi
That worked when you sold in one country, accepted a narrow range of payments, and didn’t need to think about unattended, pop-up, fuel or account-to-account.
New terminal types layered on top of old ones. A local wallet integration here. A separate gateway for one region there. A different estate tool for a specific use case. None of it arrives as part of a plan, it builds up as “just one more thing” each year.
Look at LEGO closely then, and you’ll see that the clever bit isn’t the finished model; it’s actually the connection. A brick from decades ago still snaps onto one made this year because the interface never changes.
Charles Leeming, Head of Product EMEA at Aevi, sees the same pattern in payments. Behind every transaction sits a “payment infrastructure backbone”: the secure, regulated flow that moves money, enforces schemes and networks, and passes audits.
You can innovate on the edges. The core has to stay stable.
“Aevi’s role is to hold that backbone steady while giving customers room to move around it. The ‘studs’ are the standard ways devices, apps, acquirers and services connect into that backbone. Shared interfaces, predictable data, repeatable ways of introducing something new without pulling everything apart.”
Charles Leeming, Head of Product EMEA, Aevi
That orchestration layer is what keeps the studs lined up, even as everything on top of them changes. So, essentially, you’re not buying a finished outcome, you’re buying capabilities that you can recombine, grow, adapt on.
In short, if the connections are consistent, the build becomes flexible.
If payments are meant to be modular, why does changing one thing still feel so hard?
On paper, it looks simple:
- Change acquirer, swap a piece
- Add a new device, connect it
- Introduce a payment method, slot it in
Real estates, however, don’t behave like that.
Devices are tied to specific acquirers and kernels and certifications cling to particular paths. Different parts of the estate sit in different management tools, and reconciliation depends on how one gateway structures its data. Touch one connection and you uncover three more decisions that were hard-coded years ago.
And that’s how fragile systems survive, by making change really difficult.
So, things like integrating new use cases become a bit tough; acceptance rates stay “OK” rather than “great”, and teams adapt to the model they inherited because changing it feels riskier than living with it.
However, orchestration is the way out…
“The payment application and the hardware all represent the kind of LEGO pieces you can keep rearranging as your needs change. When each piece connects through the same interface, changing one becomes a design decision, as opposed to a one off project.”
Alex Benjamin, Director of Business Development, US
But that only works if you can actually see how everything fits together.
Where do hidden dependencies creep in?
Under the surface, payment systems are very messy. APIs, SDKs, estate tools, certifications, routing logic all make things quite complicated, and truthfully, that complexity doesn’t really go away.
“There are a lot of protocols and APIs in the world,” Charles says, “but what makes Aevi powerful is that how those LEGO blocks connect is transparent to the person building the picture.”
And that’s the gap.
Most systems weren’t designed as modular builds, they were assembled over time. Each integration made sense at the time, but together they create a web of dependencies that’s hard to map and even harder to change.
In short, something that should be simple actually becomes unpredictable.
So, who’s really designing the build?
Many organizations think they’re designing their payments stack, when in reality, what they’re really doing is simply following instructions.
That’s because vendor roadmaps dictate what’s possible, and device capabilities limit what can be introduced. Add to that integrations that are shaped by what already exists rather than what’s actually needed, and the result is a system that works, but only in a way that reflects the constraints of its components rather than the intent of the business.
With orchestration, that dynamic changes.
The merchant brings the equivalent of the “box art” (aka: the image on the front of the LEGO box) and a clear idea of the journey they want at the pump, at the kiosk or in a pop-up, then Aevi handles how the pieces connect underneath.
That might involve one acquirer or several. A handful of APIs or many. The point is that the structure adapts to the design, not the other way around.
And that opens up a bigger question about how much flexibility you actually need…
When is it time to graduate from DUPLO
It’s worth saying, this isn’t about being “perfectly” modular. Some businesses are genuinely better off keeping things simple.
As Victor puts it, “for many SMEs, building something highly flexible can be more of a hassle than it’s worth. Taking something off the shelf, using it as‑is, and getting on with running the business is the right call.”
In LEGO terms, DUPLO has its place. Big pieces, straightforward builds, fast results. In payments, that usually means a single‑country, single‑acquirer, single‑channel setup: one box, one set of instructions, and it does the job.
The problem, therefore isn’t DUPLO, the problem is staying there after you’ve outgrown it. A retailer adds fuel or quick‑service, an ISV expands into new regions, a platform realizes it’s running multiple in‑person stacks in parallel.
The original setup still runs, but every new idea hits some kind of friction:
- “We can’t do that on this estate.”
- “That’ll take a year.”
- “We’d have to replace X to add Y.”
That’s the point where the model starts holding you back. Or as Victor puts it, “If you want to play with real LEGO, there’s a point where you have to move beyond DUPLO, and we can help you do that.”
So the real question for payment teams becomes: “Does the way we’re set up still match what we’re trying to build next?”
Who owns the build when everything keeps changing?
The pace of change in in-person payments isn’t slowing down, as new form factors, local schemes, evolving customer expectations, regulation, and data demands keep stacking up.
Victor’s point is that the idea of a “forever” system doesn’t really hold, and what businesses can own instead is the shape of their architecture, and then control how easily they can rebuild it without starting from zero.
That’s where Aevi is deliberately positioned: as an orchestration layer for in-person payments. One that connects devices, acquirers, applications and services into a consistent framework, so businesses can design their own model and keep adapting it over time.
Because the real advantage here is two-fold: it’s having the right pieces, as well as the ability to rebuild them into something you actually want, opposed to just what you’ve been shown on the box.
Happy building!
Interested in reading more on this topic? Check out our other related articles…
