The problem
Selling into several countries means paying the way each country pays. Multiple local payment providers brought different webhook dialects and bank settlement formats — and the ledger still had to agree with all of them at the end of every day.
What I owned
The payment gateway itself: the checkout front end, the backend integration with each provider, and the data flow between them — from the moment a customer picks a payment method to the moment the order, the payment record and the ledger entry all agree.
This case study describes my responsibilities and integration principles, without publishing merchant routing configuration, bank connection details or raw transactions.
Routing
Different markets need different payment methods and providers. I integrated their interfaces and response formats so checkout could connect to the subsequent payment state handling. Provider-selection criteria and commercial configuration are outside the scope of this public case study.
Settlement
The CODA integration replaced a manual matching step: bank statements are parsed, matched against the ledger by reference and amount, and only genuine exceptions reach a human. The improvement came not from faster code, but from removing repetitive work and giving reviewers only genuine exceptions.
Reliability safeguards
Idempotency keys let retries refer to the same operation, while a normalized webhook event shape gives downstream handlers a consistent representation of payment state. The work focused on connecting external notifications, internal state and reconciliation results.
Retention needs its own boundary: keep the transaction identifiers and processing outcomes needed for the task. If original evidence is necessary, govern it by data classification, access controls and retention rules rather than keeping every payload in full. This is a design principle drawn from the experience, not a claim that every retention control was implemented at the time. See the PSP lifecycle article for the trade-offs.