High-Load Online Payment System
High-Load Online Payment System
Information
Region:
Europe
Industry:
Financial Services and Banking
Type:
Web
Engagement model:
Time and materials
Duration:
3.5 years
Staff:
A lead developer, two mid-level full-stack developers, a QA automation engineer, a junior Android developer, a junior iOS developer
Technologies used
Nest.js
AWS
Node.js
React.js
Java Script
React Native
DynamoDB
TypeScript

Client

A major European car manufacturer used Elinext to develop a B2B online payment system.

Challenge

The company used another developer to build a custom end-to-end payment application that would allow businesses to sell to customers online. For customers, it would be the same as paying via a card terminal in a store — but on the Internet. The application needed to process payment details safely and securely.

The first version of the application lagged a lot and was difficult to use. The company decided to replace the developer team. They wanted a partner who could clear up the application’s architecture, make it more stable, and add new features. Someone in the company had already worked with Elinext and knew we had experience with building online payment software. So, we were referred to as a potential partner. We showed our expertise through several related case studies, and the company was convinced we knew what to do and we could execute as much.

Process

Our collaboration with the client was organized using the outstaffing model. This means we provided a team, and our team worked as a remote part of the client’s organization.

We aligned the process with Agile methodology, using Jira to set up a workflow across four development environments with automatic deployments. The work was broken down into five one-week sprints, each of which was built around a particular phase: investigation, implementation, testing, bug fixing and delivery.

In large part, the client planned the sprints on their own, consulting our lead developer. And the lead developer was instrumental to monitoring the progress through daily meetings, one with his team and one with the client.

In addition to sprints, the entire project included four stages: refactoring, adding new features, developing version 2.0 and improving that version. And the most crucial of them was refactoring.

Cleaning

The original application we had to work with required quite a few improvements, especially its architecture: we had to rewrite it.

We tackled the challenge by using domain-driven design (DDD). This approach allowed us to align the new architecture with the business’ needs and specifics. And the architecture we built as a result proved itself much cleaner, more stable and more load-resilient than the original. Six months from when we hopped on the project, the client had a clean, early version of the application. It included modules and entities that they and prospective businesses using the application could finally comprehend and work with. And no security risks or codebase issues were preventing further development.

Taking It to the Next Level

Once the application had a clean and efficient architecture, the client green-lighted further improvements. Over the following six months, we added new features and completed the first version of the application as it had been conceived. And we didn’t stop there.

It took us one year to build the second version and a year-and-a-half to expand the application, enriching it with further features.

Testing

Throughout the development, we checked the software using various tests. But end-to-end (E2E) tests played the most important part by allowing us to monitor how new features performed. In the process, we applied a variety of tools to analyze the application and make sure features were delivered in a continuous, timely manner.

Product

Businesses can use the application to take payments online. Once it has been integrated with a company’s website or mobile app, our client will provide that company with a merchant account and a payment gateway. These will connect the customer’s bank or payment processor with that of the company.

We enabled related data storage in DynamoDB, making it compliant with GDPR.

The Widget

A company can integrate the application with their website or mobile app by installing a widget.

The widget supports payments in ten currencies, transferred via commonly used cards (e.g. Mastercard, Visa, Paypal) and custom solutions (e.g. Klarna, SEPA). We also enabled automated recurring payments. The system complies with Payment Card Industry (PCI) standards while not being required to follow the PCI Data Security Standard (DSS).

What the widget looks like will depend on the company using it — you can easily customize its appearance. And it’s friendly to users speaking different languages. We set up a localization mechanism that automatically detects the user’s language, and presents the interface in one of ten languages available.

We used Native.js with its event system to be managed by an internal state manager (e.g. Redux). This helped prevent potential integration conflicts.

The Back End

We used Amazon Web Services (AWS) to build the back-end application in the cloud so it can process more than two million requests daily.

To streamline transactions, we used a set of technologies. Elastic Load Balancer automatically balances high loads, while Serverless Workflow Orchestrations is responsible for processing transactional mechanisms.

Now, if a transaction fails, the payment value will automatically send funds back to the payment card or wallet. Failure reasons may include wrong request handling by third parties, lack of funds in case of automated recurring payments and others. We also applied lambdas for handling scheduled jobs and all possible events.

Admin Portal

To build the admin portal, we used React.js accompanied by Redux as a state manager and AWS Cognito as an authentication tool. The portal generates access tokens required for integrating the application with a company’s site or mobile app.

Portal users can be assigned one of the three roles: Operator, Super Admin and Merchant.

A Super Admin manages the application at all levels, assigning user roles, editing organization details, setting up default localizations and more.

Operators can create business accounts, generate access tokens and manage a businesses localizations.

Finally, Merchant accounts are reserved for businesses. They can manage their business details and use access tokens to integrate the widget with their site or mobile app.

Results

We completed the project on time, cleaning up the application’s architecture, adding new features and saving the client money by removing third-party tools. And the project overall had been instructive to us, as we improved our understanding of handling huge, highly-loaded payment systems.

Today, the product is developing rapidly. And we are preparing for the next stage: refactoring the widget using React Framework.

Do you want the same project?
Got A Project Idea? Lets Discuss It With Us
Contact Us