Integration of the app with the shop and factors affecting pricing

The list of endpoints alone does not show how the application is intended to support the business process. The scope of the application’s integration with the shop is determined by the tasks of the customer or employee, the data exchanged between the application and the shop, the capabilities of the systems, and the method of synchronisation. Therefore, first establish what the user is supposed to do and where the result should be sent. Integrating the catalogue, shopping basket, orders or returns requires planning data flows and testing. API documentation and access to a test environment are also important.

In this article, you’ll find out what to prepare before integration, how to identify the source of product and order data, and when to synchronise it in real time and when to do so periodically. You’ll also learn about the differences between a customer app and a tool for the shop team. This will help you plan an integration tailored to your actual tasks, rather than simply porting the entire system to a mobile screen.

Key findings

• Select the system that manages data on products, prices and orders. This will help you minimise the risk of discrepancies between the application and the shop.
• Adjust the frequency of updates to suit the type of information and the team’s pace of work. Data that is needed immediately requires a different approach to summary reports.
• Link automation to specific stages of the order processing workflow. A clear flow of data makes it easier to track statuses and reduces the need for manual information transfer.
• Design your app around the tasks of its users. Customers need access to shopping and their accounts, whilst staff need tools to manage orders, deliveries or returns.

Table of Contents

• Determining the primary source for products, prices and orders
• Synchronisation of data, prices and stock levels
• Automation of orders and sales processes
• Integration of a customer or staff app with the shop
• Internet Stars

Determining the primary source for products, prices and orders

Start by identifying the system that manages the shop’s data. In the configuration, assign responsibility for products, prices, stock levels and orders.

A single data source and technical requirements

A single master data source means that the specified system stores the current information. The shop can manage the product catalogue, whilst the ERP system manages stock levels and orders. Establish this division before duplicate records are created. Products, prices, stock levels, orders and customer data can be synchronised between the application and the shop. The scope depends on the application’s tasks and the information required by its users. For example, the customer app can retrieve the product catalogue, shopping basket and order history, whilst the staff app can send order fulfilment status updates to the shop’s system. An API supporting the required data flow is needed for the integration. Before integration, review the API documentation and check access to the test environment. If the API does not support the required operation, it may be necessary to extend the system. When connecting the shop to BaseLinker, the configuration may require an API key or a shop add-on.

Scope and timetable for product synchronisation

The synchronisation scope determines which products and fields are transferred to the application and when they are imported or updated. Select the entire catalogue, specific categories or groups, such as products intended for business customers. Then decide whether the import includes descriptions, variants, images, prices and stock levels. Tailor the schedule to the importance of the data and how users work. Prices and stock levels may need to be updated more frequently than product descriptions. Also specify whether updates are sent to the shop, the app or both systems.

Excluding products from integration

Excluding products is a rule that omits items which do not meet the specified conditions. You can filter out products with no stock or no images if they should not appear in the app. This allows you to avoid displaying items that are unavailable or incomplete. Save the rules separately for each product group. For example, a product without an image may remain in the shop but not appear in the app’s catalogue. Also specify what should happen when the status changes or an image is added. This ensures that a re-import will restore the product in accordance with the configuration.

Synchronisation of data, prices and stock levels

Synchronisation governs the flow of data between the shop, the app and other sales channels. For each type of information, set the direction and frequency of updates.

Synchronisation mode and frequency

The synchronisation mode indicates whether data is updated in real time or according to a schedule. This choice affects the timeliness of the information and the load on the systems. Payment status may need to be transmitted quickly, whilst a summary report only needs to be refreshed periodically. Keep these cases separate. Determine separately whether changes flow from the shop to the application, or whether they also flow in the opposite direction. Customer data, for example, may be updated in both directions if both systems allow it to be edited.

Also specify the frequency of updates to prices, the catalogue and orders. Integration tools should support a scheduled workflow, rather than imposing a single rhythm on all data. If a user updates information in the application, specify the target system and how the change should be saved. This streamlines the team’s work and minimises discrepancies.

Synchronisation of stock levels

Stock synchronisation transfers available quantities between the warehouse, the shop and the app. Determine which system records the change following a sale, return or adjustment, and then specify where the update should be visible. If a product can be purchased in-store and via the app, the change should be reflected in the other channels in accordance with the agreed workflow. Otherwise, the customer may see stock levels that do not reflect the latest transaction.

