Same problem here.
I have an almost identical error – have put it in pastebin here: http://pastebin.com/iusauKUW
I tried using the http 1.1 workaround proposed a year ago here: https://wordpress.org/support/topic/sandbox-error-a-payment-error-has-occurred?replies=12
but that didn’t fix it (This change appears to have been made in a plugin update)
I think I may have solved it though by going back to this post from 2 years ago, which showed that the plugin requires a SSL certificate (which many servers don’t have): https://wordpress.org/support/topic/fixed-paypal-error?replies=3
The plugin code seems to have changed a bit, but you need to change two lines of code as instructed in this post on lines 730 and 749
From this:
$response = wp_remote_post( $url, array( 'body' => $payload, 'timeout' => apply_filters( 'camptix_paypal_timeout', 20 ), 'httpversion' => '1.1' ) );
to this:
$response = wp_remote_post( $url, array( 'body' => $payload, 'timeout' => 20, 'sslverify' => false ) );
Hope that helps!
I put the updated payment-paypal.php here: http://pastebin.com/8uuBaP7Q
It then needs to replace the one that is in wp-content/plugins/camptix/addons/payment-paypal.php
Thank you, that seems to have worked!
Pleasure! Hope it helps others 🙂
@realdoctorstu thank you for your work on this!! A small non-profit contacted me for help with this very same problem, and due to your fix, I was able to get their site working again, so they could sell tickets to their fund-raiser.
I’m very disappointed in Automattic for not fixing this issue.
– Scott
Just a note that turning off sslverify is very dangerous and allows an attacker to spoof your request regardless of HTTPS.
Thanks for the info. What’s the alternative for using the plugin over a non-https site?
Sorry for the confusion, the site itself doesn’t have to be HTTPS, but the requests to the PayPal API do. If SSL verification is not working, something is likely wrong with your hosting environment setup. I recommend you reach out to them for help, but NOT turn off SSL verification.
Hi @konstantin. I *am* the web hosting provider. We run very standard cPanel / CentOS 6 installations. What is it, exactly, that we are doing wrong, to cause this problem?
– Scott
@sneader, an outdated ca-certificates probably. Can you connect to api-3t.paypal.com over port 443 with curl?
Hi Konstantin. I wonder if this problem was already resolved in WordPress. See this bug/defect ticket:
https://core.trac.wordpress.org/ticket/34935
Certificate bundle with 1024-bit root certificates re-added
In any event, to answer your question, here are two curls:
# curl https://api-3t.paypal.com
<?xml version=”1.0″ encoding=”UTF-8″?><SOAP-ENV:Envelope xmlns:SOAP-ENV=”http://schemas.xmlsoap.org/soap/envelope/” xmlns:SOAP-ENC=”http://schemas.xmlsoap.org/soap/encoding/” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xmlns:xsd=”http://www.w3.org/2001/XMLSchema” xmlns:xs=”http://www.w3.org/2001/XMLSchema” xmlns:cc=”urn:ebay:apis:CoreComponentTypes” xmlns:ed=”urn:ebay:apis:EnhancedDataTypes” xmlns:wsu=”http://schemas.xmlsoap.org/ws/2002/07/utility” xmlns:saml=”urn:oasis:names:tc:SAML:1.0:assertion” xmlns:ds=”http://www.w3.org/2000/09/xmldsig#” xmlns:market=”urn:ebay:apis:Market” xmlns:auction=”urn:ebay:apis:Auction” xmlns:sizeship=”urn:ebay:api:PayPalAPI/sizeship.xsd” xmlns:ship=”urn:ebay:apis:ship” xmlns:skype=”urn:ebay:apis:skype” xmlns:wsse=”http://schemas.xmlsoap.org/ws/2002/12/secext” xmlns:ebl=”urn:ebay:apis:eBLBaseComponents” xmlns:ns=”urn:ebay:api:PayPalAPI”><SOAP-ENV:Body SOAP-ENV:encodingStyle=”http://schemas.xmlsoap.org/soap/encoding/” id=”_0″><SOAP-ENV:Fault><faultcode>SOAP-ENV:Client</faultcode><faultstring>End of file or no input: ‘No such file or directory'</faultstring></SOAP-ENV:Fault></SOAP-ENV:Body></SOAP-ENV:Envelope>
# curl https://api-3t.paypal.com/nvp
ACK=Failure&L_ERRORCODE0=81002&L_SHORTMESSAGE0=Unspecified%20Method&L_LONGMESSAGE0=Method%20Specified%20is%20not%20Supported&L_SEVERITYCODE0=Error
@sneader Yeah, that ticket is just WordPress trying to be nice to outdated software 🙂 But if that point release fixed the issue, then okay, though I still recommend updating libcurl, openssl and ca-certificates.
It might be outdated, but for the tens of thousands of servers (if not hundreds of thousands — cPanel keeps their license counts secret) running CentOS 6 / cPanel, it is what is being provided to us. It’s interesting that WordPress still insists on being backwards compatible to PHP 5.2, which is incredibly out of date and unsupported, but is pushing this type of update. But I disgress… I am pretty sure that the WP bug/defect fix likely solved this issue. I will remove the patch and see how it goes.
Thanks!
– Scott
Hi Scott,
Let me know if you get resolution to the issue. I’m reluctant to remove the patch if it doesn’t work as the site is active, and would need a working alternative if it doesn’t.
Thanks,
Stu
