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
S
Description
No description provided
726 MiB
Languages
JavaScript 77.7%
CSS 13.1%
HTML 9%
Shell 0.2%