 |
| Part 3 - Immediate payments |
So far we've presented research-based architectures of omnichannel customer experience, integrating with SaaS applications, and cloud-native development solutions.
In the previous article in this series we explored the common architectural elements found in a payments logical architecture.
In this article we'll walk through an immediate payments physical architecture, laying out what a successful payments solution looks like in practice.
Architecture
As a reminder, the architectural details covered here are base on real customer integration solutions using open source technologies.
The example scenario presented here is a generic common architecture that was uncovered researching customer solutions. It's our intent to provide an architecture with guidance and not deep technical details.
This section covers the visual representations as presented. There are many ways to represent each element in this architecture, but we've chosen icons, text and colors that I hope are going to make it all easy to absorb. Feel free to post comments at the bottom of this post, or contact us directly with your feedback.
Now let's take a look at the details in this architecture and outline the example.
The example scenario presented here is a generic common architecture that was uncovered researching customer solutions. It's our intent to provide an architecture with guidance and not deep technical details.
This section covers the visual representations as presented. There are many ways to represent each element in this architecture, but we've chosen icons, text and colors that I hope are going to make it all easy to absorb. Feel free to post comments at the bottom of this post, or contact us directly with your feedback.
Now let's take a look at the details in this architecture and outline the example.
Immediate payments
The example architecture shown on the right entitled Immediate payments network example outlines how an immediate payments solution is applied to a physical architecture. Note that this diagram is focusing on the highest level of the immediate payments solution and the element groupings that apply to this process.
In this example, starting from the top left corner, a user sends an event or message to execute a payment as an entry point. The users can be mobile, web, or any external device / application that acts as the entry point with the organizations payments architecture.
This request to execute payments connects to your services through the payments API. This is the bridge to the internal central payments event streams, where streams are managed to determine what selection or sub-selection of actions need to be taken. For practical purposes, we'll proceed through this architecture as if all selections are necessary to ensure coverage of all elements and services.
The first action taken is validation of the incoming payments request, using the validation microservices providing integration to all needed systems in an organization to validate funds, customers (users), and more. Once validation is completed a message is sent back to the payments event streams for further processing.
The next two phases of the payments architecture are not always necessary as they depend on validation results. If there are any issues or flags raised on a payment request then the next step would be to trigger the use of the anti-money laundering (AML) microservices or fraud detection microservices. Each of these collections determine if action needs to be taken, if payment requests need to be blocked, if the user needs to be reported, and possibly blocking funds. Both of these service areas are leveraging data caching to ensure current data is available to the decision management tooling used to back these processing phases. Any results are then pushed back to the payments event streams for further processing.
Following the process elements to the right we'll arrive at the clearing microservices where processing for actual payment funds planning where accounts are debited before routing the funds to the requested parties. These results are sent back to the payments event streams for further processing.
Finally, routing microservices are accessed to ensure the funds from the processed payments are distributed to the indicated parties through the available payments network. Note that the payments network is shown as an external secure cloud element, intended to indicate only that it's an external network and dependent on the region the solution is being deployed in for specifics as to the connection and data protocols used.
The second figure on the right here is labeled as an immediate payments data example and is meant to provide more insights into the movement of event streams and flow of data through the above described process of executing on a payments request. Exploring the details of this figure is left to the reader.
In this example, starting from the top left corner, a user sends an event or message to execute a payment as an entry point. The users can be mobile, web, or any external device / application that acts as the entry point with the organizations payments architecture.
This request to execute payments connects to your services through the payments API. This is the bridge to the internal central payments event streams, where streams are managed to determine what selection or sub-selection of actions need to be taken. For practical purposes, we'll proceed through this architecture as if all selections are necessary to ensure coverage of all elements and services.
The first action taken is validation of the incoming payments request, using the validation microservices providing integration to all needed systems in an organization to validate funds, customers (users), and more. Once validation is completed a message is sent back to the payments event streams for further processing.
The next two phases of the payments architecture are not always necessary as they depend on validation results. If there are any issues or flags raised on a payment request then the next step would be to trigger the use of the anti-money laundering (AML) microservices or fraud detection microservices. Each of these collections determine if action needs to be taken, if payment requests need to be blocked, if the user needs to be reported, and possibly blocking funds. Both of these service areas are leveraging data caching to ensure current data is available to the decision management tooling used to back these processing phases. Any results are then pushed back to the payments event streams for further processing.
Following the process elements to the right we'll arrive at the clearing microservices where processing for actual payment funds planning where accounts are debited before routing the funds to the requested parties. These results are sent back to the payments event streams for further processing.
Finally, routing microservices are accessed to ensure the funds from the processed payments are distributed to the indicated parties through the available payments network. Note that the payments network is shown as an external secure cloud element, intended to indicate only that it's an external network and dependent on the region the solution is being deployed in for specifics as to the connection and data protocols used.
The second figure on the right here is labeled as an immediate payments data example and is meant to provide more insights into the movement of event streams and flow of data through the above described process of executing on a payments request. Exploring the details of this figure is left to the reader.
Project examples
Sharing the process results for our payments architecture is what this series is about, but there are project artifacts and diagrams that can also be shared with you the reader. We've pulled together an examples repository for all our architecture diagrams.
 |
| Figure 1 - Physical diagrams in example repository. |
For example, if you scroll down to the file listings on the main page, you can locate all the example physical diagrams as shown in figure 1.
This is the collection associated with payments:
This is the collection associated with payments:
- in this case there are multiple images 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.
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:
Next in this series, taking a look at the generic anti-money laundering example in a cloud-native architecture focused on payment processing.
(Article co-authored by Ramon Villarreal)
- An introduction
- Common architecture elements
- Immediate payments example
- Anti-money laundering example
- Fraud detection example
- Financial calculations example
Next in this series, taking a look at the generic anti-money laundering example in a cloud-native architecture focused on payment processing.
(Article co-authored by Ramon Villarreal)