Commit Graph
4 Commits
Author SHA1 Message Date
DogFatherGitandClaude Opus 5 d870a9c1d7 PayPal: falsche Angabe zur Webhook-ID berichtigt, Abo-Plan-Weg ergaenzt
Filipe: "webhook id faengt bei mir nicht mit w an und wo finde ich plan
fuer betreung"

Er hat recht, ich hatte unrecht. An der Quelle nachgeprueft:

  Webhook-ID:   0NH55953DH663215D        -- OHNE Vorsilbe, ~17 Zeichen
  Ereignis-ID:  WH-3F562076HD293871E-... -- DIE beginnt mit WH-

Meine Anleitung und der Hinweistext im Formular behaupteten beide
"beginnt mit WH-". Wer sich daran haelt, sucht an der falschen Stelle
oder traegt eine Ereignis-Kennung ein -- und die Signaturpruefung
scheitert dann bei der ersten echten Zahlung, mit einer Meldung, die
nicht auf die Ursache zeigt.

Beide Stellen berichtigt, in der Anleitung mit ausdruecklichem Hinweis,
dass dort vorher etwas Falsches stand. Wer sie schon gelesen hat, soll
den Widerspruch erklaert bekommen und nicht stillschweigend eine andere
Fassung vorfinden.

ABO-PLAN: Der Grund fuer die Frage ist ein echter Stolperstein --
Abo-Plaene werden NICHT im Entwicklerbereich angelegt, sondern im
normalen Geschaeftskonto. Unter developer.paypal.com sucht man vergeblich.

Jetzt mit direkter Adresse (paypal.com/billing/plans), dem Weg ueber das
Menue und dem Schritt, den man am ehesten vergisst: den Plan nach dem
Speichern auch AKTIVIEREN. Ein gespeicherter, aber nicht aktivierter
Plan sieht fertig aus und funktioniert nicht.

Ausserdem klargestellt, dass dieser ganze Schritt entfaellt, wenn kein
monatliches Abo verkauft wird -- Anzahlung und Restbetrag laufen ohne.

Versionsstempel und Cache auf v15.

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-08-23 18:04:55 +02:00
DogFatherGitandClaude Opus 5 497c576d1c Anleitung auf den neuen Weg umgestellt -- ohne Konsole
Die Anleitung war nach dem Einbau des Formulars veraltet und haette
Filipe weiter in die Konsole geschickt.

Schritt 0 (nachsehen, was schon da ist) ging ueber SSH und grep. Das
zeigt jetzt die Verwaltung selbst an: "hinterlegt (auf dem Server)",
"hinterlegt" oder "fehlt". Kein Terminal noetig, um zu erfahren, was
noch fehlt.

Schritt 6 war "nano .env + systemctl restart". Jetzt: Verwaltung ->
Zahlungen -> Felder ausfuellen -> Speichern. Mit dem Hinweis, dass ein
leeres Feld "nicht anfassen" bedeutet und nicht "loeschen" -- ohne den
traut sich niemand, ein einzelnes Feld nachzutragen.

Schritt 7 ist neu: der Knopf "Verbindung testen" mit einer Tabelle, was
die drei moeglichen Meldungen bedeuten.

Beim Umstellen ist mir Schritt 8 (der 1-Euro-Test) aus der Datei
gefallen -- der Ersetzungsbereich reichte zu weit. Wieder eingesetzt und
gleich vervollstaendigt: jetzt mit Testkunde anlegen, Einladungslink im
eigenen Browser oeffnen und Aufraeumen danach. Vorher stand dort nur
"Zahlung erzeugen und bezahlen", was den halben Weg ausliess.

Auch die Formulierung "Beide brauche ICH" korrigiert -- ich brauche die
Werte gar nicht, er traegt sie selbst ein.

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-08-23 16:53:52 +02:00
DogFatherGit 244b275dce PayPal-Anleitung: zuerst pruefen, was schon da ist
Client ID und Secret teilt sich der Webdesign-Bereich mit dem
DogiCrew-Supporter-Abo -- laeuft das live, sind zwei der vier Werte
schon eingetragen und es fehlt nur die Webhook-Kennung.

