Beiträge von Wolfgang Vogel

Danke, Hille! Ja, aktuell funktioniert alles wieder. Ich wollte dennoch gerne den Grund dafür rausfinden. Den habe ich nach zwei Nachtschichten nun eventuell gefunden:

Ich habe nämlich festgestellt, dass trotz des inzwischen verifizierten Bankkontos bei PayPal die IPN (Sofortige Zahlungsbestätigung) und auch die Rückerstattung wegen nicht übertragener Transaktions-IDs nicht funktioniert. Nach einer Recherche und dank eines Forenentrags in eigentlich ganz anderer Sache, habe ich dafür die Ursache gefunden: Schuld war mal wieder eine Besonderheit von STRATO! Deren Option „Filter gegen Gästebuch-Spam“ hat offenbar zu einer Kommunikationsstörung zwischen PayPal und WooCommerce geführt, so dass keine IPNs ankamen. Die Option lässt sich bei STRATO unter „Sicherheit“ > „ServerSide Security“ deaktivieren. Und plötzlich funktionieren die IPNs und auch die Rückerstattung direkt aus WooCommerce.

Vielleicht lag hierin auch der Grund für das "Aufhängen" von meines Shops auf der Seite "Kasse"?

mensmaximus: Ich würde deine Theorie mit den Ajax Calls dennoch auch gerne weiterverfolgen. Meinst Du es könnte auch an der oben beschriebenen Problematik liegen: "Ich habe bei den PayPal-Einstellungen aktiviert "Lieferadresse an PayPal senden anstatt Rechnungsadresse", damit PayPal mir immer die Lieferadresse als Verkäuferschutzadresse anzeigt. Könnte das auf der Kasse-Seite einen Konflikt mit der Option "Rechnungsadresse als Standardwert" hervorrufen?"

An den Versandklassen/Versandkosten habe ich seit Monaten nichts mehr geändert. Zudem werden diese ja noch auf der Seite "Warenkorb" (http://wv-konzerte.de/tickets/warenkorb/) ausgewählt. Das Problem tauchte aber immer auf der Seite "Kasse" auf (http://wv-konzerte.de/tickets/kasse/), dort steht die Versandklasse ja schon fest und es wird nur noch die Zahlungsart abgefragt. Das Problem tauchte immer EXAKT in dem Moment wenn der Kunde in das letzte noch nicht ausgefüllte Pflichtfeld den ersten Buchstaben eingetragen hat. In diesem Moment führt WooCommerce offenbar eine solche Abfrage (Ajax Call?) aus, denn es läuft dann kurz die "Eieruhr" (bzw. in meinem Theme dreht sich ein Rädchen und die Zahlungsarten werden kurz ausgegraut). Genau in diesem Moment hängte sich die Seite auf!

Irgendeine Idee, woran es noch liegen könnte? Welche Regeln könnten sich auf der Seite "Kasse" in die Quere kommen?

Die einzigen Änderung die ich in den letzten Tagen vorgenommen habe, waren
1. PayPal von Sanbox auf Live-Betrieb umgestellt (d.h. die PayPal E-Mail-Adresse von meiner Sandbox-Mailadresse auf meine reale PayPal-Mailadresse umgestellt und die API Zugangsdaten von den Sandbox-Werten auf die realen Wert umgestellt)
2. Unter den Wordpress Einstellungen --> Allgemein als Sprache auf "Deutsch (Sie)" umgestellt und mittels des Plugins "Language Fallback" (Version 1.0.3) als Ersatzsprache / Fallback-Sprache "Deutsch" ausgewählt
3. Bei den Versand-Einstellungen unter Versandziel "Rechnungsadresse als Standardwert" statt "Lieferadresse als Standardwert" eingestellt, damit für den Kunden auf das Kasse-Seite die Felder für eine abweichende Lieferadresse standardmäßig zugeklappt sind und erst bei einem Häkchen hinter "Lieferung an eine andere Adresse senden" aufgeklappt werden.

Da fällt mir gerade auf: Ich habe bei den PayPal-Einstellungen aktiviert "Lieferadresse an PayPal senden anstatt Rechnungsadresse", damit PayPal mir immer die Lieferadresse als Verkäuferschutzadresse anzeigt. Könnte das auf der Kasse-Seite einen Konflikt mit der Option "Rechnungsadresse als Standardwert" hervorrufen?

mensmaximus: Danke für deine Testbestellung. Ist angekommen.

Plötzlich scheint es wieder zu funktionieren. Auch alle meine Testbestellungen von eben! Ich habe jetzt vorsichtig PayPal auch wieder aktiviert und werde es weiter beobachten.

Kann es sein, dass das Problem mit den PayPal API Zugangsdaten zusammenhängt? Denn ich habe mein Bankkonto bei bei PayPal noch nicht verifiziert. Und PayPal schreibt (Quelle: https://www.paypal.com/de/cgi-bin/web…pn-test-outside) dass die sofortige Zahlungsbestätigung nur funktioniert, wenn das Bankkonto verifiziert ist. u.U. kommt es durch die Eingabe der API Zugangsdaten (bevor das Bankokonto verifiziert ist) zu einer dauerhaften unvollständigen Kommunikation zwischen PayPal und WooCommerce?

Auch wenn es jetzt wieder zu funktionieren scheint, würde ich das Problem gerne verstehe, um beim nächsten Auftreten Abhilfe schaffen zu können.

Ja, Cache wurde gelöscht. Das Problem tritt auch auf mehreren Rechnern und in mehreren Browsern auf. Funktioniert es bei Dir?

Liebes Forum, ich bitte Euch um Eure Hilfe!

Ich habe einen Shop mit folgenden Komponenten aufgesetzt:
WordPress Version 4.4.1
Theme Zerif Lite Version 1.8.3.1
Plugin WooCommerce Germanized Version Version 1.5.1

Hier der Link zur Webseite:
http://wv-konzerte.de/tickets/shop/

Im 3 monatigen Testbetrieb lief der Shop einwandfrei. Gestern habe ich das PayPal-Modul vom Sandbox-Testbetrieb auf den Live-Betrieb umgestellt. Selbst danach funktionierte gestern abend meine Testbestellung noch einwandfrei.

Jetzt habe ich folgendes Problem: Der Bestelllprozess hängt sich auf im Checkout / Kasse auf, sobald man das letzte Pflichtfeld ausgefüllt hat. Dann dreht sich das Rädchen und hört nicht wieder auf….

Ich habe schon alles mögliche ausprobiert (auch PayPal wieder in den Sanbox-Betrieb zurückgestellt oder komplett deaktivier) – alles erfolglos.

Das Fatale: Der Vorverkauf und alle Werbemaßnahmen beginnt heute! Ich bin etwas verzweifelt…

Welche Ideen / Vorschläge habt Ihr?

Wenn ihr wollt, macht gerne mal eine Testbestellung (als Max Mustermann o.ä.) – diese werden ich natürlich anschließend wieder löschen

Ich hoffe sehr auf Eure Hilfe!

Beste Grüße aus Mainz
Wolfgang