Briqpay for Shopware 6 Is Live: One Plugin That Orchestrates Every Payment Method, Not Just Cards

September 18, 2026 at 08:00 AM

Today we are releasing Briqpay for Shopware 6, a free, open source plugin that puts the whole Briqpay payment layer inside Shopware's native checkout. You can download it from GitHub now, and the Shopware plugin page has the full feature list and install steps.

This post is about why we built it the way we did. Shopware already has plenty of payment extensions. Most of them are built around one provider and, in practice, around cards. That is the wrong shape for the merchants Shopware serves, and the data from our own checkouts shows why.

Cards are not how Europe pays

Shopware is a European platform. Of roughly 30,000 live Shopware stores counted by Store Leads in September 2026, three quarters are in Germany, Austria and Switzerland, and most of the rest are elsewhere in Europe. So the question that matters for a Shopware payment plugin is not "does it take cards" but "does it take what a German, Dutch or Swedish shopper actually wants to use."

We looked at completed consumer checkouts across our merchants by market. In Germany, wallets carry about 60% of consumer checkouts and cards under 20%, with invoice and buy now pay later making up most of the rest. In the Netherlands, bank transfer takes about half of all checkouts and card under a fifth. In Sweden, buy now pay later and mobile payment together are three quarters of checkouts, and card is a distant third. Only in the UK and the US does card dominate. We wrote this up in why checkout speed is a solved problem and payment preference isn't, and the pattern is consistent with what we found in the payment methods that dominate European markets.

A card-first payment extension therefore covers, generously, a fifth of a German store's checkouts well. Everything else is either missing or bolted on through another extension, each with its own settings, its own order states and its own compatibility to check at every Shopware update. Merchants end up with a stack of five or six payment plugins that only behaves when nobody touches it.

What a payment orchestrator does instead

Briqpay is not a payment service provider. We do not process the money and we do not sign the acquiring contract. We sit between your Shopware store and every provider you choose, and we make the whole set behave as one payment method.

For a Shopware merchant that changes three things:

• Every method, one integration. Cards, wallets, bank transfer, invoice, instalments and buy now pay later, from the providers you already work with or want to add, all render inside one embedded checkout. Adding a provider later is configuration in the Briqpay portal, not a new plugin install.
• Rules instead of per-plugin settings. Which methods a shopper sees, and in what order, is decided by country, currency, cart value, category or customer type. A shopper in Munich sees wallets first, a shopper in Amsterdam sees bank transfer first, a shopper in Stockholm sees instalments first, from the same sales channel with nothing configured per market.
• You keep the contracts. You sign directly with each provider and keep the commercial terms. The orchestration layer is what lets you switch or add providers without touching the integration you built, which is the point of running composable software in the first place.

We have made this argument for other platforms in payment orchestration on Magento 2, payment orchestration on PrestaShop and payment orchestration on commercetools. Shopware is where it matters most, because Shopware's merchants sell into exactly the markets where card is a minority method.

Built into the Shopware checkout, not bolted on

The plugin renders Briqpay on Shopware's checkout confirm page. Cart, sign in, addresses and shipping stay exactly as they are. At the payment step, the Briqpay checkout is embedded below the product table, presents every method you have enabled, and completes the purchase inside it. There is no redirect and no separate checkout page, and your theme is untouched.

Validation happens server-side at the moment the shopper presses pay: the plugin confirms the session belongs to this cart, that the cart is not empty and that the total still matches, and rejects with a clear message if anything is off. Because the check runs on your server it cannot be bypassed by editing the page. Headless storefronts get the same session through the Store API.

Order management stays in Shopware too. Capture, refund and cancel live in a Briqpay card on the order detail page, line by line: partial captures by quantity, refunds against a specific capture, cancel while nothing has been captured. Anything done in the Briqpay dashboard, or by a provider that captures on authorisation, is picked up by webhook and reflected on the order. Amounts are handled the way Shopware prices them, gross and in minor units, so a cart of awkward prices and a percentage discount reconciles to the cent. And for orders taken by phone or email, a payment link card on the order page generates a hosted payment page pre-filled with the order.

Consumers first, but business buyers in the same checkout

The features above are about consumer checkouts, because that is where most of the volume and most of the conversion risk sits. Shopware, though, is unusually strong in B2B, and many of its merchants sell to both audiences from one store.

The plugin handles that without a second flow. A customer with a business account, or a company name on the billing address, opens a business session with invoice and payment terms available and the VAT ID Shopware already holds passed along. Everyone else gets consumer methods. Nothing is configured per customer group, and switching between the two starts a fresh session so the right methods are always shown. Our own study of B2B checkout speed shows why that matters: business buyers stall in exactly the places where a consumer-first flow forces them to improvise.

Why now

Two dates make this a good moment for Shopware merchants to look at their payment setup. Black Friday 2026 is 27 November, and last year's data shows the peak weekend pushed shoppers further toward instalments and wallets in the markets where those were already popular, not toward cards. And on 20 November, one week before, the EU's revised Consumer Credit Directive applies in Sweden and Denmark, which changes how invoice and buy now pay later are offered. A merchant whose credit methods live in separate plugins has a lot of moving parts to check in the busiest month of the year. A merchant running them through one orchestration layer has one.

Getting started

Briqpay for Shopware supports Shopware 6.6 on PHP 8.2 to 8.5 and is published under the MIT licence with a test suite and CI. Installation is four steps: download the zip from the latest GitHub release, upload it under Extensions, enter your Client ID and Client Secret, and complete a playground purchase before switching Test mode off. The compiled administration bundle ships inside the plugin, so no Node toolchain is needed.

The Shopware plugin page has the details, the README on GitHub covers settings, webhooks, the Store API and the two developer events, and our payment method library shows what is available in each market. If you want the wider argument for why payment mix, not checkout speed, is what moves conversion and cost, start with what actually reduces checkout costs and cart abandonment.

We would rather you contract with the providers you want and let us handle the plumbing. That is what an orchestrator is for, and it is now a plugin install away for Shopware.