Your Payment Platform Says It Can Scale. What Does the Code Say?
We asked the person who reads payment platforms for a living what “resilient and scalable” turns into once somebody lifts the floorboards. The short version, from Oxagile.
Deceptively spacious
Anyone who has bought a house speaks the dialect. Deceptively spacious is small, characterful is a floor that slopes toward the kitchen, and scope for improvement usually means “bring a bucket”. None of it would fail a lie detector, since every word was true on the morning the photographs were taken, and the agent hasn’t been back since.
Payment providers have their own version of this, and it fits on one slide. “Resilient, scalable payment infrastructure” goes in right before pricing, presumably so the number lands while everybody is still nodding. And to be fair to whoever wrote it, the slide accurately reflects the platform somebody drew on a whiteboard on day one. By the time a prospective client sees it, the code has been through several feature releases that were never drawn anywhere. Same house as the rendering, in that the postcode hasn’t changed. Yet two owners, three builders, and a lodger have.
Kyrylo Petrov is the one who turns up with a torch and asks to see under the stairs. His full Expert Talks interview is the long report. This is the summary page, with the findings most likely to change the offer.
Who is answering
Kyrylo Petrov is Director of Fintech Technology Consulting at Oxagile, and the person the company sends when a client’s question begins with “how bad is it”. He has spent most of his career in payments, a good part of it inside platforms that were about to be bought, which is the one moment when everybody suddenly wants to know what the code says.
He’s a regular at fintech events as far afield as Vietnam, and has by now been quoted in enough Oxagile payment articles that readers of the blog probably recognize the photo.
An honest listing, eighteen months out of date
Kyrylo is less skeptical of the claim itself:
“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.”
Unusually for a vendor claim, you can check every line on that slide. Either services deploy independently or they share a database and cannot. And the same test works on the integration layer: either it is abstracted or every processor has its own private passage knocked through a load-bearing wall.
Someone with access to the repository can tell you which within a day. The reason it rarely happens is the same reason almost nobody commissions a full check on a house they have already fallen for. Access, if it comes at all, comes late and with a deadline attached, and by then everybody in the room would prefer the answer to be “fine”.
Sixty
The example Kyrylo reaches for is a gateway that had all the right words on the listing. It was recently built, it was selling, and the listing used the resilience language above almost word for word. It was reviewed cold, without a guided tour or any commentary from the vendor, just the codebase and a standard quality assessment.
It scored 60 out of 100.
Our instinct was to read that as damp, rot, and a call to the lawyer. Kyrylo sees the score differently:
“Sixty is the score of a system that works. It processes payments, it has clients, it does not fall over on some random Tuesday.”
The missing piece is the cost of touching anything. The coupling is such that no wall moves without involving the roof, and the test coverage is thinnest on the payment and reconciliation paths. It’s as if a survey opened every cupboard but skipped the wiring.
On top of that, modules were written by different people under assumptions that were never recorded, and the architecture diagram no longer matches the dependency graph.
Customers see none of it, because nothing on that list breaks a transaction. It shows up when somebody tries to change the platform, which is the thing the buyer wanted it for. As Kyrylo puts it:
“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.”
Forty extensions, each with planning permission
Nobody sets out to build this. The route there is sensible at every single step, and arguing with it is irritating for that reason.
Get Oxagile’s stories in your inbox
Join Medium for free to get updates from this writer.
A platform launches doing one thing well: one payment method, one market, one processor. The architecture is clean because two people hold the whole thing in their heads. Then the first client asks for a second payment method. It arrives as a feature with a deadline, and it gets built onto what exists, because redesigning the whole house for one extra room would be madness, and a startup that does that for every request never ships. Kyrylo has no argument with that decision and says he would have made it himself.
Then it happens forty times.
Boundaries designed for one payment method end up supporting six. The clean abstraction grows a conditional for every market’s edge case. It’s like a kitchen adding a second fuse box because no one wanted to open the first one.
Those working on the project that week move, split, and regroup functionality as they go. Unlike most software, payments forgive none of it: a harmless retry elsewhere is a duplicate charge here, and an undocumented exception in a settlement path is a reconciliation failure at the end of the month. The expert comments:
“What you find is not bad code. It is forty good decisions that were never allowed to talk to each other.”
Detached? No, it isn’t
According to Kyrylo, the most common finding in a payment platform review is architecture described as microservices that behaves as a distributed monolith.
A row of houses that were sold as detached properties is an example. Each house has its own front door and number, and sometimes its own family. However, they also share one boiler. If you turn it off to fix one house, the whole row goes cold.
A shared database has a similar effect on schema changes: three releases must be coordinated instead of one. The houses call each other in synchronous chains that are so long that one slow neighbor can hold up the entire payment path. The owner pays for all the inconveniences of living apart: network calls, partial failures, distributed debugging, and no privacy.
Kyrylo argues that this is worse than having an honest monolith, and that many poorly performing platforms would be better off admitting they are building one house and building it well:
“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.”
The first winter
Technical debt often gets discussed as a year-five problem, something for the next owner to discover. In payments, Kyrylo says, it shows up within months, and under exactly the conditions printed on the slide.
Volume climbs, which is the family growing. A second market lands with its own compliance rules threaded through the same code paths, which is the in-laws moving into the loft. A large merchant is onboarded with a traffic pattern that nobody tunes for, which is the lodger who runs a small bakery from the kitchen.
All three are commercial successes landing on an architecture with no headroom. Resilience fails at its first real test, long before its hundredth. In the first proper winter of a house (the one the buyer was assured the roof could withstand), it fails.
What else can you discover?
The full interview is several times this length, and the parts with the expert’s opinion and advice that we cut are the ones you would take into a negotiation:
- Five questions to put to a vendor before believing the slide, none of which need an engineer to ask
- Why “how long did the last processor integration take” is a sharper question than “how long does one take”
- What a cold review returns that a reference call cannot, down to the number of days it needs
- Whether some technical debt is the right decision, and how to tell debt taken on purpose from debt that arrived on its own
- Kyrylo’s argument that resilience cannot be added to an architecture afterward, with the consequences for anything sold as “modernized”
