In der Version 6.0.1 funktioniert das Amazon pay (3.0.2) ganz gut.
Momentan testen wir oxid 6.1.0 (Amazon pay 3.1.4) und stellen fest, dass beim rendern die js-Ressourcen (bestitamazonpay4oxid.js) nicht am Ende der Seite (also nach jquery) sondern direkt an der Stelle eingebunden werden. Das führt zu einigen undefines und das macht das Modul unbrauchbar.
Falls es jemand schon in 6.1.0 doch funktionsfähig hat, bitte melden.
Hatte ich auch. In bestitamazonpay4oxid_paybutton.tpl in Zeile 6 steht:
[{capture name="sBestitAmazonScript"}]
Aber dann in Zeile 28 steht:
[{oxscript add=$smarty.capture.sBestitAmazonLoginScript}]
da muss auch sBestitAmazonScript stehen. In neueren Versionen ist das schon behoben glaub ich.
Oh ja, das ist es tatsächlich. Vielen Dank.
Behoben ist es wohl noch nicht, da ich gerade gestern die 6.1.0 bezogen habe, aber es kommt bestimmt bald.
Genial, danke für die Info! Ich dachte schon, ich bin zu blöd, eine aktuelle Modul-Version zu finden, die fehlerfrei läuft. Die tpl-Datei hatte ich auch schon am Wickel, war aber zu blind, diesen simplen Fehler zu sehen. Der ist übrigens auch noch in der gestrigen Version 3.2.1 zu finden, ominös.
So weit so gut, aber kann es sein, dass alle Versionen > 2.5.1 oder so nicht mehr kompatibel zu OXID 4.10.x sind? Ich steige da nämlich nicht durch, denn im eXchange steht bei v2.6.3 doch “PE 4.7.x/5.0.x - 5.3.x” und PE 5.3 ist doch quasi gleich CE 4.10, oder nicht (mehr)? Etwas verwirrend das Ganze, zumal alle neuere Versionen > 2.6.3 eh nur noch bei Github zu finden sind. Aber egal, zunächst nur die Frage, welche Version nun die offiziell aktuellste für OXID 4.10.8 ist, und ob die bekanntermaßen (aus Erfahrung) auch fehlerfrei läuft? Stichwort Payment-Seite:
PHP Strict Standards: Declaration of bestitAmazonPay4OXID_oxOrder::finalizeOrder() should be compatible with oxorder::finalizeOrder(oxBasket $oxBasket, $oxUser, $blRecalculatingOrder = false)
Das könnte man zwar recht einfach fixen, aber ich habe Zweifel, ob das dann schon reicht? Weitere Vorkommen von “(Basket $” habe ich zumindest nicht gefunden …
PS: Mist, selbst man dies anpasst, kommt statt der Bestellübersicht ein Rücksprung zum Warenkorb mit der Meldung “Die gewählte Zahlart wird nicht unterstützt. Bitte wählen Sie eine andere Zahlart.” Ich komme einfch nicht weiter, irgendwas hakt da immer.
Hm, ich glaube, ich habe es verstanden:
Es gibt für diese Problematik ja extra eine Versionsweiche am Ende der metadata, um auf OXID 4/5 Rücksicht zu nehmen, nur funktionierte die hier scheinbar nicht. Mein Verdacht ist, dass ich vorher die v2.5.1 darauf hatte ohne diese Weiche und bei den Updates danach wurde die quasi ignoriert, da bereits dies in der DB stand:
‘oxorder’ => ‘bestit/amazonpay4oxid/ext/bestitamazonpay4oxid_oxorder’,
korrekt wäre aber dies gewesen:
‘oxorder’ => ‘bestit/amazonpay4oxid/ext/bestitamazonpay4oxid_oxorder_oxid5’,
Nachdem ich das Modul mal komplett entfernt und wieder installiert hatte, funktionierte auch die Weiche korrekt und die o.g. Strict-Fehler waren endlich weg. Das andere erwähnte Problem beschäftigt mich jedoch leider noch weiterhin, aber das habe ich nun besser hierhin geschrieben, damit dieser Thread (zur JS-Frage) als gelöst abgehakt werden kann 
Ich hatte bei der Integration Probleme mit ungültiger Zahlart, die waren weg nachdem ich alle Amazon-Zahlarten gelöscht habe und das Modul neu aktiviert habe, das hat dann die Zahlart neu erstellt und die hat funktioniert.
Danke auch für den Tipp! Das klang auch erstmal logisch, wg. meines erwähnten Versions-Tests-Chaos, aber ich hatte die Zahlarten kurz verglichen und keinen Unterschied gesehen. Dann trotzdem einfach mal versucht wie vorgeschlagen und nun bekomme ich die Zahlungsart gar nicht mehr zu sehen, manno. Alle Zuordnungen zu Versandarten, Länder, etc. habe ich geprüft und/oder erneuert. Erst danach tauchte auch der Amazon-Button im Warenkorb wieder auf, also sollte die Config stimmen, aber auf der Payment-Auswahlseite taucht kein Amazon mehr auf, seltsam.
PS: okay, das klärte sich evtl. schon, zumindest wird die Zahlungsart wieder angeboten, wenn man die Modul-Option “Amazon Login aktiv” deaktiviert. Keine Ahnung, ob das Sinn macht, aber ich finde diese Debatte sollte unter o.g. Thread weitergeführt werden, das passt besser zum dortigen Thema. 
Soooo…mich hat es nun auch erwischt.
Erst gab es Probleme beim Umstieg von dem JAG Amazon Modul auf BEST IT - nun bei dem Update von 2.5.1 auf 3.2.1
Erst gab es diese Meldung beim Update:
mysqli error: [1054: Unknown column ‘JAGAMAZONORDERREFERENCEID’ in ‘oxorder’] in EXECUTE (ALTER TABLE oxorder CHANGE JAGAMAZONORDERREFERENCEID BESTITAMAZONORDERREFERENCEID VARCHAR( 32 ) NOT NULL, Array) with user
Scheinbar will das Update die bereits überschriebenen JAG Dateien erneut überschreiben. Sinnfrei.
Wollte nun auf den alten Stand zurück…keine Chance. Modul kann nicht mehr geladen werden und Fehlermeldung:
Warning : Declaration of bestitAmazonPay4Oxid_oxOrder::_preFinalizeOrder(OxidEsales\Eshop\Application\Model\Basket &$oBasket, &$oUser, &$blIsAmazonOrder, &$blAuthorizeAsync) should be compatible with bestitAmazonPay4Oxid_oxOrder_oxid5::_preFinalizeOrder(oxBasket &$oBasket, &$oUser, &$blIsAmazonOrder, &$blAuthorizeAsync) in /usr/www/users/…/modules/bestit/amazonpay4oxid/ext/bestitamazonpay4oxid_oxorder.php on line 444
Ich müsste nun wohl die bestitamazonpay4oxid_oxorder_oxid5 aktiv austragen, damit er wieder die alte bestitamazonpay4oxid_oxorder nimmt - nur wie und wo!? 
Vorab:
Amazon Pay geht wieder. Wir mussten das ganze Modul deinstallieren und neu installieren.
Seit 28.06 gegen 11.00 Uhr haben wir aber folgendes Problem:
Wählt der Kunde eine andere Sprache als DEUTSCH im Shop, kann er die Bestellung zwar am Ende mit seinen Daten absenden…aber das Modul “removed” die Anschrift und bricht ab.
Sandboxbestellungen laufen in allen (!) Sprachen sauber durch.
Hat hier jemand das Modul laufen und kann testen, ob er in Englisch etc. sauber durchbestellen kann?
Danke
Heiko
mysqli error: [1054: Unknown column ‘JAGAMAZONORDERREFERENCEID’ in ‘oxorder’] in EXECUTE (ALTER TABLE oxorder CHANGE JAGAMAZONORDERREFERENCEID BESTITAMAZONORDERREFERENCEID VARCHAR( 32 ) NOT NULL, Array) with user
ja das is mir auch aufgefallen, das kommt quasi bei jeder modulaktivierung
@Jb123
Habt Ihr das Modul denn mehrsprachig laufen bzw. in einem Shop mit noch anderen Sprachen als DE?
Läuft es bei Euch seit 28.06 oder auch nicht mehr, wenn Leute aus dem Ausland in Fremdsprache bestellen wollen?
nein das rennt, der Fehler aus dem ersten Post besagt ja das jquery nicht geladen worden ist. Den Fehler mit der Spalte kann man ignorieren. Wenn die Spalte einmal erfolgreich umbenannt wurde. Wir hatte nur mal das Problem das das Modul nicht lief, als wir bei einem Update die upate_2.4.0.sql vergessen hatten.
Auch wenn Kunden aus dem Ausland bestellen und im Shop eine andere Sprache als DE wählen?
Wie geagt…bis 28.06 war bei uns alles super, seit dem 28.06 geht nur noch Sandboxmodus durch. Im Live-Betrieb kann man nur noch mit Sprachauswahl auf DEUTSCH durchbestellen