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
