Hi, Currently in upcoming Patch (4.5.3) we will fix the issue, that order is deleted after negative response comes from TS side. So in such case shop will proceed with the order as usual (will be not deleted), but no info about rejected request from TS would be displayed for now. Later (in some Major version release) we are considering to implement feature to handle response from TS side properly, displayed TS request status in order information, with logs of returned errors, etc, - to give the chance for further investigation of TS request manually by shop owner. Maybe even do pre-check before calculating the amounts in basket. Currently we are checking if such concept/process is possible from TS side.
Best regards, Dainius Bigelis -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Arvydas Sent: Thursday, September 22, 2011 10:00 AM To: [email protected] Subject: Re: [oxid-dev-general] Implementation of "TrustedShops Käuferschutz" is reason of huge Payment Problems Hi, yes, you are right and your notices are correct. We going to fix this problem in soonest release. https://bugs.oxid-esales.com/view.php?id=3265 Regards, Arvydas Vapsva -----Pirminis laiškas----- From: Ferber Sven Sent: Tuesday, September 20, 2011 6:37 PM To: [email protected] Subject: Re: [oxid-dev-general] Implementation of "TrustedShops Käuferschutz" is reason of huge Payment Problems 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 _______________________________________________ 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
