Status command not updated (but works with demo certificate MERCANET)

[kjose]

Hi,

I've installed and configured the module with the option FORCE RETURN TO BANK activated, for the google analytics treatment.

It works good with the demo certificate of Mercanet 082584341411111, i can pass an order and then it redirects me to the shop and the status of the commande si updated as "Payment OK". But when I pass the the module in Production mode, the status of the commande is not updated after the order but the payment is ok in the bank paiements logs.

I have asked Mercanet about this issue, but they don't know where is the problem. They suggest me to verify the IP adresses which are accepted but I don't have any IP restriction on my website.

This is a problem because the order is not updated and the client has to check in the bank logs if it has passed or not. And the google analytics is not updated because of that.

Have you an idea where is the problem ?

Thank you,

[TrogloGeek]

The SIPS option that forces user return is weak, you don't get any bank server to shop server direct communication, the only bank payment status is passed to the shop using the user redirection, and a great amount of data are passed using GET method, which may be filtered by security systems on you server (PHP Suhosin patch, Apache security filtering rules...), loosing the information. This must be step by step debugged to find out where the data has been lost. If your shop does not implement SSL, the client browser can also refuse the redirection because it leaks information belonging to a private context (SSL) to a listenable context.

[kjose]

Thank you for your help !

My shop does not implement SSL, I have the same problem with force return and not. I have no filtering for IP, Apache security and my suhosin limit is 2048 so much enough to work (GET parameters are about 1000 bits).

I tried with an other paiement module to see if i had the same problem. And yes the order status does not update. So the module works fine but you can may help me. I sent the following email to Mercanet with the detail of Apache Logs.

---

Bonjour,

