According to this, paypal developers need to update their machine. My question is, how can we know that our application is ready for these changes?
Thank you.
You can check your SSL details using this tool. You just need to make sure it's showing SHA256 and TLS 1.2 for the enabled protocol. It will also give you details about any potential vulnerabilities you need to fix up in general.
For the IPN change that's really just up to you to make sure you've made the change. Within the IPN script you POST data back to PayPal. You need to make sure you're using https:// on the URL that you're POSTing back to. They will reject http://.
That's really all there is to it.
Related
I tried finding an answer here but can not.
I've been using this code to process PayPal IPN for over a decade! Now, as of July 2018 it no longer works!
https://github.com/paypal/ipn-code-samples/blob/master/asp/paypal_ipn.asp
The only thing I know that is different recently is that PayPal required my domain to use TLS 1.2. I asked my hosting company to make sure that it now uses that, and they made some change to make sure. Ever since then, the listener I have set up does not process the IPN correctly. The code always falls into this IF:
if (objHttp.status <> 200 ) then
And never falls into this ELSEIF the way it used to when it was working fine:
elseif (objHttp.responseText = "VERIFIED") then
I'm not even sure how to troubleshoot this at this point. Is it something about the TLS 1.2? How can I make sure my hosting company set that up correctly?
Does my listener have to be located at an HTTPS url on my site? (Right now it is on HTTP).
Thanks.
In February, I got an email notice from Paypal that IPN would no longer validate successfully via an HTTP callback, and would further require HTTPS/SSL to validate. Update your script to connect this way, and it will probably fix it.
This PHP example should give a reasonable example.
Line 142:
" $fp = fsockopen("ssl://www.paypal.com",443,$err_num,$err_str,30);"
I had similar issues previously when connecting to Paypal on port 80.
I'm using ASP.Net Membership Provider for logging into the premium content of this web site. The content isn't downloads, it's web pages of information and discounts, etc. That part is done. We want them to also have a PayPal Subscription annual payment to see the premium content. I would like ASP Membership and PayPal Subscription to work together as much as possible, but for the minimum I am thinking they will have to create a MemberId before they pay. Then I will send that MemberId to PayPal to associate the two.
I think I can do that like this:
Set "Auto Return" on in the interface so that it will redirect to return URL when payment is made.
Set "return URL" query string to MemberId. This requires not using the precompiled "Saved" buttons. I'll have to set it in Code Behind with Name Value Pairs, "NVP" to PayPal. I was hoping to just paste the stupid button.
But then, there were those "Advanced Variables" in the Button maker. Problem was they are compiled into the Saved button, so I can't change them for each person. But maybe that one parameter could be separate from the compiled parameters? Is this better than hacking the return URL? Are "Advanced Variables" good for anything?
All the details about the transaction will be POSTed to the return URL if I put in the right code, which might be rm=2. (Right?) Then I can record it.
This process is said to be unreliable, though, and PayPal recommends using a secondary system that they have, "IPN". PayPal sends the transaction details to me. I send them back http 200 code. Then I send it back to them in the same order I got it. Then they send me http 200. Then we all know it's good. This sounds like a few hours research to me, but if you've already done it once, it sounds like copy and paste. I hate reinventing the wheel. Is there a .Net sample of this IPN handshake/dance?
Also, if I do the IPN thing, maybe I don't need Auto Return. Maybe I add MemberId to "notify" URL instead of "return" URL. Then PayPal can handle the confirmation page, email, etc. Is that better?
Assuming we get the Subscription paid for and recorded with the MemberId, at least once per user session, after they log in, I have to check if they have paid their PayPal subscription and if it's up to date. "GetRecurringPaymentsProfileDetails" does this, but it is an API operation. That makes sense, but I was hoping to avoid learning their REST API. (Is there a "NVP" version?)
REST API OAUTH tokens expire every few minutes, but the only way it tells to get one is by using "Bash" to "cURL" some Linux commands. Again, this seems like the kind of thing that would only ever have to be written once. Does this already exist as a sample code somewhere?
(I don't want to use the API to do the Subscribe, because I don't want the Credit Card numbers to ever go to our site. Too much liability. That's why I wanted PayPal.)
Will this even work? I know PayPal has 18 ways to do everything and they all exclude each other, and I'm just getting the feeling that I'm creating a patchwork of unrelated ideas to fool myself into believing there's a light at the end of the tunnel. I've already been researching and experimenting for 10 hours or so. I really thought, going in, I'd just be pasting a stupid button.
If you want to just "copy the stupid button" then you'll have to stick to Payments Standard, and then you'll be limited with what you can do. For example, you won't be able to use GetRecurringPaymentsProfileDetails for a standard subscription.
Instead, you'll need to use Express Checkout and / or Payments Pro. There is indeed an NVP API available for these, and there is also a SOAP/XML version. Details on those can be found here: https://developer.paypal.com/docs/classic/api/
Specifically, for Express Checkout, you'll want SetExpressCheckout, GetExpressCheckoutDetails, DoExpressCheckoutPayment, and CreateRecurringPaymentsProfile. Some of those calls are optional depending on how exactly you're configuring things with the checkout flow.
For Payments Pro you'll use either DoDirectPayment / CreateRecurringPaymentsProfile or PayFlow depending on what version they put you on.
In any case, IPN is definitely the way to go for post-transaction processing.
.NET IPN Sample - https://github.com/paypal/ipn-code-samples/blob/master/paypal_ipn.asp
After paypal updated their interface (sandbox.paypal.com for example is not working, now you have to go to developer.paypal.com) many of the things are not working: 2 of them are particularly frustrating and I was hoping someone here knew how to get around them:
Am I the only one whose sandbox customer test accounts are not able to make purchases? The transaction page says they are not available.
IPN validation is not letting me send a https request. When I do it says there is something wrong with the server name. Yesterday however before the update I could get verified status. If I dont put https, now my handler gives me an invalid responde status, code: 400. What does it mean?
To fix the HTTP 400 error, follow the instructions in https://www.x.com/content/bulletin-ipn-and-pdt-scripts-and-http-1-1 and update your code to pass "Host" information. Ideally, things should work with just the recommended changes from the above link. Apparently, thats not the case. Here is a fix from one of the PayPal MTS person - PalPAL sandbox IPN processor rejecting all messages?
Remove the "cmd=notify-validate" option from the validation URL. I tried this and it worked. Though it doesn't return the right string, atleast it doesnt break with the 400 error.
While we wait for a fix from Paypal, I wonder how a company like PayPal can cause such a huge blunder and not post anything on their status page - https://www.x.com/developers/paypal/documentation-tools/site-status/pp-cri. It just makes you think that even smaller companies can do a better job than companies like PayPal.
For the code:400 issue, you have to update the post to version 1.1. That information is located here.
https://www.x.com/content/bulletin-ipn-and-pdt-scripts-and-http-1-1 in this bulletin.
However, as I posted before the asp.net example uses a call, that does not exist, so I was only able to get mine partly working. After fixing this, the servers appear to be rejecting calls to https, or the cert they have installed is invalid.
Action Required before February 1, 2013
Merchants need to update their IPN and/or PDT scripts to use HTTP 1.1, and include the “Host” header in the IPN postback script. In addition to this bulletin, these merchants will be notified via a direct email.
Alright, seems to be fixed!
If you are having trouble logging in, like suggested above, clear cache and cookies and try again.
Regarding the error 400, seems to have been solved by paypal!
I am trying for the first time to setup Paypal PDT and want to test it against the sandbox.
When I try to go to http://sandbox.paypal.com, I am getting forwarded to https://www.sandbox.paypal.com/hk/webapps/mpp/home , then I get an error generated by Tomcat (404).
Is that normal? Is this site to be used only though APIs and am I doing something wrong when opening it directly in a browser?
Under the FAQ, I can read that
I'm a non-U.S. developer. How does the site redesign affect me?
The current new REST APIs and PayPal Mobile SDKs are currently
targeted for the US market only. We will be rolling out in all
geographies over the rest of the year.
Is this a reason for that? Is the sandbox a part of the REST API?
I apologize for the inconvenience. We are working to fix this as soon as possible. In the meantime please try using https://www.sandbox.paypal.com/webapps/mpp/home as a workaround to log in.
Just wanted to follow up and to let you know that the 404 issue has been resolved.
Nope, it's broken for me to in the UK. I tried using a US proxy, and it seems that it's broken for everyone, no matter where you are.
Best to just sit it out and wait, although in the meantime I'm going to be using something else. Way to go, PayPal.
I was useing a free web hosting , but now i want to find a new one that support the connection with paypal for ipn,see this topic to know what I am talking about
http://www.zymic.com/forum/index.php?showtopic=33328&st=0&gopid=141044&#entry141044
i alrdeay post this quetion but they told me "questions about free web hosting recommendations are off topic for Stack Overflow".
so i am not asking a recommendation.
my quetion is : what is the feature that must be provided in a webhost so my ipn script works?
I am not sure I understand your question of "What is the feature that must be provided in a webhost so my IPN script works?". The IPN is a POST back to your system, and then your system responds to PayPal's POST to validate the information. You can set this up in different languages, and it can be set up a a windows or linux server. Then its a matter of what you are wanting the IPN script to do with the information. You would want to make sure you are sending the post to a secure url https:// Can you be more specific of what you are asking?