Payments Architecture - Financial Calculations Example
Generic payment calculations example blueprint shown on the right entitled Financial calculations example outlines the solution in a physical architecture...
Join the DZone community and get the full member experience.Join For Free
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 architectural blueprints of omnichannel customer experience, integrating with SaaS applications, and cloud-native development solutions.
In the previous article in this series we walked through the fraud detection physical architecture.
In this article we're diving into the fraud detection physical architecture, one based on successful customer solutions.
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.
Generic payment calculations
The example blueprint shown on the right entitled Financial calculations example outlines the solution in a physical architecture. Note that this diagram is focusing on the highest level of the solution and the element groupings that apply to this process.
All previously discussed physical architectures were related to the original immediate payments architecture overview, but this one is a more generic payments case. It's possible to imagine this financial calculations architecture applying to many domains where determining discounts, taxes, fees, and special offers might be part of the payment process.
In this example, starting from the top left corner, a payment request always arrives from a fronting API element. as an entry point. The payment request starts off as a message and this is a more traditional integration architecture than one using message streams that we've been discussing previously.
The initial request arrives in the message queues where it's picked up and validated through the validation microservices. The validation requires the use of data and it shown receiving input from a reference data element that fronts all of the backing data stores.
Depending on the solution domain, these data stores can be anything from customer data, taxation information, compliance data, or other needed data sources. For this example the data stores backing payment calculations are customer, contact, tariff, and discount information.
After validation a message is sent back to the message queues.
A generic detail calculations microservices element encompasses the various stages that calculations might need to be performed on the payment request. For example, it can arrive here more than once as the payment calculations are made to apply tariffs and then discounts.
As the payment calculation is pulled together, there will be times when data or message aggregation is needed to modify for a specific calculation or backend system access. For this purpose you find the aggregation microservices which, upon final completion of all calculations and aggregations, passes the payment request on to the integration microservices.
These integration microservices ensure that the billing systems are accessible for the final processed payment request. It's shown here as a possible private cloud element as that's ensuring that integration will be effective even if the billing systems change over time or move to other architectures outside the organizations control.
This completes the tour of this financial calculations architecture.
Sharing the process results for our payments blueprint 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 blueprint 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 all the example physical diagrams as shown on the right.
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 blueprint (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.
Published at DZone with permission of Eric D. Schabell, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.