Best payment modules for PrestaShop: a complete comparison

Last reviewed June 2026, fee baselines and module maintainer status checked against current provider pricing pages; verify live rates before you commit, as they move and are negotiable above volume.

Search "best payment module for PrestaShop" and you get a wall of opinions, most of them written by whoever sells the module. Here is the honest framing instead: there is no single best payment module. There is the right one for your markets, your average order value, and how much you want to touch the back office again next year. This guide is the comparison itself: the major payment modules a PrestaShop store actually installs, what they cost per transaction, how they hook into checkout, and a decision framework that ends with you knowing which two or three to install. It is deliberately about choosing and running the modules, not a country-by-country tour of payment culture, which we cover separately and link to where it matters.

What you're actually comparing: the gateway is a PrestaShop module

Every option below is, on your store, a PrestaShop payment module. That matters more than the marketing implies, because the module, not the brand, decides what your checkout feels like and how much maintenance you inherit. Two things separate a good payment module from a liability:

• How it renders in checkout. Modern modules register on the paymentOptions hook (the old displayPayment hook on 1.6) and return one or more PaymentOption objects, which is what lets a single module surface several methods, card, iDEAL, BLIK, as separate buttons on the payment step. A weak module dumps a redirect link and breaks the visual flow.
• Who keeps it alive. A payment module talks to an external API that changes on the provider's schedule, not yours. When PayPal or Stripe revises an API version, a maintained module ships an update and your checkout keeps charging; an abandoned one fails silently at the worst possible moment. "Best" is partly a question of who is still maintaining the code.

So the real comparison is three columns deep: the per-transaction fee, the markets the module unlocks, and the maintenance burden it leaves on your back office. We will hold all three in view.

If you have never seen what that hook looks like in a module's main class, this is the entire contract, the method that decides what a customer sees at the payment step:

// In your_module.php – the modern hook every maintained gateway uses.
public function hookPaymentOptions($params)
{
    if (!$this->active) {
        return [];
    }

    $option = new \PrestaShop\PrestaShop\Core\Payment\PaymentOption();
    $option
        ->setModuleName($this->name)
        ->setCallToActionText($this->l('Pay by card'))
        ->setAction($this->context->link->getModuleLink(
            $this->name, 'validation', [], true
        ));
    // A single module can return several PaymentOption objects –
    // one per method (card, iDEAL, BLIK) – as separate buttons.
    return [$option];
}

That is the difference made concrete: a module returning a clean array of PaymentOption objects integrates into the native payment step; a module that instead echoes a raw redirect link is the one that breaks your layout and is hard to reorder. When you evaluate a module, this is the behaviour to verify on a staging order.

The major payment modules at a glance

The table below is the short answer. Fees move and are negotiable above a certain volume, so treat the figures as the publicly listed European baseline at time of writing, verify current rates on the provider's pricing page before you commit. Every "method count" is what the single module can surface in your checkout.

Each of these deserves more than a table row. We have dedicated, hands-on guides for the two that most stores end up installing, the full back-office walkthrough for Stripe on PrestaShop and Mollie as a multi-method gateway. Plus a head-to-head if you are choosing between the two best-known names in Stripe vs PayPal. For the Polish market specifically, the setup is its own job: Przelewy24 for PrestaShop.

Aggregator vs. single-method modules: the decision underneath the decision

Before you pick brands, pick a shape. PrestaShop merchants who get this wrong end up with a cluttered payment step and a maintenance headache. There are two shapes:

The aggregator module (Mollie, Stripe)

One module installs once, connects to one dashboard, and surfaces many payment methods as separate buttons in checkout. So what does that mean for you? One set of webhooks to keep healthy, one reconciliation screen, one thing to update when an API changes, and you can switch a method on or off in the module config without installing anything new. For most stores this is the correct default, because the operational cost of a payment method is mostly in the maintenance, not the transaction fee.

The single-method module (a dedicated Bizum, a standalone local gateway)

One module, one method, usually because that method isn't available through an aggregator in your region, or because a direct integration shaves the per-transaction fee at high volume. The trade-off is real: every extra payment module is another hook into the same checkout, another webhook endpoint, another update cycle.

This is the single most common technical mistake we see, stacking five or six single-method modules until the payment step is slow and conflicts start. As a working rule, keep simultaneous payment modules to three or four: an aggregator for the bulk of your methods, PayPal for buyer trust, and at most one or two dedicated local modules where the aggregator can't reach. Beyond that you are buying yourself debugging sessions, not conversions.

How to choose: a decision framework

Work top to bottom. The first question that gives a clear answer usually settles it.

1. How many markets do you actually sell into?

• One country: install the dominant local method plus PayPal as a trust fallback, and stop. A Dutch store leads with iDEAL; a Polish store leads with Przelewy24/BLIK; a German store leads with bank-based methods. Adding methods nobody in that market uses only clutters checkout.
• Several EU countries: lead with an aggregator (Mollie covers the widest spread of European local methods in one module), add PayPal, and add one BNPL module only if your category benefits. This three-module setup covers the large majority of European payment preferences while keeping exactly one aggregator dashboard to reconcile.

If you're unsure which local methods a market expects, that's a research question on its own, we mapped what European customers expect at checkout and the specific local rails in BLIK, iDEAL and Bancontact.

2. What is your average order value?

Below roughly 80 EUR, BNPL rarely earns its higher fee. Above it, especially in fashion, furniture and lifestyle, a buy-now-pay-later option can lift the share of customers who complete a larger basket, which is why Klarna shows up on those stores specifically. Whether the lift is worth the fee is a per-store measurement, not a guarantee; we walk through the trade-off in what BNPL means for your conversion.

3. Card-heavy or subscription store?

