Every CFO eventually walks into a room and says some version of the same thing: "Why do we have eleven payment integrations across our products? Let's centralize this." On paper it's obvious. One payment service, one ledger, one source of truth, one team owning the bank rails. Procurement loves it. Audit loves it. The board deck practically writes itself.
Then you start building it inside a real insurance and pension group, and you realize the eleven integrations weren't an accident. They were a coping mechanism.
The Myth of the Single Payment Pipe
In a multi-product environment — motor, health, life, individual pension, group pension, bancassurance — every product line has payment behavior that looks similar on the surface and is wildly different underneath.
A few examples from the wild:
- Motor insurance premium: single charge, optional installments via credit card, refund logic tied to policy cancellation date and unearned premium calculation.
- Health insurance: monthly recurring, often collected via direct debit (otomatik ödeme talimatı), with grace periods that vary by distribution channel.
- Individual pension (BES): monthly contributions, state contribution (devlet katkısı) reconciliation, employer-matched variants, and the regulatory requirement that a missed contribution doesn't terminate the contract — it just changes its status.
- Group pension: sponsor pays in bulk, allocation happens downstream per participant, and the timing of the bulk payment versus the allocation file is never the same day.
- Bancassurance: the bank collects, you reconcile T+1 or T+2, and the bank's file format is non-negotiable.
"One pipe" has to handle all of this. And handling it means your central payment service is no longer a payment service. It's a routing engine, a scheduling engine, a reconciliation engine, and a policy-status engine wearing a payment costume.
What You Actually Inherit
When you centralize, you inherit four things that were previously distributed across product teams who quietly absorbed the pain:
1. Routing logic. Which acquirer for which card BIN? Which bank for which product? Which channel gets which commission structure? Which currency for which contract? In Turkey alone, the difference in cost between routing a Bonus card transaction through one acquirer versus another can wipe out a quarter's worth of efficiency gains if you get it wrong. Multiply that by every BIN range, every installment option, every campaign.
2. Timing dependencies. Pension contributions have to land before the unit price calculation cutoff or the participant gets the wrong number of units. Insurance premiums collected after the policy effective date create a reconciliation gap that compliance will ask about. Direct debit files go to banks on schedule X, return files come back on schedule Y, and your accounting close depends on both. Centralization doesn't remove these dependencies — it concentrates them into one system whose downtime now affects every product simultaneously.
3. Reconciliation surface. When payments lived inside each product, each product reconciled its own slice. Centralize, and now you have one team reconciling acquirer files, bank statements, direct debit returns, state contribution files, agent commission clawbacks, and partner settlement reports — against a ledger that has to satisfy IFRS 17, local regulatory reporting, and internal management accounting simultaneously. The reconciliation team becomes the busiest team in the building, and nobody warned them.
4. Failure blast radius. A bug in the motor product's payment integration used to break motor. A bug in the central payment service breaks everything that sells, renews, or pays out. Your release cadence has to change. Your testing surface explodes. Your incident severity definitions need rewriting.
The Reconciliation Problem Nobody Costs Properly
The business case for centralization almost always underestimates reconciliation. The pitch focuses on integration savings, vendor consolidation, and unified reporting. The reality is that the moment you have one ledger absorbing payment events from twelve sources, you need:
- A canonical event model that survives every source system's quirks (and every source system has quirks — banks send fixed-width files with undocumented fields, acquirers change their CSV columns without notice, partners send Excel).
- An exception handling workflow that doesn't drown the ops team. If 0.5% of transactions need manual review and you process two million transactions a month, that's ten thousand manual reviews. Hire accordingly or automate aggressively.
- A break investigation tool that can answer "where is this 47.30 TRY?" in under two minutes, not two hours.
- An audit trail granular enough that when a regulator asks about a single participant's contribution from eighteen months ago, you can reconstruct the full lifecycle: collected, allocated, invested, reported.
Most organizations build the happy path first and discover the rest in production. That's an expensive way to learn.
What Actually Works
A few patterns I've seen hold up under real load:
- Separate the payment execution layer from the orchestration layer. Execution talks to banks and acquirers. Orchestration knows what the payment means for the product. Don't fuse them; you'll regret it the first time you onboard a new acquirer.
- Make the ledger event-sourced and immutable. Every payment event is a fact. Corrections are new events, not updates. Reconciliation becomes tractable; audit becomes trivial.
- Invest in the reconciliation tooling before you finish the migration, not after. The product team that goes last will be the one drowning in breaks because by then everyone else has moved on.
- Keep product-specific logic out of the central service. Routing rules, yes. "This is how a BES contribution behaves" — no. That belongs in the pension system, which calls the payment service with clear intent.
- Plan the cutover per product, not big bang. Run parallel for at least one full reconciliation cycle per product. The cycle for monthly direct debits is a month. Don't compress it.
The Honest Conclusion
Centralizing payments across enterprise platforms is worth doing. The cost of not doing it eventually becomes structural — every new product launch slows down, every regulatory change multiplies, every reconciliation question requires archaeology across systems.
But the framing matters. This is not a consolidation project. It's a re-platforming of how your company recognizes money moving in and out of itself. Budget it that way, staff it that way, and stop letting anyone describe it as "just one pipe."
The organizations that succeed treat the central payment platform as core infrastructure with the same seriousness as their policy admin system. The ones that fail treat it as a middleware project and discover, eighteen months in, that they've centralized the chaos instead of the payments.