--- title: Support Basics for Payment Issues | Shopware Community Hub description: >- Contact Shopware Support first for payment issues, gather the minimum administration and Dashboard data, and use sandbox testing with change control. canonical_url: 'https://hub.shopware.com/learn/unit/support-basics-payment-issues' --- # Support Basics for Payment Issues - **Treat** **Shopware Support** as the first contact for payment issues without pre-sorting Shopware versus **PayPal** ownership yourself. - **Collect** the minimum data set from **administration** and the **Merchant Dashboard** before opening a support ticket. - **Structure** a ticket around one **specific question** so support can route and resolve it faster. - **Use** the **sandbox** account with your change-control rules to validate flows before changing live configuration. # Unit 4: Support and Escalation **Strum & Co.'s** owner hit a problem during their second week live: a customer's payment showed **Authorized** in **Shopware administration** but the customer said their bank had been charged. She was not sure whether to contact Shopware or PayPal — so she spent 45 minutes reading documentation trying to diagnose the stack before reaching out. She did not need to do that. The answer was one ticket to **Shopware Support** with the transaction ID and a one-paragraph description of the issue. This unit is built around one message: **Shopware Support is your first contact for any payment issue.** You do not need to diagnose which system caused the problem before you reach out. --- ## Shopware Support Is Your Entry Point — Always You do not need to determine whether an issue is a **Shopware** problem, a **PayPal** problem, or something else before contacting support. Contact **Shopware**. Shopware handles routing — including escalating to **PayPal** on your behalf when regulated money movement is involved. For small teams without a dedicated payments specialist, this is not just a process note — it is a feature. One entry point, clear ownership, no guessing which vendor to call. --- ## What to Have Ready Before You Open a Ticket A specific ticket gets a specific answer faster than a vague one. Gather these data points before you reach out: | Data point | Where to find it | |-----------|-----------------| | **Transaction ID** | Order in **Shopware administration**; detail lines in **PayPal Merchant Dashboard → Activity** | | **Exact date and timestamp** | Same sources | | **Amount and currency** | Order payment panel; Activity row | | **Current status** | Order payment status in administration; Activity status in Merchant Dashboard | | **Expected vs. actual** | Your own notes — one short paragraph describing what you expected and what you saw instead | | **Error messages or screenshots** | From checkout, administration, or Dashboard — with sensitive payment details redacted | > **For Strum & Co.:** when the authorized-but-charged issue came up, the owner opened the order in **administration**, noted the transaction ID, the timestamp, the amount, and the status shown — then wrote one sentence: "Order shows Authorized but customer reports bank charge. Expected status: Captured or clear decline." That ticket was resolved in one exchange. --- ## Where to Look Before You Contact Support Two quick checks before opening a ticket often resolve the issue: **Order-specific behavior** — refund button missing, wrong status on one order, capture not triggering — start in **Shopware administration** on that specific order. The status and available actions shown there are usually enough to identify whether the issue is a configuration question or a transaction anomaly. **Timing, fees, payout size, dispute deadlines** — open **PayPal Merchant Dashboard → Activity** for transaction detail, and the **Resolution Center** for disputes. The dashboard often explains holds and delays in plain language without requiring a support ticket. If neither check resolves it, contact **Shopware Support** with the data points above. --- ## What Happens After You Contact Shopware Behind the scenes, topics are handled roughly as follows — but you still always start with **Shopware**: **Shopware-led topics:** - Configuration and integration behavior in administration - Sandbox setup and method activation in the shop - How payment status appears on orders - Shopware Payments onboarding questions **PayPal-led topics — typically escalated by Shopware:** - **KYB / KYC** verification and account status - **Payout release** and holds - **Chargeback outcomes** and dispute decisions - **Risk holds** and compliance decisions - Matters resolved in the **Resolution Center** or **PayPal** business programs You do not need to pre-sort your ticket into these categories. Describe the issue clearly — Shopware routes it from there. --- ## Sandbox for Testing **Shopware Payments** is available in sandbox mode in **Shopware administration** before you point a sales channel at live traffic. Use it to validate checkout flows, refund behavior, and reporting paths with your internal change-control rules before going live or enabling new methods on production. --- ## A Note on Response Times Response-time commitments differ by edition and contract. This unit is not an SLA — confirm current support scopes in official **Shopware** documentation or with your account manager before making commitments to your own team about resolution timelines. --- Finance and reporting follows: connecting shop revenue, PayPal transactions, and bank deposits so month-end close becomes a repeatable habit instead of a guessing game.