Hallo!
Wir haben Anfang des Jahres unseren OXID-Shop auf einen neuen Server umgezogen. Der Shop bedient ein extrem weihnachtslastiges Thema und hat daher unterm Jahr quasi keine Conversions, deshalb ist uns erst jetzt aufgefallen, dass Kreditkartenzahlungen nicht mehr funktionieren. Wir nutzen das Modul von D3, es liegt aber vermutlich nicht an diesem.
Wir haben uns an diese Anleitung gehalten beim Umzug: OXID Forge – Die Knowledge Base rund um den OXID eShop
Kreditkarte wurde beim anschließenden Test offensichtlich auch vergessen, denn es gab nur Checkout-Tests mit PayPal und Vorkasse.
Bei Kreditkarte passiert offensichtlich komisches mit der Session. Ein Beispiel:
Auf
index.php?cl=payment&
ist die Session-ID pgskvuvni6ugm287fb2o8prik6. Die CC-Daten werden eingegeben, es gibt einen kurzen Trip zum Heidelpay-Server (wo eine Reservierung über 0 Euro angelegt wird) und dann wird versucht
index.php?force_sid=9u474gq84pgvpg7si9c60hqkj3&cl=order&remoteaccess=true&stoken=86BCA10B
aufzurufen. Die Session-ID ist jetzt also 9u474gq84pgvpg7si9c60hqkj3.
Das führt dann direkt zu einem Redirect auf die Startseite. Und dort ist die Session-ID dann fio2nc6sn21eac8k95484tmvr1.
Lasse ich mir mit iDebug=-1 in der Config den Fehler ausgeben kommt:
Different browser (Apache-HttpClient/4.4.1 (Java/1.8.0_71), Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36), creating new SID…
Aber eigentlich sollte OXID doch mit force_sid die alte Session wieder aufnehmen, wobei verwunderlich ist, dass force_sid einen anderen Wert enthält wie vor dem Trip zum Heidelpay-Server. Das D3-Modul ist verschlüsselt, ich kann daher leider nicht debuggen, ob da noch einmal eine neue Session-ID erzeugt wird (diese ich nenne sie mal Interims-Session gibt es aber kurzzeitig im Filesystem wie ein mitlaufender watch-Prozess bestätigt).
Ich bin für jeden Tipp dankbar woran es liegen könnte…
Matt