Les URL de retour sont bien appelées et reçues par nos serveurs, il n'y a pas de blocage d'IP ou de limitation apache suhosin (on l'a mis à 2048).

Voici les LOGS APACHE pour une commande en certificat de production. Le statut paiement accepté ne remonte pas

/modules/tggatos/autodispatch/userreturn.pub.php?DATA=2020333831603028502c2360532e2324532d2360522d5360502c4360502c3334502d3328522d4344502e3360582c2360502c533 82a2c2360532c2360502d2324522e23342a2c2360552c2360502c33342a2c3360552c2360502d2539293454242a2c2360562c2360512d2328502c3334512c2328582c332c542e3328505c224324502c5360502c2338512d2334502c43242a2c3360542c2360502e2328502c3334512c2328585c224324 502c3360502c2328502c6048512c2360502c2360562d4328522c3338505c224360522e3360502c2329463c4048502c2340502c2360532e333c585c224360502e3360502c2329463c4048512c2338502c2360572d2344572c5c2258522d5048512c3330502c2360562c4360512d5360555c224360522d5 360502c33392e33555d3231352d303354593331355d3030343d255c224360532e2360502c2334532c332c562c4048502d2360502c2324543035353432245d3237542d21342531353444342a2c232c592c2360502c33602a2c3360522c2360512c4634532e3630572e2331442e3634522d3048512c2344 502c2360522f535c2a2c3324502c2360502c33242a2c3324512c2360502c4360505c224324512c4360502c2328502c6048512c4328502c2360512c3048512c432c502c2360512c6048502c3338502c2324502c54313f3455352330543533345048502c4338502c2360552c5360562d23402a1d232c018 f36029a HTTP/1.1" 302 1326 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.80 Safari/537.36"

/confirmation-commande?id_cart=31362&id_order=14407&transaction_id=5&key=739dc288ecc2d77f94ffeaf7a68bfde9&id_module=160&tggatos_date=2015-10-28 HTTP/1.1" 200 7761 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.80 Safari/537.36"

Voici les LOGS APACHE pour une commande en certificat de test. Le statut paiement accepté remonte bien

/modules/tggatos/autodispatch/userreturn.pub.php?DATA=2020333539603028502c2360532d3344532d2360522d3360502c4360502c3334502e2328552e2330532d2324542c3324512c332 42a2c2360532c2360502d2334572d23602a2c2360552c2360502c333c2a2c3360552c2360512c2455213455312534442d213444302a2c2360562c2360512d2328502c3334512c2328582c3330532d3324575c224324502c5360502c2338512d332c552c533c2a2c3360542c2360502e2328502c333451 2c2328585c224324502c3360502c2328502c6048512c2360502c2360562c2330522e332c575c224360522e3360502c2329463c4048502c2340502c2360532e333c585c224360502e3360502c2329463c4048512c2338502c2360572d2344572d5c2258502c6048512c3330502c2360562c4360512d332 4505c224360522d5360502c33392e33555d3231352d303354593331355d3030343d255c224360532e2360502c2334532c332c552c4048502d2360502c2324543035353432245d3237542d21342531353444342a2c232c592c2360502c33602a2c3360522c2360512c2324542d2338502d2328592c533c 2a2c3360592c2360502c4331245c224324512c2360502c2324515c224324512c3360502c2328502c6048512c432c502c2360512c6048502c3338502c23605334552d2c5c224360522d4360502c2334532c5344512d6048608f2bffb84a673cff HTTP/1.1" 302 1324 "-" "Mozilla/5.0 (Macinto sh; Intel Mac OS X 10_11_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.80 Safari/537.36"

/confirmation-commande?id_cart=31352&id_order=14411&transaction_id=7&key=ee3e596d84aae4c0698642b55383195f&id_module=160&tggatos_date=2015-10-28 HTTP/1.1" 200 7714 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.80 Safari/537.36"

Il y a une différence entre le mode TEST et le mode PRODUCTION. Le mode production passe par une validation du paiement avec un 3D secure alors que le paiement avec le certificat de test lui ne passe pas.

Avez-vous déjà eu un cas similaire ?

Merci pour votre aide,

[TrogloGeek]

Do you mean that order is created but the problem lays in the status being assigned to that order? If yes, it has great chance to be an error or a timeout on a module subscribed to the hook "actionOrderStatusUpdate" (often a delivery module trying to contact the provider server to create the delivery record, or a bridge with a CRM or ERP)

[kjose]

Ok thank you,

This is a screen capture of my hook actionOrderStatusUpdate.

Yes that is the problem the status of the command is not updated as "Paiement accepted" after the paiement. Its strange that it works with the demo certificate but not with production certificate of the bank. Except that there is no change .. But in production there is the 3D secure activated, maybe it comes from here ?

[TrogloGeek]

I tried with an other paiement module to see if i had the same problem. And yes the order status does not update. Its strange that it works with the demo certificate but not with production certificate of the bank. Except that there is no change ..

If the problem arise wise another payment module too, but not in demonstration mode of this module I guess that the problem is (pseudo-)random (which is often the case with external call causing timeouts): the problem should arise sometimes too with demonstration certificate.

HTTP daemon and PHP log set to debug level could help.

You could try disabling all these modules and see if it works better, if yes enable them one by one to try to pin the one causing a timeout/crash, or better (but harder): override Hook class to profile the calls to the hooks. If you have a module called on a hook but which has never returned you know you have an issue: either the module crashes, stops execution or timeouts (in case of timeout, it may be an issue with preceeding hook calls cumulating to many time, profiling will let you see this).

[kjose]

Hello and thank you for your answer,

I have tried to disabled all the module of hook actionOrderStatusUpdate. I have the same problem the status is not updated with the real certificate.

Then I tried the demo mode of Mercanet BNP Paribas, with the 3D secure. I have the same problem the status is updated OK with the test certificat but not with the real certificate.

So I looked the log of the module and I get two responses, one response type silent and one response type user.

I really don't understand why it works with the demo certificate but not with the final certficate. It would be really nice if you could help me, because this is for a professional purpose and I said to my client that I don't have any other solution.

Thank you,

[TrogloGeek]

What is the status set to problematic orders? May be related to the complementary_code handling, would worth checking this field on responses related to correct and problematic orders.

[kjose]

Yes!

Hum I was just writing about this, I compared two logs :

• One with the demo certificate
• The second with the final certificate.

And the response is 00 for both case but the complementary_code is empty for the final certicicate. So it pass in the following code of the module.

                switch ($response->complementary_code)
                {
                    case '00':
                        break;
                    default:
                        $orderState = $this->get(self::CNF_OS_NONZERO_COMPCODE);
                        break;
                }

Il pass in the default case. So i guess that the status order is not updated due to that ?

Thank you

[TrogloGeek]

It shoud be updated with the status configured in the CNF_OS_NONZERO_COMPCODE option ("Order state to apply on payment success with a non zero complementary_code").

I've already seen this problem of unprovided complementary_code but only once, weird. along with case '00': and before its break, you should add case '': and case null: (already done on the future version of the module I'm working on, but highly experimental as it introduces PrestaShop 1.4 compatibility and not really much time to work on it these days).

This is the code on the last draft (not published)

                    switch ($response->complementary_code)
                    {
                        case null:
                        case '':
                        case '00':
                            break;
                        default:
                            $orderState = $this->get(self::CNF_OS_NONZERO_COMPCODE);
                            break;
                    }

[kjose]

The status is well configured for CNF_OS_NONZERO_COMPCODE and appears in the database.

I told my client to test again with the modification.

Hope it works ;)