If most of your customers pay by card and you don't need exotic local rails, Stripe's lower EU card fee and built-in recurring-billing support make it the efficient pick, and it's the one agencies reach for because the integration and documentation are clean. If brand trust at the moment of payment is your bottleneck (new store, first-time buyers, international), PayPal's recognition is worth its higher fee as a secondary button.

The broader case for offering more than one method, and why a single gateway leaves money on the table, is its own argument, made in full in payment methods matter: why more options means more sales.

Technical checks before any payment module goes live

The fee comparison is the easy part. These are the things that quietly break payment modules in production, and each is checkable from your own server or back office.

Webhooks must actually arrive

Every modern gateway confirms payment status with a server-to-server webhook, not the customer's browser redirect. Which means an order can be paid at the gateway while your store still shows it unpaid if the webhook never lands. Before launch, confirm three things: your SSL certificate is valid (gateways refuse to post to a bad cert), your server answers the webhook URL within the gateway's timeout (commonly ~30 seconds), and your firewall or CDN isn't blocking the gateway's IP ranges. In PrestaShop, the webhook hits the module's own front controller (the module's controllers/front/ handler, reached via index.php?fc=module&module=...&controller=...); check it resolves publicly before you trust it.

One detail that trips up Stripe integrations specifically: Stripe signs every webhook with a secret, and your module verifies the Stripe-Signature header against it. If you regenerate the signing secret in the Stripe dashboard but don't paste the new value into the module config, every webhook arrives and is rejected as unsigned, the gateway shows the payment as captured while PrestaShop never flips the order to paid. When a Stripe order hangs in "pending" but the dashboard shows it charged, check the webhook signing secret matches before you check anything else.

Never let a module touch raw card numbers

If a payment module collects card numbers on a form served from your own domain, you inherit full PCI DSS scope. An annual compliance cost in the thousands. Choose modules that use the gateway's hosted fields or iframe (PayPal Checkout, Stripe Elements, Mollie Components): the card data never reaches your server, so you stay in the lightest PCI bracket (SAQ A) and the scope stays with the provider. This is non-negotiable, and it's a fair reason to reject an otherwise cheaper module.

Test the conflict surface in staging

Because every payment module registers on the same paymentOptions hook, two modules can fight over checkout rendering, ordering, or assets. Install and exercise a new payment module on a staging copy first, place a real test order through every method, before it ever sees a live customer. A payment module that throws a 500 on the payment step doesn't lose one sale; it loses every sale until you notice.

Our recommendation

For most European PrestaShop stores the efficient starting point is one aggregator (Mollie if your markets lean on European local methods, Stripe if you're card-heavy or need subscriptions) plus PayPal as the trust fallback, two modules, covering the bulk of demand, with one dashboard to reconcile. Add Klarna only where your AOV and category justify the BNPL fee, and a dedicated local module only where the aggregator can't reach the method your market actually uses. Then leave it: every additional payment module is ongoing maintenance, and a lean, well-maintained payment stack converts better than a crowded one.

Whichever modules you land on, the principle holds for the surface they live on: the payment step is the most valuable screen in your store, and the job of every module on it is to charge correctly, fast, and without surprising the customer. The modules above all register on the same payment step, so how that step is laid out matters as much as which modules sit on it, keeping the methods, the order total and the confirm button in one view is where our Checkout Revolution one-page checkout earns its place, since it gives a clean payment step for Stripe (cards, Apple Pay, Google Pay, Link), PayPal and your local rails to render into without the customer losing momentum. Pick for your markets, keep the stack small, verify the webhooks, and you've made a business decision, not just a technical one. Which is exactly what choosing payment modules is.

Frequently asked questions

How many payment modules should a PrestaShop store run at once?

Three or four is the practical ceiling for most stores: one aggregator (Mollie or Stripe) for the bulk of your methods, PayPal as a trust fallback, and at most one or two dedicated local modules where the aggregator can't reach a method your market needs. Each extra module is another webhook to keep healthy and another update cycle, and because they all share the same paymentOptions hook, stacking too many is where checkout conflicts and slow payment steps start.

Is Mollie or Stripe the better aggregator for a PrestaShop store?

It depends on where your customers are. Mollie carries the widest spread of European local methods (iDEAL, Bancontact, BLIK, Przelewy24, Klarna and more) in one module with per-method pricing, which suits multi-market Benelux/DACH stores. Stripe has the lower EU card fee, built-in recurring billing, and clean wallet support (Apple Pay, Google Pay, Link), which suits card-heavy or subscription stores. Card-heavy and global → Stripe; broad European local coverage → Mollie.

Do I need PCI certification to take card payments through these modules?

Not in the heavy sense, as long as the module uses the gateway's hosted fields or iframe (Stripe Elements, Mollie Components, PayPal Checkout). With those, raw card data never touches your server, so you fall into the lightest self-assessment bracket, SAQ A. The trap is any module that renders a card-number form served from your own domain, that pulls full PCI DSS scope onto your store, with the audit cost that implies.

An order shows paid at the gateway but unpaid in PrestaShop, what's wrong?

Almost always a webhook that didn't arrive or wasn't accepted. Confirm your SSL certificate is valid, that the module's front controller resolves publicly, and that no CDN or firewall is blocking the gateway's IP ranges. For Stripe specifically, check the webhook signing secret in the module matches the one in the Stripe dashboard. A mismatched secret makes the store silently reject every otherwise-valid webhook.

Are the fees in the comparison table fixed?

No. They're the publicly listed European baselines at time of writing, and they move. Providers revise pricing, and most rates are negotiable once you pass a certain monthly volume. Treat the table as the shape of the comparison, not a quote, and confirm current rates on each provider's pricing page before you commit.