Payments Architecture - Common Architecture Elements

Cloud technology is changing the way payment services are architected. In this series we will be presenting insight from our customers on adopting open source and cloud technology to modernize their payment service.

So far we've presented research-based architectures of omnichannel customer experience, integrating with SaaS applications, and cloud-native development solutions.

In part one of this series we introduced the concept of an architecture and shared the planning for this series to cover the logical, physical, and details of the solution. In this article we'll explore the logical diagram that captures the elements of a successful payments solution.

From specific to generic

Before diving in to the common elements, it might be nice to understand that this is not a catch all for every possible payments solution. It's a collection of identified elements uncovered in multiple, from two to three, customer implementations. These elements presented here are then the generic common architectural elements identified and collected into the generic architecture.

It's our intent to provide guidance and not deep technical details. You're smart enough to figure out wiring integration points in your own architecture. You're capable of slotting in the technologies and components you've committed to in the past where applicable.

It's our goal to describe the architectural generic components and outline a few specific cases with visual diagrams so that you're able to make the right decisions from the start of your integration projects.

Feel free to post comments at the bottom of this post, or contact me directly with your feedback.

Now let's take a quick tour of the generic architecture and outline the common elements uncovered in my research. The first diagram you'll meet in this series provides a logical view of the solution elements. These elements are grouped for easier understanding and we'll cover each one.

External applications

Starting at the top left of this diagram, there are two elements that represent external applications that interact with the architecture. Distilling the various applications discovered in customer solution research, we've come up with two common representations.

The first is mobile applications, covering basically everything that customers use to interact directly with a company. This can be mobile applications deployed by the company themselves or developed by third party organizations to interact with the services offered.

The second is web applications, a broad element to contain all other types of applications, web sites and/or services that are deployed by the company or any third party organizations to interact with the services offered.

Container platform

Without a doubt, organizations engaged in modernizing their payments offerings have seen the value of containers and container platforms. The container platform provides for one consistent environment for developers and operations to manage services, applications, integration points, process integration, and security.

It's also the one way to ensure you can uniformly leverage the same container infrastructure across any cloud environment. It avoids becoming locked into any private or cloud platform as you have an exit strategy with a container platform that's consistent across your architecture.

The security aspect is interwoven in the container platform, as each container service, application, or process integration can be plugged in to an organization's authentication and authorization mechanisms.

Within this view of the container platform there are elements grouping general microservices (validation, integration, integration data, and caching) that offer integration with an organization's often existing service offerings. 

For payments processing you'll notice that there are more specific elements associated with microservices dedicated to payments activities (clearing, fraud detection, anti-money laundering (AML), and payment exception management). These tend to be part of the financial industry requirements and can be specific to the region of operation. 

Finally, there are elements that are prolific across the landscape of microservices, such as API management and single-sign-on (SSO) technologies used by one and all.

Infrastructure services

While the infrastructure services might not be where you would expect to find event streaming elements for payments solutions, we've found that putting that extra emphasis on it was necessary.

This element is core to the solutions researched and found to be the design mechanism most often mentioned, that of Event Driven Architecture (EDA). Data streams are the backbone of processing payments and were used extensively to manage a customer's payment request from validation, fraud & AML checks, clearing, to finally routing the payment request. More on this in later articles in this series, but the foundation is clearly on managing the flow of data through events and messaging.

External systems

These elements capture the existence of regional or local needs for using clearing, compliance, reconciliation, payment networks, and other financial systems. They are not always under control of the organization or if they are, can often be externalized behind API access or private cloud access points. 

It's important to understand that some of the solutions for payments involve accessing systems that are not in the control of the payment solution organization and require architectural attention to ensure robust and clean interactions.

Hybrid cloud infrastructure

This element is the infrastructure layer that indicates the possibility of this solution riding on everything from a private data center, a private cloud, a public cloud, or a combined multicloud infrastructure. Note that it can be a single solution for deployment or any combination of private or public cloud deployments.

Storage services

The storage services uncovered in customer solution research were diverse and numerous. For that reason there is no single common architectural element shown at the highest level. Everything from container native storage to traditional block storage can be found in successful solutions.

This completes our overview of the common generic elements that make up our architecture for payments.

Project examples

Sharing the process results for our payments architecture is what this series is about, but there are project artefacts and diagrams that can also be shared with you the reader. We've pulled together an examples repository for all our architectural diagrams. 

The Portfolio Architecture Examples repository makes it possible to collect and share individual images from each diagram element as well as the entire project as a whole.

For example, if you scroll down to the file listings on the main page, you can locate a logical diagram as shown in figure on the right.    This is the collection for the logical diagrams associated with payments:

• in this case it's a single image you can click to view
• a project file you can download to your local machine using the Download Diagram link
• a Load Diagram link that you can click to automatically open the project diagrams in the diagram tooling used in this architecture (use private or incognito browser mode to avoid caching issues and a smoother tooling experience)

Give it a try and feel free to explore the collection of logical, schematic, detailed, solution, and community diagrams. This should allow you to get started much quicker than from scratch if you can kick-start a project with existing diagrams.

Should you desire to start designing your own diagrams, please contribute the project file (ending in .drawio) by raising an issue with the file attached. We'd love to continue collecting these projects for others to use.

Finally, there is a free online beginners guide workshop available focused on using the diagram tooling, please explore to learn tips and tricks from the experts.

What's next

An overview of the series on the payments portfolio architecture can be found here:

1. An introduction
2. Common architecture elements
3. Immediate payments example
4. Anti-money laundering example
5. Fraud detection example

Catch up on any articles you missed by following one of the links above.

Next in this series, taking a look at the generic immediate payments example associated with cloud-native architecture focused on payment processing.