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