What the solution is
PrestaShop is a French open source commerce platform widely used in France, Spain and Italy. It is easier to start with than Magento and has a large marketplace of modules, but the quality of those modules varies a great deal, and that applies to the integrations too.
The integration to Business Central here is a module from PrestaShop's own addons marketplace. It is a single publisher rather than an established integration house, and we have not been able to find technical documentation, a version history or a named reference customer. That is why the solution carries low confidence in our research.
How the integration works
We cannot describe the integration precisely, and it is more honest to say so than to guess. A module of this type normally works against Business Central's standard API from the outside and transfers items, customers and orders on a schedule, but we have not been able to confirm the directions, the interval or the error handling.
Most fields in the table below therefore stand as not stated rather than as a no. That difference matters: the solution may well do more than we can document, and it may also do less. We have no basis for saying which.
What should weigh in the decision is not the feature list but the vendor risk. An integration carrying the connection between your storefront and your accounts needs a version history, a support channel and a name you can call when Business Central ships twice a year. Those are the three things to confirm here.
Prices, discounts and agreements
PrestaShop has customer groups with their own prices and a discount system built in, and that pricing logic lives in the storefront. We have found no documentation that agreed prices are fetched from Business Central.
The solution therefore carries the label for logic set up in two places. For a consumer store with one price list that is immaterial. For business selling it means the agreement has to be maintained in the store.
If you sell to business with agreed prices, this is not the solution to start with. The catalogue contains several solutions where the pricing logic either runs in Business Central or is documented as transferred from it, and they are a better starting point.
The order and the finance function
The purpose of the integration is getting orders from the store into Business Central so the accounts department does not key them in. That is the value worth paying for, and it is also the easiest to verify in a demo.
Everything after the order, meaning partial shipments, back orders, returns and credit memos, is handled in Business Central. Whether any of it is reflected back into the store we have not been able to document.
VAT is decided by PrestaShop. If you sell across borders, it is the store's VAT setup that carries it, and OSS should have a concrete answer.
Who the solution fits
The solution can fit a smaller company that already has a PrestaShop store and would like orders to reach Business Central automatically. If the store is there and the problem is manual keying, a module for a couple of hundred euro is a reasonable place to start.
It also fits if you sell in France, Spain or Italy and need a platform your local agency knows. PrestaShop's reach in those markets is a real advantage when looking for help.
The solution does not fit if the integration has to be operationally critical from day one, and it does not fit business selling with agreed prices. With the documentation we have been able to find, we cannot recommend it for a setup where a synchronisation failure costs money the same day.
What to settle before you decide
Ask for a version history. When was the module last updated, and which Business Central versions has it been tested against? Without an answer, that is the largest risk in the solution.
Ask for a support channel with a language and a time zone, and ask for a named reference customer running the module in production. Two vendor statements are enough to move the solution from low to medium confidence in our assessment, and they are quick to obtain.
Our large scenario stands as not served. Three companies, eight countries and sixty thousand items is not a setup we can defend pricing for this solution, and a band would be misleading rather than informative.