Bei uns kann nach einer Bestellung mit Kreditkarte, wenn man beim Kreditkartenunternehmen den Browser schließt ohne seine Daten einzugeben, nach erneutem Öffnen des Browsers eine Bestellung auslösen, ohne dass man an das Kreditkartenunternehmen weitergeleitet wird. Der Benutzer bleibt auch trotz vorherigem Schließen des Browsers im System eingeloggt. Die Bestellung wird auch erst mit internem Status OK angezeigt, später dann nach ein paar Stunden oder am nächsten Tag als FAILD.
Problem wurde mit Firefox und IE entdeckt läßt sich bei meinem Kollegen so durchführen, bei mir selbst tritt das Problem im selben Shop nicht auf.
Oxid hat die Version 4.4.3_30016
salut,
welches Kreditkartenmodul verwendest du, hast du den Anbieter des Moduls schon kontaktiert?
ceau
qpay wird hier verwendet. Den Anbieter habe ich noch nicht verständigt. Wollte erst mal Fehler meinerseits ausschließen.
Stutzig macht mich eben auch, dass die betreffenden nach den Schließen des Browsers und dem neuerlichen Öffnen immer noch eingeloggt sind.
Hallo Till,
das kann an verschiedenen Dingen liegen. Wahrscheinlich lässt sich das Phänomen im Demoshop kaum nachvollziehen, da kein KK-Provider eingebunden ist?
Gruß
[QUOTE=Till;54022]
Stutzig macht mich eben auch, dass die betreffenden nach den Schließen des Browsers und dem neuerlichen Öffnen immer noch eingeloggt sind.[/QUOTE]
Das dürfte den Session-Cookies geschuldet sein.
Die “asynchronen” Zahlverfahren (Kunde verlässt Shop um beim Zahlungsdienstlesiter zu zahlen, woraufhin der Shop eine Zahlungsbestätigung erhält) sind m.E. alle inherent unsicher…
Denn die zwischen Shop und Zahlungsdienstleister ausgetauschten Meldungen lassen sich sehr einfach über den Browser bzw. simple PHP-Programme nachbilden, um dem Shop eine erfolgreiche Zahlung vorzutäuschen.
In den Open Source Versionen kann man die Logik des Zahlungsablaufs erkennen, mit Firebug oder ähnlichen Tools kann man den Datenverkehr zwischen den Servern analysieren und dann nachbauen…
Sicher (wenn man mal MITM-Attacken unberücksichtigt lässt) sind da nur die “synchronen” Verfahren, bei denen der Shop (dessen Zahlungsmodul) direkt in einem Server-Aufruf vom Server ein Clearing erhält.
Im vorliegenden Fall scheint das Zahlungsmodul sogar im Fehlerfall eine positive Zahlung zu übermitteln.
Ich habe das nun auch getestet nach den Tutorial AlertPay zur Einbindung von externen Bezahlsystemen mittels Weiterleitung auf die Seite des Bezahlservices.
Dort tritt das gleiche Phenomen auf.
Hier gibts kein Fail und keine Bestätigungsemail, aber die Bestellung wird auch als OK abgelegt.
Ich poste mal hier meine beiden Dateien mit denen ich order und oxorder erweitere, ich finde den Fehler nicht
order=>hi_Dienstleister_order
<?php
class hi_Dienstleister_order extends hi_Dienstleister_order_parent{
private $_xmlData = '';
private $_DienstleisterPaymentTypes = Array('oxDienstleister1' => true);
protected function _getNextStep($iSuccess){
$oOrder = oxNew('oxorder');
$oOrder->load(oxSession::getVar('sess_challenge'));
if ($oOrder && array_key_exists($oOrder->oxorder__oxpaymenttype->value, $this->_DienstleisterPaymentTypes)){
if(is_numeric($iSuccess) && $iSuccess == 1){
return 'order?fnc=DienstleisterPayform';
}
}
if ($iSuccess === 'DienstleisterOK' && $oOrder->load(oxSession::getVar('sess_challenge'))) {
$oOrder->oxorder__oxtransstatus = new oxField('OK');
$oOrder->oxorder__oxfolder = new oxField('Dienstleister_neu', oxField::T_RAW);
$oOrder->save();
$oBasket = $this->getBasket();
$oUser = $this->getUser();
$iSuccess = $oOrder->sendDienstleisterOrderByEmail($oUser, $oBasket);
}
return parent::_getNextStep($iSuccess);
}
private function _createPaymentData(){
$oBasket = $this->getBasket();
$oOrder = oxNew('oxorder');
$oUser = oxNew('oxuser');
$oUser->load($oOrder->oxorder__oxuserid->value);
if($oOrder->load(oxSession::getVar('sess_challenge'))){
$aPaymentInfoArr = array();
$aDynvalue = oxSession::getVar( 'dynvalue' );
$aDynvalue = $aDynvalue ? $aDynvalue : oxConfig::getParameter( 'dynvalue' );
$anz = $aDynvalue['Anzahlung'];
$this->_aViewData['DienstleisterAnz2'] = $aPaymentInfoArr;
if (!$anz) $anz = 0;
if ($anz <= 0 || $anz > 100){
oxUtilsView::addErrorToDisplay("Dienstleister DOWN PAYMENT1");
oxUtils::getInstance()->redirect("http://test02.hi-tech.at/index.php?cl=payment");
}
...
}
public function DienstleisterPayform(){
$this->_createPaymentData();
$this->_aViewData['DienstleisterData'] = base64_encode($this->_xmlData);
$this->_sThisTemplate = 'Dienstleister.tpl';
}
public function processDienstleisterOk(){
$iSuccess = 'DienstleisterOK';
return $this->_getNextStep($iSuccess);
}
}
?>
oxorder=>hi_Dienstleister_oxorder
<?php
class hi_Dienstleister_oxOrder extends hi_Dienstleister_oxOrder_parent {
private $_DienstleisterPaymentTypes = Array('oxDienstleister1' => true);
protected function _sendOrderByEmail($oUser = null, $oBasket = null, $oPayment = null)
{
if (array_key_exists($oOrder->oxorder__oxpaymenttype->value, $this->_DienstleisterPaymentTypes)) {
return 1;
} else {
return parent::_sendOrderByEmail($oUser, $oBasket, $oPayment);
}
}
// once order status = OK
public function sendDienstleisterOrderByEmail($oUser = null, $oBasket = null, $oPayment = null) {
return parent::_sendOrderByEmail($oUser, $oBasket, $oPayment);
}
}
?>
Hab nun den Verdacht, dass das Problem an der oxbasket.php im Core-Verzeichnis liegt.
Dort wird ein oxorderarticle in den Warenkorb gelegt, der die Bestellnummer ect. beinhaltet. Da bei einem Abbruch auf der Seite eines Bezahlanbieters der Warenkorb nicht gelöscht wird, befindet sich der Artikel immer noch im Warenkorb.
Werd mall versuchen ob ich das so lösen kann, indem ich im Bestellschritt eins irgendwie diesen Artikel lösche.