--- title: Local Payment Methods and PayPal Web SDK Integration | Shopware Community Hub description: >- Why local methods lift conversion, key EU options, PayPal Web SDK v6 dynamic loading, and availability checks before you enable a method. canonical_url: 'https://hub.shopware.com/learn/unit/local-payment-methods-paypal-web-sdk' --- # Local Payment Methods and PayPal Web SDK Integration - **Explain** why **local payment methods** often lift conversion and trust in specific markets. - **Describe** how **Shopware Payments** delivers eligible local methods through **PayPal Web SDK v6** and **dynamic component loading**. - **Identify** key **EU local methods**—including **iDEAL**, **Bancontact**, **EPS**, and **SEPA** options—and when each matters commercially. - **Decide** when to add a local method and which **availability checks** to run before you promise it in checkout or marketing. # Unit 4: Local Payment Methods **Strum & Co.** launched with cards and **PayPal**. Conversion in Germany was solid. In the Netherlands it was not. Their Dutch customers were abandoning at checkout — not because the price was wrong, but because **iDEAL** was not there. Adding a global method mix and assuming it covers every market is one of the most common and most fixable conversion problems in cross-border ecommerce. This unit explains why local methods matter, which ones are worth knowing for EU merchants, how **Shopware Payments** delivers them at checkout through **PayPal Web SDK v6**, and how to decide when to add one. --- ## Why Local Methods Matter Shoppers trust what they already use. In many markets, a card-and-wallet default is not a complete checkout — it is a signal that the merchant does not fully serve that market. Local and regional methods do three things that global defaults cannot always replicate: - **Reduce abandonment** — shoppers who do not see their preferred method often leave rather than use an unfamiliar alternative - **Signal market presence** — offering **iDEAL** to a Dutch shopper or **EPS** to an Austrian shopper communicates that the merchant serves that market, not just tolerates it - **Manage risk differently** — bank-based local methods often carry lower fraud and chargeback rates than card payments, which can reduce dispute overhead over time When you expand cross-border or add **sales channels** per country, treat local methods as part of the same decision as **multi-account configuration**: which channel, which **PayPal Business account**, and which method mix belong together. --- ## Key Local Methods for EU Merchants The following methods are commonly expected in their primary markets. Availability through **Shopware Payments** depends on your **PayPal** account configuration and geographic eligibility — confirm before committing to checkout UX or marketing. **iDEAL — Netherlands** The dominant payment method in the Netherlands, covering the large majority of online transactions. A bank redirect that completes in the shopper's own banking app or portal. Expected, not optional, for any merchant selling seriously into the Dutch market. **Bancontact — Belgium** Belgium's primary local debit scheme. Shoppers in Belgium use Bancontact the way Dutch shoppers use iDEAL — it is the default expectation. Card-only checkout will lose a meaningful share of Belgian traffic. **EPS — Austria** Austria's bank transfer standard. Similar redirect pattern to iDEAL — the shopper authenticates through their bank. Common expectation for Austrian B2C ecommerce. **Giropay — Germany** A bank-based redirect method for Germany. Adoption is lower than iDEAL in the Netherlands, and German shoppers also use **PayPal**, cards, and **SEPA** — but Giropay appears in checkout expectations for segments of the German market, particularly for higher-value purchases. **SEPA Direct Debit — EU-wide** Pulls funds from a bank account across the **SEPA** zone. Common for recurring payments, subscriptions, and B2B invoicing. Has a reversal window — the shopper can recall the payment within a defined period — which affects how merchants handle fulfillment timing. **SEPA Instant — EU-wide (where supported)** Real-time bank transfer within the **SEPA** zone, settling within seconds. Relevant for high-value orders where payment confirmation before dispatch matters. Availability depends on the shopper's bank supporting the scheme. **Przelewy24 (P24) — Poland** Poland's leading online payment aggregator, covering multiple Polish banks through a single redirect interface. Essential for merchants expanding into the Polish market. > **For Strum & Co.:** the minimum viable local method set for their EU markets is **iDEAL** (Netherlands), **Bancontact** (Belgium), and **EPS** (Austria). **Giropay** and **SEPA Direct Debit** are worth evaluating for the German market depending on their customer segment. **P24** becomes relevant if they expand into Poland. --- ## How Shopware Payments Delivers Local Methods at Checkout **Shopware Payments** integrates via **PayPal Web SDK v6** with **dynamic component loading**. Understanding how this works helps set realistic expectations for method rollouts. **PayPal Web SDK v6** is the storefront integration layer between your **Shopware** checkout and **PayPal's** payment components. It is not a separate plugin you maintain per method — it is the foundation that determines which payment UI components can appear. **Dynamic component loading** means the checkout loads only the payment UI components needed for eligible methods in the current session — based on market, currency, and account configuration — rather than loading every possible method upfront on every page. In practice this means: - A Dutch shopper sees **iDEAL** at checkout because their session meets the eligibility conditions for that method - A German shopper on the same storefront sees a different method set appropriate for their market - Page load is not penalized by loading components for methods that will never appear in that session This supports a broader method portfolio — including local options where **PayPal** enables them — without treating checkout as a fixed, one-size-fits-all embed. --- ## Availability: What Dynamic Loading Does Not Override Dynamic loading determines *how* eligible methods reach the shopper. It does not determine *whether* a method is eligible. A method still appears only when: - Your **PayPal Business account** is configured and approved for it - The shopper's country, currency, and **sales channel** meet geographic rules - **PayPal** supports the method in that context > Confirm enabled methods in **Shopware administration** and your **PayPal** contract before advertising a local method in marketing or **CMS blocks**. Sandbox validation is not sufficient — verify on your production account. --- ## When to Add a Local Method Not every market needs every local method immediately. Use these three conditions as a practical gate: **1. It is expected in the market** Not "nice to have" — genuinely expected. iDEAL in the Netherlands is expected. Giropay in Germany is contextual. Know the difference before adding complexity. **2. You can operate its refund and dispute patterns** Bank-based refunds work differently from card refunds — they require a separate outbound transfer rather than an instant reversal. Support needs to know this before the method goes live. Factor these patterns into your launch method mix decisions before you enable the method. **3. Eligibility is confirmed on the production account** Sandbox validation shows the flow works. Production eligibility confirms the method is actually approved for your account and market. Do not skip this step. > **Strum & Co.'s approach:** they activated **iDEAL** and **Bancontact** at launch for their Dutch and Belgian channels. **EPS** followed in the second sprint after confirming production eligibility. **Giropay** is on the list for review after they have three months of German method-mix data to assess whether it moves the needle for their specific customer segment. --- ## Local Methods and Multi-Account Configuration When you run multiple **sales channels** with separate **PayPal Business accounts** — for example separate accounts for Germany and the Netherlands — local method eligibility is evaluated per account, not per storefront globally. This means: - A local method approved on your Dutch account will not automatically appear on your German channel if that account has not been approved for the same method - Method configuration and eligibility checks need to happen at the account level, not just the Shopware level - Finance reconciliation for local method transactions follows the account assigned to that channel — see the lifecycle overview for multi-account mapping --- You'll then turn method knowledge into a launch checklist—balancing conversion, BNPL decisions, operational load, and a dated review so your mix stays deliberate after go-live.