Enzo79

But I assume I can safely delete that section completely? I will make the suggested changes to this section, thanks for your input.

If set up a test copy of the site, what's the best way to update? Do I just use the update thing in the app, or is there less risk of it going wrong if I uninstall the payment modules, do the updates and then re-install them?

I too am having trouble with the TLS v1.2 Test... but have been using PayPal Pro Hosted for a couple of years and they haven't at any time contacted me or put any limit on my account, so am wondering if its just the test that doesn't work for me. PHP: 7.2.6 PayPal App: v4.039 Running on: BS 2.3.4.1 cURL Version: 7.59.0 cURL SSL Version: OpenSSL/1.0.2o I have tried the newer version of the paypal.com.crt off of Gary Burtons GitHub, but that hasn't sorted it. App can retrieve balance, and all the bits in the log are green. Does anything in the log tell me if its using TLS v1.2? The weird thing is I did accidentally break the Paypal app somehow a few days ago, and had to get my host to install a back up of the files and DB from 6 days ago to get it all working, but in that time I had tried to install various versions of the PayPal app but couldn't get any of them to work properly and load the iframe, but the TLS v1.2 test was passing using the newer versions of the app! Anyone got any pointers? I am reluctant to update the app, as don't want to break it again.

I have finally got it working... I really don't know what I had done, if I had done it, or if I just made things worse in the last few days trying to change to a newer version of the app... On comparing the old and new versions of the DB there were 18 rows from the Configuration table to do with PayPal that had gone missing. I started manually putting the missing ones back in one by one, and before I even completed it had an order come through! Thanks to everyone that has made some input, and I will make the changes to the .htaccess as advised.

Just as quick update the host have used a backup of my files from midnight on the 6th, and am now back to the PayPal app v4.039, but its still not working. They have done me a backup of the DB from the same time, and set it up as a new DB, so I can compare the current and old one. Am I right in thinking the only bits in the DB that I could/would have messed up in the meantime are in the CONFIGURATION table?

No, there are no subdomains or add-on domains. The only php_value ones are the ones that I think are commented out. # Fix certain PHP values # (commented out by default to prevent errors occuring on certain # servers) # php_value session.use_trans_sid 0 # php_value register_globals 1 Infact I don't think there is anything in my entire .htaccess that I don't mind posting on here... if someone could have a look over it and see what bits I can ditch, and end up with something that could cause me as little problems as possible. <IfModule mime_module> AddType application/x-httpd-ea-php72 .php .php7 .phtml </IfModule> RewriteEngine On RewriteCond %{HTTPS} !on RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} # $Id$ # # This is used with Apache WebServers # # For this to work, you must include the parameter 'Options' to # the AllowOverride configuration # # Example: # # <Directory "/usr/local/apache/htdocs"> # AllowOverride Options # </Directory> # # 'All' with also work. (This configuration is in the # apache/conf/httpd.conf file) # The following makes adjustments to the SSL protocol for Internet # Explorer browsers #<IfModule mod_setenvif.c> # <IfDefine SSL> # SetEnvIf User-Agent ".*MSIE.*" \ # nokeepalive ssl-unclean-shutdown \ # downgrade-1.0 force-response-1.0 # </IfDefine> #</IfModule> # If Search Engine Friendly URLs do not work, try enabling the # following Apache configuration parameter # AcceptPathInfo On # Fix certain PHP values # (commented out by default to prevent errors occuring on certain # servers) # php_value session.use_trans_sid 0 # php_value register_globals 1 <IfModule mod_headers.c> Header unset ETag </IfModule> FileETag None ## EXPIRES CACHING ## ## https://gtmetrix.com/leverage-browser-caching.html ## <IfModule mod_expires.c> ExpiresActive On ExpiresByType image/jpg "access plus 1 year" ExpiresByType image/jpeg "access plus 1 year" ExpiresByType image/gif "access plus 1 year" ExpiresByType image/png "access plus 1 year" ExpiresByType text/css "access plus 1 month" ExpiresByType application/pdf "access plus 1 month" ExpiresByType text/x-javascript "access plus 1 month" ExpiresByType application/x-shockwave-flash "access plus 1 month" ExpiresByType image/x-icon "access plus 1 year" ExpiresByType application/javascript "access plus 1 year" ExpiresDefault "access plus 2 days" </IfModule> ## EXPIRES CACHING ## <Files 403.shtml> order allow,deny allow from all </Files> deny from 46.229.168.65 deny from 46.229.168.66/31 deny from 46.229.168.68/30 deny from 46.229.168.72/30 deny from 46.229.168.76/31 deny from 46.229.168.78 deny from 46.229.168.79 deny from 46.229.168.80 I don't really know what I am doing, and tend to learn as I go... but from what I can understand, the first bit lists all the versions of PHP I can run, so can try and roll it back to an earlier version of PHP7 until they remove it. The next bit is the redirect to make sure everything is .https, but will switch that out for JCMagpie's version. Not sure what next bit is, and the bit after that is to do with caching, but I have never put that in, must have been done by the host. I do have problems with some browsers not loading the newest versions of pages on my site, IE especially, so maybe that section needs a tweek. The last bit I assume is where I have blocked some URLs that were trying to do some weird stuff, like stuff added on the end of URL's, but when I googled the URL they were trying it keep coming up with wordpress vulnerabilities, but I don't use wordpress so guessed it was people just trying stuff incase you did.

