I have been using a Xojo Web IPN listener for a while. Lately I got some alerts about it from Paypal.
Today I got the letter below. Looks like I have work to do.
This year, weve made a number of upgrades to the PayPal system enabling us to continue providing the highest level of security available for customers. Throughout 2018, we will continue to upgrade our security protocols to the highest levels of protection available, which includes moving all of our systems to TLS 1.2, an enhanced security protocol that encrypts customer data over the Internet. We also announced several new security requirements for merchants who use PayPal, to ensure they do their part to protect sensitive customer data, as well.
Our records indicate that you still need to make critical security upgrades to your systems. If you see a YES next to a security change, your integration must be updated to accept these new security measures as soon as possible.
Change
Change Required?
Merchant API Certificate Credential Upgrade No
TLS 1.2 and HTTP/1.1 Upgrade No
IPN Verification Postback to HTTPS Yes
Discontinue Use of GET Method of Classic NVP/SOAP No
If you have not made the necessary changes by the date specified, you wont be able to accept payments with PayPal until you do so. But most importantly, failure to make these upgrades will put your customers sensitive personal and financial data at risk.
From the old Real Developer’s Spot website, I’ve imported the Open Source PayPal Payments Classes that I originally developed for the community over to XDS. The classes utilize the actual PayPal API’s, and do not rely on just a ‘call-back’ URL from IPN. The API supported is for direct payments, so you can accept payments without the user ever leaving the website or desktop application, and get instant notification of payment. 
In the above, your connection looks secure, all but the callback URL that you provided to the API interface (at paypal.com) should be HTTPS, not HTTP.
Figured I’d re-put these classes out into the community since it’s been a while… and it’s a great way to save $300!
Merry Early Christmas Everyone!
For your post back socket just convert it to Xojo.Net.HTTPSocket and you should be good to go.
Phillip,
It looks like the link is no good. Can you please confirm?
Thank you,
Tim
[quote=365922:@Tim Seyfarth]Phillip,
It looks like the link is no good. Can you please confirm?
Thank you,
Tim[/quote]
It wasn’t meant to be a link, the forum software made it so. It’s just a Xojo class name:
http://developer.xojo.com/xojo-net-httpsocket
It is already a Xojo.Net.httpsocket. I will see next week what is going on. I don’t quite understand how to set things like TLS 1.2, though.
Thank you Phillip.
That is very odd. Currently the class does not let you specify a TLS setting. However it should default to what the server supports. My guess is it is currently defaulting to the lowest (say TLS 1.0). So when PayPal shuts off TLS 1.0 and 1.1 I suspect it will still work.
Actually, apparently Paypal detects TLS 1.2. You are probably right, the only hurdle seems to be https.
I believe i’ve had the same issue when trying to connect to the quickbooks online api. My issue was not being able to get xojo to send out the proper headers using https. TLS 1.2 is not the issue and can simply be set.
dim request as new HTTPSecureSocket
request.Secure = True
request.ConnectionType = SSLSocket.TLSv12
But my issue i continue to believe is with a flaw in EncodeBase64 to generate an authorization header from the Client ID and Client Secret Keys.
i’m have not tried to do this with Paypal api but you can take a look at what my issue that might help you. https://forum.xojo.com/42715-quickbooks-online-api-oauth2-httpsecuresocket/p1#p347647
Thank you NIcholas. Seems to have been a temporary glitch in their servers, actually. I did not do anything, and the problem went away.