This website uses cookies to help improve your user experience
“Resilient and scalable” is a checkable claim, and almost nobody checks it. Independent deployability, shared databases, integration abstraction, and coverage on payment paths are all verifiable in code within days. The claim routinely travels further than the evidence behind it.
In payments, architecture erosion shows up in months. New markets, new processors, and large merchants with atypical traffic all arrive as signs of commercial success within the first year, and land on an architecture built with no headroom.
That does not make technical debt inherently bad. A payment platform designed upfront for every feature it may ever need would probably never ship. Some debt is the price of moving fast. What matters is whether the team knows where it is, why it was taken, and what it will cost when the platform needs to change.
That line between necessary compromise and architecture that has quietly become a constraint is the focus of this Expert Talks edition, where we give the floor to one of the engineering voices behind Oxagile.
Kyrylo Petrov, Director of Fintech Technology Consulting at Oxagile, has spent much of his career inside payment platforms that are about to be bought. We asked him which architectural choices are genuinely load-bearing, which ones only feel that way, and how each shows up later as cost, exposure, or a ceiling.
Key takeaways:
“Resilient, scalable payment infrastructure” appears in almost every payment provider’s pitch deck, usually on the slide right before pricing. It may seem like a lie, but it is more like a description of intent, of what the architecture was meant to be on the day someone drew it.
By the time a prospective client hears it, the code underneath has usually been through two years of feature releases that nobody drew at all.
Kyrylo notes:
“The gap between those two things is not visible from the outside. It does not show up in a demo, in uptime dashboards, or in a reference call, because it is not a reliability problem yet.
It becomes one later, at the precise moment a client starts scaling volume, adding markets, or onboarding a second processor, which is to say, at the moment the word “scalable” was supposed to start paying for itself.”
A payment provider’s technical pitch has a fairly consistent shape. Microservices, for components to scale independently. Horizontal scaling so volume is not a constraint. Redundancy and failover, meaning a single component going down does not take payments with it. And modular integrations to make a new processor or market a configuration change instead of a project.
Expert thoughts:
“Nobody is lying in those decks. They are describing the system they designed, and it was probably a good design. The problem is that the design and the code stopped being the same thing about eighteen months ago, and the deck never got updated because nothing broke yet.”
Every one of those claims is architecturally meaningful, and every one of them is verifiable in code. That is the useful part: unlike most vendor claims, these are not matters of opinion.
Kyrylo points out:
“Either services can be deployed and scaled independently or they share a database and cannot. Either the integration layer is genuinely abstracted or each processor has its own bespoke path threaded through the core.
Somebody who opens the repository can tell you which case it is within a day.”
The reason nobody usually does is that access is rarely granted, and when it is, the review happens under commercial pressure with a deadline attached. So the claim travels further than the evidence.
Kyrylo recalls:
“The clearest example in my recent memory involved a payment gateway that was, by any commercial measure, doing well. Recently built, actively selling, positioned on exactly the resilience and scalability language above.
It was reviewed cold, with no context from the vendor, no guided tour, just the codebase and a standard quality assessment.
It scored 60 out of 100.
That number deserves unpacking, because the instinct is to read it as a failing grade and it is not quite that.
Sixty is the score of a system that works. It processes payments, it has clients, it does not fall over on some random Tuesday.”
What sixty reflects is everything that has been deferred:
None of that is visible to a customer today. All of it is a constraint on what the platform can do next.
Kyrylo argues:
“Sixty is not a bad score for a young product. It is a bad score for a product being sold on scalability. Those are different statements.
The number tells you what it will cost to change the system, and changing the system is precisely what the client is buying.”
Nobody sets out to build this. The pattern is close to universal and it is, at every individual step, the correct commercial decision.
Kyrylo gives an example:
“A platform launches with one thing done well, like a single payment method, a single market, a single processor. The architecture at that point is usually clean, because the scope is small and one or two people hold the whole thing in their heads.
Then the first client asks for a second payment method. It arrives as a feature, on a deadline, and it gets added to the existing structure with little reason or time to revisit the architecture around it.
Which is right: revisiting the architecture for one feature would be over-engineering, and a startup that does that for every request never ships. The problem is that this happens forty times.”
Each addition is locally reasonable and none of them triggers a redesign, because no single one justifies it. Meanwhile the boundaries that made sense for one payment method are quietly carrying six, the module that was a clean abstraction has accumulated conditionals for every market’s edge cases, and functionality gets re-clustered on the fly: moved, split, and grouped by whoever is working that week rather than by any principle that survives being written down.
What makes this specifically painful in payments is that the fintech domain does not forgive it. A retry that is safe in most software is a duplicate charge here. A settlement path with an undocumented exception is a reconciliation failure at month end. The bolt-on pattern produces exactly the kind of implicit, memory-resident knowledge that this domain punishes hardest.
The expert adds:
“What you find is not bad code. It is forty good decisions that were never allowed to talk to each other. Any one of them, in isolation, I would have made the same way.”
Learn how Oxagile migrated card payments for 1.5+ million active users for a major food delivery platform. This resulted in improved security, conversions, and overall financial observability.
Kyrylo brings up another matter:
“The most common finding in a payment platform review is an architecture that is described as microservices and behaves as a distributed monolith.”
The services exist. They have their own repositories, their own deployment pipelines, sometimes their own teams. What they do not have is independence. They share a database, so a schema change requires coordinating three releases. They call each other synchronously in chains deep enough that one slow service degrades the whole payment path.
He mentions:
“They cannot be scaled separately in any meaningful sense, because the bottleneck is shared. The organization has taken on every operational cost of distribution, like network calls, partial failures, deployment complexity, distributed debugging, and acquired none of the benefits it was paying for.
This is worse than a monolith, and it is worth saying plainly because the industry’s instincts run the other way.”
A well-built monolith with clear internal boundaries is a perfectly respectable foundation for a payment platform, and it is far easier to decompose later than a distributed system is to un-distribute.
Many of the platforms that score poorly would have been better served by admitting they were building a monolith and building a good one.
A takeaway from Kyrylo:
“If your services cannot be deployed independently, you do not have microservices. You have a monolith with network latency added, and you are paying for the privilege.”
Kyrylo has seen this firsthand:
“The timeline surprises people. Technical debt is discussed as a long-horizon problem, something that catches up with you in year five, and in payment platforms it does not behave that way.
Performance degradation typically shows up within months of launch, and it shows up under exactly the conditions the platform was sold on.”
Transaction volume climbs. A second market comes online with different compliance requirements threaded through the same code paths. A large merchant onboards and their traffic pattern does not resemble the one everything was tuned for. Each of these is a normal commercial success, and each of them lands on an architecture that had no slack in it.
The expert adds:
“The result is that resilience fails at its first real test, not its hundredth.
Which is the actual argument against the bolt-on pattern: not that it produces messy code, but that it produces a system whose limits are reached on the way up than at the top.”
Oxagile reviews and modernizes payment platforms, including cold code reviews for teams deciding whether to build on, buy, or rebuild.
If you are evaluating a payment platform, as a client building on it, an acquirer, or an investor, the useful questions are narrow and answerable. Broad ones (“is it scalable?”) get you the deck.
Kyrylo advises:
“Ask whether services can be deployed independently, and ask for the last three releases for concrete evidence.
Ask what the test coverage is specifically on payment paths and reconciliation, not overall.
Ask how long it takes to add a new processor, and what the last one actually took.
Ask whether services share a database. Ask to see the architecture diagram, then when it was last checked against the code. The answer to the second question is usually more informative than the diagram.
None of that requires deep technical expertise to inquire, and the quality of the answers is diagnostic on its own.”
A team with a well-maintained system answers these quickly and specifically. A team carrying significant debt answers them in the language of the pitch deck.
Where the stakes justify it, an independent code review settles it properly. A cold review by people with no stake in the answer takes days as opposed to months and produces something the commercial conversation cannot: a number and a list of what produced it.
From Kyrylo’s experience:
“Every one of those questions has a factual answer sitting in the repository. That is the thing worth remembering about this whole category of claim, it is checkable. People just do not check.”
The honest position is that some technical debt is correct. A payment platform that designs for the full scope of functionality before shipping anything ships nothing, and the graveyard of over-architected fintech products is not smaller than the graveyard of under-architected ones.
The distinction that matters is whether the debt was taken deliberately. A team that knows it bolted on the last six features, knows what that cost, and has a view on when the structure needs revisiting is in a fundamentally different position from a team that has been re-clustering functionality on the go and describing the result as microservices.
Both have debt. Only one of them can tell you what it will cost to change the system. And for a client evaluating a payment platform, that is the entire question.
Resilience is not a property you add to an architecture. It is a property of having designed for the scope you actually intended to serve, before the first feature shipped. Everything after that is modernization, which is a good and normal thing to do, but it is a different activity, with a different price, and it should not be sold as the original design.
Oxagile’s expert team knows how to build architectures to scale and last.
It is the accumulated cost of architectural decisions deferred while features shipped, coupling between components, inconsistent patterns, and gaps in test coverage on critical paths. In payments it carries higher consequences than in most domains, because the failure modes are duplicate charges, reconciliation errors, and compliance gaps that can seem like cosmetic bugs.
Oxagile’s expert fintech team does that through an independent review scoring coupling, architectural conformance, test coverage on payment and reconciliation paths, and consistency across modules. A cold review, conducted without a guided tour from the vendor, takes days and produces a defensible score alongside the specific findings that generated it.
It describes a system that works but is expensive to change. It typically indicates deferred architectural decisions more than active defects: the platform processes payments reliably today, while coupling and inconsistency constrain how quickly and safely it can be extended tomorrow.
Because the pressures that cause erosion, like new payment methods, new markets, large merchants with atypical traffic, arrive as commercial success within the first year. An architecture designed for the initial scope and extended by bolt-on meets those pressures without headroom, so degradation surfaces in months, not years.
Whether services deploy independently and what the last three releases show. Other questions include: test coverage specifically on payment paths, how long the most recent processor integration actually took, whether services share a database, and when the architecture diagram was last verified against the code. Specific, evidenced answers indicate a maintained system.
