Photo by Devon Janse van Rensburg on Unsplash
Payments by Wix is not just a name for the platform within Wix.com that powers millions of businesses worldwide, including businesses on our Premium Plan. It’s also the name for the internal team of engineers, building and operating the Wix payments platform on a daily basis.
Our platform allows merchants to connect payment methods to their sites, accept payments online and offline, manage their payments and receive payouts directly to their bank accounts. Our users can either use third-party payment processors, or let Wix manage the complete financial process (as in checkout, processing, deposits, refunds. etc.) by using our homegrown Payment Service Provider that is Wix Payments. We operate in 200 countries, support 155 currencies, 60 payment methods and process billions of dollars.
Challenges financial systems face
Financial systems are not like any other online service. They have high legal, security and operational requirements and thus building such systems is challenging. We define at least three key requirements for our Payment Platform, which we keep in mind as we work:
Traceability
Extensibility
Quality
We gained a lot of experience building financial systems at Wix and would like to share our solutions and approaches that help us meet these requirements.
Traceability
Why traceability is so important
There are several stereotypes surrounding the development of payment systems. For example, one may say it’s a slow process that is plagued by bureaucracy and one where price of error can be measured in millions of dollars. We beg to differ, as we were able to build our system in a way that allows us to keep our dev velocity high on one hand, and provide transparency and traceability on the other.
Errors and anomalies happen in all systems that are big enough, of course, and errors in payment systems are even more critical. Which is why traceability is a must have property for any payment system.
We are achieving traceability in Payments By Wix by utilising an array of different tools and techniques, including, in particular, things like audit logs, event sourcing, and logging. Let’s look at each of them more closely.
Audit logs
Pretty much any modern payment system has a lot of critical integrations with 3rd party services and providers. And thus there might be cases when integration protocols break, for one reason or another. To detect, investigate and react to cases like that we use audit logs. In essence, these logs are a dedicated database set up to store requests to 3rd parties, responses from 3rd parties, and entity ids associated with such interactions.
We developed a thin wrapper with a nice API to encapsulate DB interaction and mask all personally identifiable information inside request and response objects. We use this tool in write-like flows and in flows that change the state of the system (like create transaction, refund transaction, etc.). As a result we have a mechanism that allows us to quickly find error-causing things within the boundary between our system and the outside world.
Event Sourcing
Payment system entities like transactions, accounts or payouts have pretty complex life cycles that tend to change due to new requirements or conditions. To guarantee high development velocity and to have a clear vision of the system we’re utilizing a methodology known as Event Sourcing (https://martinfowler.com/eaaDev/EventSourcing.html). In event sourced systems we don’t store particular states of specific entities, rather we store a set of events that lead to a particular state instead. For example, in case of a successful transaction, three records will be made in the database:
Event 1 Transaction created
Event 2 Transaction pending
Event 3 Transaction successful
Every event has a sequence number in the entity scope and a timestamp of when it was created. As a result we can reproduce the state of the system at any given point in time - using this we can clearly see what the reason for any action was.
Logging
The third tool in your Traceability toolbelt is logging. And yes, we’re talking about good old-fashioned straightforward logging - with levels, context, etc. This tool has a number of limitations due to retention policy and reliability, so it is better suited for collecting non-critical information about control-flow. Which is useful during opening or debugging new features.
Those are the three pillars of Traceability you should really consider when payment systems are concerned. Yet, that’s just part of a functioning architecture. Let’s now look at another crucial part of any payment processor - it’s security setup.
Extensibility
In the olden days of Payments by Wix, we had to integrate payment providers ourselves - on the WIX side and manually. Needless to say that required a lot of human resources and a lot of code changes to maintain a single codebase. And then we would also need to support each implementation in terms of bug fixes, behaviour alignment, and any API updates involved in the migration processes. All of that eventually started to really slow down the evolution of the whole system. The more WIX grew, the longer the backlog of companies wishing to integrate with Wix Payments grew, too.
An approach like that was not very scalable. Solution? Move the implementation of any new payment processors to the third party. Now if a company wants to become a payment provider / processor with Wix, we can point them to internal resources and a developer-friendly system to do just that. The Platform, as we call it, comprises the Wix DevCenter, and client-facing API and SPI. There’s also a certain legal process associated with becoming a payments processor with Wix, but that’s not the subject of this article.
This allowed us to not only ease the load on our developers, but also to significantly speed up our ability to expand to other countries and regions and to bring local providers closer to merchants.
Our Platform is a rather comprehensive solution, so let’s have a closer look at the elements it comprises:
SPI - an API that needs to be implemented by payment providers. Important for both PCI- and non-PCI providers. We tried to make SPI as flexible as possible - it currently supports both synchronous and asynchronous flows.
API - it allows providers to access WIX Payments on their own and use it to provide information about current state of payments.
Dev center - an internal developer-oriented portal which allows providers to configure triggers for creating payment, refunds, and other events; it can also be used to onboard merchants. The dev center can also help providers set up everything that’s required to validate incoming requests from WIX as well as sign requests going our way.
The results of adopting this approach speak for themselves. As of writing this, we have already expanded to dozens of countries and regions and currently have multiple providers in active development, which we’re planning to roll out to all Wix users in the nearest future.
Quality
You might have noticed that there’s a lot of moving parts in the whole system setup. And naturally you might have a lot of questions about the quality of the system and how on Earth we make sure the product works properly altogether. Let’s work through several factors that, we believe, play an important role here.
The team
The team behind the project is a cohort of great professionals. Every team member inside our company (i.e. the Payments team) is passionate about our product and their work. It is very important to have the right team to be able to build and to support such a complicated system.
The whole Payments by Wix team is separated by domains and have their own micro-services.
Every feature team has their own set of expertise, including QA. This helps us make sure each part of the system behaves correctly and not overload our engineers with knowledge and information from a different product domain.
Releases
You might think we release once or twice a year, since that seems to be the most common scenario, but we actually have TDD and CI/CD development philosophy which helps us release weekly or even daliy to production. By the way, we’re also testing in production - with the help of an A/B Testing System developed at WIX.
Without proper automation coverage in place, it would not have been possible to release new versions of the product so rapidly without compromising on quality. In addition to that, manual regression cycles would’ve taken ages to perform, and then we would probably end up with an undesired result.
“Automate what could be automated” is our rule of thumb. Since the product and feature teams differ, we apply different types of automation accordingly.
Automation tools
The API Testing Framework was developed inside WIX and helps us have test coverage for main API endpoints end-to-end. And as we know, the API tests are easy to develop, support and execute. We were able to cover most of the API testing scenarios here, including a combination of API & UI for wallet-like provider integration. It takes us as little as two minutes to health check fifty provider integrations.
Conclusion
Millions of our customers rely on our systems daily to run their businesses. The solutions and approaches we listed in this article help us to continuously deliver new features and meet all the strict industry requirements. We are trying to keep the balance between the pace of development and reliability while providing our users with the best possible experience.
This post was written by Kyrylo Ponamariov, Yaroslav Hryniuk, Oleg Tarapata, Oleksandr Samsonov, Dmytro Lukianchuk
For more engineering updates and insights:
Join our Telegram channel
Visit us on GitHub
Subscribe to our YouTube channel