Problem: Build a flexible payment gateway connector
Solution: Use the adapter pattern and microservices (a.k.a. Invocable Methods)
About a year ago I was deep in a project of integrating a payment gateway with B2B Commerce LE and Salesforce Order Management.
The payment gateway has uncountable options and functions. We got tasked to build a connector that can be used by every merchant (customer) as they see fit for their business.
First, we analyzed the payment gateway’s API extensively, all its functionality and options. The outcome of the analysis was: It’s complex, with so many variants for each functionality.
We were paralyzed, how should we ever cover all the thousands of permutations? The code will become nothing else than a tangled mess.
At some point, we went back to our business process map and realized: From a business point of view it’s only a handful of elements, each with a set of inputs and outputs.
That sounds a lot like invocable methods.
Once we had the first POC using Invocables it was clear: Invocable Methods are the way to go.
We combined the concept of Invocable Methods with the adapter pattern and we had a clear path forward.
From now we could work in two ways simultaneously:
Top-down defining and coding all Invocable Methods with their expected behavior based on certain inputs.
Bottom-up writing the connector to the payment gateway. In between, we had an “adapter layer” that translated between the business (aka. Invocables) and the bank (aka API).
That’s where all the analysis came in handy, it became a simple game of mapping left to right.
A few rounds of refactoring later, we had a clean, flexible, well-documented payment gateway app that passed the security review on the first try.
Summary: Use the learning of the elders before us, they’ve done the same already countless times.