Hi Reinhard, you are right, if the payment interface only relys on that code without checking back on the value returned by oxOrder->finalizeOrder() this can be a potential risk. In most of the implementations I know, the actual payment is executed/processed in either order->execute() or in order->_getNextStep().
Best regards, Sven Am 20.09.11 17:10 schrieb "Reinhard Vogl" unter <[email protected]>: Hi Sven, a numeric state of the _executeTsProtection() will help to show a customer an error message in shop frontend. But for payment its too late. the customer already started a bank transfer or a credit card payment. I cant remember a module that will handle a failed trusted shops call and reclaim customers money. regards, Reini Am 20.09.2011 17:00, schrieb Ferber Sven: > Hi, > > I think that what OXID does here is not a mistake or anything like that. It > is obviously a mistake in your payment interface. > If the trusted shop protection ($blRet = $this->_executeTsProtection( > $oBasket );) fails, a numeric order state value (6) will be returned and must > be handled after order->_getNextStep(). _getNextStep() should normally > redirect the user to the payment view with a payment gateway specific error. > So it's up to the payment interface provider to handle this case. > > Correct me if I'm wrong, but these are my thoughts on the topic. > > Best > Sven Ferber > > > Am 20.09.11 16:37 schrieb "Reinhard Vogl" unter<[email protected]>: > > Hi everybody, > > on 16.9. we released our newest Project on an OXID EE 4.5.1. > Today the finacial accounter told me that he has a lot of payments, that > did not execute an order. > Usually I would search in the paymentmodule. But the problem was not > continuous and it just happened in connection with the "Trusted Shop > Käuferschutz". > I Looked in the source and found a almost criminal part of native Oxid > code in the finalizeOrder function of oxorder. > > // executing payment (on failure deletes order and returns error code) > // in case when recalcualting order, payment execution is skipped > if ( !$blRecalculatingOrder ) { > $blRet = $this->_executePayment( $oBasket, $oUserPayment ); > if ( $blRet !== true ) { > return $blRet; > } > } > > // executing TS protection > if ( !$blRecalculatingOrder&& $oBasket->getTsProductId()) { > $blRet = $this->_executeTsProtection( $oBasket ); > if ( $blRet !== true ) { > return $blRet; > } > } > > This means to me that first a payment is executed and THEN depending on > the success of a Trustedshops call Order will be saved or skipped. > I Looked at the Orders and I found, some orders with successful Trusted > Shops Calls. but ther must be many, that failed an Money was already sent. > > In my opinion there shouldnt be any interface call after a payment, that > could prohibit the execution of the order. > > Please share some thoughts about a better Implementation of TrustedShops > Käufeschutz within the finalizeOrder. > > best regards, > Reinhard Vogl > _______________________________________________ > dev-general mailing list > [email protected] > http://dir.gmane.org/gmane.comp.php.oxid.general > > _______________________________________________ > dev-general mailing list > [email protected] > http://dir.gmane.org/gmane.comp.php.oxid.general -- ____________________________________ Reinhard Vogl Technische Leitung DeutscheDaten Portal- und Plattformlösungen GmbH Gabrielenstraße 9 80636 München Amtsgericht München: HRB 160521 Telefon: 089 542 742 43 Internet: www.deutschedaten.de ____________________________________ _______________________________________________ dev-general mailing list [email protected] http://dir.gmane.org/gmane.comp.php.oxid.general
