The fundamental difference

With PrestaShop, you are building a second source of truth. Customer-specific prices, credit limits, and invoices exist as copies of what is already in your client's ERP, and you build and maintain the synchronization that keeps both worlds aligned. Does it work? Yes. Until a price agreement changes, a price bracket shifts, or a credit limit is adjusted and the shop isn't aware of it yet.

Marcando uses the truth that already exists. The ERP remains the source system: products, customer-specific prices, price brackets, inventory, credit limits, and orders are linked bidirectionally, and that connection is our product. We build and maintain them for AFAS, Adsolut, Business Central, Navision, Exact, Odoo, and Dave & Venice. Whatever your client changes in the ERP appears in the shop immediately. There is nothing to keep in sync.

In both cases, the project remains yours: your design, your stack, your client relationship. The difference is how much you have to build, and who carries the burden afterward.

Building on the API

If you ask PrestaShop "what does this item cost for this specific customer," that price must first exist as a specific price in the shop database, synchronized from the ERP via a connection you build. If you build directly against an ERP API, you get raw lists back: all items, all price lists, all discounts, all warehouses. The resolution logic, data layer, caching, and sync are then your job. You can build it yourself, but then you are maintaining half an integration platform.

With Marcando, that puzzle has already been solved and maintained for each ERP. One call provides one usable answer: price, price bracket, inventory, and credit for that specific customer. You build your own front-end in your own stack against our documented GraphQL API, exactly as you would build headless against any other platform. If you don't want to build everything yourself, you can drop our building blocks like Checkout and Promotions into your own front-end; ready-made is also an option for projects without a development budget.

In that regard, timing is relevant. PrestaShop 9 introduced a modern Admin API on API Platform with OAuth2, which is a real step forward. However, it is a back-office API with incomplete coverage, and there is no official API for the storefront: headless today means using the legacy XML-Webservice, a third-party module, or custom controllers. PrestaShop 10 promises a headless-ready architecture, but the details won't follow until late 2026, with development planned for 2027 and beyond. Anyone wanting a custom front-end now is building against a moving target.

Customer-specific prices: the second truth

PrestaShop has more to offer here than most platforms: specific prices per customer, customer groups, and a B2B mode with credit limits and payment terms are built into the core. For a client with a handful of fixed agreements, that is sufficient.

The bottleneck is the wholesaler where every buyer has their own contract prices, price brackets, and time-bound agreements in the ERP. You translate that reality into thousands of specific price rules in the PrestaShop database, plus a synchronization that keeps them up to date, plus queries that continue to perform under that load. And the question your client ultimately asks is not whether the shop can display prices, but whether they are the prices their internal sales team would quote over the phone. With a copied price list, the answer is "usually." With Marcando, it is "always," because the price comes live from the ERP.

Documents: where the dual stream hurts

PrestaShop neatly generates its own PDF invoices. Since January 1, 2026, that has become a problem rather than a feature: for B2B transactions between Belgian VAT-registered companies, structured e-invoices via Peppol are mandatory, and a PDF from the webshop is not sufficient for that. Therefore, actual invoicing happens via the ERP, and the shop invoice becomes a second stream that you have to reconcile or disable. Quotes are an additional layer provided by modules.

With Marcando, that second stream does not exist. Your client's ERP remains the invoicing system that carries the obligation, and the customer portal displays invoices, payment status, and available credit directly from that ERP. Quote-to-order is standard in the platform, as are the sales representative module, approval rules, quick order via barcode or Excel upload, and multi-warehouse support. That is the list that, on PrestaShop, becomes a module stack with annual renewals or custom development.

Maintenance: who carries what after go-live

On PrestaShop, you maintain the entire stack: core, theme, modules, hosting, security, and the connection you built yourself. Version upgrades are the heaviest burden: moving from PrestaShop 8 to 9 (Symfony 4.4 to 6.4, PHP 8.x) costs a shop with twenty or more modules one to three months of work, according to migration analyses. That is work you either bill to a client who gets no new functionality for it, or you absorb yourself.

With Marcando, that layer is our job: platform, ERP connections, updates, security, and roadmap are included in the client's subscription. Your seniors build what sets you apart, not what you have to maintain. It also makes your quote sharper: no risk item for custom integration, no open maintenance item, but a predictable subscription that the client finds easier to approve.

When should you build on Marcando?

• Your client's ERP is the source system and must remain so.
• Every buyer has their own prices, price brackets, and credit agreements that must be accurate in real-time.
• Quotes, invoices, and approval flows are part of the daily process, and the source of truth for these belongs in the ERP.
• Sales representatives place orders on behalf of customers.
• Your client is primarily B2B, possibly with a side of DTC.
• You don't want a module stack, security watch, or integration maintenance in your fixed costs.
• Your client wants one predictable license instead of a sum of hosting, modules, and management.
• You want to spend your hours on front-end, UX, and the client relationship, not on invisible plumbing.

When should you build on PrestaShop?

• The project is primarily B2C or D2C.
• Your client demands ownership of code and data, and wants to be able to host and migrate independently.
• There is no ERP, or the ERP is just an accounting package that only needs to receive orders.
• You have in-house PrestaShop expertise and a management contract to keep the stack secure and up to date.

What else you should know

To be fair, this is part of the picture too.

• Freedom. PrestaShop is more open. If it can't be done with the standard features, you write a module. With us, you work within a platform with an API and building blocks; spacious, but bounded.
• Ownership. Your client owns a PrestaShop installation; with Marcando, they rent a platform. Their data remains in their own ERP, which limits dependency, but it is not open source.
• Scale. Marcando is a Belgian company of 13 people with 200+ clients. Continuity is a valid question for both you and your client; ask us, and we will provide a concrete answer.
• B2C. For a consumer brand, PrestaShop is the better choice. If you are primarily B2B with a side of DTC, you have come to the right place.

Conclusion

The difference is architectural, not functional. With PrestaShop, you build a B2B shop that mimics the ERP: prices, credit, and invoices as copies that you keep in sync, within a stack that you have to patch and migrate. With Marcando, you build an ordering layer that uses the ERP: the same data, but live, and without a second source of truth to maintain.

For a consumer brand or a client without a real ERP, PrestaShop remains the logical choice. But if you are dealing with a wholesaler or manufacturing company where the ERP is the source of truth and every customer has their own pricing, you should build on Marcando: you deliver faster, your quote has no open risk items, and your hours go toward the work the client actually sees. There is a partner model with financial incentives for agencies that build on it or refer clients.

Are you unsure about a specific project? Run it by us, even if the answer turns out to be PrestaShop. Schedule a call

‍