Amazon Payments (LPA) für JTL Shop4

[DITH-Shop]

Ich arbeite noch mit der 1.08 muss ich dazu sagen

Ich bin wohl zu blöd.
Habe (abgesehen davon das bei mir "Login und Pay" gewählt ist genau dieselben Einstellungen. Ich muss aber nach dem Versand immer auf "refresh" klicken damit die Zahlung in der Wawi ankommt..

 

[Xantiva]

Trotz Update auf die 109 funktioniert der IPN Aufruf von Amazon scheinbar nicht. Ich muss weiterhin bei allen versendeten Aufträgen auf "Refesh" klicken, damit sich der Shop die Daten aktiv von Amazon holt. 🙁

 

[Dustin]

Wenn ihr ins Backend schaut vom Shop im bzw. Backend vom Plugin was steht denn da unter Status (Shop) ?

Bei uns ist es so das nur Geld angefordert wird wenn die Bestellung versandt ist. Dann wird auch die Zahlung im Shop gesetzt und somit die Zahlung in der Wawi!

Frage noch an euch setzt ihr den Worker ein?

 

[Xantiva]

Status Shop: "Alles Grün"
Hinweis:

Folgende Plugins benutzen einen identischen Hook.
129

• JTL PayPal
• Solution 360 Amazon Login-and-Pay (JTL-Shop 4)

134

• JTL Search
• Solution 360 Amazon Login-and-Pay (JTL-Shop 4)

140

• JTL PayPal
• JTL Search
• Solution 360 Amazon Login-and-Pay (JTL-Shop 4)

In meinem früheren Post siehst Du die erweiterten Einstellungen: Capturemodus nach Versand

Der Status im Plugin ist - in Abhängigkeit vom Versand - In Bearbeitung oder Versandt.

Und ja, der Worker läuft.

 

[301Moved]

Hallo, wir bekommen seit neuestem diese Fehlermeldung im Log:

LPA: LPA-Login-Fehler: CURL-Fehler: Operation timed out after 300479 milliseconds with 0 out of 0 bytes received

Auf den ersten Blick scheint aber alles zu funktionieren, wir prüfen das aber nochmal.

Ups, manchmal sollte man gründlich gucken, das gibt es auch noch:
LPA: LPA-Login-Fehler: CURL-Fehler: OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to api.amazon.de:443
LPA: LPA-Payment-Fehler: Technischer Fehler beim Bestellabschluss: OrderReference P02-0103742-xxx is not in draft state and cannot be modified with the request submitted by you.

Also wir stellen einen sehr langsamen Login fest, bei Chrome deutlich länger als in Firefox, aber es geht irgendwann. Zahlungen werden wohl eingezogen...

 

[mr.youngchicken]

Hallo,
wir haben das Plugin erst ganz neu eingebunden. Offensichtlich scheint auch alles zu funktionieren und nun, da die erste Bestellung mit Amazon Payments rein gekommen ist, ist auch bei uns die Zahlung nicht in der Wawi angekommen. Im Shop steht als Bestellstatus OPEN, auch wenn ich auf REFRESH klicke. Muss ich zusätzlich noch auf EINZIEHEN klicken, oder passiert das automatisch, wenn ich die Bestellung ausliefere?

Im Amazon Payments Account ist die Zahlung bisher auch noch nicht aufgeführt. in der Wawi habe ich aber eine Zahlungs-Referenz der Art P02-... drin stehen.

Danke.
Grüße David

 

[Dustin]

Das soll automatisch passieren wenn du in der Wawi den Versandt setzt und das dann zum Shop übertragen wird.

 

[mr.youngchicken]

Danke Dustin,
Versand haben wir gesetzt und die Zahlung ist jetzt auch in der Wawi angekommen. 🙂 Im Shopbackend und auch direkt bei Amazon Payments ist der Order-Status (Amazon) allerdings immer noch immer auf OPEN/OFFEN ?

 

[Dustin]

Läuft euer Shopabgleich komplett durch? Werden die Versanddaten richtig an den Shop übertragen?

 

[mr.youngchicken]

im Shop steht "Versandt". Der Shopabgleich funktioniert einwandfrei. Auch in der Wawi ist die Zahlung angekommen.
Vielleicht verstehe ich das einfach nur falsch. Im Sellercentral Account steht bei Status der Zahlung noch "offen", aber auch, dass ich die Zahlung "einziehen" kann. Muss ich das immer per Hand machen, oder passiert das nach einer Weile von alleine - der Einzug?

 

[Dustin]

Das muss eigentlich alleine funktionieren.

 

[Shopworker.de]

Hallo junges Hähnchen,

m Shop steht "Versandt". Der Shopabgleich funktioniert einwandfrei. Auch in der Wawi ist die Zahlung angekommen.

das ist alles korrekt. Bei Amazon Pay-Aufträgen übernimmt Amazon quasi die Zahlungsgarantie und der Auftrag wird freigegeben, das Geld aber noch nicht beim Kunden abgebucht.
Der Auftrag landet als "nicht bezahlt" in der Wawi.
Wenn du den Auftrag dann versendest (das kann ja theoretisch auch Wochen später sein) wird die Versandmeldung an den Shop und von dort an Amazon gemeldet.

Dann zieht Amazon beim Kunden das Geld ein, an die Wawi kommt die Rückmeldung "bezahlt" und alles ist korrekt gelaufen.

Dass in deinem Backend "offen" steht heisst nur, dass der Auftrag noch nicht "geschlossen" ist.

Theoretisch könntest du noch einen kleineren Betrag (ich vermute 10 bis 15 %, da habe ich keine genaue Angabe zu gefunden) vom Kunden nachträglich anfordern ...

Und dafür steht der Auftrag noch auf "offen" und du könntest theoretisch noch einen kleineren Betrag "einziehen".

Der Auftrag wird nach einiger Zeit / einigen Monaten dann von Amazon automatisch geschlossen ...

 

[Xantiva]

Dann zieht Amazon beim Kunden das Geld ein, an die Wawi kommt die Rückmeldung "bezahlt" und alles ist korrekt gelaufen.

Das wäre ja schon, bei mir kommt der IPN-Call immer nur mit einem Fehler im Shop an. Somit wird die Zahlung nie in der Wawi gesetzt. 🙁

LPA: LPA-IPN-Fehler: Invalide Nachricht empfangen: Error with message - header does not contain x-amz-sns-message-type header
=> HTTP/1.1 400 Bad Request

Das ist der Aufruf im Log:
54.240.197.105 - - [09/Dec/2017:10:46:37 +0100] "POST /includes/plugins/s360_amazon_lpa_shop4/version/109/frontend/ipn.php HTTP/1.0" 400 467 "-" "Amazon Simple Notification Service Agent"

 

[Xantiva]

So ...

... ich muss jetzt nur noch mal Ware versenden, um zu sehen, ob es jetzt funktioniert!

In der ipn.php wird die Funktion lpa_getallheaders definiert:

    function lpa_getallheaders() {
        $headers = '';
        foreach ($_SERVER as $name => $value) {
            if (substr($name, 0, 5) === 'HTTP_') {
                $headers[str_replace(' ', '-', strtolower(str_replace('_', ' ', substr($name, 5))))] = $value;
            } else {
                $headers[strtolower($name)] = $value;
            }
        }
        return $headers;
    }

Leider wird dort die Variable $headers als string initialisiert, dann im Verlauf aber als array verwendet. Das sorgt scheinbar (unter PHP 7.1) für den Fehler!

Ein Beispiel:

$headers = "";
$headers["test"] = "mike";
var_dump("String Init", $headers);

$headers = array();
$headers["test"] = "mike";
var_dump("Array Init", $headers);

Ausgabe mit PHP 7.1.12:

string(11) "String Init"
string(1) "m"

string(10) "Array Init"
array(1) {
  ["test"]=>
  string(4) "mike"
}

Ausgabe mit PHP 7.0.26:

string(11) "String Init"
array(1) {
  ["test"]=>
  string(4) "mike"
}
string(10) "Array Init"
array(1) {
  ["test"]=>
  string(4) "mike"
}

Hier ist auch die Fehlermeldung in der error.log:

Got error 'PHP message: PHP Warning: Illegal string offset 'test' in /var/.../miketest.php on line 5\n'

 

[Shopworker.de]

@Xantiva: Hast du diese Fehler schonmal bei Solution360 gemeldet bzw. nachgefragt, woran das liegen könnte?

 

[Xantiva]

Ja, ich habe denen gestern eine entsprechende Mail geschickt.

Also mal an alle, die Fragen:

• Wenn die Wawi KEINE Zahlung übermittelt bekommt: Welche PHP Version setzt Ihr ein?
• Setzt jemand PHP 7.1 ein und erhält aber die Zahlung automatisch in der Wawi?

Hier: Shop 4.05.5, Plugin 109, PHP 7.1.12

Hier ist das Verhalten auch schon im 2. Teil beschrieben:
http://php.net/manual/de/migration71.incompatible.php#120845

The backwards incompatible change 'The empty index operator is not supported for strings anymore' has a lot more implications than just a fatal error on the following code

<?php
$a = "";
$a[] = "hello world";
var_dump($a);
?>

This will give a fatal error in 7.1 but will work as expected in 7.0 or below and give you: (no notice, no warning)

array(1) {
[0]=>
string(11) "hello world"
}

However, the following is also changed:

<?php
$a = "";
$a[0] = "hello world";
var_dump($a);
// 7.1: string(1) "h"
// pre-7.1: array(1) { [0]=> string(11) "hello world" }

$a = "";
$a[5] = "hello world";
var_dump($a);
// 7.1: string(6) " h"
// pre-7.1: array(1) { [0]=> string(11) "hello world" }

?>

 

[Shopworker.de]

Dann fange ich mal an:

Ich habe einen Kunden mit Shop 4.04(1), Plugin-Version 104 und PHP-Version 5.4.45 wo alles bis auf die Rückmeldung der Zahlung in die Wawi funktioniert.

mehrere Shop 4.05(5), Plugin 108, PHP 5.6.x funktionieren.


PHP 7.1 habe ich keinen Kunden, der die Version schon nutzt.

 

[consumed]

Hallo zusammen,

ich wurde jetzt gerade an diesen Thread hier verwiesen, da wir ein Problem mit Amazon Pay haben.
(https://forum.jtl-software.de/threads/amazon-pay-abweichende-lieferadresse.105856/)
Wir nutzen das Plugin seit diesem Wochenende und haben jetzt auch schon einige Bestellungen bekommen.
Einer der Kunden hat sich dann direkt bei uns heute gemeldet, weil er keine abweichende Lieferanschrift angeben konnte, dies mussten wir dann händisch ändern.
Bei Amazon sei sie zwar hinterlegt, wenn er sie aber auswählt, ist das dann aber auch gleich die Rechnungsanschrift, was er aber nicht wolle.
Weiß jemand Rat?


MfG,

Consumed

 

[Xantiva]

Das war der Fehler! 😀

Alle Amazon Pay Aufträge wurde nach dem Versand heute automatisch auf bezahlt gesetzt:




Wer also mit der aktuellen Version 109 und PHP 7.1 keine Zahlung in der Wawi angezeigt bekommt, kann es mal mit dieser Version ausprobieren:

    function lpa_getallheaders() {
        $headers = array(); // <= Diese Zeile muss geändert werden.
        foreach ($_SERVER as $name => $value) {
            if (substr($name, 0, 5) === 'HTTP_') {
                $headers[str_replace(' ', '-', strtolower(str_replace('_', ' ', substr($name, 5))))] = $value;
            } else {
                $headers[strtolower($name)] = $value;
            }
        }
        return $headers;
    }

 

[Xantiva]

Erreicht man Solution360 nicht über die support@ Mailadresse? Bislang hat sich zumindest noch keiner auf meine Fehlermeldung gemeldet. (Dafür treffen weiter fleissig die Zahlungen ein.)

 

[Rico Giesler]

Die haben dafür scheinbar ne extra Support-Seite: https://jira.solution360.de/servicedesk/customer/portal/6/group/21
Also am besten darüber bei denen melden.