View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0006122 | module PayPal | module PayPal - sub | public | 2015-04-16 14:25 | 2018-04-27 14:23 |
| Reporter | patchwork.de | Assigned To | |||
| Priority | high | Severity | major | Reproducibility | have not tried |
| Status | resolved | Resolution | fixed | ||
| Product Version | 3.1.1 | ||||
| Fixed in Version | 3.4.0 | ||||
| Summary | 0006122: Response from PayPal during IPN is always 'DNS failure' | ||||
| Description | in modules/oe/oepaypal/logs/log.txt you find for every IPN transaction the response from PayPal 'Service_Unavailable_-_DNS_failure - The_server_is_temporarily_unable_to_service_your_request___Please_try_again' | ||||
| Steps To Reproduce | standard 4.8.ff/4.9.ff with PayPal-Module activatet and running. PayPal-logging activatet. After every payment via PayPal you find the above mentioned response. | ||||
| Additional Information | not critical for 'normal' PayPal-transactions but for transactions if payment is 'pending' more info in forum: http://forum.oxid-esales.com/showthread.php?p=158504#post158504 | ||||
| Tags | Solution Provided | ||||
|
|
Waiting for feedback from PayPal |
|
|
Reminder sent to: patchwork.de There was an issue with Akamai which started happening on the 12th of April and ended some time around the 15th wherein some IPN verification requests returned a HTTP 500 Server error. Akamai, PayPal's CDN, includes a tracking ID like 11.73959d50.1429094977.fe60210 in their HTTP Error Pages. Can you see an ID in the 'PayPal Full Response' in your log? The issue should've been resolved by now, so if you're still seeing a problem, could you please forward a sample from within the last 24 hours? After that, the tracking ID becomes useless. |
|
|
could not find this ID in log file! And the first entry (what I have seen) was in Dec. 2014 Due to that this shop is only for testing I have no new data. Waiting for response from forum come back ... Note: in other shop-systems (not oxid) IPN is working fine - all over the time! |
|
|
It can any ID like that. It will not be exact the same. Note that the IDs are a little bit scrambled by the parser. The ID I mentioned would be written in the log file as follows: Reference] => [# 32;] => [# 35;11] => [# 46;73959d50] => [# 46;1429094977] => [# 46;fe60210 |
|
|
You are right! I found this - first one dated Dec 2014. But newest failure has Reference] => [0000032;] => [0000035;11] => [0000046;e60b0ac3] => [0000046;1429130634] => [0000046;2c9e717 |
|
|
Reminder sent to: patchwork.de Thanks for your feedback. When did this occur the last time? Is there anyone out there who saw this behaviour after the 15th Apr., 2015? |
|
|
last entry now: 23rd Apr.: ======================= IPN VERIFICATION FAILURE BY PAYPAL [2015-04-23 15:05:19] ======================= # SESS ID: 49uj5avgrveoggnfcko3im2k93 array ( 'Shop owner' => '[email protected]', 'PayPal ID' => '[email protected]', 'PayPal ACK' => 'NOT VERIFIED', 'PayPal Full Request' => 'Array ( [Shipping_calculation_mode] => FlatRate [mc_gross] => 26.67 [protection_eligibility] => Eligible [address_status] => confirmed [payer_id] => 2LL7VN2QJEYJN [tax] => 0.00 [address_street] => Im test 4 [payment_date] => 06:05:03 Apr 23, 2015 PDT [payment_status] => Completed [charset] => windows-1252 [shipping_option_name] => Paketversand mit DPD innerhalb Europa (ohne deutsche Inseln) [address_zip] => 53639 [first_name] => test [mc_fee] => 0.86 [address_country_code] => DE [address_name] => test [notify_version] => 3.8 [custom] => Bestellnummer 11497 [insurance_option_selected] => 0 [payer_status] => verified [business] => [email protected] [address_country] => Germany [shipping_option_amount] => 6.90 [address_city] => test [quantity] => 1 [verify_sign] => AuRlNZvMOhdn8iDWY5YoMB9iRTDzA-uUjtTfztggPkp.Ivyl.LQFEyQw [payer_email] => [email protected] [txn_id] => 8JU75372XG0226317 [payment_type] => instant [last_name] => Strasser [address_state] => [receiver_email] => [email protected] [payment_fee] => [insurance_amount] => 0.00 [receiver_id] => JRKMUYM8677AA [txn_type] => express_checkout [item_name] => Bestellnummer 11497 [mc_currency] => EUR [item_number] => [residence_country] => DE [handling_amount] => 0.00 [transaction_subject] => [payment_gross] => [shipping] => 6.90 [shipping_is_default] => 1 [ipn_track_id] => dc599fc31c4d1 ) ', 'PayPal Full Response' => 'Array ( [<HTML><HEAD> <TITLE>Service_Unavailable</TITLE> </HEAD><BODY> <H1>Service_Unavailable_-_DNS_failure</H1> The_server_is_temporarily_unable_to_service_your_r equest___Please_try_again later_
|
|
|
Reminder sent to: patchwork.de I can't reproduce this issue. In our test system the IPN function works as expected. Please give us additional information how to reproduce this issue. You can also contact paypal support https://ppmts.custhelp.com and send them paypal response message. Add the paypal full response, especially the tracking ID which you can read in the full response. The entry [# 32;] => [# 35;11] => [# 46;73959d50] => [# 46;1429094977] => [# 46;fe60210 is translated to the tracking ID 11.73959d50.1429094977.fe60210. |
|
|
Maybe there are problems with the AKAMAI firewall. As workaround you can use https://ipnpb.paypal.com/cgi-bin/webscr as post back url. I think it works if you change the file modules/oe/oepaypal/core/oepaypalconfig.php. Change the function \oePayPalConfig::getIPNResponseUrl. public function getIPNResponseUrl() { if ($this->isSandboxEnabled()) { return 'https://ipnpb.sandbox.paypal.com/cgi-bin/webscr&cmd=_notify-validate'; } else { return 'https://ipnpb.paypal.com/cgi-bin/webscr&cmd=_notify-validate'; } } So maybe this issue is a feature request that you can configure the post back url if your server has problems with this firewall. |
|
|
I have the same issue, paypal module version 3.2.1. How to reprodce: deaktivate sandboxmode send POST with paypal message to your shop https://domain.de/index.php?cl=oePayPalIPNHandler&fnc=handleRequest&shp=1 ---- I debugged the curl and saw that the paypalmodule uses the right url but the NVP API host, after changing the host with $oCurl->setHost('www.paypal.com') to the correct host it seams to work. This will be tested in a projects in some days, so i will be able to confirm the solution. But as this issues was reproducible for me, so i like to reopen this ticket. |
|
|
If I understood Keywan's note (#11266) correctly, the fix would look a little something like this: In oePayPalService::doVerifyWithPayPal() insert: $oCurl->setHost('www.paypal.com');after: $oCurl->setUrlToCall($this->getPayPalConfig()->getIPNResponseUrl()); https://github.com/OXID-eSales/paypal/blob/v3.2.2/source/modules/oe/oepaypal/core/oepaypalservice.php#L274 However it might be worth to check all URLs and hosts of the PayPal API which are used inside the module via cURL. There are proposals for changes in other places as well: |
|
|
Hey Keywan, we cannot reproduce this issue, and information is unclear. Can you confirm that changing the host with $oCurl->setHost('www.paypal.com') to the correct host works, and which host name exactly works for you? |
|
|
The problem is still there. I can reproduce with the following cUrl which is similar in IPN-Curl-function. It seems paypal is the origin of the problem. The host is different to the CURLOPT_URL. The host-line in CURLOPT_HTTPHEADER causes the DNS-error. This DNS-error comes probably from wrong DNS-resolution in the paypal-API itself. They try to resolve http://api-3t.paypal.com which is only available for HTTPS-protocol. Just remove the host in CURLOPT_HTTPHEADER for IPN-functions and it will work fine. // ---- cURL $sHost = 'api-3t.paypal.com'; // <- this is the problem $aHeader = array(); $aHeader[] = 'POST /cgi-bin/webscr HTTP/1.1'; $aHeader[] = 'Content-Type: application/x-www-form-urlencoded'; if(isset($sHost)) { $aHeader[] = 'Host: ' . $sHost; // <- this is the problem } $aHeader[] = 'Connection: close'; //cURL settings $curlOptions = array ( CURLOPT_URL => 'https://www.paypal.com/cgi-bin/webscr&cmd=_notify-validate', CURLOPT_VERBOSE => 0, CURLOPT_SSL_VERIFYPEER => false, CURLOPT_SSL_VERIFYHOST => false, CURLOPT_SSLVERSION => 6, CURLOPT_RETURNTRANSFER => 1, CURLOPT_POST => 1, CURLOPT_HTTP_VERSION => 2, CURLOPT_HTTPHEADER => $aHeader, ); $ch = curl_init(); curl_setopt_array($ch, $curlOptions); $response = curl_exec($ch); // -> $response with DNS-error message |
