BazPay for Shopware 6

Install the plugin

Composer is the supported route. It keeps the plugin in your lock file, which means it is versioned, reviewable and revertible like everything else in the project.

# install as a Composer dependency, the supported routecomposer require bazpay/shopware-paymentsbin/console plugin:refreshbin/console plugin:install --activate BazPayPaymentsbin/console cache:clear​# the payment methods now exist, but are not yet assignedbin/console plugin:list --filter=BazPayBazPayPayments  1.8.3  active  installed

On a clustered setup, run the install once and let the deploy pipeline clear caches on every node. Plugin activation writes to the database, not to local state.

Then open Settings → Extensions → BazPay Payments → Configure and set the sandbox key pair. The selector at the top of that screen is the sales-channel switch — read the next section before you touch it, because it is the difference between configuring one storefront and configuring all of them.

Sales channel scope

Every setting the plugin exposes belongs to a sales channel. That is more granular than most carts allow, and it is the reason multi-brand groups run Shopware in the first place.

Rule Builder availability

Shopware decides which payment methods a given cart may use through the Rule Builder, and our methods are ordinary payment methods, so they obey it. Nothing about availability is hard-coded in the plugin — which means you can express policies we never anticipated.

• Show iDEAL only when the billing country is the Netherlands.
• Show BLIK only when the currency is PLN, so the six-digit code makes sense.
• Hide SEPA Direct Debit below a cart value where its clearing time is not worth it.
• Offer cards to every customer group but wallets only to guests, who convert differently.
• Withdraw a method entirely from a channel during a promotion without uninstalling it.

Assign the rule on the payment method itself, under Settings → Payment methods. A method with no availability rule is available whenever the channel offers it, which is the right default for cards and rarely the right default for a country-specific bank method.

The transaction state machine

Shopware separates the order state, the delivery state and the transaction state. Payments belong to the third, and the plugin never writes to the other two — an order that is paid is not automatically an order that should ship, and conflating them is how stock goes out against a failed payment.

# order_transaction states, as the plugin drives them​open              order placed, shopper sent to the methodin_progress       authenticating, or waiting at the bankpaid              webhook payment.succeeded verifiedpaid_partially    a partial capture was takenrefunded          refund total reached the captured totalrefunded_partiallycancelled         authorisation voided before capturefailed            declined; reason code written to the order

Transitions run through Shopware's own StateMachineRegistry, so every change is recorded in the state machine history with a timestamp and an actor.

Because the transition is driven by the signed webhook rather than by the shopper's browser, an abandoned tab does not leave an order in limbo. The event arrives server-to-server, the transaction moves, and any Flow Builder rule watching that transition fires normally.

Flow Builder automation

The plugin publishes its own business events, so a merchant can react to payment outcomes without writing a subscriber. These appear in the trigger list in Settings → Flow Builder alongside Shopware's native events.

Each event carries the payment id, the reason code where there is one, and the order it belongs to. That is enough to build a dunning flow entirely in the administration, with no deployment. Where you need more than the events expose, the same data is on the API.

Subscriptions and repeat carts

One payment handler serves both the one-off cart and the recurring one. That is deliberate: a separate "subscription gateway" is how stores end up with two sets of keys, two descriptors and two reconciliation files for the same customer.

• The first payment is customer-initiated and authenticates in the usual way.
• Renewals run as merchant-initiated transactions against the stored token.
• Card tokens are network tokens where the scheme supports them, which lifts approval rates.
• SEPA subscriptions reuse the mandate captured at the first collection.
• A failed renewal returns the issuer reason code, so a retry flow can be selective.

Scheduling, proration and dunning stay in Shopware. We report the outcome and the reason; the store decides the policy. The API-side detail is on recurring billing, and the exemption logic that keeps renewals out of a challenge is covered under fraud and SCA.

Common questions

Why does BazPay not appear at checkout after activating the plugin?

Because activating a plugin in Shopware does not assign its payment methods to a sales channel. Open Sales Channels, pick the channel, and add the methods under Payment methods. This is Shopware behaving as designed, and it catches almost every first installation.

Can one Shopware instance run several BazPay accounts?

Yes. Configuration is sales-channel scoped, so each channel can hold its own key pair, method mix and descriptor. A group running a B2C storefront and a B2B channel from one instance can settle them to different accounts without a second Shopware installation.

How do refunds work from the administration?

From the order detail view, on the transaction. Full and partial refunds are both available and both reach the gateway immediately. The administrator needs the order refund privilege in their ACL role, which is not granted to every role by default.

Does the plugin work with Shopware's subscription feature?

It does, on 6.6 with subscriptions enabled. One payment handler serves both the one-off cart and the recurring one, and renewals run as merchant-initiated transactions against the stored token, so the shopper is not asked to authenticate for a charge they are not present for.

We run a reverse proxy in front of Shopware. Anything to change?

One thing: the webhook route must bypass the HTTP cache and any bot challenge. Our sender is a server, it will not solve a JavaScript challenge, and a challenged webhook is a webhook you never receive. Everything else can stay cached as normal.