Whats the difference between the way the host told me to do it and the way you have recommended? RewriteEngine On RewriteCond %{HTTPS} !on RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} vs RewriteEngine On RewriteCond %{HTTPS} off RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

I have spoken to host, and they have nightly backups at midnight and keep them for 6 days, so can roll me back to midnight on the 6th. I had an order at 22:11 on the 6th where the customer paid straight off a credit/debit card using the PayPal Pro Hosted which uses the iframe, so was definitely working then. Fingers crossed the backup works.

In a schoolboy error kind of way I don't have backups of either. The only change I made was adding the following code to the .htaccess file, as when visitors first came on the site the index.php page wasn't secure, and obviously now throws a warning in some browsers. RewriteEngine On RewriteCond %{HTTPS} !on RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} My last edit to .htaccess file was on the 2nd September, so don't think this has anything to do with it either.

I spoke to them yesterday and they said it was on 7.1.2 they actually did the switch back on the 23rd of August, so as it was working fine until the 7th September I don't think this is my problem.

It all seems fine to me... cURL Version: 7.59.0 cURL SSL Version: OpenSSL/1.0.2o Default Setting: Success TLS v1.2: Success

I don't know if its something I did, only changes made recently were so whole site was made secure, and a recent switch to PHP 7.2.6 by the hosting company, but over the weekend something seems to have gone wrong, and now have no end of PayPal related problems. Site runs on a BS version of 2.3.4 from about this time last year, and was using the PayPal app, using both the Express Checkout and Payments Pro Hosted parts with no problems. Since the weekend when you go through checkout and select the option for paying by card (PayPal Payments Pro Hosted) it used to open up in a iframe on the checkout_confirmation.php page, but for some reason nothing now shows up, and you are left with a checkout_confirmation.php page with the bottom bit missing. The Express Checkout thing will also sometimes be a bit sketchy, as I seem to be able to stuff in a weird order to get it to kind of work, but other times it will throw a 500 error, but not one that ends up in the error log, and have spoke to the hosting company and they have said its an Apache error and is just that the script timed out. Various bits in the app seem to work, it can fetch my PayPal Balance, and passes that TLS V1.2 test, but if I try and get it to automatically retrieve my API credentials I click on the button and it thinks about it for a while, and then throws that same '500 Internal Server Error' As an emergency I have switched to using PayPal Standard so I can take some sort of payment, and that pretty much works, as I can put through real test orders using my own personal PayPal account to pay, and the order will come through and show up in admin, but don't think it ends up on the right page when it passes the customer back. It is a live site, and any assistance would be greatly appreciated.