Waiting for bank validation

[tucoinfo]

Probably nothing to do with tggatos but is anyone else getting this return response since a day or two? I thought it may be connected to enabling 3X payment this week but no (merci Damien).

Of course ATOS is useless for sending pre-warning emails for critical changes, unlike PayPal (e.g. for SHA256, TLS1.2, etc) but there was some message in the merchant portal that is now gone.

In my case, I have 3 sites on a single server, only one of which has this problem. The problem is for all ATOS payments, it is the only site that has tggatos 3X enabled but even disabling 3X doesn't change the problem.

• the payment is correctly registered in the ATOS portal
• return is Waiting for bank validation
• no order created

[TrogloGeek]

Related to #46

This is not a response code sent by the bank, this is the message my module displays if the user return context is not able to obtain the cart lock within the time allocated by CNF_CONCURRENCY_MAX_WAIT configuration value (3s by default).

This means:

• You have the concurrent response behavior #46 addresses
• The silent response take more than CNF_CONCURRENCY_MAX_WAIT seconds to remove its own lock or has crashed before removing lock.

If the order is never created, then you either have a timeout or a crash in silent response, which is more than often a module registered on a hook triggered by order creation (either order creation or order status update) that performs an external webservice call, peer webservice taking too much time to answer, resulting in a timeout while creating your order. So far I had to investigate 3 shops having this problem: two of them were caused by SoColissimo webservice, and the third one was caused by a ROI analytics module also using a webservice on order creation or status update.

[tucoinfo]

Thanks for the reminder Damien, unfortunately disabling nearly all modules didn't help in this case.

No log errors, nothing. ATOS says no maintenance last weekend. So I tried everything else I could imagine on the test site and then I noticed that the cart I was using didn't look right. I'm not sure but maybe it wasn't updating correctly with respect to the FO. So I deleted my cart and truncated response_lock just in case. Payment works again.

I did the same on the production site but it did not help!

To reproduce the issue again I refreshed the test site with an exact copy of the live DB. The test site payment still works! Both sites run 4.1.1 and the only DB differences are contact emails, site URLs and dumped with --order-by-primary

Is it possible that the issue stems from some corrupt cart or something related?

[TrogloGeek]

This is not ATOS related (appart from the fact they do allow response concurrency since a few month as of #46 which introduces alot more problems when bridging PrestaShop with SIPS), il there is a lock on the cart on user return it means that silent response have been received and successfully decyphered. The problem comes either from the module or from PrestaShop (or any module), PaymentModule::validateOrder() is most probably taking to much time to process. Difference between production vs test shop may simply by performances (even on the same server with same config as production shop should have more visitors than test shop, thus more DB noise/locks).

To find out where the problem is, I would run profiling on silent response to check where the process hangs or crashes.

[tucoinfo]

Profiling didn't reveal much, initContent was quite long without cache however increasing CNF_CONCURRENCY_MAX_WAIT didn't help.

I managed to reproduce the issue on the test site by provoking a 500 error on the returns. Then I have an entry in response_lock and I remove the 500 error. All further attempts to pay the same cart will fail unless I delete the lock. If I create a new cart ID then it works anyway.

This doesn't explain the origin of my problems (not related to tggatos) but truncating the resulting lock table on the prod site seems to have enabled new payments (also manually delete all cache folders).

[TrogloGeek]

Chances are it is related to deleting the cache folder. How many entries did you have in the table before truncating ?

Profiling didn't reveal much?

• How long did the whole silent response take to complete?
• How many time spent in validateOrder?
• Did the request complete?

[tucoinfo]

I have reviewed the backups and I think the original problem is quite clear now. silent response was getting a 500 error due to a hack in tggatos.php which raised an undef. Why it only started 2.5 days after testing and installation and purging the cache (but via the BO) is a mystery as payments were fine till then.

Following the undef fix there were about 8 pending locks. As I mentioned, this doesn't stop new carts converting to orders but it does seem to block the locked ones. And ofcourse we were always testing on the same ones...

On the test site there is no cache however.