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.
Related
I have a setback I hope you can help me
the following happens
I'm doing a test of the payment gateway of my website and what happens is that once inside the checking (or about to make the payment) when I go back it sends me back to the page to finalize the purchase (so far so good) .
the problem is that it seems that when doing that some options on the page disappear and when trying to go to the home page
I get an error 414 for URl too long.
and I can not access the page again until I exit the browser clear cache and reopen
I know that this can be solved by modifying the Apache httpd configuration, however it seems to me that it is not correct.
I use Wordpress with Woocommerce and CoinPayments gateway
I do not put my web address because I do not know if it is allowed by the forum, thank you very much in advance.
I've encountered a weird situation, after registration we're sending an email with a verification link, pretty standard stuff, but somehow clicking on the link seems to make the request twice, looking at the logs, the first time it comes from my IP and the second request comes from some Google IP: 66.102.8.60 (doing a reverse lookup shows google-proxy-66-102-8-60.google.com).
Any idea what's going on and how to prevent this?
The server is running Nginx and the site is Ruby on Rails if that helps.
I do not know the root cause but my best guess is same as Tripleee wrote above - most probably google is scanning urls. This happens in all browsers (well at least in Chrome and Firefox), but only under following circumstances:
the url is clicked from gmail (if you copy paste it to browser tab, the second request is not issued)
the url is clicked for the first time... Subsequent clicks from the same email do not trigger second request
I know it is probably not the answer you expected, but after giving it some thought I figured that operation like this should be handled on server side. In my case I am tracking information about confirmation urls anyways, so the first time the request comes to my backend I am deleting it and proceeding with confirmation normally. Since the confirmation entry is missing in the database for the second request it returns immediately with status 404, 422 or something whatever suits you.
Hope that helps anyone who gets here looking for an answer to this problem ;)
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 integrating payfort in wooCommerce site, I have installed the payfort plugin, and configured according to my payfort test account settings.
Now on checkout its showing error
There are some issues with the items in your cart. Please go back to the cart page and resolve these issues before checking out.
I tried to check order history on wooCommerce which showing transaction status pending, then I checked on payfort test account logs, and I found the response for this transaction was sent with response_message 3d secure check requested.
Now I wonder how to handle payfort response on wooCommerce side while integration type is MerchantPage 2.0, which I am expecting to handle the response itself.
I need little help to understand the payfort integration process, as my search couldn't find any help online.
Thanks in advance
I have emailed Payfort support center, but as its weekend, the response will be late.
The issue resolved finally, let me share the solution.
Issue:
In this plugin payment.php file has a function callApi($postData, $gatewayUrl) which is sending request to payfort to notify and parsing response to json
$array_result = json_decode($response, true);
while the response was coming in XML format so it was returning null to $array_result.
Solution:
To resolve the above issue in Payfort account settings, under Account Setup > Technical Settings enable
Json for response type.
Suggestion:
Plugin should be updated to configured with this settings as well, if an account settings is with XML response type, then response should be parse accordingly.
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?