Challenge

As there is no possibility for the customer to statistically process the transaction data of their customers, the evaluation of this data turns out to be tedious and time-consuming.

Solution

The goal was to build a portal that serves the secure statistical processing of a customer’s transactions and additionally enables simple transaction changes. This required the programming of a frontend, backends, asynchronously workers and an API on our part.

1. Potential analysis

After an intensive exchange with the customer, we obtained an overview of their ideas and wishes. Based on this, we were able to make recommendations for tools, technologies and architectures, such as Flask and MongoDB. Together with the customer, the best possible potential from the business process was worked out in subsequent discussions.

2. Use case definition

Based on the process analysis, we defined the use case of the desired portal. Such a use case contains all possible scenarios that can be performed with the help of the system.

Scenario 1

Precondition:

The client’s API is responsive and the user has authenticated to the portal.

Postcondition:

All transactions have been successfully statistically processed.

Process – normal scenario:

1. The user enters an empty dashboard.

2. As a result of the user entering the dashboard, the portal requests data from the API.

3. The requested data is displayed graphically by the portal.

Process – alternative scenario:

3.1 The user filters the data according to specified criteria.

3.1.1 The portal prepares the graphics according to the selected filter criteria.

3.2 The user accesses the Counter page and views payment statistics.

3.2.1 The user filters the data according to specified criteria.

3.2.2 The portal prepares the data statistically according to the selected filter criteria.

Scenario 2

Precondition:

The client’s API is responsive and the user has authenticated to the portal.

Postcondition:

The data of the transaction can be accessed.

Process – normal scenario:

1. The user accesses the transactions.

2. As a result of the user accessing the transaction page, the portal requests data from the API.

3. The portal prepares the data of the transactions of the user’s customers as a table.

4. The user opens a specific transaction through a link in the table.

5. The user accesses sensitive customer data and its transaction history by another API request.

Scenario 3

Precondition:

The client’s API is responsive. The user has authenticated on the portal, views the transactions and has the right to modify transactions.

Postcondition:

An existing transaction has been successfully modified.

Process – normal scenario:

1. The user opens a specific transaction via a link in the table.

2. The user clicks on the action button.

3. The user modifies the transaction with a refund.

4. The action is transferred to the customer API for execution.

Process – alternative scenario:

3.1 The user modifies the transaction by a capture.

3.1.1 Continue as in step 4.

3.2 The user modifies the transaction by a cancel.

3.2.1 Continue as in step 4.

3. Iterative model creation

The use case definition enabled our team to work out a mockup portal. This was discussed with the customer and expanded with further requests.

After the concept development, we started with the implementation of the portal, i.e. the implementation of the defined structures and process flows.

During the entire process, the highest priority was given to the protection of sensitive customer data. It had to be ensured that the connection to the customer API was encrypted. In addition, the portal does not store customer-related data at any point.

Another important implementation was the integration of an API (Application Programming Interface) provided by the customer, which required authentication per user. This API allows access to data relevant to the transaction. This data is requested via the backend and prepared by the workers for the frontend.

During the integration, we created a frontend that displays all data in a table and allows filtering of different criteria and modifying transactions afterwards. The frontend was also extended to include a dashboard that displays statistical graphics. Filtering is also possible here.

After the implementation, we presented the system we had worked out. Here, in consultation with the customer, adjustments were made to the frontend that met his expectations.

4. Integration and result analysis

After we integrated the portal at the customer, a results analysis of the commissioned portal was carried out. For this purpose, various tests were carried out with regard to user interface functions and security in order to ensure the portal’s functionality.