Neuer Schritt 0 mit Befehlen, die nur ANZEIGEN, ob ein Wert gesetzt ist,
ohne ihn auszugeben. Verhindert ausserdem, dass eine zweite App fuer
dasselbe Konto entsteht: Das funktioniert zwar, macht aber jede spaetere
Fehlersuche doppelt muehsam, und beim Erneuern eines Secrets braeche
womoeglich der andere Bereich weg.
2026-08-23 16:33:32 +02:00
DogFatherGitandClaude Opus 5 321e378f9b Zahlungen: Routen, Zustimmung nach § 356 Abs. 4 und Einrichtungsanleitung
Das PayPal-Modul und die Tabellen standen seit dem 22.08.2026 -- es
fehlten die Wege dorthin. Jetzt vollstaendig.

DREI DINGE, DIE HIER ANDERS SIND ALS BEI EINEM UEBLICHEN BEZAHLKNOPF

1. DIE ZUSTIMMUNG IST TEIL DER ZAHLUNG, kein Haekchen daneben.

   Die 30-%-Anzahlung wird faellig, BEVOR die Widerrufsfrist ablaeuft.
   Damit trotzdem sofort begonnen werden darf, verlangt § 356 Abs. 4 BGB
   die ausdrueckliche Zustimmung UND die Bestaetigung, dass der
   Verbraucher dadurch sein Widerrufsrecht verliert. Die Beweislast fuer
   beides liegt beim Unternehmer.

   Gespeichert wird deshalb nicht "hat zugestimmt", sondern der
   WORTLAUT, den der Kunde gesehen hat, samt Fassung und Zeitstempel.
   Im Streit zaehlt nicht DASS, sondern WOZU jemand zugestimmt hat --
   und Texte aendern sich ueber die Jahre.

   Der Wortlaut steht auf dem SERVER, nicht im Browser: Was als Nachweis
   gespeichert wird, muss das sein, was der Server kennt, sonst koennte
   man ihm einen beliebigen Text unterschieben.

   Geschaeftskunden werden gar nicht erst gefragt. Ein Unternehmer hat
   kein Widerrufsrecht; ihn eine Verzichtserklaerung unterschreiben zu
   lassen waere sinnlos und wuerde nur Misstrauen wecken.

2. NICHT EINGERICHTET IST EIN ZUSTAND, KEIN FEHLER.

   Ohne Zugangsdaten sagt die Seite das freundlich und nennt den Weg
   ueber das Postfach. Ein Knopf, der eine technische Fehlermeldung
   wirft, sieht nach einer kaputten Seite aus -- und niemand bezahlt gern
   auf einer kaputten Seite.

3. DER WEBHOOK IST DIE WAHRHEIT, nicht die Rueckkehr des Browsers.

   Der Kunde kann das Fenster schliessen, bevor er zurueckgeleitet wird.
   Die Zahlung ist dann trotzdem erfolgt. Beide Wege schreiben ueber
   DIESELBE Funktion -- zwei getrennte Fassungen wuerden frueher oder
   spaeter auseinanderlaufen und unterschiedliche Felder setzen.

   Doppelte Zustellung ist bei PayPal normal. Die Merkliste verhindert
   die Doppelverbuchung, und "verarbeitet" wird erst NACH der Auswertung
   gesetzt: Bricht der Server dazwischen ab, steht die Meldung als
   empfangen-aber-offen da und faellt auf, statt spurlos als "schon
   behandelt" zu gelten.

Ohne gueltige Signatur wird nichts verarbeitet -- sonst koennte jeder
eine Zahlung als bezahlt melden.

GEPRUEFT: 26 Pruefungen auf dem Server, alle bestanden. Bewusst OHNE
PayPal-Zugangsdaten, weil genau das der heutige Zustand ist. Geprueft
wird vor allem, was NICHT passieren darf: kein Bezahlvorgang ohne
Zustimmung, keine Zustimmungsfrage an Geschaeftskunden, keine fremde
Zahlung sichtbar, keine Doppelverbuchung, kein Geldfluss ohne
Zugangsdaten -- und dass ein gescheiterter Versuch die Zahlung
unangetastet auf "offen" laesst.

ANLEITUNG: PAYPAL-EINRICHTEN.md, Schritt fuer Schritt mit den genauen
Klicks. Sie nennt ausdruecklich die drei Fallen, die man sonst erst
spaeter merkt: der Sandbox-Schalter (Zugangsdaten ohne echtes Geld),
"Select all" bei den Webhook-Ereignissen (erzeugt Rauschen, in dem echte
Probleme untergehen) und Client-ID und Secret aus verschiedenen Apps.

Das Secret gehoert nach Bitwarden -- die Anleitung sagt das an drei
Stellen und bietet an, dass Filipe es selbst eintraegt, ohne es mir zu
zeigen.

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-08-23 16:24:51 +02:00