Briqpay

More insights

Knowledge Hub

Payment Orchestration on PrestaShop: How to Add More Payment Methods Without Adding More Plugins

Logo

Mats Andersson

Co-founder, Chief Executive Officer

September 15, 2026 at 07:00 AM

Person shopping online at home with a laptop and a payment card

The module-by-module way PrestaShop payment stacks grow

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.

What a payment aggregator does differently

Abstract network of connected nodes, representing an orchestration layer routing between providers 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.

Access to more payment methods without a shelf of native modules

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.

Mixing payment methods instead of being locked to one provider's list

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.

A short note on running B2B and B2C from the same store

Two business colleagues reviewing documents together at a table 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.

Where this leaves a PrestaShop merchant

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.

Keep reading

Sweden just ran a live test of how its regulators handle a hard credit-licensing deadline, and most of the market didn't survive it. We look at what the July shakeout tells us about November 20, why most of the EU still isn't ready for CCD2, what critics are saying that Klarna isn't, and why the application date landing one week before Black Friday changes how merchants should plan the next ten weeks.

Knowledge Hub

September 11, 2026 at 07:00 AM

Business checkouts are faster than consumer ones at the median, until you look at the slowest 10%, where B2B stalls out longer. We analyzed 2.2 million checkout sessions to find out why, and what it's really costing merchants.

Knowledge Hub

September 9, 2026 at 07:00 AM

For 99% of online shoppers, entering billing details now takes less than a second: the browser fills it in before they've finished tapping. We analyzed 900,000 consumer checkouts to find out why, and discovered that the small minority who still type it all out by hand are also your highest-value customers.

Knowledge Hub

September 9, 2026 at 07:00 AM

REQUEST A DEMO

Ready to simplify your payment setup?

Connect any payment provider. Optimize your payment flow. Scale without limitations - with Briqpay’s Payment Integration Platform.

STAY CONNECTED

Subscribe now for exclusive insights and updates.

Briqpay logo
Copyright © 2026 Briqpay AB All rights reserved
Terms & Privacy