--- title: Transactions vs. Payouts vs. Fees | Shopware Community Hub description: >- Define transactions, payouts, and fees; apply the payout net formula; introduce three-way matching; and use TPV, AOV, and method mix in fee modeling. canonical_url: 'https://hub.shopware.com/learn/unit/transactions-vs-payouts-vs-fees' --- # Transactions vs. Payouts vs. Fees - **Define** **transactions**, **payouts**, and **fees** in the context of **Shopware Payments** and name where each appears in reports. - **Apply** the **payout net formula** to explain why bank deposits differ from gross order revenue. - **Explain** **three-way matching** across **orders**, **transactions**, and **payout batches** as the backbone of finance reconciliation. - **Use** **TPV**, **AOV**, and **payment method mix** as inputs for fee and performance conversations with stakeholders. # Unit 1: Transactions, Payouts, and Fees — Separating the Three The most common finance complaint after a merchant goes live with **Shopware Payments** is some version of: *"The money from PayPal doesn't match what we sold."* It never will — not if you compare **payout net** to **gross order revenue** without the layer in between. The fix is not better reporting. It is the right mental model. **Strum & Co.'s** finance lead had this conversation three weeks after go-live. She was comparing the March bank deposit to the March order total in **Shopware administration** and coming up short every time. Once she understood that three separate ledgers feed into that comparison — not two — the numbers started making sense. This unit separates **transactions**, **payouts**, and **fees**, introduces **three-way matching** as the discipline that closes the month, and explains how **Shopware Payments** pricing is structured so finance knows what to expect and what to challenge. --- ## Three Concepts That Must Stay Separate Most reconciliation confusion starts here — finance treats these three things as one: | Concept | What it is | Where it shows up | |---------|-----------|-------------------| | **Transaction** | A single payment event: gross amount, fee, net; recorded when it happens | **PayPal Merchant Dashboard → Activity** — immediately after the event | | **Payout** | A batch of settled transactions transferred to the bank on a defined date, after fees and in-period refunds are reflected | **PayPal Merchant Dashboard → Money / Payouts** | | **Fees** | Not a separate invoice — deducted as part of transaction and payout logic | **Activity** rows per transaction; rolled into payout totals | The merchant who says "PayPal sent us less than we sold" is almost always comparing **payout net** to **gross order revenue** without the transaction ledger in between. Fix the vocabulary before you fix the report. --- ## The Payout Net Formula — Applied to Reconciliation Course 3 introduced the payout net formula. This unit applies it to reconciliation work: **Payout net ≈ captured transactions − fees − refunds − chargebacks ± reserves** The payout will be lower than gross order revenue for the same period because of fees, refunds, chargebacks, settlement timing, and reserve movements. None of these are defects — they are the mechanics of how payment settlement works. > **Strum & Co. — the conversation that clicked:** > Finance lead: "March revenue was €18,400. The PayPal deposit was €16,950. Where did €1,450 go?" > Owner: "Fees were €520. Refunds processed in March were €680 — including two February returns. Reserve movement was €250." > Finance lead: "So the gap is accounted for. I just needed to know where to look for each piece." > > That is the conversation three-way matching enables — and prevents from happening every month. --- ## Three-Way Matching — The Discipline for This Course **Three-way matching** is the reconciliation habit that ties all three ledgers together: **Layer 1 — Order ledger** (Shopware administration) What was ordered, what was captured, what was refunded — at the order level. The commerce record. **Layer 2 — Transaction ledger** (PayPal Merchant Dashboard → Activity) The payment events that correspond to those orders — gross, fee, net, status. The payment record. **Layer 3 — Payout ledger** (bank statement + PayPal Merchant Dashboard → Money / Payouts) The batched transfers that moved settled funds to your bank account. The cash record. Each layer answers a different question. Only together do they close the month. The remaining units in this course build out each layer and the matching process step by step. --- ## Fees — What to Expect and What to Watch For **Fees in Shopware Payments are per-transaction** — deducted from each settlement rather than invoiced separately. There are no additional Shopware-layer surcharges on top of published per-transaction rates in the standard positioning: no extra line item for settlement speed, monthly minimum, statement fee, or payout fee as described in product materials. This is a meaningful contrast against stacks that add intermediary markups when merchants accept **PayPal** through their platform — layered fees on top of **PSP** pricing. With **Shopware Payments**, **PayPal Wallet** is natively embedded without platform-layer intermediary fees. > **What to verify in your own contract:** confirm your specific per-method rates, any wallet-specific terms, and what happens to fees after any promotional pricing period ends. The positioning above describes how the product is structured — your commercial schedule is the source of truth for your numbers. --- ## Inputs That Make Fee Modeling Useful Before you optimize rates or compare providers, align on three numbers. Without them, fee conversations stay abstract: **Total Payment Volume (TPV)** — total payment value processed in a period. Not the same as revenue, but closely related for online sales. Your primary input for any fee forecast. **Payment method mix** — share of volume by method. Two shops with the same TPV can have very different fee outcomes if one is wallet-heavy and the other is card-heavy. **Average Order Value (AOV)** — drives per-transaction economics when fees include a fixed component per transaction. You do not need perfect data on day one. But without method mix and TPV, fee comparisons are guesswork. Collect these before you negotiate or redesign checkout so you can tie rate changes to expected cash impact. --- ## Shopware Payments Pricing — What the Structure Means for Finance The pricing model is designed to be predictable as volume grows. Here is what each element means in practical finance terms: | How Shopware describes it | What it means for your books | |--------------------------|------------------------------| | **Transaction-based pricing** | Costs scale with volume — no large fixed payment platform commitment ahead of sales | | **No upfront license cost** for the core embedded path | Lower day-one cash commitment versus models that front-load platform charges | | **Transparent cost structure** | Fees visible in the flows you already operate — fewer surprise line items at month-end | | **No surcharges for additional payment methods** (where applicable in your agreement) | Expanding your method mix does not automatically increase platform costs | | **Predictable planning** | Fee drivers tie to TPV, method mix, and contract tables — not opaque bundle rules | > **Important:** this table reflects positioning. Always reconcile against your commercial schedule and what you see in live settlement reports — not against marketing descriptions. --- ## Promotional Pricing — Read Before You Sign Commercial offers sometimes show three columns: promotional rates, standard rates, and indicative market rates. The column that "wins" depends on assumed TPV, method mix, and model transaction size. Before you sign: - Confirm in writing what happens to rates after any promotional period ends - Map fee rows to the payment methods you actually use — not a theoretical mix - If **PayPal Wallet** pricing is negotiated separately with **PayPal**, carry that distinction into your margin model --- ## A Note on Fee Claims If you publish payment fee comparisons in your own marketing — internally or externally — apply the same discipline: - Define the benchmark: which providers, which region, which date, which cost components - Treat example figures as illustrative, not universal - Prefer "transparent, competitive pricing" over superlatives like "lowest fees on the market" — the latter requires continuous substantiation - If a claim looks absolute, rewrite the claim — not only the footnote Finance and legal should own final wording on any customer-facing savings statements, particularly under EU comparative advertising rules. --- You'll build the three-way matching process step by step—moving from order ledger to transaction ledger to payout ledger, and explaining every gap without a support ticket.