Thanks

[kjose]

No it still does not work,

Below the result of a command where the status is not updated.

[TrogloGeek]

complementary_code is correctly set, so that is not the problem. I still need to know what is the order status associated with these orders. CNF_OS_PAYMENT_SUCCESS may have been configured with an order status which exists no more.

What version are you using? I see you customized order message to add "Payment accepted" and "Mode", is this the only thing that have been moded? Please push your version to a fork so that I can see code changes.

[kjose]

My fork:

I changed tggatos.php because the client wanted the message Paiement accepted YES . https://github.com/kjose/prestashop-tggatos-module

version of TggATOS : 3.4.0 version of Prestashop : 1.5.6.1 bank : Mercanet (BNP Paribas)

CNF_OS_PAYMENT_SUCCESS is 2 and it seems to exist in Prestashop.

Thank you

[TrogloGeek]

What is the status set on problematic orders ? (ps_orders.current_state)

Please give me the result of following query (after updating ps_ prefix if needed):

SELECT * 
FROM `ps_configuration` c
LEFT JOIN `ps_order_state` os ON c.`value` = os.`id_order_state`
WHERE c.`name` IN ('TGGATOS_OS_NONZERO_COMPCODE', 'TGGATOS_OS_PAYMENT_SUCCESS');

[kjose]

[TrogloGeek]

Ok, no configuration issue here, but you still did not told me what is the actual order state of problematic orders (please also check consistency on ps_order_history)

[kjose]

For the order with the problematic i dont have any data in the table ps_order_history.

The status order appears as "--"

Paiement accepted is my test with demo certificate. Status -- is the test with real certificate

[kjose]

For the order, current state is 0

[TrogloGeek]

Hmmm the module cannot request creation of an order without a state id because of these two lines https://github.com/kjose/prestashop-tggatos-module/blob/RC_3.4.0/tggatos.php#L818-L819

• Either the $orderState is invalid (you could easily check this adding a line in your custom order message: orderLog[] = sprintf('$orderState: (%s) %s', gettype($orderState), $orderState); But any fault here should leverage an Exception here: https://github.com/PrestaShop/PrestaShop/blob/1.5.6.1/classes/PaymentModule.php#L146-L147 preventing the whole order to be created, so I'm quite sure the issue is elsewhere.
• or PrestaShop fails during PaymentModule::validateOrder().

If you get the expected $orderState: integer 2 then you really should use a profiler to log hooks enter/exists, when PrestaShop fails setting an order state it's usually a failing hook.

Order is created here (no status yet): https://github.com/PrestaShop/PrestaShop/blob/1.5.6.1/classes/PaymentModule.php#L263 And order current_state is committed to DB here: https://github.com/PrestaShop/PrestaShop/blob/1.5.6.1/classes/order/OrderHistory.php#L286 via https://github.com/PrestaShop/PrestaShop/blob/1.5.6.1/classes/PaymentModule.php#L542

As you can see there is a bunch of code that can fail between order creation and setting status, often hooks or advanced stock management.

[kjose]

Thank you,

I will do that, with a real paiement card. If I Identify the problem i will talk to you what it is.

Great Job for the module it works perfectly and very useful :)

Kevin

[TrogloGeek]

Cannot say that is works perfectly until you troubleshoot your issue :-p And there is many things I'd like to enhance if I had time.

[kjose]

Hi,

So i tried with a real card (credit mutuel bretagne), and bad luck ... it works for me...

it seems that it's not working with the bank of my client (banque populaire).

It must be a configuration from the bank but its strange that i receive the logs.

The problem is killing me haha ;)

I keep you informed,

[TrogloGeek]

PrestaShop and SIPS debugging are part of the professional services I can provide if needed ;-)