I am setting up a website using osCommerce 2.3. The site is close to completion so I set up a PayPal sandbox to test the transaction/payment process. I am using the PayPal Express Checkout module provided with osCommerce. I inserted the sandbox username, password and signature into the module and tried the credentials test link. The test failed and the test debug email showed that no data was being transmitted by either $_GET or $_POST. Where do I go from here?
It turns out I am using WampServer 2.2.22, a 64-bit version which contains a buggy version of the curl.dll. Curl was refusing to load, so when it was making the call to PayPal in the sendTransactionToGateway function in paypal_express.php, the function failed. Working 64-bit versions of curl can be found at http://www.anindya.com/ for php 5.3.13 and 5.4.3. Replacing the old version of curl with the new one and restarting wampserver did the trick.
Related
I am trying to get a sandbox PayPal IPN working with the Coldfusion example shown here:
https://github.com/paypal/ipn-code-samples/tree/master/coldfusion
I've added the location of my IPN file to PayPal and the page is being called by it but all I get is a 'Connection Failure' message in the text file. The IPN file is being called from an https location so not sure what is wrong.
Any ideas?
The JRE (version 7) that comes with ColdFusion 10, doesn't support TLS 1.2, which you require to talk to the PayPal API. You need to either update the JRE to 113+ and enable TLS 1.2 via argument or upgrade altogether to JRE 8. To upgrade, you have to let the jvm.config point to the installation and replace the tools.jar in CF with the one from the JDK 8. (Also make sure to have at least update 14 installed on your ColdFusion 10 server.)
I have a PrestaShop installation with the following versions:
PrestaShop 1.6.0.14
PayPal add-on v3.11.1
When I try to checkout through Paypal, the server throws a 500 error. By checking the log file I've found this error:
Property Customer->passwd is empty at line 872 in file classes/ObjectModel.php
I suspect that the problem it's not actually the Paypal add-on, but as it's the only payment method currently supported by the site, I'm unable to check my suspicion.
Any idea?
Edit: It seems to happen only with logged in customers.
After I install the module and complete my API credentials I click the "save" button and I always get the following error:
Error !
You need to complete the PayPal identification Information in step 3
otherwise you won't be able to accept payment.
I already uninstalled and reinstalled the module.
PrestaShop version: 1.6.1.4
PayPal version: 3.10.6
Because of You install module that is unknown if it support PayPal's latest changes or not.
Seems like when You click save button it send CURL request to PayPal and tires to get necessary data. But response is not same as supposed to be.
If You're PHP dev: You've to debug that module,
otherwise: find someone to fix it.
I am getting empty array when call paypal setExpresschecout function with sandbox credential.
if i put live credential then its work fine.
This problem occur from last couple of week. before that the code worked fine on both live and sandbox credential.
Anyone have any idea?? Please Help.
Did you check which version of SSL/TLS your are using to make the API call?
PayPal recently upgraded to TLS 1.2 as you can see on their developer blog:
https://devblog.paypal.com/upcoming-security-changes-notice/#tls
For now it's only on the sandbox but they are going to do this on the live environment in the future.
It means if you're using TLS 1.1 or 1.0 for your API call it won't work anymore.
I had to update my test server because it was impossible to call their API anymore.
Up until today, I have been successfully developing with PayPal's sandbox using the new PayPal PHP SDK which comes preconfigured to use this sandbox URL:
https://api.sandbox.paypal.com/2.0/
(URL in Chrome currently returns: "Error 107 (net::ERR_SSL_PROTOCOL_ERROR): SSL protocol error.")
But today my webapp is crashing due to a SSL handshake failure:
Uncaught exception 'PPConnectionException' with message 'error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure' in ./paypal-sdk-1.0.92/lib/PPHttpConnection.php:185
The only event that has occurred since yesterday (when my webapp was last working) was I reset my sandbox "seller" account, which may have reset the API credentials according to this post. Since I've updated the API credentials manually, and have verified them to be correct, I cannot say if they were ever wrong at this point.
After lots of searching, I found other web articles that say the URL should be:
https://api-3t.sandbox.paypal.com/2.0/
(URL in Chrome returns a SOAP response.)
So I changed my PayPal PHP SDK's included URL from https://api.sandbox.paypal.com/2.0/ to https://api-3t.sandbox.paypal.com/2.0/ and it is working perfectly again. What happened here? Is the non-"3t" sandbox URL simply broken right now?
EDIT: After the feedback received from #Win and #JoelP, I have filed a bug report through the PayPal SDK github so someone at PayPal can explain what changed today and fix the SDK to have the correct URL when using Signature credentials.
EDIT 2: PayPal fixed the issue a few days ago. It's going to be available in the next release. https://github.com/paypal/SDKs/issues/22#issuecomment-8660682
Thanks for the help everyone.
Differences are between Certificate and Signature
Signature is the preferred way of accessing PayPal API.
The issue is fixed and the code has been pushed to master branch. You should see the refreshed bundles of the sdk out on x.com in the next couple of days.
Refer GitHub issue here https://github.com/paypalx/SDKs/issues/22
Thanks,
Prasanna.
I can't answer the question but I can say that I have just discovered the same problem. I confirm that jimp's workaround of changing the SDK's service endpoint config to :
service.EndPoint="https://api-3t.sandbox.paypal.com/2.0/"
solved my issue. (This is in the Paypal SDK config/sdk_config.ini file).
In my case I am using the PHP SDK. I have not changed anything on my sandbox account. My best guess is that the original URL is simply down for a while. (Firefox shows the "Secure Connection Failed" alert).