Stripe-Integration (S7.4): Payment-Dashboard für Stripe

- Provider-Status/Uptime: Stripe-Kachel aktiviert; payment:check-uptime prüft
  zusätzlich api.stripe.com/v1/ (401 ohne Key = erreichbar) inkl. Auto-Incident
- Zahlungen: Anbieter-Filter, Provider-Badges, Umsatz je Provider,
  Stripe-Dashboard-Deep-Links (ShoppingPayment/PaymentTransaction::
  stripeDashboardUrl, pi_-Guard, testmodus-bewusst)
- Rohe Transaktionen: Anbieter-Filter/-Spalte, Erfolgsraten je Anbieter;
  Bugfix: Stringable-Vergleich ließ den txaction-Filter immer mit leerem Wert
  greifen — Liste war dauerhaft leer
- Neue Kachel „Abos je Anbieter" (Index + GF-Ansicht) mit Fehlerzählern und
  Stripe-Anteil-Fortschrittsbalken (Auslaufmodell PAYONE → Stripe ablesbar)
- Incident-Kachel weist Stripe/PAYONE getrennt aus; Log-Viewer mit
  Kanal-Umschalter stripe/payone
- Plan-Doku: S7.4-Umsetzungsstatus, Abo-Go-Live 2026-07-10 vermerkt

Tests: PaymentDashboardProviderTest (9 neu), Dashboard-Suite 49 grün.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

dev/2026-07-08-stripe/ENTWICKLUNGSPLAN-STRIPE.md

@@ -1,6 +1,6 @@
 # Entwicklungsplan: Stripe als Zahlungsanbieter (PAYONE bleibt als Option)
 
-> **Status:** In Arbeit (S0 ✓, S1 ✓, S2 ✓, S3 ✓ — **live in Produktion**; S4 ✓ **E2E komplett** (Abschluss, Cron, Decline→Recovery, authentication_required); S5 ✓ „Zahlungsart ändern" inkl. E2E über CRM + Kunden-Link (nur Portal-Pfad ohne Sichttest, gleicher Code-Pfad); S7.6 ✓ Zahlarten-Kommunikation — **vor Abo-Freigabe:** Deployment + 3 Migrationen, dann `abo-payments-frozen` aufheben, §16) · **Erstellt:** 2026-07-08 · **Zuletzt aktualisiert:** 2026-07-09
+> **Status:** In Arbeit (S0–S5 ✓, S7.4 ✓, S7.6 ✓ — **alles live seit 2026-07-10 inkl. Abos**, Freeze aufgehoben, Vorkasse wieder sichtbar, läuft fehlerfrei; offen: S7.1/S7.2/S7.3/S7.5, S6-Rest, S9 → §16) · **Erstellt:** 2026-07-08 · **Zuletzt aktualisiert:** 2026-07-10
 >
 > **Lage-Update 2026-07-09 (Stakeholder):** Das PAYONE-Konto ist **wieder freigeschaltet**.
 > Daraus ergeben sich folgende verbindliche Entscheidungen (Details §7.2):
@@ -459,8 +459,9 @@ in `StripeCheckoutTest.php`; Karten-Update-Regressionssuite (17 Tests) unveränd
        57831, 57832 — müssen noch storniert/bereinigt werden, Statistik/Provision!).
 8. [x] Checkout geöffnet: Einmalzahlungen laufen seit 2026-07-08 abends für alle über Stripe.
 9. [x] Kontrolle: `storage/logs/stripe.log`, `stripe_webhook_events`, Payment-Dashboard.
-10. [ ] **Nach S4/S5 (JETZT offen, → §16):** Deployment + 3 neue Migrationen, dann
-        `abo-payments-frozen` aufheben und Vorkasse wieder einblenden.
+10. [x] **Nach S4/S5:** Deployment + 3 neue Migrationen, `abo-payments-frozen`
+        aufgehoben, Vorkasse wieder eingeblendet — ✅ **live seit 2026-07-10, läuft
+        fehlerfrei** (→ §16).
 
 ---
 
