Payments Architecture - An Introduction

Cloud technology is changing the way payment services are architectured. 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.

What's in an architecture and how are customers applying these solutions you ask? It's an interesting challenge in that we've been creating architectural content based on common customer adoption patterns. That's very different from most of the traditional marketing activities usually associated with generating content for the sole purpose of positioning products for solutions. When you're basing the content on actual execution in solution delivery, you're cutting out the marketing chuff.

These portfolio architectures are providing you with a way to create a cloud native payment architecture focusing on the interactions, messaging, processing, and integrations proven to work. What's not included are any vendor stories that you'll find in normal marketing content. Those stories that when it gets down to implementation crunch time, might not fully deliver on their promises.

Let's look at the payments architecture and explore its value in helping your solution designs.

The process

The first step is to define what we are focusing on when talking about payments development. We've developed the following statement to guide our architecture:

Financial institutions enabling customers with fast, easy to use, and safe payment services available anytime, anywhere... 

This is the principle guiding our research into how organizations are looking at providing their customers with robust payment experiences.

The approach is researching several existing customers with implemented solutions in this space, collecting their content, researching the internal implementation documentation, and where necessary reaching out to the field resources involved.

The generic architecture is the final results and presents the reader with a higher level look at the elements used and their positioning in successful solutions. The idea of the generality of this architecture is that you can determine the links to your own organization when applying the layout to your own existing architectural choices. It's going to be a descriptive journey and not a prescriptive narrative as you might find in very specific reference architectures where component versions are tightly coupled in the solution.

We'll start by touring a logical diagram, providing an overview of the elements and groupings involved in the solution space. You'll find a diverse collection of open technologies in these architectures such as a container platform, process automation, decision management, runtimes, data grids, AI/ML, API management, security, storage and so much more.

This follows on with specific schematic diagrams (physical) exploring use cases and example solutions architectures. While generic in nature, they should guide you in mapping these solutions to your existing architectures. Some of the diagramming examples focus on networked connections and others provide examples focused on data flows. Finally, a detailed diagrams are presented for use in diving deeper into individual elements or groupings from the example use cases.

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:

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 workshopavailable focused on using the diagram tooling, please explore to learn tips and tricks from the experts.

What's next