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.
Related
I have a website that integrates with authorize.net and received a notice that they are upgrading their certificates so that they are signed using Security Hash Algorithm 2 (SHA-2). Specifically, that their API services will use EnTrust’s SHA-256, 2048-bit certificate.
It goes on: "Please contact your solution provider and web hosting company to ensure your solution has these certificates installed and is capable of using them to secure your connection to Authorize.Net. "
When users connect to the payment pages on my site, they are on a secure connection (DigiCert SHA-256 certificate), but I'm not sure if that means that my site's connection to api.authorize.net is similarly secured.
Sorry for asking what is probably a very dumb question, but how can I find out if this change will require any re-coding on my end, and how can I check that my site's certificate is going to work?
Thanks so much for your help!
I also got the notice from authorize.net, but fortunately for me our hosting site's admins took care of it. I got a similar notice from PayPal, which is also upgrading their certificates for SHA-256 compliance. In researching that one I came across this related Stack Overflow question: How can I tell if my paypal certificate is SHA-256? - PayPal service upgrades.
One answer links to this github gist which uses openssl and awk to check the installed certs. If you run it and see the certs that authorize.net has upgraded too listed, that should tell you your server will work. This is a assuming you're on a Linux server. Disclaimer: I'm no expert on dealing with SSL and servers - I'm chiming in only because no one else has.
I'm looking to integrate Sagepay Direct, their onsite payment gateway option but I've read that it requires an SSL certificate for secure data transfer. Is the Cloudflare pro DNS SSL a valid option for this payment method or would I need a true onsite SSL?
"Is the Cloudflare pro DNS SSL a valid option for this payment method or would I need a true onsite SSL"
It sounds like that they are requiring that you have a valid SSL certificate directly on your server, something we don't provide (Flexible would only do so between browser and our network). This really explains the difference in the SSL options.
I have a website that plans on accepting payment orders. My host (heroku) offers piggyback ssl (free). My payment gateway (stripe) needs ssl in order to process payments. Is heroku piggyback ssl enough to process stripe payments?
From stripe's site:
If you want to go into production before setting up SSL, you could consider hosting your site with a provider that gives you a secure
subdomain. For example, Heroku allows you to host at
https://yourapp.heroku.com.
Yes it will work fine.
You could even use a custom domain for your http traffic and then the https://yourapp.herokuapp.com for your SSL if you want to keep the cost down rather than having to buy an SSL and pay for the addon.
I am developing a event website ( on php and mysql ) which requires online payment for event registration. The payment gateway we have purchased from a bank. The bank asks us to have SSL certificate for our website.. As banks websites usually have Verisign certificate therefore the people with whom we had a conversation told us to have verisign SSL certificate on our event website
When i checked Verisign.com then i found that there are many types of certificates available.
Secure Site Pro with EV
Secure Site with EV
Secure Site Pro
Secure Site
I want to know, is it enough to have the most basic of all.. what difference does it make with different options which are available with verisign. i still believe that the people at the bank have no knowledge of other companies providing SSL certificates. So can i use godaddy or other SSL Certificate providers instead of Verisign.
please help if anyone have worked with payment gateways and SSL Certificates..
You can use any SSL certificate you want. The SSL certificate and payment gateway are independent of each other and one does not directly affect the other. So you can use Godaddy or any other SSL provider you want with your payment gateway.
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.