---
title: 'Key Terminology: Your Payments Glossary | Shopware Community Hub'
description: >-
  Lifecycle, PSP, Shopware Payments, economics, and dispute terms reused across
  the learning path—your quick reference glossary.
canonical_url: 'https://hub.shopware.com/learn/unit/payments-key-terminology'
---

# Key Terminology: Your Payments Glossary

<LearningObjectives>

- **Define** core lifecycle terms—including **authorization**, **capture**, **settlement**, **payout**, and **refund**—and how they appear in tools and reports.
- **Explain** **PSP**, **wallet**, **BNPL**, and common **payment method** vocabulary in plain merchant language.
- **Recognize** **Shopware Payments** platform terms such as **embedded** payments, **multi-account configuration**, **PayPal Web SDK v6**, and **TCO** drivers.
- **Distinguish** **dispute**, **claim**, and **chargeback** at a headline level and name **Seller Protection**, **3D Secure**, and **SCA**.
- **Identify** where **Shopware administration** versus the **PayPal Merchant Dashboard** is the right surface for operations and reporting.

</LearningObjectives>

# Unit 1: Key Terminology — Your Payments Glossary

When **Strum & Co.'s** finance lead says "settlement hasn't come through," and their support lead says "the order shows settled" — they are describing two different things. That kind of vocabulary mismatch is where tickets spiral and reconciliation takes longer than it should.

This unit gives everyone on the team — commerce, finance, and support — one clear definition per term. Later units go deeper on each topic; here the goal is a shared reference you can return to whenever **Shopware administration**, **PayPal Merchant Dashboard**, or internal reports use a word in a way that feels ambiguous.

---

## Money Flow and Lifecycle

**Authorization** — A request to reserve or check funds for a payment. May succeed, fail, or require extra steps such as authentication.

**Capture** — The step that collects authorized funds for settlement. Timing depends on product and settings.

**Partial capture** — Collecting only part of an authorized amount — for example for split shipments or partial fulfillment.

**Auth-and-capture** — Authorize and capture in one step at checkout. Typical for instant-fulfillment B2C.

**Authorize-only (capture on dispatch)** — Hold funds at checkout but capture only when you ship. Common for delayed fulfillment, pre-orders, and B2B.

**Authorization window** — The time limit an authorization hold stays valid. After it expires you usually must re-authorize or ask the customer to pay again.

**Void / Cancel** — Release an authorized but not yet captured payment so the hold drops off the customer's account. The visible balance may take a few days to update.

**Settlement** — Movement of funds between financial institutions behind the scenes after capture. Merchants rarely see every hop, but it drives when money becomes available.

**Payout** — The batch or transfer from your **PSP** balance to your bank account. Schedule and rules depend on the provider and risk profile.

**Payout batch** — A single bank transfer that groups settled transactions — minus fees, refunds, chargebacks, and reserve movements — since the last payout.

**Refund** — Returning captured funds to the customer. In **Shopware Payments**, refunds tie to orders and return workflows in **administration**.

**Partial refund** — Returning less than the full captured amount. Multiple partial refunds are allowed up to the captured total.

**Transaction** — A single payment event — attempt or success — traceable by ID in **administration** and in **PSP** reports.

**Decline** — An authorization or payment attempt that was rejected. Reasons include insufficient funds, fraud rules, or technical errors.

---

## Industry and Network Roles

**PSP (payment service provider)** — The regulated party that processes payments and moves money toward your payout. In this learning path, **PayPal** is the underlying **PSP** for **Shopware Payments**.

**Standalone PSP** — A payment provider you contract with directly, often via plugin or API. Strong method coverage, but separate onboarding, portals, and accountability from the commerce platform.

**Acquirer** — The merchant-facing side of card processing.

**Issuer** — The customer's bank that issued the card or funding instrument.

**Card scheme** — Networks such as **Visa** or **Mastercard** that set rules and messaging between acquirer and issuer.

**Wallet** — A stored funding and checkout experience — for example **PayPal Wallet**. Can include cards, balance, and linked sources depending on region and account.

---

