I've been working with the REST API for PayPal and I'm able to get the sales, refunds, etc processed without an issue. But I am having an issue with the webhooks.
I have a webhook configured in sandbox and it never posts the information to the webhook URL (doesn't even attempt to according to the access logs).
Since wbehooks required https I was wondering if there is an issue with using self signed certificates with webhooks? It's the only thing I can think of to prevent PayPal from accessing the URL short of PayPal's sandbox being glitchy (I know, that NEVER happens). I can get IPN to work with the self signed but iirc SSL isn't a requirement for IPN.
HELP, PLEASE...
~ Wranorn
Hey this is Avi from PayPal. Self signed certs should not be working for webhooks, if you want to test out a different endpoint you can use something like ngrok to test it locally. Otherwise it would be useful to know debug id received from PayPal for the payment execution call. There are some existing service issues for webhooks on Sandbox currently that could be contributing to this, and those are being actively worked on.
Related
I want to be able to expose my local machine address to the internet to be able to work with:
Google OAuth2 flow;
Receiving Push-Notifications for changes in my calendars/events;
So that, I need some tool that will expose my local machine URLs to the Internet so Google will be able to use this web hooks.
I found that ngrok with basic(5$) subscription works for me. Free versions doesn't work since I need SSL as it's required by google:
This is your Webhook callback URL, and it must use HTTPS. Note that
the Google Calendar API will be able to send notifications to this
HTTPS address only if there is a valid SSL certificate installed on
your web server. Invalid certificates include: • Self-signed
certificates. • Certificates signed by an untrusted source.
• Certificates that have been revoked. • Certificates that have a
subject that doesn't match the target hostname.
The question is whether there is something else I haven't taken into account that will force me to buy more expensive type of subscription? Maybe some specific requirenments from Google that basic subscription can't work with.
Basic $5 subscription works perfectly. It fits all Google's requirements + it provides static URLs that make it possible to receive PUSH notifications even when you restart your ngrok or computer.
this year paypal have been informing site owners they need ssl with HTTPS requirement for IPN Postback and SHA-256 etc
I have a website which uses woocommerce, I pass my checkout basket to paypal to process the payment and get a success or fail back to add an order onto my site.
Do I need all this SSL etc on my site even though im using a cart which doesn't process payments itself it hands data to paypal to process?
or can I carry on with no ssl
thanks
No, you don't need SSL on your site. In fact, the notice regarding IPN explicitly says "there is no requirement for HTTPS on the outbound IPN call from PayPal to the merchant's IPN listener".
The changes that are coming are in regards to PayPal's setup. Since part of the process in receiving an IPN is posting it back to PayPal for verification, you need to make sure that your system will still be able to communicate back to PayPal after the changes are done. Since WooCommerce runs on PHP and cURL, this will mean making sure that the underlying SSL libraries are up-to-date:
Most servers use OpenSSL. If this is the case, you need to make sure that you're using at least version 1.0.1.
Some Linux distros (centOS in particular) use NSS instead of OpenSSL. If this is the case, you'll need to make sure that you're using version 3.15.1 or better.
If you're unfortunate enough to have your store hosted on a server running OS X, you'll need to make sure that the server is running OS X 10.8 or better.
Since almost all PHP and cURL setups get all of their SSL/TLS capabilities from one of these libraries, this should be all most people need to do.
About a week ago I got the email below from Twilio letting me know about security updates and the possibility of compatibility issues on applications using older SSL client libraries. My app is hosted on Heroku, is not using a custom domain and piggy-backs on their SSL. This issue isn't an issue for me, is it? Heroku is usually on top of security and up to date on these things but googling I only find info on setting up SSL for custom domains on Heroku. Anyone have any ideas?
Twilio View Online Reminder: Security Certificate Changes
This is a reminder that on December 1, 2015 at 4:30 PM PT, we’ll be
updating api.twilio.com with a SHA2-signed certificate, a significant
improvement in encryption technology. From the official announcement
on October 8, 2015: Though the vast majority of applications will not
be impacted in any way, there is a possibility that applications using
older SSL client libraries may run into compatibility issues. To
verify that your application is compatible with the new certificate,
we’ve provided a test API endpoint at api.twilio.com:8443. Please note
this endpoint uses a different port from the current default port of
443. Make sure you specify that port in your Twilio SDK.
The validation endpoint will be deprecated on December 1, 2015 when
the new SHA2-signed certificate is deployed to the main Twilio API
endpoint (port 443). Please let us know at help#twilio.com if you have
any questions. We’re always listening and we’re here to help.
Cheers, Team Twilio
Twilio developer evangelist here.
This warning is not about your domain, but the SSL library on the platform on which you make API requests to Twilio.
Since you posted this question not long before the cut off came and it is now gone, I can't give you advice for testing this before the old certificates are removed. Basically, by now, if you are not seeing any errors in your application that makes calls to the Twilio API, then you are safe.
As you said, Heroku are normally on top of things like this and keep their SSL libraries up to date, so you should have nothing to worry about. I just spun up a dyno and ran some tests and everything seemed to work fine, so I suspect you have nothing to worry about.
If you were to have tested this before the change was made, you could have used the test endpoint on port 8443. In Ruby (I'm not sure what language you're using, but it's a good example anyway) you would do this:
require 'twilio-ruby'
account_sid = "AC123..." # your Twilio account sid
auth_token = "xyzabc..." # your Twilio auth token
client = Twilio::REST::Client.new(account_sid, auth_token, port: 8443)
Then, make any call to the API and check that it works over this port.
client.messages.list
If it does work then you are safe and have nothing to worry about.
We're using PayPal REST API for processing user transactions and recurring payments. In few weeks we are going online, and the last piece of information I need is SSL certificate. Do we need to install SSL certificate on our website in order to PayPal integration work well?
Thx!
The answer is no, you do not have to install a SSL certificate on your website in order to work with PayPal API properly, but your server has to be able to establish secure connections with PayPal servers.
For testing purposes I have and SSL certificate set up on a dev site where the domain does not match SSL domains valid for that certificate.
Would it still be possible to validate credit cards with Authorize.net even though the certificate domain is invalid?
It depends on how you are communicating with authorize.net, but when I did it, I sent a request from my server to their's to authorize the transaction. So, they never saw my SSL certificate, because they never sent a request to my web server. So, to answer your question, assuming you are authorizing the transaction by initiating an SSL connection to their server, then it shouldn't matter one bit if you have a valid SSL cert or not.
That of course was the technical answer. As for what their rules might be, I couldn't say.
Yes. This is because the the data being transmitted to Authorize.Net is being sent from server to server which is not using your installed SSL certificate. So although the user might be seeing an invalid certificate Authorize.Net will not. Plus they do not care if the certificate is with the proper domain name as long as they data is encrypted on your end.
Of course a better even answer would be to try it out. That's the best way to know for sure. Sign up for a developer test account and run some test transactions.
Authorize.net's code library has several parameters you can set to indicate you are doing a test transaction, in which case it shouldn't worry about your ssl cert. Would probably depend on which of Authorize.net's payment api's you're using though. I know this is generally how it works with their CIM library.