If your shop displays product availability separately for different warehouses or locations, ensure these are also separated in the configuration. Specify whether the application should display the total stock levels or the stock level for a specific location. This makes it easier to tailor the information to the collection or dispatch process. Multi-channel sales require a clear link between a product and its stock levels.

Synchronising sales with marketplaces

Synchronisation with marketplaces transfers data on product listings and sales between the shop and the external channel. Specify whether the system should transfer products, prices, stock levels and orders, or only selected information. For example, an order from a marketplace may be sent to the system managing the shop, whilst a stock level update may be sent back to the sales channel. The direction of data flow should correspond to where the team fulfils orders.

Set separate rules for prices and availability. A promotion on one channel should not necessarily change the price on the others. Similarly, a product available in-store may be excluded from a specific marketplace. Tests should cover the entire workflow: listing a product, processing an order and updating data. A well-planned integration of sales channels helps to organise these operations without mixing up their rules.

Automation of orders and sales processes

Automation links an in-store event to the next action. Once an order has been placed, the system can forward the details to the customer service team, update the status and trigger a notification. Map out the entire workflow, from purchase to order fulfilment. This ensures the team knows which actions are carried out by the platform and which require their decision.

A new order may, for example, be routed to the order processing system, where a member of staff can view the products, delivery details and payment status. Changing the status to ‘accepted for processing’ may trigger the next stage. If payment has not been recorded, the process should halt at a predetermined point. Separating these pathways reduces the risk of dispatching an unpaid order.

Dispatch can be linked to the transfer of order details to a labelling tool. Once the parcel has been posted, the shop updates the status and the customer receives a message confirming dispatch. Define the content of messages relating to subsequent stages, such as purchase confirmation, order preparation and dispatch. This ensures that the team has a clear division of tasks, and the buyer knows what is happening with their order.

Push notifications can alert users to a change in status, product availability or the start of a promotion. In marketing, a rule can trigger a message following a specific action, such as adding a product to the basket. Plan which event triggers a message, who it is sent to and when it becomes out of date. This ensures that customers receive messages tailored to their activity, rather than every message that is sent.

Before implementation, outline exceptional scenarios: order cancellation, returns, payment errors and missing delivery details. For each scenario, specify the next step and the person responsible should the automated process come to a halt. Next, test a sample order, from purchase through to the dispatch notification. Check that the statuses match in the shop and the back-end system. Well-designed automations take the pressure off the team, whilst also highlighting areas requiring manual intervention.

It is also worth combining automation with customer service: in the ‘State of the Connected Customer’ survey, 83 per cent of customers expect immediate support. According to a Zendesk report, 50 per cent of customers use website chat as their preferred channel of contact.

Integration of a customer or staff app with the shop

First, decide who will be using the app and what tasks they are expected to carry out. A customer app might handle purchases, whilst a staff app might handle order fulfilment.

Methods for integrating applications with the shop

An API, a plugin and an integration platform connect the application to the shop in various ways. An API allows you to tailor the data flow to a specific scenario, whilst a plugin utilises a ready-made connection available for a given system. An integration platform acts as an intermediary between the tools. The choice depends on the shop’s capabilities, the API documentation and the application’s requirements. Also check whether a test environment is available.

Stages of integration implementation

Implementation begins with defining the task, followed by selecting the data and designing its flow. The next steps involve connecting the systems and testing a scenario, such as placing an order and recording its status. To integrate the application with the online shop, you should also specify the scope of customer data. The shop must comply with the GDPR, and according to EUR-Lex, data processing for the purposes of ensuring network and information security must be strictly necessary and proportionate.

Implementation time and integration risks

The implementation time depends on the number of workflows, the API documentation, the availability of tests and the scope of changes required on the systems side. Simply retrieving a catalogue is different from handling shopping baskets, orders and returns. Risks include, amongst other things, incompatible fields, the absence of a required API operation and incorrect status recording. Minimise these risks by defining scenarios and exceptions before work begins.

Testing and maintaining integrations