@@ -713,10 +714,38 @@ Payment-Dashboard kennt Stripe.
 | S7.1 | **Schalter-UI** im Admin (Einstellungen): aktueller Provider, Umschalten mit Bestätigungsdialog + Hinweistext („wirkt nur auf neue Zahlungen"), `SysLog`-Eintrag. Nur berechtigte Admin-Rolle. |
 | S7.2 | **Refunds:** `OrderWithdrawalController` (Widerruf) um automatische Erstattung erweitern — Provider der Ursprungszahlung entscheidet (Stripe: `Refund`-API; PAYONE: bestehender/manueller Weg). Teil-Erstattungen unterstützen. |
 | S7.3 | Admin-Detailansichten (`ShoppingOrder`, `UserAbo`, Zahlungen): Provider-Badge, Stripe-IDs verlinkt zum Stripe-Dashboard (Deep-Link `https://dashboard.stripe.com/...`). |
-| S7.4 | Payment-Dashboard (`/admin/payment-dashboard`) **für Stripe anpassen/optimieren** (Stakeholder 2026-07-09): Kacheln/Listen kennen bisher nur PAYONE — Stripe-Zahlungen korrekt ausweisen (Provider-Filter, Zahlart-Labels, Verlinkung ins Stripe-Dashboard), Umsatz/Fehlerraten je Provider, Übersicht „Abos je Provider" (Auslauf-Fortschritt ablesbar). |
+| S7.4 | Payment-Dashboard (`/admin/payment-dashboard`) **für Stripe anpassen/optimieren** (Stakeholder 2026-07-09): Kacheln/Listen kennen bisher nur PAYONE — Stripe-Zahlungen korrekt ausweisen (Provider-Filter, Zahlart-Labels, Verlinkung ins Stripe-Dashboard), Umsatz/Fehlerraten je Provider, Übersicht „Abos je Provider" (Auslauf-Fortschritt ablesbar). **ERLEDIGT ✅ (2026-07-10), siehe Umsetzungsstatus S7.4 unten.** |
 | S7.5 | Doku: Betriebs-Runbook (Webhook neu ausliefern, Key-Rotation, Testmodus) in diesem Ordner ablegen. |
 | S7.6 | **Zahlarten-Kommunikation** (Stakeholder 2026-07-09): Die über Stripe verfügbaren Zahlarten klar benennen, möglichst mit Logos — (a) im Checkout unter der „Online-Zahlung"-Option, (b) auf den Shop-Seiten, (c) im Footer bei den Zahlungsmöglichkeiten, (d) auf der Seite `/zahlungsarten`. Vorkasse als „Vorkasse (PAYONE)" ausweisen. **ERLEDIGT ✅ (2026-07-09), siehe Umsetzungsstatus unten.** |
 
+### Umsetzungsstatus S7.4 (ERLEDIGT ✅, 2026-07-10)
+
+`/admin/payment-dashboard` kennt jetzt beide Provider (Alt-Zeilen ohne Provider-Wert
+zählen defensiv als PAYONE):
+
+- **Provider-Status/Uptime:** Stripe in `getProviderStats()`/`getUptimeStats()` aktiviert;
+  `payment:check-uptime` prüft zusätzlich `https://api.stripe.com/v1/` (401 ohne Key
+  belegt Erreichbarkeit → kein API-Key nötig) inkl. Auto-Incident/Auto-Resolve wie PAYONE.
+  Incident-Kachel zeigt Stripe+PAYONE getrennt (`stripe_incidents_30d`).
+- **Zahlungen** (`payments`): Anbieter-Filter (Stripe/PAYONE), Provider-Badge statt
+  rohem clearingtype, Umsatz-je-Provider-Kacheln (bezahlt/gesamt + Summe), Deep-Link
+  ins Stripe-Dashboard an Zahlung (external_reference `pi_…`, testmodus-bewusst) und
+  an jeder Stripe-Transaktion (txid). Helper: `ShoppingPayment::stripeDashboardUrl()`,
+  `PaymentTransaction::stripeDashboardUrl()`.
+- **Rohe Transaktionen** (`transactions`): Anbieter-Filter + -Spalte, Karte
+  „Erfolgsraten je Anbieter". **Bugfix nebenbei:** `request()->string()` liefert ein
+  `Stringable` (immer truthy, `!== ''`) → der txaction-Filter griff IMMER mit leerem
+  Wert, die Liste war dauerhaft leer; jetzt `->toString()` wie in `payments()`.
+- **Abos je Anbieter** (Index + GF-Ansicht): neue Kachel mit aktiven Abos je Provider
+  (`scopeActiveAbo`), Fehlerzähler (Status 3) und Fortschrittsbalken „Anteil Stripe" —
+  der Auslauf PAYONE → Stripe (§7.2) ist damit direkt ablesbar. GF-Ansicht zeigt
+  zusätzlich Zahlungsquote je Provider im Anbieter-Status.
+- **Log-Viewer:** Kanal-Umschalter stripe/payone (Default stripe, Whitelist),
+  Tab heißt jetzt „Provider-Logs".
+- **Tests:** `tests/Feature/PaymentDashboard/PaymentDashboardProviderTest.php` (9 Tests:
+  Filter, Stats je Provider, Abo-Auslauf, Deep-Links, Log-Kanäle, Uptime via Http::fake);
+  gesamte Dashboard-Suite (49 Tests) grün.
+
 ### Umsetzungsstatus S7.6 (ERLEDIGT ✅, 2026-07-09)
 
 Kommuniziertes Zahlarten-Set (per API gegen die aktive Stripe `PaymentMethodConfiguration`
@@ -885,14 +914,12 @@ Abo-/Order-Views (Provider-Badge, maskiertes Zahlungsmittel)
    PayPal, PAYONE→Stripe-Umzug), Decline → Status 3, Recovery-Checkout,
    authentication_required. Aufräumen: Test-Abos #440/#442 (Abo 442 steht nach dem
    letzten Test auf Status 3 mit der `…3184`-Testkarte) und Test-Bestellungen bereinigen.
