--- title: >- Merchant Scenario: How Payment Platform Choices Change Your Shop | Shopware Community Hub description: >- Follow Strum & Co. through PSP trade-offs, flexibility versus efficiency, situation patterns, and a stakeholder decision checklist. canonical_url: >- https://hub.shopware.com/learn/unit/merchant-scenario-payment-platform-tradeoffs --- # Merchant Scenario: How Payment Platform Choices Change Your Shop - **Compare** **standalone PSP** setups and **Shopware Payments** using the **Strum & Co.** evaluation scenario. - **Apply** the **flexibility versus operational efficiency** map to judge trade-offs for your own shop. - **Recognize** common **situation patterns**—fragmented plugins, split **BNPL** and **PSP**, legacy fatigue, or hybrid scope—and the questions each pattern raises. - **Use** the **internal stakeholder checklist** and **FAQ-style** answers when building a decision pack for leadership or finance. # Unit 4: Merchant Scenario — How Payment Platform Choices Change Your Shop By now, **Strum & Co.** has a clear picture of what **Shopware Payments** is and how it works. This unit asks a different question: *what actually changes for the business depending on which payment approach they choose?* The goal is **decision clarity**, not a ranking of providers. You will follow **Strum & Co.** through the situations that come up most often in real merchant evaluations — and work through the checklist their internal stakeholders raised before making a call. --- ## Two Questions That Matter More Than Coverage Tables Before picking or changing a **PSP**, it helps to separate two distinct questions: 1. **Can this provider process the methods my customers want?** — coverage, currencies, risk tools 2. **Where will my team live every day?** — **Shopware administration**, the **PSP portal**, spreadsheets, or all three Most merchants answer question 1 first, then discover that question 2 dominates their week. **Strum & Co.** is no exception — especially when returns and cross-border orders pile up during peak season. --- ## Situation Patterns You Might Recognize These patterns reflect common merchant situations. Use them as a self-check — if one row feels familiar, the sections below show what the embedded alternative looks like in practice. | Pattern | What it often looks like | Why it hurts Strum & Co. | |---------|--------------------------|--------------------------| | **Accidental architecture** | **PayPal** plus another provider for cards or locals, several extensions stacked over years, checkout starting to feel patchwork | Unclear ownership when a capture fails; no single place for truth between **order**, **payment**, and **payout** data | | **Split BNPL, PSP, and wallet** | **Klarna** beside a card **PSP**, **PayPal** wired separately — each with its own reporting slice | Disjointed shopper experience; finance rebuilds spreadsheets to answer "what did we actually earn?" | | **Legacy PSP fatigue** | Long-running **PAYONE** or **Unzer**-class setups; change requests feel slow; integrations resist quick experiments | Every promotion or new market waits on payment plumbing, not merchandising | | **Hybrid scope first** | Only fixing card economics or one method family before touching the rest of the stack | Sensible risk control — but requires a clear reconciliation plan across two worlds until you consolidate | | **Replatforming window** | Moving to **Shopware 6** or rebuilding checkout without re-importing a decade of **PSP** complexity | The cheapest moment to simplify is while teams already expect change — waiting recreates old debt in a new UI | | **Vendor and contract sprawl** | Too many **PSP** relationships, long legal cycles, billing that does not line up with how commerce reports revenue | Leadership time is real cost, not only the processing rate | --- ## What Changes When Strum & Co. Uses Shopware Payments In every scenario above, **Strum & Co.** runs **Shopware 6** — only the payment layer changes. Here is what shifts when they move to **Shopware Payments**: **Embedded operations** — more of **refunds**, **transaction context**, and daily checks stay in **Shopware administration**, aligned with orders and returns. Fewer "which system is truth?" moments for a small team. **Faster time to value** — activation and configuration happen inside **Shopware**, with **PayPal's** infrastructure for scale and resilience — without giving up openness to other providers where needed. **TCO framing** — competitive, transparent pricing plus lower operational overhead when payments, commerce data, and reporting share one system of record. **The merchant outcome:** **Strum & Co.** still chooses methods and markets deliberately, but the owner spends less time chasing portals during peak season — and finance gets a straighter line from **order** to **payout** inside **Shopware**. > One scenario worth naming: some commerce platforms bundle payments tightly and charge extra fees or create friction when merchants use another **PSP**. **Shopware's** public positioning emphasizes value-based adoption, not forced exclusivity — but always confirm your specific contract terms before signing long-term agreements. --- ## The Flexibility vs. Efficiency Map A useful way to visualize the trade-off across provider types is a two-axis map: - **Horizontal axis — operational efficiency:** how light the setup feels for daily work — onboarding speed, fewer tools, fewer handoffs, reconciliation effort - **Vertical axis — enterprise-grade flexibility:** how far you can stretch methods, markets, risk, and payout logic as you grow Many **PSP** stories cluster along a diagonal trade-off: strong flexibility often pairs with more operational weight; strong simplicity sometimes pairs with less architectural freedom. **Shopware Payments** is positioned toward the upper-right — **embedded** efficiency in **Shopware** plus room to grow, with **PayPal** behind the scenes and no forced lock-in on the Shopware side. ![Scatter plot comparing operational efficiency and enterprise-grade flexibility, with Shopware Payments in the upper-right and other PSPs distributed for comparison](./assets/images/powerEffortlessPositioningMap.jpg) Use this figure as a conversation guide with your agency or finance lead — then validate coverage, pricing, settlement, and support against your contracts and markets. --- ## When Stakeholders Push Back — Internal Checklist The same themes surface inside your own business when finance, IT, or the owner asks hard questions. Use this checklist to turn those conversations into evidence tasks. | If you hear… | What it often signals | What to verify in your shop | |-------------|----------------------|----------------------------| | **"Our payments already work."** | Fear of disruption; change fatigue | Whether hidden work — portals, refunds, disputes, spreadsheets — is growing faster than volume. Whether you can try **Shopware Payments** in sandbox alongside an existing **PSP** before switching traffic. | | **"We can't afford vendor lock-in."** | Long-term architecture and negotiating power | Contract language: penalties for using other **PSPs**, data portability, and who owns checkout UX. | | **"Prove it on price only."** | CFO-style scrutiny of margin | Total payment economics: processing fees plus settlement timing, wallet markups, dispute and refund effort, and engineering time. Model with **TPV**, **method mix**, and **AOV** — see **Finance and Reporting Essentials**. | | **"Will it survive peak traffic?"** | Production readiness and revenue risk | UAT and load behavior on your checkout. **Shopware Payments** as a product can be newer than the underlying **PayPal** infrastructure that carries scale — your proof is testing, not headlines. | | **"We'll lose advanced PSP features."** | Fraud rules, niche methods, custom flows | A feature matrix for must-keep capabilities versus nice-to-have; which exceptions stay on a second **PSP** during a hybrid phase. | | **"Migration is too risky."** | Tokens, subscriptions, CX, rollback | A phased plan — market, channel, or method slices — with rollback criteria and clear ownership of data migration tasks. Treat "all at once" as a red flag. | | **"Legal won't like liability and PCI."** | Data ownership, audit trails, PCI scope | Where card data is handled, who holds **PCI** responsibilities in the contract, and whether reporting and audit exports meet your governance needs — involve legal and security, not commerce alone. | | **"We can't align another project."** | Internal change capacity | Whether onboarding can be incremental — parallel to today's processes — and which one metric leadership will use to decide success. | > **How to use this table:** each row should end with an evidence task — a document to review, a test to run, or a contract clause to check — not a debate about which provider is better in the abstract. --- ## Quick Answers Merchants Often Look Up **Is Shopware Payments mandatory?** No. It is optional by design. Merchants are not penalized for using other **PSPs** or staying on extensions such as the **PayPal** plugin — adoption is driven by fit and value, not platform pressure. **Can we use other providers alongside Shopware Payments?** Yes, where your architecture and agreements allow. Many shops run a hybrid phase while they validate coverage, economics, or edge-case flows — like **Strum & Co.** keeping a local-method route while piloting embedded payments. **How is this different from the PayPal plugin?** The **PayPal plugin** is **PayPal's** integration product for Shopware. **Shopware Payments** is **Shopware's** embedded product powered by **PayPal** infrastructure — Shopware owns more of the **administration experience**, **onboarding path**, and platform-side commercial framing; **PayPal** remains central to regulated processing and money movement. **Can we test before going live?** Yes. Use sandbox mode in **Shopware administration** to validate configuration and flows without live customer charges, then promote to live when your checks pass. **Where is Shopware Payments available?** Markets open in controlled phases so licensing, compliance, currency, and local method coverage can be validated before scale. For current countries, timelines, and method lists, use official **Shopware** documentation or your account manager — do not rely on static Academy content for geography. **How is it priced?** Typically transaction-based fees that scale with volume. Exact rates and surcharges depend on region, methods, and commercial terms. Use **Shopware** pricing materials and your quote or contract as the source of truth. **Is it "white-label" PayPal?** No. It is a platform-native **Shopware** experience with **PayPal** providing regulated global infrastructure — not a generic rebranded gateway bolt-on. **What reporting exists?** Centralized visibility in **administration** for transactions, statuses, and settlement-oriented information — enough for many merchants to reduce manual consolidation. Finance should still map outputs to their own close process — see **Finance and Reporting Essentials** in this learning path. --- With platform evaluation in place, the learning path moves to shared payment vocabulary, the lifecycle from checkout to payout, and a method strategy for a deliberate launch mix.