Back
- Payments look modern, but core infrastructure is still legacy
- The real challenge is managing hidden complexity, not adding features
- Future platforms must be cloud-native, modular, and built for change
Payments may feel simple on the surface but the infrastructure behind them tells a very different story.
If you ask most businesses how payments work today, they will point to what they can see.
Fast checkouts. Digital wallets. Clean integrations. APIs that make it easy to get up and running.
And they would be right... on the surface.
But underneath, much of the infrastructure that powers payments today is still built on technology that is 15 to 20 years old.
The rails, the actual movement of money from merchant to scheme to issuer and back, haven’t fundamentally changed. What has changed is everything wrapped around them.
So the biggest misconception is this: payments look modern, therefore they must be modern. In reality, we are still working with the same plumbing. We have just built better interfaces around it.
Payments are simple for the user and complex everywhere else
One of the defining characteristics of payments is that the more invisable the experience becomes, the more complexity is hidden beneath.
A single tap or click triggers a chain of events:
- Routing across networks
- Authorisation checks
- Messaging between schemes and banks
Compliance and risk controls
All of this happens in seconds.
But that simplicity creates a challenge. When something goes wrong, it is rarely obvious where the problem sits. It could be the terminal, the integration, the acquirer, the issuer or somewhere in between.
From a customer perspective, it is just “the payment didn’t work.”
From a platform perspective, it is a highly distributed system with multiple dependencies, all of which need to function perfectly.
The real challenge is not innovation it is complexity
Modern payment platforms are not struggling because they lack features. They are struggling because of complexity.
Every new payment method, every new market, every new regulation adds another layer:
- Different acquirer requirements
- Different message formats
- Ongoing certification and mandates
- Continuous updates to remain compliant
Most of this work is invisible. Customers do not see it. But it is where a significant amount of effort and cost sits.
Over time, this creates a system that is harder to maintain, slower to adapt, and more expensive to operate.
Why “cloud native” is often misunderstood
There is a similar misconception when it comes to modern architecture.
Many platforms describe themselves as cloud-based. But there is a difference between running in the cloud and being built for the cloud.
True cloud native architecture means:
- Applications designed as microservices
- Built to handle failure as a normal condition
- Able to scale up and down dynamically
- Distributed across multiple regions and availability zones
What often happens instead is a “lift and shift” approach; taking existing applications and hosting them in the cloud.
That delivers some benefits, but not the most important ones.
If you do not modernise the application itself, you do not get the elasticity, resilience, or cost efficiency that the cloud is designed to provide. In fact, you can end up increasing your costs.
The non-negotiables of modern payment infrastructure
When I think about building payment platforms, there are three things that are not optional.
- Stability – the system must work, consistently
- Security – protection must be built in, not added later
- Scalability – it must handle growth and change without breaking
You can add speed as a fourth, but those three are the foundation.
The challenge is that these are often in tension with each other. Delivering new features quickly is important but not at the expense of resilience or security.
In payments, failure is not theoretical. It has real consequences.
When infrastructure fails, the impact is immediate.
Across the industry, there are plenty of examples where things have gone wrong.
I have seen situations where systems were designed with full resilience, active-active data centres, with failover, everything working as intended.
And then a simple human error; running the wrong script during maintenance, took down the active environment.
Processing stopped.
From the outside, it looks like a single outage. Internally, it is a reminder that even well-designed systems can fail if they are not built to handle real-world conditions.
Other failures are less visible but just as damaging:
- Duplicate transactions charging customers twice
- Incorrect settlement leading to overpayment
- Delays that impact customer trust
These are not edge cases. They are part of operating at scale.
Building for change, not just scale
Historically, payment platforms were designed to handle volume. Today, they need to handle change.
New payment methods. New markets. New expectations. New regulations.
That is why modern architecture is moving towards:
- Modular, API-driven systems
- Microservices that can evolve independently
- Cloud-native environments that support rapid scaling and recovery
The goal is not just to process transactions efficiently, but to adapt continuously without disruption.
Connecting payments to the broader ecosystem
Another shift is happening beyond payments themselves.
Processing is becoming increasingly commoditised. The real differentiation is moving into how payments connect with the rest of the business.
That means integrating with:
At Planet, a big part of our focus is on building that connectivity.
Not as an afterthought, but as part of the core platform.
The plumbing is already in place, linking payments into the wider operational ecosystem. That is what allows businesses to move beyond payments as a standalone function and start treating them as part of a broader value chain.
If we started again today
If I were designing a payment platform from scratch today, the approach would be clear.
It would be:
- Cloud native from day one
- Modular and microservices-based
- API-first for both front-end and back-end connectivity
From a customer perspective, it would be simple; connect, configure, and go.
Behind the scenes, the complexity would still exist. But it would be managed in a way that allows the platform to evolve without friction.
Final thoughts
Payments have never been more important, or more complex.
The front end has transformed. The expectations have changed. The scale has increased.
But much of the underlying infrastructure is still catching up.
The next generation of payment platforms will not be defined by features. They will be defined by their ability to handle complexity quietly, reliably, and at scale.
Because in payments, the best technology is the kind you never notice.
Planet newsletter
Built for your industry. Focused on your challenges. Delivered to move you forward
We respect your privacy. Unsubscribe at any time.