## Payment Methods and Checkout

**APM (alternative payment method)** — Non-card local or regional methods such as bank redirects and local schemes. Availability depends on country and **PSP** support.

**Local payment methods** — Country- or region-specific options that shoppers often trust more than global defaults alone.

**Bank-based payments** — Methods that pull funds via bank account — redirect, direct debit, real-time bank pay. Refund and dispute behavior differs from cards.

**BNPL / Pay Later** — Buy now, pay later: installment or deferred pay options such as **PayPal Pay Later**. May include messaging on product or cart pages where supported.

**Express Checkout** — Accelerated checkout using a wallet, with fewer steps than full guest checkout. Often configurable per page type in **administration**.

**Vaulting** — Secure storage of payment methods for returning customers. Eligibility and supported methods depend on **PSP** and settings.

**Payment method mix** — The share of volume and count by payment method. Drives fees, support load, dispute patterns, and conversion.

**Conversion (checkout)** — The share of shoppers who complete payment after starting checkout. Often measured by method to judge what to keep or add.

---

## Shopware Payments and the Platform

**Shopware Payments** — Shopware's embedded payment offering for **Shopware 6**, built on **PayPal's** infrastructure and managed from **Shopware administration** alongside orders and operations.

**Embedded / native payments** — Payments built into the commerce platform — configuration, status, and workflows — instead of relying on isolated gateway plugins and separate consoles.

**Integrated (payments)** — A **PSP** connected to Shopware via plugin or API. Still a separate component you coordinate — contrast with embedded **Shopware Payments**.

**PayPal-native** — The **Shopware Payments** path where **PayPal** provides regulated processing, settlement, disputes, and wallet and **BNPL** depth without extra intermediary wallet markups in typical positioning.

**Payment plugin / extension** — A Shopware extension that connects a **PSP** or method. Contrasts with platform-native **Shopware Payments**, which ships with the core product — no separate install for the integration layer.

**Shopware administration** — The back office where merchants configure **Shopware Payments**, orders, and operational workflows.

**First Run Wizard** — Guided initial shop setup in Shopware. **Shopware Payments** onboarding can align with this flow for faster activation.

**Shopware Account** — Identity and commercial relationship with Shopware. Can support pre-onboarding or account-level steps before the shop goes live.

**Pre-onboarding** — Account- or license-level setup steps that can start before the shop goes live, so **Shopware Payments** is closer to operational when the shop is created.

**Sandbox** — A non-live test environment to validate checkout, refunds, and reporting before real traffic. Use with your change-control rules.

**PayPal Web SDK v6** — PayPal's storefront JavaScript integration layer used by **Shopware Payments** to render payment components at checkout.

**Dynamic component loading** — Loading only the payment UI components required for eligible methods in the current session. Improves performance and flexibility versus loading every method up front.

**Sales channel** — A storefront or surface — for example a shop, marketplace connection, or **POS** — that can have its own payment configuration.

**Multi-account configuration** — Connecting multiple **PayPal Business accounts** in Shopware and assigning each to one or more **sales channels**. Used for multi-brand, multi-entity, or regional setups, with separate production and sandbox accounts where needed.

**Order status synchronization** — Automatic alignment between payment state — authorized, captured, refunded — and the **Shopware** order status, so **administration** reflects reality without manual updates.

**CMS blocks (payment)** — Configurable storefront content blocks for payment UX — for example **Express Checkout** and installment messaging — without one-off third-party embeds.

**Return management** — Shopware's returns workflow. With **Shopware Payments**, refunds can tie to returns for traceability in **administration**.

**Rule Builder** — Shopware rules engine for conditions — for example controlling when to show certain payment or financing options.

**Flow Builder** — Shopware automations — triggers and actions — that can include payment-related steps where integrated.

**Transaction history (payment layer)** — Payment records linked to orders — and sometimes broader than a single order — for traceability in **administration**.

---

## Economics and Fees

**Processing fee / transaction fee** — The **PSP** charge per transaction or scheme. Compare rates using the same basis — gross vs. net, included vs. excluded.

