More insights
Co-founder, Chief Executive Officer
September 15, 2026 at 07:00 AM
PrestaShop remains one of the most widely used open source platforms among independent and growing merchants in Europe, with strong concentrations in France, Spain, Poland and Italy. Most of these stores are small or mid-sized businesses, which is exactly the segment that feels payment complexity the hardest, because every new payment method tends to arrive as its own project.
The pattern is familiar to anyone who has managed a PrestaShop store for more than a year or two. A card acquirer's module goes in first, installed from PrestaShop Addons. Then a BNPL provider joins, because customers keep asking for installments. Then a local wallet, because the store just expanded into a new market. Each one is a separate module, with its own settings screen, its own API keys, its own release notes to track, and its own risk of quietly breaking during a PrestaShop core upgrade.
The cost of getting this wrong shows up directly in checkout completion. Baymard Institute's long-running checkout usability research finds that roughly 9% of shoppers who abandon their cart do so specifically because there were not enough payment methods available. PrestaShop's own blog has made a similar point, noting that around three out of four shoppers abandon a cart before completing checkout, with payment friction consistently among the top reasons. A module-by-module approach to payments means a merchant is always slightly behind whatever their next market or customer segment actually needs.
Payment orchestration is not a new concept invented for e-commerce. It describes a layer that sits between a store and the payment providers behind it, so the merchant integrates once and gains access to many providers, methods and markets through that single connection instead of building a separate relationship with each one. NetSuite's explainer on the topic puts it plainly: with one integration, a business gains access to a wide network of providers and services, and NetSuite notes that large enterprise merchants often end up managing 20 or more separate PSP and acquirer integrations without an orchestration layer in place, a maintenance burden most PrestaShop merchants would rather avoid entirely.
Applied to PrestaShop, this means the store itself only ever talks to one payment method. Behind that single method, the orchestration layer holds the relationships with card acquirers, BNPL providers, wallets and local payment methods, and routes each transaction to whichever provider fits the customer, the market or the order. From PrestaShop's point of view, nothing new was installed when a new payment method becomes available to shoppers. The complexity simply moved outside the platform, into a layer built specifically to manage it.
This is the practical upside for a PrestaShop merchant. Without an aggregator, every payment method a store wants to offer is its own module from PrestaShop Addons, each requiring its own onboarding with that specific provider, its own testing, and its own place in line when PrestaShop ships a new version. Wanting to add installment payments alone is a meaningful undertaking this way, and demand for exactly that keeps growing. PrestaShop's own blog reports that around six in ten consumers across major European markets now use installment payments regularly, which makes it a method few growing merchants can afford to skip.
With a payment aggregator sitting behind the storefront, adding a payment method becomes a configuration change on the orchestration side instead of a new PrestaShop module. A merchant expanding into a new market gains access to that market's preferred local methods without a developer opening PrestaShop Addons to search for a compatible extension, install it, and hope it still works after the next core update. The store's payment method list grows with the business, not with how many separate modules a development team has time to maintain.
A single PSP's native PrestaShop module only ever offers the payment methods that specific provider has chosen to support, in whatever order they have chosen to prioritize. If a merchant wants a BNPL option that provider does not offer, or a local wallet that is popular in one market but irrelevant in another, the options are to wait for that provider's roadmap or start an entirely separate integration project alongside the first one.
An aggregator removes that constraint by design. Because it connects to many providers instead of just one, a merchant can mix and match: one provider's network for card acquiring, another for BNPL, a local wallet provider for a specific market, all surfaced through the same checkout without the shopper ever noticing the difference. Which methods appear can also be tailored by market or customer segment instead of shown identically to everyone, so a Polish shopper sees the methods that convert in Poland and a French shopper sees the methods that convert in France.
The commercial case for this flexibility is well documented. Bain & Company's research into BNPL found that 90% of merchants offering it experienced at least one measurable benefit, with 57% reporting improved checkout conversion and 46% reporting a lift in average order value, alongside 54% citing increased brand exposure to new customers. Numbers like these are a strong argument for offering more than one payment method. They are a weaker argument for building a separate native module for each one, which is exactly the gap an aggregator closes.
Most of what makes PrestaShop attractive to growing merchants is consumer-facing, but a good number of them eventually need to serve business buyers too, whether that is a wholesale arm, a trade account program, or simply a subset of customers who expect invoice or credit terms instead of paying by card upfront.
PrestaShop's own guidance on B2B commerce points merchants toward Multi-Store, running a separate storefront with its own branding and pricing for business customers alongside the main consumer store. That works, but it also means maintaining two checkout stacks, two sets of payment logic, and often two different payment providers behind them.
An aggregator built to handle both checkout types removes that split. The store still registers one payment method, but the decision logic underneath it can tell a consumer buyer from a business buyer and treat them differently, fast card or wallet checkout for one, credit checks and invoice terms for the other, without running two separate stores or two separate payment integrations to get there. This is the same underlying pattern Briqpay uses across every platform it supports, PrestaShop included: one integration, with orchestration and decisioning for both consumer and business checkout built in underneath it.
None of this means every PrestaShop store needs an aggregator from day one. A store with one market and one or two payment methods is not the audience for this. But the moment a store plans to add a market, add installment options, or start selling to business customers alongside consumers, the module-by-module model starts costing more in development time than it saves in provider choice.
Briqpay's own PrestaShop integration is built around exactly the pattern described here, one module registered in PrestaShop, an orchestration layer behind it giving access to a wide range of payment methods and providers, and a decision engine that can be configured for both B2C and B2B checkout. Briqpay describes it as well suited to startups and growing merchants specifically because it removes the need to build and maintain a new integration every time the payment method list needs to grow. For a platform where most stores are exactly that size, it is a reasonable place to start the conversation about how payments should scale alongside the business.
Briqpay's PrestaShop plugin page has the integration details. The same architecture on Magento 2 is covered in payment orchestration on Magento 2, and if you are comparing orchestration providers, see how Briqpay compares with Primer.
On Black Friday 2025, Swedish and Dutch shoppers moved six points toward pay later, Germans moved to wallets and the British stayed with cards. Our consumer checkout data, market by market, and what to put first in each checkout this year.
Card payments acquired in the shopper's own country are approved more often, and between the UK and the EU they can cost five times less. What local acquiring is, what it saves and how to set it up across the Nordics.
CCD2 brings buy now pay later and invoice under consumer credit law on 20 November 2026. What changes at checkout, which countries are ready (the Netherlands and Norway are not), and how exposed each market is, with our own checkout data.
Connect any payment provider. Optimize your payment flow. Scale without limitations - with Briqpay’s Payment Integration Platform.
