Kann man unter 5.5.4 jetzt eigentlich das Update von 8.2.3 auf 8.2.4 installieren, oder funktioniert dann wieder nix?
Ich habe keine Probleme - aber wenn Du kannst, warte noch mal die Woche. Ich hab mitbekommen, dass die 8.2.5 gerade bei den Beta-Testern ist und auch in Kürze freigegeben wird. Ansonsten läuft das Plugin wieder stabil.
1 „Gefällt mir“
Hi zusammen,
ich habe hier ein ganz komisches Phänomen.
Wenn die Amazonemail nicht der Shopmail entspricht, dann legt das Plugin immer ein neues Kundenkonto an. Der Kunde ist eingeloggt und führt die Zahlung ganz normal per Checkout über Amazon aus.
Früher -meine ich mich zu erinnern- gab es da eine Einstellung wo man dies festlegen konnte, also ob es dem Kundenkonto zugeordnet werden soll oder eine Neues angelegt werden soll, aber irgendwie sehe ich den Wald vor lauter Bäumen nicht 
Kennt das Problem jemand ?
Du meinst bestimmt den Gast Checkout.
Das Amazon Plugin identifiziert über die eMail Adresse und ja - es ist doof, wenn unterschiedliche eMails verwendet werden
Dadurch wird dann ein neuer Kundenaccount als “Shopware Account” (nicht Gast) angelegt und der vorherige Kunde landet als “Abbrecher” in der Datenbank.
Mein letzter Infostand dazu ist das sich dies nicht mal “eben” so einfach ändern lässt, da die eMail der identifyer ist.
Du meinst bestimmt den Gast Checkout.
Hi,
nein, ich meine einen regulären Checkout mit vorhandenem Kundenkonto. Gastkonten und Expresscheckout habe ich deaktiviert.
Das Plugin legt trotzdem immer einen neuen Kunden an sobald die Amazonemail != Shopemail ist.
Komisch…
Is this plugin working with 5.5.4 version or is still broken ?
For me it is not working in Finish…
{
“exception”: “[object] (OffAmazonPaymentsService_Exception(code: 0): The OrderReferenceId is invalid. at /engine/Shopware/Plugins/Community/Frontend/BestitAmazonPay/Components/OffAmazonPaymentsService/Client.php:742)”
}
UPDATE: Aktuell haben wir festgestellt, dass die IPN ggfls. diesen Eintrag im Log hinterlässt:
„message“: „Error with message - header does not contain x-amz-sns-message-type header“
Die Ursache ist im Moment noch nicht klar ermittelt, aber wir haben inzwischen eine Empfehlung, wie der Statuswechsel weiterhin funktioniert.
Setzen Sie im Plugin die Option der IPN von aktiviert auf deaktiviert. Damit übernimmt der Cronjob diese Funktion!Der Cronjob muss natürlich dafür laufen.
Unter https://bestit.atlassian.net/wiki/spaces/SKB/pages/655982619/Exception+mit+SnsMessageParser.php steht woran es liegen kann, bei mir lag es an PHP 7.2 mit PHP 7.0 funktioniert es.
UPDATE: Aktuell haben wir festgestellt, dass die IPN ggfls. diesen Eintrag im Log hinterlässt:
„message“: „Error with message - header does not contain x-amz-sns-message-type header“
Die Ursache ist im Moment noch nicht klar ermittelt, aber wir haben inzwischen eine Empfehlung, wie der Statuswechsel weiterhin funktioniert.
Setzen Sie im Plugin die Option der IPN von aktiviert auf deaktiviert. Damit übernimmt der Cronjob diese Funktion!Der Cronjob muss natürlich dafür laufen.
Unter https://bestit.atlassian.net/wiki/spaces/SKB/pages/655982619/Exception+mit+SnsMessageParser.php steht woran es liegen kann, bei mir lag es an PHP 7.2 mit PHP 7.0 funktioniert es.
Da hast Du aber Glück…
Das weiss jeder, der deswegen mit dem Support zu tun hatte; Lösung ist das leider auch keine; und offensichtlich auch keine in Sicht (Fehler immer noch vorhanden trotz letztem Update)
…und ich wollte letztes Wochenende auf 7.2 umstellen, zum Glück hatte ich dann doch keine Zeit 
Der Fehler tritt nicht nur bei 7.2 auf…die meisten merken es erst, wenn sie in Ihren log schauen…
Der Fehler tritt nicht nur bei 7.2 auf…die meisten merken es erst, wenn sie in Ihren log schauen…
Ich habs über Twitter erfahren: https://twitter.com/bestitcon/status/1075692283356373000 - bei mir ist es php 7.3.1
Das weiss jeder, der deswegen mit dem Support zu tun hatte; Lösung ist das leider auch keine; und offensichtlich auch keine in Sicht (Fehler immer noch vorhanden trotz letztem Update)
Ich hab die Info, dass die IPN Geschichte komplett umgebaut werden muss, weil Amazon ein neues Feature möchte. Die IPN soll demnächst direkt eine Rolle spielen, wenn der Käufer noch im Shop ist. Bei einem Ausfall wird er sofort abgefangen und bekommt gar nicht erst die „finish“ Seite - bevor er „finish“ ist.
Is this plugin working with 5.5.4 version or is still broken ?
For me it is not working in Finish…
{
„exception“: „[object] (OffAmazonPaymentsService_Exception(code: 0): The OrderReferenceId is invalid. at /engine/Shopware/Plugins/Community/Frontend/BestitAmazonPay/Components/OffAmazonPaymentsService/Client.php:742)“
}
It seems not to be the plugin. See your error: The OrderReferenceId is invalid
It’s just in german but the faq got an article abot this: Jira Service Management
Basicly it depends on you theme. Try what happens if you use the shopware standard responsive theme.
See the announced article on this site: Jira Service Management
Hallo Community,
auch wir dürfen uns nun mit diversen Fehlern vom Plugin rumschlagen.
Shop 1 (Shopware 5.5.6, AmazonPay 8.2.5)
Unser erster Shop läuft mit PHP 7.2, demnach funktioniert IPN nicht. Erstmal halb so wild, würde wenigstens der Cronjob funktionieren, aber das tut er nicht. Im Log sehe ich zwar, dass der Cronjob diverse Dinge tut, letztendlich aber sich der Status der Bestellung und Zahlung nicht ändert. Ich lese aus dem Log des Cronjobs, dass zwar Status-Änderungen angedacht sind, jedoch nicht ausgeführt werden.
Start of Cron
(…)
[2019-02-05 10:56:04] amazon.INFO: Bestellstatus: 4
[2019-02-05 10:56:04] amazon.INFO: Authorisation of authorized orders
[2019-02-05 10:56:04] amazon.INFO: Amazon-Status: AuthorizeNew
[2019-02-05 10:56:04] amazon.INFO: Bestellstatus: 36
[2019-02-05 10:56:04] amazon.INFO: Authorisation Request
[2019-02-05 10:56:04] amazon.INFO: Amazon-Status: Authorise
[2019-02-05 10:56:04] amazon.INFO: Zahlstatus: 37
[2019-02-05 10:56:04] amazon.INFO: Bestellstatus: 38
[2019-02-05 10:56:04] amazon.INFO: Found 3 orders
[2019-02-05 10:56:04] amazon.INFO: 20XX6: PXX-XXXX784-XXXX698
[2019-02-05 10:56:04] amazon.INFO: 20XXX: PXX-XXXX233-XXXX630
[2019-02-05 10:56:04] amazon.INFO: 20XX8: PXX-XXXX896-XXXX934
[2019-02-05 10:56:04] amazon.INFO: Authorization Response
[2019-02-05 10:56:04] amazon.DEBUG: Shopware_Plugins_Frontend_BestitAmazonPay_Classes_AmazonPay::getAuthorizationStatus called
[2019-02-05 10:56:04] amazon.INFO: Amazon-Status: AuthoriseDone
[2019-02-05 10:56:04] amazon.INFO: Zahlstatus: 38
[2019-02-05 10:56:04] amazon.INFO: Bestellstatus: 38
[2019-02-05 10:56:04] amazon.DEBUG: Orders fetched
[2019-02-05 10:56:04] amazon.INFO: Capture Request
[2019-02-05 10:56:04] amazon.INFO: Amazon-Status: Capture
[2019-02-05 10:56:04] amazon.INFO: Zahlstatus: 5
[2019-02-05 10:56:04] amazon.INFO: Bestellstatus: 7
[2019-02-05 10:56:04] amazon.INFO: Capture Response
[2019-02-05 10:56:04] amazon.INFO: Amazon-Status: CaptureDone
[2019-02-05 10:56:04] amazon.INFO: Zahlstatus: 7
[2019-02-05 10:56:04] amazon.INFO: Bestellstatus: 7
(…)
End of Cron
Shop 2 (Shopware 5.5.3, AmazonPay 8.2.5)
Unser zweiter Shop läuft immerhin unter PHP 7.0, bedeutet wir haben IPN aktiviert. Jedoch hier das selbe Problem. Die Bestellung erhält initial den zugeordneten Status einer „autorisierbaren“ Bestellung. Die Bestellungen werden durch die Konfig „immer“ direkt autorisiert, auch das funktioniert soweit. Im Debug-Tool von BestIT (www.domain.de/backend/AmazonPay/cron) werden die Bestellungen auch als „autorisierst“ gelistet. Die Statusänderung auf „autorisiert“ bzw „nach erfolgreicher Auszahlung“ durch IPN (oder Cronjob) bleibt jedoch aus. Capture now wurde aktiv wie auch deaktiviert mit manuellem Einzug getestet, selbes verhalten.
Es wurden bereits zich Kombinationen aus Konfigurationen ausprobiert. Keine davon hatte den Status bisher geändert.
Hilfe 
Grüße
Hallo,
wir haben hier das Problem, dass wenn der Kunde AmazonPay auswählt, er sich durchklicken kann bis zum letzten Bestellschritt.
Klickt er dann Zahlungspflichtig bestellen, so lädt die Seite kurz und es passiert nichts, ein Bestellabschluss nicht möglich!
Plugin neuinstalliert haben wir schon, hat aber auch nicht funktioniert.
Hallo,
wir haben hier das Problem, dass wenn der Kunde AmazonPay auswählt, er sich durchklicken kann bis zum letzten Bestellschritt.
Klickt er dann Zahlungspflichtig bestellen, so lädt die Seite kurz und es passiert nichts, ein Bestellabschluss nicht möglich!
Plugin neuinstalliert haben wir schon, hat aber auch nicht funktioniert.
Mit der aktuellen Pluginversion funktioniert es unter Umständen nur mit 2 existierenden Versandarten pro Lieferland. Zum Testen kann man die Versandart kopieren und umbenennen. Es gibt wohl noch einen Fix, der noch nicht im Store steht. Am besten mal beim bestIT-Support nachfragen
Bei uns wird immer Versandart “0” angegeben, obwohl die Versandkosten korrekt berechnet werden.
Unschön immer nachträglich die Versandart zu korrigieren.
Ansonsten funktioniert alles gut.
Bei uns wird immer Versandart „0“ angegeben, obwohl die Versandkosten korrekt berechnet werden.
Unschön immer nachträglich die Versandart zu korrigieren.
Ansonsten funktioniert alles gut.
Auch das Problem haben wir und wurde durch eine neuinstallation ausgelöst.
Auch das Problem haben wir und wurde durch eine neuinstallation ausgelöst.
Das heißt das Problem wurde mit einer Neuinstallation gelöst oder dadurch verursacht?
Hallo Zusammen,
wir bevorzugen zwar aus unserem Ticket-System heraus zu helfen, haben aber auch das Forum gelegentlich in Sichtweite. Wir hoffen das euch folgende Hinweise unterstützen können:
Problem: Nach Bestellabschluss wird man wieder in den Checkout geleitet ODER Versand = 0 ist in der Bestellung eingetragen
Ursache: In dem Subscriber/CheckoutSubscriber.php haben wir bislang ein Array der Versandarten erwartet, bei dem das Array [0] ein Value bietet. Dies ist jedoch unter umständen je nach Shop und Historie nicht gewährleistet.
Lösung: Es gibt eine Anpassung der betroffenen Zeile. Im Store war nach Veröffentlichung diese alte Codezeile für ca. 1.5 Tage online, bis wir von den ersten zwei Shopbetreibern gleichlautene Fehlermeldungen erhalten haben. Bereits 1h später wurde der Source Code korrigiert im ZIP ausgeliefert. Man kan im Shopware Account die ZIP Datei einach noch mal herunterladen und im Backend hochladen. Alternativ ist dies die Zeile die ausgetauscht werden muss:
bestitamazonpay/src/.../Subscriber/CheckoutSubscriber.php - Zeile ~209:
vorher: $dispatch = $dispatches[0];
danach: $dispatch = array_shift($dispatches);
----
Das php 7.x Problem:
Unter https://bestit.atlassian.net/wiki/spaces/SKB/pages/655982619/Exception+mit+SnsMessageParser.php steht woran es liegen kann, bei mir lag es an PHP 7.2 mit PHP 7.0 funktioniert es.
Wir haben keine Freigabe für das Plugin unter php 7.1 oder höher veröffentlicht. Das die Hoster hier so zeitnah ein Update durchführen ist zwar nachvollziehbar, aber sprengt derzeit unsere Roadmap. Daher haben wir hier zunächst ein Workaround veröffentlicht, der hier bereits gefunden/kommuniziert wurde. Dies ist also kein „Beinbruch“, sondern der Komfort des Plugins ist derzeit in dieser Frage eingeschränkt. Abhilfe wird die Version 8.2.6 bringen die wir heute aus er internen QA zurück bekommen haben.
Wir haben haben hier im Verlauf (oder war es ein weiterer Threat?) mitbekommen, dass eine Aussage unseres Supports Zitiert und anschließend bezweifelt wurde. Es geht um die QA und damit um die BETA Tester. Das möchten wir hier noch einmal erklären.
Seit dem wir mit der Version 8.2.x bekannter Weise ein Qualitätsproblem hatten, haben wir Maßnahmen ergriffen um die Fehlerquote möglichst einzudämmen. Seit dem gehen wir wie folgt vor. Wenn uns Shopbetreiber einen BUG Melden und dieser auch als solcher Identifiziert wird, fragen wir den Kunden ob er speziell diesen Bug, in der kommenden Lösungsversion vorab als PreRelease haben möchte. Er ist also potentieller Beta Tester, dessen LIVE Shop das Problem vorher hatte. Wir reden also nicht von fiktiven Beta Testern. Bevor wir die PreRelease an die Beta Tester ausgeben, haben wir unsere eigene DEMO Shop Umgebung, die in der Regel frisch aufgesetzt wird. Hier haben wir ein Deployment und automatisierte Tests, die einen Matrix Test machen. Das bedeutet, dass hier Legacy, -1 und aktuelle Versionen getestet werden. Im Moment sind das für uns SW 5.3.5, 5.4.0, 5.5.0 und 5.5.6. Dies erfolgt nach unserem Code Standard (Basis derzeit php 7.0). Wenn wir diese Tests und die einzelnen Tickets persönlich in dieser Umgebung abgenommen haben, liefern wir die ZIP Datei an einen externen Dienstleister aus. Hier wird zwar auch in „klinischen“ Umgebungen getestet - dafür aber händisch, durch Dritte, die der Entwicklung selbst fern sind. Wenn hier auch ein positives Feedback zurück kommt, erfolgt die Freigabe für das PreRelease.
Wir können jeden Shopbetreiber das PreRelease anbieten. Es handelt sich in diesem Moment um die ZIP Datei, die theoretisch in den Store gehen würde, es sei denn der LIVE Test beim PreRelease hätte entsprechend negative Auswirkungen wir haben in den letzten 2 Releases 3 bzw. 5 Release Tester gehabt. Bei den 8.2.5 Testern gab es keinen Hinweis darauf, dass die Versandart als NULL Objekt übergeben wurde. Also auch hier gibt es niemals eine perfekte Version. Dafür sind die Möglichkeiten die uns Shopware an Optionen und die Shopbetreiber uns an Konfigurations-Historie bietet einfach zu breit aufgestellt.
Deshalb bitten wir euch alle - Meldet fehler!
Was gar nicht in Ordnung ist - das ist eine eigenständige „Korrektur“ des Codes.
Im Beispiel [hier] wurde eine Funktion wieder eingebaut - „weil es damit funktioinert“. Dass wir hier aber refaktorisiert haben und dies einem bestimmten Grund hat, wird außeracht gelassen. Fakt ist, dass wir künftig erst mal prüfen müssen ob unserer Source Code verändert wurde - um hier einen Fehler aufgrund unbedachten Eingriffs auszuschließen. Dies ist derzeit ebenfalls in der Entwicklung. Seit dem das Plugin offen zur Verfügung steht müssen wir hier den Eingriff Dritter nicht zur unserer Haftung übernehmen. Was uns jedoch viel mehr freut ist eine konkrete Fehlermeldung oder gar Verbesserungsvorschläge die wir gerne validieren und aufnehmen.
Wer hilfe benötigt - bekommt Hilfe | eMail an: support@bestit-online.de
Folgt uns gerne auch auf twitter @bestitcon
Mit _best_en Grüßen aus dem Münsterland
Euer best it Support 
2 „Gefällt mir“
Deshalb bitten wir euch alle - Meldet fehler!
Was gar nicht in Ordnung ist - das ist eine eigenständige „Korrektur“ des Codes.
Im Beispiel [hier] wurde eine Funktion wieder eingebaut - „weil es damit funktioinert“. Dass wir hier aber refaktorisiert haben und dies einem bestimmten Grund hat, wird außeracht gelassen.
Nochmal: Ich habe an niemanden (außer an Amazon) eine korrigierte Version mit meinen Änderungsvorschlägen weitergegeben. Ansonsten dürfen Sie es gerne mir überlassen, welche Änderungen ich an einem auf unserem Server installierten Plug-In vornehme, damit das von Ihnen veröffentlichte Plug-In wieder funktioniert. Es hat Sie sicher auch niemand daran gehindert, sich selbst um die Sache zu kümmern, anstatt so lange zu warten bis Ihnen die Sache um die Ohren fliegt.
Bereits 1h später wurde der Source Code korrigiert im ZIP ausgeliefert. Man kan im Shopware Account die ZIP Datei einach noch mal herunterladen und im Backend hochladen.
Warum ändert man eigentlich „hintenrum“ Code in einem bestehenden Release, anstatt korrekterweise eine neue Version zu veröffentlichen?