When you work in the payments space, merchants (and the platforms that serve them) depend on your technology to be solid and reliable at all times. Their businesses literally depend on it. Everything from onboarding to chargebacks needs to be built with quality in mind. 

This is something the product and engineering teams at Finix take as highest priority when designing and building products. In order to maintain the highest quality we have built a rigorous testing environment. This testing environment results in highly reliable APIs, efficient merchant underwriting, quick fraud detection, and reliable settlement payouts.

Testing is nothing new to anyone building software, but the processes we focus on testing have a different focus than most payments processing platforms. For example, the payment lifecycle looks a little different than it would for a company that focuses on the issuing/consumer side, so the processes we test also look different. Below are some additional thoughts about why we conduct the tests we do. 

The Issuing Side (the Buyer)

Generally, when a payment lifecycle is referenced, people are talking about it from the buyer’s point of view, focused mostly on the issuing side of the payments layer cake. The steps in the lifecycle look something like this:

1. The cardholder enters their card details to make a purchase

2. This cardholder information is transferred to the merchant’s acquirer via a payment gateway

3. The acquirer sends the information to the relevant card network

4. The network passes the information onto the issuer 

5. The issuer confirms that the card is authentic and releases the funds, or denies the transaction if necessary

6. This information is transmitted back to the card network which then passes the response to the acquirer

7. The acquirer sends the message to the merchant

8. The merchant confirms that the payment has been received

The Acquiring Side (the Merchant)

From the payment processors point of view, the lifecycle looks a little different. We are focussed on the merchant, not the consumer. On the acquiring side, not the issuing side. Our merchant lifecycle looks something like this:

1. Create an identity for a merchant

2. Tokenize a bank account for funding the merchant

3. Provision the merchant account

4. Create an identity for a buyer

5. Tokenize the buyer’s card

6. Create a sale

As a payments provider that serves merchant accounts, we’re not only responsible for building a sound merchant-facing API - we’re also responsible for back-office operations like fraud detection, underwriting and settlements. The more stable these processes are, the better the experience for platforms, their merchants, and the customers of those merchants. 

The Testing Engineering Team at Finix regularly tests to make sure all of these processes are sound. We classify the tests into the following categories:

1. Tests to ensure our APIs work correctly. This includes tests such as:

   • Ensuring data sent by merchants is validated 

   • Ensuring that the right error handling is being performed

   • Ensuring that the API calls perform the right operations on the backend

2. Tests to ensure that our user interface is both correct and spiffy. This includes tests such as: 

   • Ensuring that our UI displays the right data

   • Ensuring that responses to user interaction are spiffy and that we do not waste our user’s time

3. Tests to ensure that our back-office operations are sound and performant. This includes tests that:

   • Ensure all settlement and chargeback reports are ingested without interruption and in a timely manner.  

   • Ensure that settlements with fees are generated correctly given all the business rules

   • Ensure that disputed transactions are handled correctly  

   • All the above are performed within the specified time constraints

4. Tests to ensure all compliance requirements are met. This includes tests for: 

   • PCI DSS compliance

   • SOC 2 compliance

Imagine for a second that you’re a merchant that has geared up for a big sale event or launch of a new product. You spend considerable resources to drive traffic to your platform only to find that the increased traffic and usage is met with failing payments processing infrastructure. It isn’t something we like to imagine, and that’s why we put processes in place to make sure it doesn’t happen.

In order to maintain stability and performance during peak periods (think Black Friday), we conduct regular load and performance tests to identify potential bottlenecks and less-than-performant subsystems. We never, ever want to encounter these issues in a live environment, so this testing is very important to us, and the platforms and merchants we serve.

There may also be situations where we come up against failures of external systems. While repairing these external system failures is not our responsibility, we need to make sure that our system handles these failures gracefully.

In order to handle the graceful degradation of service, we test for various failure scenarios of external systems by utilizing mock servers that simulate the external system but where we are able to control the scenarios.

The Finix team knows that the reliability of our platform is mission critical. Without the stability that results from rigorous testing we could face platforms and merchants missing out on millions of dollars in transactions in a matter of minutes. That’s why quality is at the center of everything we build.

Building payments infrastructure is not for the faint of heart, but it’s a challenge that we face head-on every day. It’s part of our mission to create the most accessible financial ecosystem in history.