• Toine van Beusekom, the Strategy Director at Icon Solutions


• 21.03.2025 10:15 am
#Orchestration #BankingTech

In response to rapidly changing payment requirements, more and more banks are migrating from big monoliths to a microservices approach for payments processing. By leveraging reusable functions related to the critical parts of a payments flow, microservices are a way for banks to accelerate the development and deployment of new capabilities. But if monoliths are broken up, who is responsible for ensuring the right steps in a payments process?

We see how microservices by themselves are presenting some new challenges. Throughout my career, I have witnessed many attempts by banks to develop ‘all-knowing and all-encompassing’ microservices-based solutions. However the reality is that for every new payment function added, another microservice is needed to handle it, or a microservice is updated and consequently other microservices need to be made aware of this change to maintain the end-to-end processing flow. This is difficult enough for a ‘happy path’ flow, but it inevitably becomes more complex to manage the contextual awareness when handling exceptions. That is why an orchestrator is needed: to prevent processing business logic from ending up in the microservices.

What is orchestration?

Orchestration is a design pattern that involves a central coordinator managing the interactions and dependencies between different microservices. In the context of payments, a dedicated orchestration microservice acts as ‘controller’ and ‘orchestrates’ the flow of a payment by calling on different microservices to perform specific functions.

To better visualise what this means, I like to use the analogy of a literal orchestra. Just like musicians playing a symphony, a payments ecosystem needs a conductor to provide direction. This is important because it allows the microservices (musicians) to concentrate on what they do best, which is perform their function (or play their instrument).

Orchestration versus choreography

Orchestration is not the only design pattern that can be used. For example, a choreography pattern indicates interactions between different microservices without a central coordinator, meaning that the service needs knowledge about the sequence and context. This may work for a single chord lullaby, but not for Bach.

So, while this can work in specific simple use-cases, ultimately, it constrains a bank’s ability to adapt and improve in a change-heavy environment. Think about new CSMs, new regulation, technology upgrades and new value-added services. All at the same time.

To play a different symphony or add new instruments (to use that analogy again), you need a central co-ordinator (or orchestrator) to provide direction, otherwise it is simply too difficult to co-ordinate, and will take too long to learn and play. While in the meantime the musicians may need to play in different orchestras.

The benefits for A2A payments processing

Having had extensive experience with black box payment engine implementations, as well as cumbersome choreography projects, I have always seen orchestration as the natural pattern for payments processing to overcome the limitations of choreography outlined above.

Orchestration offers significant advantages when it comes to mitigating the risks and costs associated with transforming business-critical payments services. It provides clear observability of the process and state of a payment at any point in time, making it easier to manage and expand functionality. Orchestration also enables high reusability of individual microservices, which reduces the cost and effort of software development.