Settlement Systems at a Large E-Commerce Platform
A settlement system determines who the platform should pay, how much should be paid, and the basis for each amount, while retaining evidence that allows every result to be checked later.
Although the system is presented through financial administration screens and business documents, its data and state directly affect the safety of money. A field or status change can influence reconciliation, payment, invoicing, export, permissions, and audit records.
I worked on the application architecture and continuing evolution of this system during 2023 and 2024. Company names, amounts, and internal rules have been removed; the focus here is the problem and my contribution.
Business complexity
A settlement can pass through reconciliation, document creation, confirmation, payment, and invoicing. Different systems and teams may complete those steps at different times.
Imagine that we send a payment request and the connection times out. We know only that no response arrived. The payment provider may still have completed the transfer. Retrying blindly could pay the same money twice.
The system therefore had to answer three questions: was the amount correct, could an exception be recovered safely, and could we explain exactly what happened afterwards?
Role and key responsibilities
My role covered application architecture and key solution design. I consolidated business rules scattered across pages, APIs, and scheduled jobs into a system structure that could be maintained and evolved consistently.
Key responsibilities included:
- clarify the relationships between reconciliation records, settlement documents, payment instructions, invoices, receiving details, and settlement parties;
- centralise money precision, rounding, state transitions, permissions, and manual-adjustment rules so every channel used the same interpretation;
- separate responsibilities for queries, business actions, batch calculation, external integration, and large exports;
- make timeout, duplicate request, partial success, reversal, and manual repair part of the normal design;
- review data impact before releases, prepare rollback or compensation paths, and reconcile the result afterwards.
This moved the conversation from “can we change the code?” to “what happens to the money, the state, the external systems, and the recovery path?”
Safety of financial operations
External payment and invoicing requests used stable business identifiers. If a timeout caused the same request to be sent again, the receiving system could recognise that it had already handled it.
An unknown result was not forced into success or failure. It entered a state that could be checked later by a reconciliation job. That reduced the risk of both duplicate payments and genuine payments being recorded as failed.
Manual changes were also controlled. The system recorded who changed what, when, why, the values before and after, and the approval evidence. Audit data became part of the business record rather than an afterthought in application logs.
Module boundaries and deployment strategy
The system combined interactive queries, long exports, scheduled calculation, and calls to external systems. The architecture separated these responsibilities without assuming that every module required an independent deployment.
The main objectives were to give each rule a clear owner, maintain explicit dependency direction, and prevent long-running work from blocking interactive operations. Deployment boundaries were then selected according to load, failure isolation, and maintenance cost.
Outcome and architecture value
The result was a more controllable way to change software that moves money. Business rules had a single home, exceptions had defined recovery paths, external results could be reconciled, manual actions were traceable, and releases included verification and recovery plans.
Complex financial processes became explicit system rules, and when something went wrong the system stayed controllable, recoverable, and explainable.