Paypal Ipn And Google Recaptcha (Addon From Ecom Labs) Stoped Working

I also have WHM/Cpanel (CentOS) - The issue occurred right after a forced server patch of us. My money is currently on server side, not PayPal (it would be an impeccably timed event). What sort of things could prevent the IPN notice from "communicating" to the cart fully? (and is there any "safe" data that we could provide that would help trouble-shoot the issue more to narrow it down some?) It looks like more people are realizing an issue and saying something about it... Thanks!

That would mean that everyone that has this problem had changes done to their servers and/or cpanel, and I for one did't have anything done, it was the first thing I thought also, but no, no upgrades, no maintenance, no changes of any kind.

That would mean that everyone that has this problem had changes done to their servers and/or cpanel, and I for one did't have anything done, it was the first thing I thought also, but no, no upgrades, no maintenance, no changes of any kind.

Don't forget most people have WHM automatic updates turned on. I agree with SkywayWebDesign - my money is also on server side.

Hi,

Just to add this has happened with our cart too,

IPN is sent, and received, but not processed, and were on WHM / cPanel too

Stephen

The quick and easy solution is to enable a notification for the New order status that PayPal orders are coming in as.

Then open a support ticket. CSC support is acknowledging that there is a bug in CSC and they will fix the issue on your installation.

After the fix, we are now getting two status notifications sent so we just disabled the one that we never used anyhow.

Then open a support ticket. CSC support is acknowledging that there is a bug in CSC and they will fix the issue on your installation.

Thanks, I've done that, now waiting for the fix.

Nevertheless, they should have posted in this topic the instructions, tickets cost support credits.

Pretty sure they do not charge support credits for bug fixes and it is worth the $5 spent anyhow to get quick(er) resolution anyhow. I do not think is was billed support credits.

The quick and easy solution is to enable a notification for the New order status that PayPal orders are coming in as.

But PayPal order status is coming in as "payment_status=Completed" and CS-Cart's PayPal addon matches the name/value pair in function fn_process_paypal_ipn : " if ($data['payment_status'] == 'Completed') "

What "new order status" are PayPal order coming in as?

But PayPal order status is coming in as "payment_status=Completed" and CS-Cart's PayPal addon matches the name/value pair in function fn_process_paypal_ipn : " if ($data['payment_status'] == 'Completed') "

What "new order status" are PayPal order coming in as?

Everyones Order Status naming is going to be different. I doubt many people use the default names. Anyhow, ours were coming in as "In Process" which has an order status code of "0". They normally come in as "Order Placed" which for us has a status code of "P". These are in Admin Order Statuses. If you go into Add-ons/PayPal payments you can manipulate what what the default PayPal statuses map to in CSC. In our case Completed was mapped to Order Placed.

Recently the mapping was not working apparently due to a bug in CSC and were coming in as "In-Process". In our case no email notification is sent to Admin. Supplier or Customer for this status. We temporarily fixed that by enabling the notification for the incorrect order status.

I was less concern about the IPN info and did not bring that up to CSC support because it has already been brought up. The payments were there. Nobody was getting notified. The quick fix is to turn on the notification that is specific to your set-up until CSC resolves it for everyone.

Thanks

Ken

Hi colleagues,

I had same issue in June 2018, and found out that PayPal plugin uses CURL, and CURL requests were missing "User-Agent" header that is required by PayPal. It worked for me without that header because depending on CURL configuration on particular web-server that header can be automatically added. On localhost I had this header set by web-server. Same is true for some ISPs.

But some web-server configurations (Apache or nginex) in some PHP mode (FastCGI, FPM or Apache Module) can have "vanilla" setting when nothing is added. In this case PayPal payment will fail, as CS-Cart addon does not add "User-agent" header to their CURL calls in PayPal Addon, so they entirely rely on the server configuration. Once I fixed it, my PayPal payments work correctly - even today.

Please check if this helps: https://forum.cs-cart.com/tracker/issue-7298-paypal-addon-does-not-handle-ipn-because-curl-settings-are-missing-user-agent-header/

Also a gist with code to be adjusted, and test tool: https://gist.github.com/zahhar/5238491f7a274c10bbcc3306e76a5618

Please tell me if this helped or not, curious to know.

Well there are just too many people that are experiencing this issue that apparently just started, for most, last week.

From what I can tell, the request and response are working correctly so the only thing I can think of is CSC isn't handling the response.?

Strange

want to say this page is not accessible for you ?

https://www.paypal.com/cgi-bin/webscr?cmd=_display-ipns-history

in bottom results checkbox desired transaction then hit resend

That I tried, my PayPal IPN history area does not have that option, to resend IPM, I can only see them. I'm with PayPal Spain.

At first I thought it was because I have IPN history off within Paypal (although I can see IPN history all the same), but then cs-cart states on all nstructions that we do not need to have those configurations done on PayPal, that that's what the PayPal Payments addon is for.

I applied this fix, but unfortunately it didn't help. This really seems to be something new and I still think it's related to a WHM update or something like that.

Strange

want to say this page is not accessible for you ?

https://www.paypal.com/cgi-bin/webscr?cmd=_display-ipns-history

in bottom results checkbox desired transaction then hit resend

It is accessible yes, but the option to resend IPN is not there.

____________

Anyway, Helpdesk just applied the fix to app/Tygh/Http.php file and orders are back to normal.

It is accessible yes, but the option to resend IPN is not there.

____________

Anyway, Helpdesk just applied the fix to app/Tygh/Http.php file and orders are back to normal.

Maybe you could share the changes with us?

Maybe you could share the changes with us?

I would, but I have no idea of what they did to the file, helpdesk just told me that they applied the fix to the app/Tygh/Http.php file, nothing more.

But it's just a matter of opening a ticket at helpdesk, they don't charge for this fix and in a matter of a few hours you have it fixed.

Could you upload the file so we can compare?

Certainly, here it goes.

Http.php

Thanks, this indeed fixed the problem :)

Note that E.Qi.Librium is using 4.3.9 Flow.

There are several differences in the file but it appears this is what CSC added to E.Qi.Librium's file /app/Tygh/http.php:

Find

    /**
     * Parse response contents to split headers
     * @param  string $content response contents
     * @return string contents without headers
     */
    private static function _parseContent($content)
    {
        while (strpos(ltrim($content), 'HTTP/1') === 0) {
            list(self::$_headers, $content) = preg_split("/(\r?\n){2}/", $content, 2);
        }
    return $content;
}

Replace:

    /**
     * Parse response contents to split headers
     * @param  string $content response contents
     * @return string contents without headers
     */
    private static function _parseContent($content)
    {
        while (strpos(ltrim($content), 'HTTP/1') === 0) {
            list(self::$_headers, $content) = preg_split("/(\r?\n){2}/", $content, 2);
        }
    while (strpos(ltrim($content), 'HTTP/2') === 0) {
        list(self::$_headers, $content) = preg_split("/(\r?\n){2}/", $content, 2);
    }

    return $content;
}

It is clear now. Thanks for keeping us updated