The history of Tectonics: a front-end payment page framework

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.

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.

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

Software engineer.