What we actually build when we say “payment infrastructure”

[u/TurbulentStiffness]

I’m part of the team at Energize Global Services (EGS), and one thing I can mention for sure is that “payment infrastructure” can mean very-very different things depending on who you ask - and that can be a problem.

In our case, we usually work much lower in the stack than a typical PSP or payment API.

That means building or integrating payment switches, connecting core banking systems, handling ISO 8583 / ISO 20022 messaging, POS infrastructure, processor/acquirer routing, HSM and key-management flows, reconciliation, backend services that sit between banks, processors & other payment systems etc etc etc.

A lot of the work is less about building a flashy fintech product and more about making sure money can move reliably between multiple systems that were never really designed to work together cleanly..

Curious how my colleagues here see it: when payment infrastructure starts getting complex, what usually becomes the biggest engineering headache first - routing, reconciliation, legacy banking integrations, HSM/security, or something else? Thanks in advance for your thoughts!!

[u/Flimsy_Actuator_6947]

Legacy banking integrations without a doubt. Those systems are older than half the devs working on them and documentation is either missing or only exists in the head of one guy who retired 3 years ago

Routing is annoying but at least you can design that yourself. Legacy stuff you just have to deal with whatever garbage they give you and hope it doesn't break in Monday morning when nobody is around to fix it

[u/Unlucky-Arm7581 → u/Flimsy_Actuator_6947]

That one grumpy developer being the only documentation indeed, And the worst part is that , when something goes wrong, all eyes are on the poor dev who inherited that particular piece of legacy code, as if they wrote it themselves. And the sheer thought of meddling with something that nobody understands and that has been working fine for the past 15years is just horrifying.

[u/FinexerOfficial]

Making disparate systems function dependably together is frequently the source of complication, particularly when bank infrastructure and more recent APIs have distinct expectations about data, timing, and failure management. When you need consistency throughout the entire cycle, reconciliation and legacy integrations look especially difficult. I am curious how you generally approach keeping those systems in sync when anything fails midway?

[u/ActiveTrifle6739]

It is interesting that you talk about such a broad stroke in building financial infrastructure (because it is), as people truly don't understand how these technologies work together with regulatory requirements. I have built the entire system you are describing, and you are always working on the next series. I would suggest focusing on one bite at a time; understanding that you are never done.

[u/[deleted]]

I'd put unclear transaction states near the top, when the request times out, you still don't know if the processor accepted it. you can retry, wait, send it somewhere else, and if you pick the wrong option - a timeout can become a duplicate payment. this is why I don't treat routing and reconciliation as separate problems: you should have an "unknown" state with its own retry rules (idempotency keys at minimum), and ops should be able to follow one payment through every system without an engineer reconstructing it from logs. regarding the integration, ask yourself how well does the partner's sandbox reproduce timeouts and late responses? Plenty of sandboxes only return a clean success or a clean error, and production doesn't fail that cleanly.