**TPV (total payment volume)** — Total payment value processed in a period. Your main input for fee forecasting and **PSP** comparisons. Related to, but not identical to, revenue.

**AOV (average order value)** — Typical basket size. Matters when fees include a fixed per-transaction component.

**Wallet markup / intermediary markup** — Extra fees some platforms charge for accepting a wallet such as **PayPal** through their stack. Distinct from standard **PSP** pricing.

**TCO (total cost of ownership)** — All-in cost of payments: not only fees, but settlement speed, dispute workload, reconciliation time, integrations, and support overhead.

**Transparent / predictable pricing** — Pricing that is easy to forecast as volume grows. Contrast with opaque or punitive models.

**Lock-in / penalties** — Contractual or economic pressure to stay on one **PSP** or platform bundle. **Shopware Payments** is positioned as avoiding penalties for using other providers where applicable.

**Instant settlement** — Faster availability of funds through **PSP** infrastructure. May still be subject to risk, region, and account rules.

**Reserve / rolling reserve** — Funds the **PSP** withholds temporarily from payouts as a buffer against refunds and chargebacks. Common on new or higher-risk accounts.

**FX (foreign exchange)** — Currency conversion when order currency differs from settlement or bank currency. Gains and losses follow the settlement-time rate, not necessarily the checkout rate.

**Gross / net** — Gross is typically before certain deductions; net is after fees or adjustments. Always check definitions in each report.

---

## Risk, Disputes, and Compliance

**Dispute** — A buyer-initiated challenge after payment. Reasons vary: item not received, not as described, and so on. Handled in provider workflows with deadlines.

**Claim** — A structured case inside a **PSP** dispute system. Wording varies by provider.

**Chargeback** — A card-network reversal path. Often stricter evidence rules and scheme timelines than wallet-only disputes.

**Escalation (dispute)** — Moving a case from buyer–seller negotiation to **PayPal** mediation or a bank-led chargeback. Usually stricter deadlines and higher cost.

**Evidence pack** — The documents and short narrative you submit in the **Resolution Center** to defend a case. Matched to the dispute reason and deadline.

**Funds hold (dispute hold)** — During an open dispute, claim, or chargeback, the disputed amount stays in your balance but is not available for payout until the case closes.

**Billing descriptor** — The name on the customer's card or bank statement. Unclear descriptors are a top driver of "I don't recognize this charge" disputes.

**Seller Protection** — **PSP** programs that may cover eligible sales if conditions are met — shipping proof, timelines, and so on. Not automatic for every transaction.

**3D Secure (3DS)** — An extra authentication step for many card payments. Can reduce fraud and shift liability when used correctly.

**Strong customer authentication (SCA)** — Regulatory extra verification for many card payments, often implemented via **3D Secure**. Outcomes are logged with the transaction.

**KYB / KYC** — Know Your Business / Know Your Customer: identity and business verification required before full processing or payout. Handled by the **PSP**.

---

## Reporting and Where to Look

**Reconciliation** — Matching orders, transactions, payout lines, and bank deposits so finance numbers tie out.

**Three-way matching** — Reconciliation discipline that ties orders → **PSP** transactions → payout batches so finance can explain every gap.

**Month-end close** — The finance rhythm of locking a period's numbers — matching orders, transactions, payouts, and bank deposits before reporting.

**PayPal Merchant Dashboard** — **PSP**-side financial detail: payouts, fees, and disputes at account level. Often the system of record for money movement.

**Resolution Center** — **PayPal's** dispute workspace in the **Merchant Dashboard**. Home for disputes, claims, and chargebacks — status, deadlines, and evidence.

**Shopware order / payment views** — Operational truth in **Shopware**: status, refunds, and IDs for support. Not a full accounting ledger by itself.

---

> **How to use this glossary:** You do not need to memorize every term before moving on. Return here when a word in **administration**, the **PayPal Merchant Dashboard**, or a later unit feels ambiguous. The definitions here are the ones used consistently across this entire learning path.

---

With terms aligned, you'll trace money from checkout through authorization, capture, settlement, and payout—and map multi-account setups to your sales channels.
