Case study: rebuilding a payments platform's core into auditable, event-sourced services ahead of a compliance recertification deadline for a Series B European fintech.
Key Results
StepTo re-architected the payment processing core of a Series B European fintech (payments and lending, Lithuania) into auditable, event-sourced transaction services ahead of a PCI-DSS / PSD2-style compliance recertification. The original platform, built quickly to hit an earlier compliance deadline, had accumulated technical debt: a monolithic payment processor with no clean audit trail, manual reconciliation against processor settlement files, and a pre-recertification audit that flagged insufficient transaction logging and inadequate access controls. The project took 5 months with a 4-person dedicated squad (2 backend engineers, 1 DevOps/security engineer, 1 tech lead), migrating one payment rail at a time in shadow mode alongside the live system with zero processing downtime. Results: recertification passed on schedule with zero critical findings, reconciliation time cut from 3 days to under 4 hours, reconciliation discrepancies down 92%, and €42M in transaction volume processed during the migration with zero missed or duplicate transactions.
A Series B European fintech had built its payments platform fast to hit an early compliance deadline — and the shortcuts were catching up with them. The payment processing core was a monolith with no clean audit trail, reconciliation was a manual, spreadsheet-driven process prone to error, and a pre-recertification audit had just flagged gaps serious enough to put their PCI-DSS / PSD2-style license renewal at risk, with a hard deadline to fix them.
StepTo assembled a 4-person dedicated squad and re-architected the payment processing core into auditable, event-sourced transaction services in 5 months — migrating one payment rail at a time alongside the live system with zero processing downtime, and passing recertification on schedule.
Measured through the recertification audit and the quarter following full rollout
The client's payments platform had been built in an 8-week sprint three years earlier to hit the deadline for their initial e-money license — speed mattered more than architecture at the time, and it showed. The payment processing core was a single monolithic service handling authorization, ledger updates, and settlement in one code path, with no structured event log and inconsistent logging across payment rails.
Reconciliation — matching internal transaction records against processor and bank settlement files — was done manually in spreadsheets by two finance analysts, taking up to three days each month and prone to human error. When a pre-recertification compliance audit flagged insufficient transaction logging and inadequate role-based access controls, the client had a hard deadline to remediate before their next PCI-DSS / PSD2-style recertification — miss it, and they risked losing the license that let them operate as a payment institution.
Compounding the pressure: the same monolithic architecture that made the audit trail hard to produce was also the reason the client had been unable to ship a new payment rail for over a year — every change risked breaking reconciliation in ways that were hard to detect until the next manual close.
StepTo proposed re-architecting the payment processing core around event sourcing: every state change — authorization, capture, settlement, refund — would be recorded as an immutable, timestamped event in an append-only ledger, rather than overwritten in place. That gave the client a complete, tamper-evident audit trail as a structural property of the system, not a report generated after the fact.
The new core ran as idempotent transaction services on Node.js, with Kafka handling asynchronous event processing between authorization, ledger, and reconciliation services, and PostgreSQL holding the append-only event store. Role-based access control was rebuilt from scratch around the audit's specific findings, with every access grant and change logged through the same event pipeline. Migration happened one payment rail at a time: each rail ran in shadow mode — processing real traffic through both the old and new systems in parallel — until reconciliation between the two matched exactly, then traffic cut over with no downtime.
Mapped every payment flow end-to-end against the audit findings, catalogued which components lacked a clean audit trail, and prioritised the remediation plan against the recertification deadline.
Built the new transaction services around an append-only event log — every authorization, capture, settlement, and refund recorded as an immutable event, with role-based access control designed around the audit's specific findings.
Built an automated reconciliation engine that matches processor and bank settlement files against the internal ledger nightly, replacing the manual spreadsheet close.
Migrated one payment rail at a time in shadow mode — running old and new systems in parallel and reconciling them line-by-line — before cutting live traffic over, with zero processing downtime.
Compiled audit trail documentation, ran a pre-audit dry run with the client's compliance team, and supported them through the live recertification audit.
We treated the specific gaps the pre-recertification audit flagged — transaction logging depth, access control granularity — as functional requirements from day one, not a checklist bolted on at the end. The client's compliance team reviewed the architecture and the emerging audit trail at the end of each phase, not just at the final handover, so there were no surprises going into the pre-audit dry run.
Every historical transaction was backfilled into the new event-sourced ledger as an append-only import, then reconciled record-by-record against the old system in a shadow environment before any live traffic touched the new core. Nothing was overwritten or deleted — the old ledger stayed queryable throughout the migration as a fallback of record.
A consultant tells you what is non-compliant; we built the engineering that made the platform compliant and kept it that way. The audit trail here is not a report generated after the fact — it is a structural property of the event-sourced architecture, so every future audit is materially easier, not just this one.
No planned downtime. Each payment rail was migrated individually in shadow mode — processing real traffic through both the old and new systems simultaneously — and traffic only cut over once reconciliation between the two matched exactly. If a discrepancy had appeared, that rail simply stayed on the old system until it was resolved.
Whether you're facing a compliance deadline, need a dedicated team, or an architecture review — let's talk. We'll have a scoped proposal to you within 48 hours.
Start the conversationTell us what you're building and we'll get back to you within one business day with a no-obligation assessment.
We'll reply within one business day.
Work with accountable, English-fluent professionals who communicate clearly, protect quality, and deliver with a steady operating rhythm. Cost efficiency matters, but performance is why clients stay with us.
