The example blueprint shown on the right entitled Immediate payments network example outlines how an immediate payments solution is applied to a physical architecture.
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.
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.
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 blueprint that was uncovered researching customer solutions. It's our intent to provide a blueprint that provides guidance and not deep technical details.
This section covers the visual representations as presented. There are many ways to represent each element in this architectural blueprint, 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 blueprint and outline the example.
The example blueprint 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 p_ayments 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.
Funny enough, in all my years of writing, speaking, and recording video content on all matter of topics from baseball to technology... . I've never been on a single podcast. That all changed last week when I got the chance to join David Rubinstein, editor in chief of SD Times, for a quick chat on his podcast called What the Dev?
In this article we're diving into the fraud detection physical architecture, one based on successful customer solutions.
Cloud technology is changing the way payment services architectured. In this series we will be presenting insight from our customers on adopting...
In part one of this series we introduced the concept of an architecture blueprint 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.
Companies need to be thinking long-term before even starting a software development project. These needs are solved at the level of architecture: business owners want to assure agility, scalability, and performance.