Modernise the Payment Platform With Event-Based Architecture

When the CODIV-19 pandemic started nearly 2 years ago, many were not prepared and suffered a great pain to maintain normal life, including the businesses. Eventually the disruption pushed the industries to accelerate the innovation to ensure they can continue to run their businesses and to support their customers. 

This is no different for the payment industry. Among others, the payment industry is one the most needing rapid innovation and change to stay ahead of competitions. Many businesses that turned to online platforms require a reliable and flexible payment system to help them to continue to support their existing customers and to reach a wider customer base. 

Accenture forecasts nearly 2.7 trillion transactions worth US$48 trillion will shift from cash to cards and digital payments in the next decade. From the survey, 7 out of 10 executives agree that transforming the payments industry is a core pillar of their larger digital program. 

Figure 1: Accenture executives survey about payments modernization programs.

These statistics imply that the revolution of the payment industry is not over yet. Banking and finance players, the typical payment services providers, not only need to answer to the industry business needs, but also need to be able to support the exponential growth of the payment transactions contributed by the growing online businesses.

Industry players that do not innovate fast enough will stay behind others and suffer the loss of business compared to others who are few steps ahead. Companies need to embrace the new business models the disruptive change opens up. Kodak story is a very good mirror that these industry players can learn from. Kodak, a more than 100 years old company, which was founded in 1889 went from a $10 billion sales in 1981 to filing a bankruptcy in 2012 in just 30 years because it failed to see the era of digital cameras was coming.

Event-Based Payment Architecture

In order to pick up the pace to meet the rapid changing of the payment industry, the industry players need a new approach for their payment platform. They need a scalable and agile platform for their payment systems. One that can support large transaction loads and be able to adapt quickly to the industry changes, to be able to innovate and change together with the customers.

This modernized architecture that we are referencing in this post is the event-based architecture as per illustrated in Diagram 1. 

In this post, we are going to briefly look at what is the event-based payment architecture. We will have more upcoming series of posts in the future to cover this topic in depth.

Diagram 1: Event-Based Payment Architecture

What is event-based payment architecture?

It centers around treating the payment transactions as event occurrences where multiple participating systems or services react to these events to perform their necessary processing in order to fulfill the payment transactions. Each of these services is decoupled and independent while still being able to work together to support the payment system as a whole.

Along the modernization process, the systems or applications in this payment ecosystem need to be amended in order to support this new initiative. The ideal situation is to maintain the changes as minimal as possible but sometimes to support this initiative is inevitable if the current systems are too old to be adapted into this new platform. 

Let’s look into what are the options available for payment platform modernization in the next section.

Payment Platform Modernization

Payment platform modernization is no different from other application modernization exercises. There is a systematic approach to do this. The following provides a quick overview of the application modernization approaches available. The decision to decide which modernization option could be different for each of the applications depending on the maturity and gaps. 

Application assessment and gap analysis is required to help us to determine this. If you are interested to go into more detail, I had it covered in this post “This is how you can modernise your applications

Diagram 2: Application modernization options

Certainly there is no single formula for which is the best option to start with. Decisions need to be made based on the timeline and effort required to enable the business to continue to innovate and at the same time to be able support the immediate needs. This is always the collective decision within the organization itself. However they would not run much from the summary as illustrated in Diagram 3. 

Diagram 3: Payment platform modernization options and approaches.

Based on my past experiences in dealing with banking customers, they typically would like to revamp the entire payment platform but would like to introduce minimum changes to supporting systems such as the core banking and credit card systems. 

For example, when we are looking into refactoring the existing payment applications and supporting systems, customers would like to maintain the current core banking system and to minimize the load at the same time. This approach is looking at making the core banking as the system of record, and move the processing logic into a modern architecture. This is where the pseudocore modernization comes into the picture.

In situations where the applications cannot be replaced or refactored, we can consider the life-and-shift option. Most of the time by going down this path, we need to introduce supplemental services such as the integration services to ensure that the existing applications can work together with the modernized applications.

In addition, workflow services and decision services always play a key role in payment modernization for both modernization categories (Refactor/New and Retain/Replatform/Rehost) illustrated in Diagram 3. The low-code approach provided by the workflow and decision services help to accelerate the business requirement realization and also fill the gaps between modernized application and traditional applications. For example, decision service introduces a GUI based credit check decision table service that is easier to maintain, and at the same time it can also consolidate the result from the existing AML check, resulting in a simplified single service interface to multiple payment validations. 

At the same time, while customers consciously acknowledge the importance of event-based architecture and how event streaming plays a key role in modernizing the payment platform, we are aware that it is more than just event-based architecture. Most of the time we need to take into consideration the supplemental services such as data services and integration services that are required to enable the new platform to be able to work well with the existing systems.


In this post, we cover some of the considerations to take note when modernizing the payment platform based on the event-based architecture. Payment platform modernization is a journey and there will always be new business functions added over time. This journey will be less painful when you have done it right at the beginning and I hope this post provides you an insight of how to get this journey started. 

Please subscribe to my Twitter and Blog site for the upcoming series posts for the related topics.

One thought on “Modernise the Payment Platform With Event-Based Architecture

  1. Pingback: Event-Driven Payment Exceptions Handling Using Kogito – brainDOSE

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s