After utpdating to Umbraco 6.1.4 and TeaCommerce 1.4.4.5 our custumers suddenly mailed us complaining on missing goods.
It turns ut that after returning from DIBS the TeaCommerce.GetFinalizedOrder() is null.
Is this a case of timeout of somekind? the DIBS config is just the same as before the upgrade. I tried to call DIBS in testmode and the same thing happened.
If i use the default payment proivder everything is working as expected.
Hmm have you checked the App_Data/Logs for data about the error. Nothing about the finalize process changed for TC 1.4.4.5 so it should work. What version did you update from?
So i went through the compiled code and removed some skelletons. Everything seemed ok before, and even better now. No changes to the above behaviour though.
Then i got the idea that the accepturl was wrong: See, I had placed the order using http://www.myurl.com and set the accepturl to http://myurl.com/accept-page. When i changed my accepturl setting to http://www.myurl.com/accept-page my finalized orders suddenly started to appear on that page! (i used DIBS in test mode) I thought everything was ok once again...
BUT
In the backoffice, the order still has the Orderstatus as New, paymentStatus as initial, orderStage as isCart.
Could this be a licencing problem? The log is silent.
The license says that myurl.com is ok. it says nothing of www.myurl.com
The reason for the orders to be "finalized" is that Tea Commerce use the session state to trick orders to behave as finalized when you get to the confirmation step using the continue url in the payment provider. This is because a payment gateway can use several minutes before they make a callback to your server. And the reason for the order now to be "finalized" is that the session cookie is not the same for domain.com and www.domain.com.
Now the callback is properly not working correctly. So check that your site is at a live url that the gateway can invoke. If you run the payment provider in test mode then it should log if it gets a request from the callback from the payment gateway.
TeaCommerce.GetFinalizedOrder() is null after returning from DIBS
After utpdating to Umbraco 6.1.4 and TeaCommerce 1.4.4.5 our custumers suddenly mailed us complaining on missing goods.
It turns ut that after returning from DIBS the TeaCommerce.GetFinalizedOrder() is null.
Is this a case of timeout of somekind? the DIBS config is just the same as before the upgrade. I tried to call DIBS in testmode and the same thing happened.
If i use the default payment proivder everything is working as expected.
Hmm have you checked the App_Data/Logs for data about the error. Nothing about the finalize process changed for TC 1.4.4.5 so it should work. What version did you update from?
Kind regards
Anders
Hi!
I think i updated from 1.4.4.1
So i went through the compiled code and removed some skelletons. Everything seemed ok before, and even better now. No changes to the above behaviour though.
Then i got the idea that the accepturl was wrong:
See, I had placed the order using http://www.myurl.com and set the accepturl to http://myurl.com/accept-page. When i changed my accepturl setting to http://www.myurl.com/accept-page my finalized orders suddenly started to appear on that page! (i used DIBS in test mode) I thought everything was ok once again...
BUT
In the backoffice, the order still has the Orderstatus as New, paymentStatus as initial, orderStage as isCart.
Could this be a licencing problem? The log is silent.
The license says that myurl.com is ok. it says nothing of www.myurl.com
The reason for the orders to be "finalized" is that Tea Commerce use the session state to trick orders to behave as finalized when you get to the confirmation step using the continue url in the payment provider. This is because a payment gateway can use several minutes before they make a callback to your server. And the reason for the order now to be "finalized" is that the session cookie is not the same for domain.com and www.domain.com.
Now the callback is properly not working correctly. So check that your site is at a live url that the gateway can invoke. If you run the payment provider in test mode then it should log if it gets a request from the callback from the payment gateway.
Kind regards
Anders
is working on a reply...