---
title: Choosing a Launch Method Mix | Shopware Community Hub
description: >-
  Use a launch method mix checklist to balance conversion, BNPL, fees, support
  load, and documented follow-up experiments.
canonical_url: 'https://hub.shopware.com/learn/unit/choosing-launch-method-mix'
---

# Choosing a Launch Method Mix

<LearningObjectives>

- **Apply** the **launch method mix checklist** to select methods for your markets, channels, and customer profile.
- **Balance** conversion goals with **technical effort**, **fee mix**, and expected **support load** when enabling methods.
- **Decide** whether **BNPL** belongs in your first mix based on **AOV**, market expectations, and operational readiness.
- **Document** launch assumptions and follow-up experiments so you can adjust the mix with evidence after go-live.

</LearningObjectives>

# Unit 5: Choosing a Launch Method Mix

**Strum & Co.** had a spreadsheet with twelve payment methods they were considering at launch. Their owner's instinct was to enable as many as possible — more choice, more conversion. Their support lead's instinct was the opposite — fewer methods, fewer edge cases.

Both instincts are partially right. The goal of a launch mix is not maximum coverage or maximum simplicity. It is a deliberate set of choices you can justify, operate, and measure — then adjust with real data.

---

## Why a Deliberate Launch Mix Matters

Payments sit at the intersection of **conversion**, **cash flow**, and **day-to-day operations**. A mix that works technically can still cost you in ways that do not show up until week three of operations: refund queries for methods your support team does not understand, reconciliation lines that do not match, or cart abandonment from a market where the expected local method is missing.

The goal is not to offer every method on day one. It is to design a mix that matches your markets and order profile, stays manageable in **Shopware administration**, and leaves room to expand once you have data.

---

## One Integration, Many Methods

**Shopware Payments** gives you broad method coverage from a single platform-native integration — cards and wallets, regional methods, and **BNPL** — without stitching together separate plugins for each brand.

![Hub-and-spoke diagram with Shopware Payments at the center and connections to PayPal, Bancontact, Visa, iDEAL, Przelewy24, Mastercard, EPS, Blik, Google Pay, SEPA, and Klarna](./assets/images/shopwarePaymentsMethodMixHub.jpg)

For your launch plan, treat this as a **menu you selectively enable** — not a mandate to activate every logo at once. Start with the subset that matches your priorities and evidence, then widen the menu as you learn.

---

## BNPL in the First Mix — Decide Deliberately

**BNPL** is worth calling out separately because it tends to be either over-enabled (added without thinking through support implications) or under-enabled (skipped because it feels complex).

The right question is whether your **average order value (AOV)** and customer segment make **BNPL** a meaningful conversion lever. For **Strum & Co.**, guitars over €300 are natural **BNPL** candidates — the installment option reduces the perceived barrier on higher-basket purchases.

If you are unsure, enable **BNPL** for a defined test window — one market or customer group — measure completion rate and support tickets, then decide whether it stays in the baseline mix. Do not add it by default and do not skip it without checking whether your **AOV** profile justifies it.

---

## The Launch Method Mix Checklist

Work through this sequence for every go-live or major new market. The goal is a documented, defensible method list — not a guessing game revisited every quarter.

**Step 1 — List your primary markets and channels**
For each country you are targeting, note the dominant local methods and whether B2B norms change expectations — for example invoice or bank transfer requirements in certain segments. Use Unit 4 as your local method reference.

**Step 2 — Cover the universal baseline**
In most B2C scenarios, ensure **cards** are available where your risk policy allows, plus the **wallets** your customers already use — **PayPal**, **Google Pay**, **Apple Pay** depending on region and device mix.

**Step 3 — Add must-have local methods**
If a method is genuinely expected in a market — not just available — treat it as launch-critical. **iDEAL** in the Netherlands, **Bancontact** in Belgium, **EPS** in Austria. Missing these is not a conservative launch — it is a conversion gap with a known fix.

**Step 4 — Decide on BNPL deliberately**
Use your funnel data: **AOV**, repeat purchase rate, and support capacity. Prefer a phased or measured rollout when evidence is thin. Do not add **BNPL** as an afterthought and do not skip it without checking your basket profile first.

**Step 5 — Stress-test operations**
For each candidate method, ask: who handles **refunds**, how are **disputes** initiated, and what does the customer see when something fails? Drop or postpone any method your team cannot support calmly in the first weeks. This is the filter that keeps the checklist honest.

**Step 6 — Document assumptions and owners**
Write down why each method is on or off at launch, who approved the list, and which metric will trigger the next review — conversion rate, chargeback rate, support volume, or margin per method.

**Step 7 — Align with any structured program commitments**
If you are part of a **Shopware Payments** pilot or early-access program, your launch plan may need to match baseline metrics, feedback cadence, and confidentiality terms from that agreement — not only this checklist. See Course 1, Unit 2 for the typical pilot pattern.

**Step 8 — Schedule a post-launch review**
Set a fixed date — 30 to 60 days after go-live — to compare checkout mix usage, failed payments, and operational load. Without a calendar commitment, the mix you designed for launch will still be running unchanged a year later.

> **What this checklist is and is not:** It helps you choose and justify a launch mix inside **Shopware Payments**. It is not a substitute for contracting, **KYC**, or scheme rules — your agreements and acquirer requirements still define what you may enable.

---

## Strum & Co. — Working Through the Checklist

Here is how **Strum & Co.** applied the checklist for their EU launch:

**Markets and channels:** Germany (primary), Netherlands, Belgium, Austria. Separate **sales channels** in **Shopware** per country, each with its own **PayPal Business account**.

**Universal baseline:** Cards (**Visa**, **Mastercard**) and **PayPal Wallet** across all channels. **Apple Pay** and **Google Pay** enabled for mobile — their analytics showed over 55% mobile traffic.

**Must-have local methods:** **iDEAL** for Netherlands, **Bancontact** for Belgium, **EPS** for Austria. All three confirmed on production accounts before launch. **Giropay** deferred — German customers already use **PayPal** heavily, and the owner wanted data before adding another bank redirect.

**BNPL decision:** **PayPal Pay Later** enabled for Germany and Austria, where **AOV** on guitar orders regularly exceeds €250. Netherlands and Belgium deferred to the 30-day review.

**Operations stress-test:** Support lead confirmed they understood bank-based refund timelines before **iDEAL** and **Bancontact** went live. A one-page internal reference was written for the two local methods covering refund steps and dispute paths.

**Documented owners:** The owner approved the final list. Finance owns the 30-day review trigger.

**Post-launch review date:** Booked for 45 days after go-live — enough time to have meaningful data across a peak weekend.

---

## Common Pitfalls

**Enabling everything by default** — more methods mean more edge cases, more reconciliation lines, and more training for support. Launch lean, then expand with data.

**Ignoring local norms** — cards alone underperform where shoppers expect a trusted local option. Missing **iDEAL** in the Netherlands is not a conservative choice — it is a gap.

**Treating pricing tables as the whole story** — compare all-in effort: integration maintenance, reporting, refunds, and support time — not only percentage fees. **TCO** applies to method choices as much as to **PSP** selection.

**No dated review** — method importance shifts with markets, seasons, and customer mix. Without a calendar reminder, the launch mix becomes the permanent mix by default.

---

Daily operations come next: which surface to open, per-order actions in administration, and how to read payouts without a second portal for every question.
