--- title: How Payments Work in Ecommerce | Shopware Community Hub description: >- Trace checkout through authorization, capture, settlement, payout, refunds, and disputes—and map multi-account setups to sales channels. canonical_url: 'https://hub.shopware.com/learn/unit/how-payments-work-ecommerce' --- # How Payments Work in Ecommerce - **Trace** the payment lifecycle from **checkout** through **authorization**, **capture**, **settlement**, **payout**, and post-payout **refunds** or **disputes**. - **Identify** the key actors in the flow—including **shop**, **customer**, **issuer**, **schemes**, **PayPal**, and **Shopware Payments**. - **Explain** how **multi-account configurations** assign **PayPal Business accounts** to **sales channels** in complex merchant setups. - **Decide** whether a status question belongs in **Shopware administration** or the **PayPal Merchant Dashboard**. # Unit 2: How Payments Work in Ecommerce A customer on **Strum & Co.'s** shop adds a guitar to their cart, enters their payment details, and clicks "Buy." From that moment, a sequence of events unfolds — across systems, institutions, and time zones — before the money reaches **Strum's** bank account. Most of that sequence is invisible to the merchant. But when something goes wrong — a decline, a delay, a dispute — the team that understands the lifecycle can diagnose and respond. The team that doesn't hears "we're looking into it" too many times. This unit maps the full lifecycle from checkout to payout, shows where **Shopware** and **PayPal** each play a role, and explains what changes when you run **multi-account** configurations across brands or regions. --- ## The Payment Lifecycle — Stage by Stage ### Stage 1: Checkout and Payment Initiation The shopper selects a payment method and submits their details. **Shopware** sends the payment request to **PayPal** for processing. What happens here: - The **payment method** determines what the shopper sees — card form, wallet button, **BNPL** option, or local method - **3D Secure (3DS)** or **Strong Customer Authentication (SCA)** may be triggered depending on the method, region, and risk profile - The order is created in **Shopware administration** with an initial payment status **Where to look:** Shopware order view — payment status reflects the initiation outcome. --- ### Stage 2: Authorization **PayPal** submits an authorization request to the issuing bank. The bank checks available funds, fraud signals, and authentication results, then responds. Possible outcomes: - **Authorized** — funds are reserved; the order can proceed - **Declined** — the authorization was rejected; the order cannot proceed without a new payment attempt - **Pending** — additional verification is required before a decision is returned The **authorization window** — the time the hold stays valid — varies by method and region. If capture does not happen within that window, re-authorization is required. **Where to look:** Shopware order view for authorization status; **PayPal Merchant Dashboard** for the transaction record. --- ### Stage 3: Capture Capture is when funds are actually collected. The timing depends on your settings: - **Auth-and-capture** — capture happens immediately at checkout. Common for B2C orders with instant fulfillment. - **Authorize-only (capture on dispatch)** — capture is triggered when you ship. Common for pre-orders, delayed fulfillment, and B2B. - **Partial capture** — only part of the authorized amount is captured, for example when only some items in an order ship. In **Shopware administration**, capture can be triggered per order — without opening the **PayPal Merchant Dashboard** for standard flows. **Where to look:** Shopware order view — capture action and status; **PayPal Merchant Dashboard** — transaction record updates. --- ### Stage 4: Settlement After capture, funds move between financial institutions — from the issuer through the card scheme or payment network to **PayPal**. This process is largely invisible to merchants but drives when money becomes available in your **PayPal** balance. Settlement timing varies by: - **Payment method** — cards, wallets, and bank-based methods settle on different timelines - **Region and account type** — some markets and account programs offer faster settlement - **Risk profile** — new or higher-risk accounts may have funds held in a **rolling reserve** before settlement completes **Shopware Payments** aims to reduce layered intermediary costs at this stage — **PayPal-native** access means no additional wallet markups that some platform stacks add on top of standard **PSP** pricing. **Where to look:** **PayPal Merchant Dashboard** — transaction and balance activity. --- ### Stage 5: Payout A **payout batch** transfers settled funds — minus fees, refunds, chargebacks, and reserve movements — from your **PayPal** balance to your bank account on a defined schedule. Key points: - Payouts are **batched**, not instant — the schedule depends on your **PayPal** account settings and region - **Instant settlement** via **PayPal's** infrastructure can make funds available faster without additional surcharges — contrast with models where accelerated settlement is a paid add-on - Each **payout batch** covers transactions settled since the last payout, which is why a single payout rarely maps cleanly to a single order or day's revenue **Where to look:** **PayPal Merchant Dashboard** — payout history and batch detail; bank statement for the deposit. --- ### Stage 6: Post-Payout — Refunds and Disputes The lifecycle does not end at payout. Two common post-payout events affect your balance and operations: **Refunds** — returning captured funds to the customer. In **Shopware Payments**, refunds are triggered per order in **administration** and tied to **Shopware's** return management workflow. A refund reduces your next payout batch or draws from your current balance. **Disputes** — a buyer-initiated challenge. The disputed amount is placed on a **funds hold** until the case closes. Disputes are managed in the **PayPal Resolution Center**, with clear deadlines and structured escalation paths. **Seller Protection** may apply to eligible transactions — see the Disputes Essentials course for a full walkthrough. **Where to look:** Shopware order view for refund status; **PayPal Resolution Center** for dispute status and deadlines. --- ## The Full Lifecycle at a Glance | Stage | What happens | Where to act | |-------|-------------|--------------| | **Checkout** | Shopper submits payment; order created in Shopware | Shopware administration | | **Authorization** | Bank approves or declines the funds hold | Shopware order view; PayPal Merchant Dashboard | | **Capture** | Funds collected — immediately or on dispatch | Shopware administration | | **Settlement** | Funds move to PayPal balance | PayPal Merchant Dashboard | | **Payout** | Funds transferred to your bank account | PayPal Merchant Dashboard; bank statement | | **Refund / Dispute** | Post-payout adjustments | Shopware administration; PayPal Resolution Center | --- ## Multi-Account Configurations The lifecycle stages above apply to every order. What changes in multi-account setups is **which PayPal balance** receives the funds — determined by which **PayPal Business account** is assigned to the **sales channel** where the order was placed. ### Supported Capabilities - **Multiple PayPal Business accounts** connected in one **Shopware** instance - **Individual assignment** of each account to one or more **sales channels** - **Separate production and sandbox accounts** so live traffic and test traffic do not share credentials or payout paths ### Typical Use Cases - **Multi-brand or multi-entity setups** — each brand or legal entity has its own **PayPal** account, method configuration, and reporting - **Regional or country-specific separation** — channels mapped to different markets, local methods, or settlement entities - **Parallel production and testing** — validating a new method mix in **sandbox** while live channels keep processing on production accounts ### Account Management for Connected Accounts For each connected account, **Shopware administration** provides: - **Direct links** to the **PayPal Merchant Dashboard** for that account - **Manual disconnect** functionality when you need to rotate or retire a connection > **Practical note for finance and support:** Multi-account setups do not change the authorization → capture → settlement → payout model. They change *where you look* — transactions, payouts, and disputes are separated by account, so reconciliation across brands or regions requires checking the right account in the **PayPal Merchant Dashboard**. --- ## Where Shopware and PayPal Each Own the Story A common source of confusion for support and finance teams is not knowing which system to check first. Here is a simple split: | Question | Start here | |---------|-----------| | What is the order status? | Shopware administration | | Was a refund processed? | Shopware administration | | Did the capture go through? | Shopware administration — then PayPal Merchant Dashboard if unclear | | Where is my payout? | PayPal Merchant Dashboard | | What fees were deducted? | PayPal Merchant Dashboard | | Is there an open dispute? | PayPal Resolution Center | | Why was an authorization declined? | PayPal Merchant Dashboard — transaction detail | > **For Strum & Co.:** when a customer emails saying they were charged but the order shows unpaid, the first check is the **Shopware** order view for payment status — and the second is the **PayPal Merchant Dashboard** for the transaction record. Nine times out of ten, the answer is in one of those two places without a support ticket to a third system. --- From how money moves, you'll compare payment method families—card, wallet, bank-based, BNPL, and local options—and when each fits your customers and markets.