Rebuilding a Live Payment Core — Across 4 Markets, With Zero Documentation

From a regional fintech powerhouse to a fully rebuilt payment core — engineered for real money, real markets, zero margin for error.

This wasn’t a greenfield project. Real users were transacting. Logistics fleets depended on it for fleet card payments. Maritime companies ran seafarer payroll through it. Over a million SME merchants relied on it to move money. There was no pause button.

The existing infrastructure ran on PHP — a working system, but one that had accumulated years of undocumented business logic baked into the code. The goal was to migrate that logic into a new Golang-based architecture: faster, more maintainable, built to scale. The challenge was doing it without a single document to guide the way.

Why this rebuild couldn’t wait

• Core payment processing needed sub-second latency across four markets
• Security and compliance requirements were non-negotiable — MAS licensing meant enterprise-grade standards at every layer
• The legacy PHP system had no documentation — business logic lived only in the codebase
• The in-house team was running at full intensity; they needed a partner who could operate at the same pace without hand-holding

The client’s in-house team had a specific culture — high intensity, high ownership, low tolerance for people who needed to be managed. They described their DNA as: decisive, self-sufficient, unafraid of hard problems. They weren’t looking for a vendor. They were looking for a team that could embed, adapt, and operate as if they’d always been there.

We started with four engineers — three Golang developers and one Data Engineer — in August 2025. No formal onboarding. No documentation handover. Just access to the codebase and a clear mission.

Phase 1: Navigate the undocumented system

The first challenge wasn’t technical. It was epistemic — we didn’t know what we didn’t know.

The existing PHP codebase contained years of accumulated business logic: payment routing rules, transaction validation flows, edge case handling built up from real incidents. None of it was written down anywhere outside the code itself.

The team’s approach: read everything. We dug through the PHP system methodically, tracing execution paths, mapping transaction flows, and cross-referencing our interpretations with the in-house team to validate assumptions. Every conversation with the client’s engineers became a documentation session in disguise.

This wasn’t glamorous work. But it was the work that made everything else possible — and the process we built for onboarding ourselves became the onboarding playbook for the six engineers who joined later.

Phase 2: Build the new core in Golang

With enough of the legacy logic mapped, we began the migration to Golang — building the new payment features in parallel with the live PHP system, not replacing it overnight.

The scope covered:

• Core payment feature development (new transaction types, routing logic, settlement flows)
• Backend performance optimization for sub-second processing across markets
• Live production incident investigation and resolution — debugging issues on the running system while building the replacement
• Backlog clearance — resolving accumulated bugs in the existing PHP system that had been deprioritized

At every stage, the team went beyond the task definition. When we spotted a structural improvement in the Go architecture — a cleaner way to handle a transaction state, a more efficient data model for a particular flow — we raised it. Not as a change request, but as a conversation. The client’s team responded well to this because it came from genuine understanding of the system, not from guessing.

Phase 3: Earn the expansion

Six months in, the client’s confidence had shifted. What started as a cautious four-person engagement — a trial, in all but name — had become a structural dependency.

In early 2026, the client asked Sun* to take on additional project scopes. The team expanded to ten engineers across two phases (March and April 2026). The knowledge the original four had built — the mental map of the system, the working relationships with the in-house team, the documented patterns from the zero-docs onboarding — became the foundation for scaling faster than any new team could have managed from scratch.

The 250% team growth wasn’t the result of a sales process. It was the result of four engineers doing exactly what they said they would do, consistently, for six months. When the client decided to scale, the question wasn’t “can Sun* handle more?” — they already knew the answer. The question was how fast they could bring new people up to speed.

That’s where the zero-docs onboarding work paid a second dividend. The mental models, the codebase maps, the validated assumptions about the PHP business logic — all of that became institutional knowledge that the team could transfer. The six engineers who joined in 2026 onboarded faster than the original four did, because the original four had done the hard work of figuring it out and writing it down.

We also learned something about what fintech clients actually need from an ITO partner. It isn’t just technical competence — the market has plenty of that. It’s the ability to operate without supervision in a high-stakes environment. To ask the right questions rather than the easy ones. To care about the system you’re working on, not just the task you’ve been assigned.

Role-based access and data perimeters matter earlier than you think. In multi-market fintech systems, the security architecture decisions made at the beginning of an engagement have outsized downstream consequences. Getting those boundaries right before the system scales is far cheaper than retrofitting them after.

Ambiguity is the real technical challenge. The hardest part of this project wasn’t the Golang architecture or the PHP migration. It was navigating a complex, undocumented system under time pressure, with real transactions running in parallel. The engineers who thrive in that environment — curious, systematic, comfortable with incomplete information — are a fundamentally different profile from those who need well-scoped tickets to perform.