When sending customers to Paypal from my website I am seeing a new error message I've never spotted before:
Error Detected
We are sorry, we are experiencing temporary difficulties. Please try again later. If this error occurred while making a payment, avoid duplicate payments by checking your Account Overview before resending a payment.
Message 3005
Googling this message suggests it is just one shown to the general public when Paypal is overloaded....but I don't think that can apply to me becuase the Paypal site responds normally to other parts of my website which use a HTML link. It is when I use an ASP.NET Response.Redirect that I see the error.
I have checked the URL is correct and encoded correctly. So I really would like clarification that message 3005 is indeed one that can be shown when the incoming request is erroneous, as well as when the Paypal site is under heavy load.
Is this generic message shown in both circumstances? Is Response.Redirect acceptable?
"Googling this message suggests it is just one shown to the general public when Paypal is overloaded..."
And that's why you can't always trust Google results.
No, a '3005 error' does not mean PayPal is 'overloaded'. It is a generic error which can be returned for various internal and external reasons.
It's the PayPal equivalent of 'Something went wrong', without actually saying what went wrong.
Can you reproduce this error consistently? And if so, what are the steps to reproduce it?
Can you include your code?
Related
I am integrating Woo-commerce API’s in my wordpress site using Woo-commerce official rest sdk. I made a link using authentication endpoint URL. When I click the link it takes the user to Woo-commerce authentication page, where user login and Approve the request.
After approving the request it should take me to return url which i mention in the link. Instead it shows me the following error.
Error: An error occurred in the request and at the time were unable to send the consumer data.
I was having the same issue as well, and in my case, the return_url on my backend server was accepting GET requests, I changed it to POST, and everything worked perfectly. I hope it helps!
I know it's late for the answer but writing it for the people who will face the same issue in the future.
I was having the same issue and my problem was that the callback_url was wrong which was creating the error internally. So if you are getting this error, most probably your callback_url is not correct, please check that properly.
For whoever Shattique's answer
did not work,
check the response status code sent by the callback_url handler.
Anything other than 200 will throw the error in OP's question.
Here is link to woocommerce github repo,
where it throws the error.
TLDR: Make sure callback_url handler returns statusCode: 200
I am at my wits end with the following problem:
My site www.sebastianthalhammer.com is available under that URL without any problems.
However Google Search Console as well as other external third party test tools return a 404 error.
Status report from Uptrends
It is just the main page that's affected. All the other subpages and blog content isn't affected.
I have been in contact with the server stuff but it seems alright to them. As mentioned. The site can be reached. The site runs on wordpress - latest version.
I have no real clue where to start as this error seems to be quite a tricky one. Does anyone here might have an idea what's going on?
Sebastian
The 4xx class of status code is intended for cases in which the
client seems to have erred. Except when responding to a HEAD
request, the server SHOULD include a representation containing an
explanation of the error situation, and whether it is a temporary or
permanent condition. These status codes are applicable to any
request method. User agents SHOULD display any included
representation to the user.
This leaves me with two possible explanations:
Explanation 1: it's a server error.
the server wrongly returns a 404 status code
the browser thinks the response body contains details about the error and displays it - for the end user this is the actual page
Explanation 2: it's done on purpose to defeat crawlers and page watchers.
the server returns 404 on purpose - non-browser user agents won't process the result as they interpret it as error
browsers are unaffected, the end user doesn't care as long as the page is being displayed
The second one would indeed be kind of clever if you don't want your page to be indexed.
Thanks to your feedback I could think about the problem in a different way.
Ultimately at the unholy depths of a certain plugin I could dig out a setting that caused the error.
It was a redirection plugin that (for whatever reason) sent out a 404 signal when the URL was requested.
I don't know what the purpose would be for something. All I know is that the setting was on default for quite a while now and that caused the weird situation.
thanks guys for getting me on the right track.
Sebastian
I am a new member.
I have an error when send message using HTTP Post to "graph.facebook.com/v2.11/me/messages?access_token=MY_PAGE_TOKEN"
This is error return:
`{"error":{"message":"(#100) Tried accessing nonexisting field (messages) on node type (Page)","type":"OAuthException","code":100,"fbtrace_id":"EB39Xkxnf6O"}}`
Despite error, tester and developer still able to receive message. But the FB viewer might not and they not approve my review submission:
"We did not receive an automated response when we messaged your Page. Bots should respond to all input from the user within 30 seconds so that the experience feels like a continuous conversation. Please ensure that your experience is functional before you resubmit."
The log show same error with FB viewer when server trying to response.
Any help. Thanks a lot
As the documentation explains you are required to submit a {conversation-id} before the messages.
More info here
After a few days we always get this email from paypal when someone is paying with paypal on our onlineshop:
Please check your server that handles PayPal Instant Payment
Notifications (IPN). IPNs sent to the following URL(s) are failing:
[OUR_SHOP_URL]/commerce_paypal/ipn/paypal_wps%7Ccommerce_paymen
t_paypal_wps
If you do not recognize this URL, you may be using a service provider
that is using IPN on your behalf. Please contact your service provider
with the above information. If this problem continues, IPNs may be
disabled for your account.
Thank you for your prompt attention to this issue.
Sincerely,
PayPal
We are using Drupal Commerce on Drupal 7. The "funny" thing is: Sometimes this error appear, sometimes not. When this error appear the Drupal-Commerce can not set the Payment status to "Completed" so it costs a lot of time to do this manually ...
I found a "solution" for this here but the *.patch does not removed the problem: https://www.drupal.org/node/1055390
Any other solutions ? :/
Edit:
When take a look at the drupal recent log messages I can find the error which was tracked.
Here's the information I get:
Type commerce_paypal
Date Thursday, October 9, 2014 - 13:15
User Anonymous (not verified)
Location [URL]/commerce_paypal/ipn/paypal_wps%7Ccommerce_payment_paypal_wps
Referrer
Message IPN URL accessed with no POST data submitted.
Severity warning
Hostname 173.0.81.1
Operations
Edit 2:
We found smth ... We have HTTPS. I jsut treid to use the HTTP Url. And ... this works fine. But we want to be at HTTPS isntead of HTTP. But maybe it will help you whats happened here ?
This seems to be an issue with Paypal itself - a user noted that sometimes the Paypal callback is encoded, thus pipe characters ("|") get encoded to "%7C". That user has described your problem - it's very hard to debug this issue, as it only occurs sometimes.
Here is a link to the issue, along with a small patch:
https://www.drupal.org/node/1055390#comment-7436538
This issue occurs on Paypal itself, although I am wondering why this patch hasn't been included in drupal commerce itself...
You need to check your web server log files to see exactly what error is happening on the failures. You'll be able to see the PHP error that you would typically see on screen when something is failing like that.
That will give you direction on what is going wrong and what you might need to do to fix it.
Another thing you could do is replicate the IPN that failed yourself and POST it directly to your IPN listener in a browser so that you can see the result on screen. This can help with troubleshooting and debugging. Just create an HTML form with the action set to your IPN URL and then add a bunch of hidden fields that match the names/values you got in an order that failed. That would trigger the same error so you can see it.
Here's an interesting one for you.
I've got my custom 500.aspx setup which is called when a 500 error occurs in my application. The 500.aspx also sends me an email with the error details.
I've noticed one small problem.
If you attempt an xss attack on the 500.aspx itself, the 500 page is not called.
This is obviously some sort of logic issue.
In fact, microsoft themselves suffer from the same issue.
See it in action here
http://www.microsoft.com/500.aspx?aspxerrorpath=%3Cscript%3Ealert(%22XSS%22)%3C/script%3E
How can I prevent this?
Ed
If you attempt an xss attack on any page, the custom error page will not be called (here's another random page on Microsoft.com with xss in the querystring).
The behavior appears to be intentional to stop the attack dead in its tracks. Even the error message indicates this behavior:
Request Validation has detected a
potentially dangerous client input
value, and processing of the request
has been aborted.
The only workaround appears to be to disable validation or to capture and handle the error in your global on Application_Error.
It appears that once you define a page to handle specific(or non specific?) errors, it is no longer available directly via its url, sorta like the Web.Config cant be called via the browser.
I would set up a 500Test.aspx which throws an exception causing a 500 error (and thus fires the 500.aspx)
That might work.
You might want to think about handling your errors in the Application_Error event in Global.asax.cs instead of the 500.aspx page. You could put the email code there, then redirect the user to an error page after you've done your error handling (this is how we do it where I work).