EBANX is a global payment processor, so nothing is more feasible than having a payment page framework to use with different checkout solutions. But that wasn’t the case in the early days of the company.
The early days
In the beginning, we worked only with a redirect solution for checkout pages (it was named Volcanes). Those days, having a basic front-end form for getting customers’ payment information was more than enough.
EBANX has been growing fast and we had to integrate our payment solution with other ecommerce platforms; the first one was Shopify. At that moment, our former payment page wasn’t enough for our needs anymore, and its design was really hard to maintain and improve. So, what did we decide? At glance, we decided to develop a new front-end project to work only with Shopify. Wrong decision!! We should have taken this opportunity to refactor all this stuff.
But the decision of creating a new project is understandable. The former project was not easy to change, and they should deliver this new integration fast. And actually, this second project was much better than the first one. But the biggest problem was, at that moment, we were having to maintain two projects doing the same thing in different ways.
Moment for refactoring
As new requirements were appearing in our business and we’re working to implement them in our payment pages, fastly the two projects started to have different levels of supported features, they started growing in different paths. And most of the time we were duplicating effort implementing the same thing in both places. It started to overwhelm us and decrease the quality of both systems.
After some discussions and some concept proving, we agreed that we couldn’t wait anymore. That was the time to create a more robust and reusable payment page framework/platform for all of our checkout solutions.
We’ll introduce you to Tectonics: our all-in-one solution for checkout pages developed by EBANX.
Our stack and architecture
Stack
Before Tectonics, our basic front-end pages used React/Redux stack. We decided to continue using React but without Redux. Instead, we choose to React Hooks for defining our data handling layer.
Architecture
We designed a pretty simple and powerful structure that splits our system into four main pieces: User data, Controller, Look and Feel, and Features Specification. User data and Controller are responsible for managing general stuff like data storage, validation, normalization, and communication with back-end services. Look and Feel is the part that’s responsible for providing each checkout solution a visual identity, and the Features System is responsible for describing common traits between Look And Feels so that we can avoid duplicating components while keeping Look and Feels flexible for defining their characteristics.
Process during refactoring
The whole journey until reaching this architecture was conducted by trial and error steps. We had tried some approaches to discover the best design that was easy to adapt to new checkout solutions while also being easy to implement without having to duplicate code. And it wasn’t easy at first. We had to eliminate some aspects of the “desired” architecture to increase flexibility and maintainability; The engineering team worked hard together; the first steps had a load of diagrams and throwaway prototypes. However, the achieved architecture was very reasonable and fit well in practically all the requirements we had first.
Migrating from the old structure to the new one
Every day, we have a lot of users accessing our checkout solutions, and this change should have no impact on those users at all, we had to define a strategy to migrate from the old structure to the new one, called Tectonics.
The first part of this strategy was a router (back-end component) to decide if the user should be redirected to Tectonics or the previous checkout solutions. This router used a percentage rate based on an algorithm, the country of the requested payment, and the payment page this user was requesting access. So, we could redirect users to Tectonics progressively and follow its accuracy.
The other part of the strategy was a robust monitoring system. It was responsible for detecting unusual behavior on the users’ activity and notifying us about that. So we could respond fast to errors and avoid impacts. Also, this system was monitoring the number of processed payments in case of the first monitoring fail.
Then, with that strategy supporting us, we were very confident about the migration process. Everything went fine thanks to this effort we had at the beginning of the project, which gave us the confidence we needed to make it work as expected.
The benefit of this refactoring
Currently, we have all of our checkout solutions running on the same project. And as we guessed before, we’re integrating more and more ecommerce systems to the EBANX payments platform. And thanks to Tectonics, it has been much easier than it was before.
Although in the past, we had just one payment page project to work with, we can honestly say that it was harder to maintain. We have proved that a decoupled architecture is always the best thing to do. Even though you’re spending a little more time planning and designing at first, it’s worth it.
After all, we achieved almost 100% of the requirements we had in the beginning, with some little adjustments to improve flexibility. Tectonics has helped us to deliver a more reliable, stable and solid product to our users.
In the next posts, we’re going to dive more into implementation details, and explain how we used React ecosystem to make this project work. For now, thank you all.
Top comments (0)