Microservices for an online payment platform

Payment platforms

Payment platforms are dime-a-dozen these days, but that wasn't the case 10 years ago, when we started this project. Microservices as a concept hadn't taken off and payment platforms weren't everywhere, although payments on consumer phones are still a problem. So we set out to build a White-Label solution for merchants to use us for their payment needs. I am not going to name the company here (memories of shutting it down, still haunt me).

Anyway, thinking about what we needed to accomplish, I broke the problems/needs down into its integral parts as I saw it then.

  • We need to be able to secure Consumer Payment instruments at all times.

  • We need to be able to execute transactions through multiple gateways. Authorize.net, Chase etc.

  • We need to be able to serve up contents to multiple device form factors.

  • We need to be able to impersonate a Merchant to manage their products, price etc, incase there is a problem.

  • We need to be able to have high-availability (version 1 of the product had data contention and build deployment downtime issues).

  • We need to be able to scale up, to certain extent.

  • Boss needs it to be a Microsoft centric solution (my background was in MS based solutions as well)

  • MS has no other database solutions to fit other than SQL Server, so that was easy, phew!

  • For the web application, MVC was a good option, it had proven itself around that time, and Web Forms had started to show its age.

  • I tried a POC with the Microsoft ORM product (Entity Framework), but it doesn't yet (2016) know how to handle multiple database servers or multiple databases. I really wanted multiple databases in my solution, because PCI data and Non-PCI data shouldn't be in the same database IMHO, ever. So we had resolved to build one.

  • I hadn't yet heard of the Microservices concept yet, but I had planned to use WCF windows services to supply data and logic for the Web Application, I had called it the UNIX model. 1 application to do 1 thing and 1 thing well. Another reason for using separate services was that, I wanted other applications to be able communicate with our platform as well (e.g: IOS, Android apps)

  • I wanted to use AWS but the public facing AWS platform wasn't PCI certified at the time, or there was a different reason for it. So we were going to use something like RackSpace/Softlayer.

So the architecture I had in my mind, was something like the below diagram:
architecture diagram without specifics

The specifics hadn't been filled in yet. For example, I didn't quite figure out how to load-balance the calls to the services yet. Or what the services were going to be, or what the delineation between the internal services were going to be. That came later thanks to many discussions and ideas from our operations Director RyCo.

architecture after RyCo's help

So at this point, we know what technology to use, we know how to make it highly-available for deployment and other purposes. We knew roughly how to delineate the features. What we didn't know were how to secure the system, how to make the databases load-balance, how to deploy this platform with zero manual work, how to create a development environment that worked on a local machine, how to create configuration for all these services and applications, what to use for our code repository and so on and so forth. But what we knew at the time was we had enough people in the team to have an honest shot at making a highly-available, somewhat scaleable, Microsoft technology based, online payment platform which catered to every Device form-factor.

I will detail the role & architecture of some of the services in greater detail in later posts.