The test covers the entire workflow: source data, reading the data in the application, saving changes and displaying the result in the shop. Check, for example, an order, a status update and a connection error. Once the system is up and running, monitor failed operations and data discrepancies. Only store a copy from the ERP system to the extent necessary for the process, particularly when working offline. Plan an application tailored to the shop’s processes.

In a customer app, the scope of integration may include retrieving the catalogue, prices, account details, shopping basket, orders and information about the loyalty scheme. An employee app, on the other hand, may handle order fulfilment, order statuses, deliveries or returns. Start your analysis of mobile app integration with a business scenario, rather than a list of endpoints.

The analysis should involve the process owner, the application team and the technical specialist responsible for the ERP, CRM or e-commerce system. Before defining the scope, check whether the system has a documented API and an available test environment. Tailor the integration with the ERP or CRM to the mobile user’s actual tasks, rather than simply porting the entire system to a small screen.

Internet Stars

Internet Stars helps to bring together the needs of the shop, customers and the team into a cohesive digital solution. Where a ready-made integration does not support a specific process, a bespoke application can accommodate users’ tasks and data flows. If repetitive tasks are a challenge, automation helps to streamline the various stages of the sales process. Depending on the project’s requirements, the scope of work may also include an online shop or staff training.

Get in touch with Internet Stars if you’re planning to integrate applications, developing an online shop, or want to tailor tools to the purchasing process and your team’s workflow. Describe your objective, your users and the systems that are to exchange data. Contact Internet Stars and present your idea.

Plan the next step for your shop

Treat the integration of your application with the shop as part of your business’s growth, rather than a one-off system integration. Processes, sales channels and user needs are constantly changing. The solution should therefore allow for the addition of new features without complicating the team’s day-to-day work.

Internet Stars develops bespoke applications, online shops and automation solutions. This is useful if you’re planning to develop an application, streamline your online sales or reduce the need for manual task handover. Start by defining your objective: what needs to change for the customer, the team and the purchasing process? A specific answer will help you translate your idea into the scope of the solution.

Present your plan and discuss with Internet Stars the possible direction of our collaboration, so that you can move on to the next stage of your shop’s development.

Frequently Asked Questions

What needs to be established before defining the scope of integration?

Prepare a sample purchase process and specify what should happen in unusual situations. Describe, for example, the absence of a flat number, the cancellation of an order once picking has begun, or a change to the delivery address. For each scenario, specify the expected message and the decision-maker. Such scenarios help to clarify the scope of functionality before starting to design the solution.

Should the application store a copy of the data from the ERP system?

The decision depends on the application’s purpose and how the user works. If the application needs to display selected information without access to the ERP, you can set up local storage for a limited set of data. You should also set up a conflict resolution rule: specify which version of the data takes precedence once the connection is re-established. The application can retrieve information that does not need to be available offline on demand.

Can every application be integrated with an ERP or CRM system?

Integration is possible if an agreement can be reached on how to identify records and handle changes to them. For example, the customer number used in the application should point to the correct record in the CRM, even if the company name has changed. Before implementation, set out how to handle mismatches, merged accounts and outdated identifiers. These rules prevent data from being assigned to the wrong person.

Can I integrate more than one online shop?

Yes, the application can support several shops, provided that the data flows take account of the differences between them. Determine how to identify the source of each order and where to route the relevant information. A separate channel identifier, for example, can enable the team to distinguish between purchases from different websites within a single dashboard. Also plan user access rights: an employee may need data from one shop, whilst a manager may need data from several.

How often are orders sent to the shop?

Orders can be submitted on an ongoing basis or in batches according to a schedule, depending on the working method adopted. When submitting in batches, set the processing order and mark records that have already been sent. If the system repeats an operation following an error, it should recognise that the order in question has already been accepted. This reduces the risk of duplicates and makes it easier for staff to identify which requests require a response.

What should you do if the app hasn’t passed on your order?

First, check whether the order has been saved in the app or has already reached the shop. Next, read the error message and decide whether the dispatch can be retried or whether manual intervention is required. Record the time of the attempt, the order ID and the result of the operation to facilitate analysis. After making the correction, check that the resubmission has not created another order for the same transaction.

An article by

Andrzej Klimek

Owner of Internet Stars since 2008