The situation
At LOQBOX, payment collection was both a scaling challenge and a customer-care responsibility. A sequential process took approximately ten hours to work through around 200,000 payments. Retry behaviour also needed to be made safe.
As Lead Developer, I provided technical leadership within a nine-person engineering team. I championed the modernisation, built the initial proof of concept, coordinated the wider implementation, and owned the production release and monitoring.
The decisions that mattered
Separate preparation from execution
We separated the process that identified and calculated payments from the workers that executed them. Individual collections could then be queued and processed concurrently.
Concurrency had to respect the payment provider’s limits. I worked with the gateway to understand those limits and with Finance to make sure downstream systems could handle the more concentrated flow of events.
Make retries represent the same payment
We introduced deterministic payment references. An uncertain or repeated request retained the same reference, allowing the provider to recognise the same logical payment. This property is called idempotency: repeating an operation does not create another successful charge.
Safe retries and concurrency belonged in the same design. Increasing speed was useful only if we could preserve correct behaviour when requests failed or responses were uncertain.
Coordinate the whole change
I worked across Product, Finance, Marketing, DevOps and the external payment provider. The release needed an operational plan as well as working code. We observed the rollout together, including the high-volume first-of-month collection run.
How we worked together
Reliability also depends on how a team learns. At LOQBOX, I supported practical code reviews, testing, staged releases, monitoring and runbooks, alongside coaching and blameless incident learning.
I adapted feedback to the person and the situation. Private, contextual conversations helped people understand the issue, ask questions and take ownership of the next step.
What changed
Processing around 200,000 payments moved from approximately ten hours to around two hours. Some runs completed sooner. The new retry approach prevented repeated requests from being treated as new successful payments.
The shorter collection window also reduced the time engineers spent supervising the process. The result connected faster processing with a clearer operational model and better protection for customers.
What I take forward
Reliability is a product concern. I want technical decisions to account for the customer, the team operating the system, and the other departments that depend on its behaviour.