-2. **Deployment + Migrationen** (3 neue: Provider-/Stripe-Abo-Spalten,
-   `widen_clearingtype`), dann im Admin: **`abo-payments-frozen` aufheben** (§7.2),
-   Vorkasse wieder einblenden (`payment-vorkasse-hidden` aus). Ersten 04:00-Cron-Lauf
-   beobachten (holt eingefrorene PAYONE-Abbuchungen nach → großer Lauf!):
-   `abo_order.log`, `stripe.log`, `stripe_webhook_events`, Payment-Dashboard.
-   Der Mischlauf PAYONE+Stripe verifiziert sich dabei. Dazu im **Live**-Stripe-Dashboard
-   das Zahlarten-Set mit dem Testmodus abgleichen (S7.6 kommuniziert u. a. Link, EPS,
-   Bancontact — Test/Live sind getrennt konfiguriert!).
+2. ~~**Deployment + Migrationen + Freeze aufheben**~~ ✅ **LIVE seit 2026-07-10**
+   (Stakeholder): S4/S5/S7.6 deployt, Abo-Freeze aufgehoben, Vorkasse wieder sichtbar —
+   läuft bisher fehlerfrei. **Weiter beobachten:** die ersten 04:00-Cron-Läufe
+   (`abo_order.log`, `stripe.log`, `stripe_webhook_events`, Payment-Dashboard) und im
+   **Live**-Stripe-Dashboard das Zahlarten-Set mit dem Testmodus abgleichen (S7.6
+   kommuniziert u. a. Link, EPS, Bancontact — Test/Live sind getrennt konfiguriert!).
 3. ~~Phase **S5**~~ ✅ umgesetzt + E2E (2026-07-09, Scope erweitert auf „Zahlungsart
    ändern"): CRM-Pfad und Berater-Kunden-Link im Browser verprobt (inkl. PayPal und
    PAYONE→Stripe-Umzug, Abo 440). Nur der **Portal-Pfad** ist ohne Sichttest
@@ -900,5 +927,10 @@ Abo-/Order-Views (Provider-Badge, maskiertes Zahlungsmittel)
 4. ~~**S7.6 Zahlarten-Kommunikation**~~ ✅ umgesetzt (2026-07-09, siehe Umsetzungsstatus
    in §11): Logos + Benennung in Checkout, Footer (alle Shop-Seiten) und `/zahlungsarten`.
    **Offen:** kurzer Sichttest im Browser (Footer, `/zahlungsarten`, Checkout).
-5. **S7.4 Payment-Dashboard** für Stripe anpassen/optimieren (Stakeholder 2026-07-09).
-6. Nachgelagert: **S9 Rückbuchungen & Stornierungen** (§12.1).
+5. ~~**S7.4 Payment-Dashboard**~~ ✅ umgesetzt (2026-07-10, siehe Umsetzungsstatus in
+   §11): Provider-Filter/-Badges, Stripe-Deep-Links, Umsatz-/Erfolgsraten je Provider,
+   Abos-je-Anbieter-Kachel (Auslauf-Fortschritt), Stripe-Uptime-Check, Log-Viewer für
+   stripe/payone. **Offen:** kurzer Sichttest im Browser.
+6. Verbleibend aus S7: S7.1 (SysLog für Schalter), S7.2 (Refunds), S7.3
+   (Admin-Detailansichten mit Provider-Badge/Deep-Links), S7.5 (Betriebs-Runbook).
+7. Nachgelagert: **S9 Rückbuchungen & Stornierungen** (§12.1).