Eric D. Schabell: Payments architecture - Financial calculations example

Thursday, October 15, 2020

Payments architecture - Financial calculations example

financial calculations
Part 6 - Financial calculations
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 experienceintegrating with SaaS applications, and cloud-native development solutions.

In the previous article in this series we covered our fraud detection physical architecture.

In this article we're exploring the final physical architecture in this architecture,  a generic financial calculations example, one based on successful customer solutions.

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 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.

Generic payment calculations

The example 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.

financial calculations
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.

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. 

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.
financial calculations

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
  • 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
  6. Financial calculations example
    Catch up on any articles you missed by following one of the links above.

    This completes our series that has laid out a cloud-native architecture focusing on payment processing with suggestions for leveraging open technologies.

    (Article co-authored by Ramon Villarreal)