order thru keyclient payment module not showing up in admin, or mail

[keneso]

Hi

Orders made with credit card (keyclient payment module https://www.zen-cart.com/downloads.php?do=file&id=922) don't show up in admin or in mail; I do get the payment confirmation mail.

As per the customer side the payment goes thru correctly, customer is charged, and gets the mail that payment has been done.

Last record of order by cc dates back in March 2016.
Note it did happen both with v.1.5.1 and currently with 1.5.4.

I did test COD and the order is shown.

php v.5.4.45
mariadb v.5.5.53

I don't know if it is related, when testing the payment at the time of redirecting from gateway to the site I got 403

https: // www dot cadante dot com/index.php?main_page=checkout_process&mail=mailname%40gmail.com&data=20161112&orario=131429&messaggio=Message+OK&cognome=LastName&divisa=EUR&importo=110&languageId=ITA&session_id=null&nome=MyName&tipoTransazione=SC_FULL&mac=xxxxxxxxxxxxxxxxxxxxxxxxxxxxx&codTrans=4-20161112-121103&codAut=584761&esito=OK&alias=payment_278542&OPTION_CF=&brand=MasterCard

Thank you

When loging back the order is still in cart.

[DrByte]

Lines 15-53 of /includes/application_top.php deal with preventing unexpected URL parameters from being abused to target your site. It also rejects requests that contain very long parameter values, because those are commonly used to trick insecure servers into crashing.

Your payment module is using the nowadays-unconventional approach of passing all its response parameters as GET parameters in the URL (instead of fields in a form POST), and might be getting caught in that protection system.

Do your server's access-logs or error-logs show any "406" responses to any hits on index.php?main_page=checkout_process ? If so, then that may be tripping things up for your module.

[keneso]

Thank you.

server's access-logs or error-logs

Do you mean the error_log in public_html?
I don't see 406, only this (3 triplets with slight time difference):

[11-Nov-2016 00:06:37 Europe/London] PHP Warning:  require(includes/application_top.php) [<a href='function.require'>function.require</a>]: failed to open stream: No such file or directory in /home/cadante/public_html/index.php on line 26
[11-Nov-2016 00:06:37 Europe/London] PHP Warning:  require(includes/application_top.php) [<a href='function.require'>function.require</a>]: failed to open stream: No such file or directory in /home/cadante/public_html/index.php on line 26
[11-Nov-2016 00:06:37 Europe/London] PHP Fatal error:  require() [<a href='function.require'>function.require</a>]: Failed opening required 'includes/application_top.php' (include_path='.:/opt/alt/php53/usr/share/pear:/opt/alt/php53/usr/share/php') in /home/cadante/public_html/index.php on line 26

And as you can see date is yesterday, whereas the issue happened today.

Are the two issues (no order in admin, and the 403) related?

Like added when I got back into the account the order was still on the cart, where is that in the database, so that I can check when I get a payment, and no order in admin, until I get to fix it?

To be honest I haven't understood much of what you said, I mean I got it, but don't know how to use the info you kindly shared to solve it.

[DrByte]

The unsaved order problem is caused by the fact that your store is not properly receiving the payment confirmation from the Keyclient gateway, and therefore doesn't complete the steps of storing the payment confirmation and then storing the order. Once you fix the problem of the confirmation being received, the orders will store properly again.

The "missing application_top" warnings may or may not be related to the unsaved orders: you will need to determine what's causing those PHP errors first to know whether they're connected.

The points in my previous comment may be irrelevant to your problem. They were based on initial observations of the symptoms as you reported them. You could use them to attempt some debugging by perhaps temporarily removing the lines mentioned and testing whether payments suddenly work again.
But it would be better to get your payment gateway to use POST responses instead of GET responses (and edit the payment module to respond to $_POST data instead of $_GET), as that would be more secure and less likely to trigger the spam-protection defenses.

[keneso]

Thank you.

I'll look into it and see what I can do, I'll report back; may take some days.

[keneso]

I edited the module files (please see attached zip) to use _POST - I am not sure I done it correctly though (not a coder). Anyhow with this I still got the 403, and the card was charged.

I reverted back to the original module files, and removed the lines 15-53 of application_top.php, retried and got the same 403, and card charged.

Of course in both cases no order was passed to admin.

keyclient_v0.2_POST.zip

[keneso]

A bit more info from the sslaccesslog where there is the 403 (HTTP/1.1" 403 1139 "https://ecommerce.keyclient.it/ecomm/ecomm/MerchantServlet.....)

2.234.145.206 - - [14/Nov/2016:22:58:52 +0000] "GET /index.php?main_page=checkout_process&mail=xxxxxxx%40gmail.com&data=20161114&orario=235851&messaggio=Message+OK&cognome=Lastname&divisa=EUR&importo=90&languageId=ITA&session_id=null&nome=Name&tipoTransazione=SC_FULL&mac=YKfmtHTfrjI2MjPgtRDjaPHjYWQxODgtMNGpekk4MjA%253D&codTrans=4-20161114-221142&codAut=643757&esito=OK&alias=payment_274532&OPTION_CF=&brand=MasterCard HTTP/1.1" 403 1139 "https://ecommerce.keyclient.it/ecomm/ecomm/MerchantServlet;jsessionid=Mfd0peb+Vgf8jjFErsngrGEh.ecomas6" "Mozilla/5.0 (Windows NT 6.3; WOW64; rv:49.0) Gecko/20100101 Firefox/49.0"

[DrByte]

1. Don't change the PHP code to use $_POST until AFTER you've found out how to get the gateway to send POST responses. (That means you have to talk to their tech staff, to determine if they offer that, and then find out how to enable it.)
This change to POST is only a recommendation for things being more secure. If the gateway doesn't support it, then it's moot and you'll have to live with it.

2. The response you posted above shows a field "mac=YKfmtHTfrjI2MjPgtRDjaPHjYWQxODgtMNGpekk4MjA%253D" ... which is longer than the 43 characters I mentioned that application_top is protecting against.
So,edit /includes/application_top.php by adding the highlighted change:

      $len = (in_array($key, array('zenid', 'error_message', 'mac', 'payment_error'))) ? 255 : 43;

[keneso]

Thank you for your patience.

I changed the application_top.php line as you suggested, double checked by downloading it back, but I got 403 again, basically same log line.

[keneso]

Any other ideas please?