View Issue Details

IDProjectCategoryView StatusLast Update
0006122module PayPalmodule PayPal - subpublic2018-04-27 14:23
Reporterpatchwork.de 
PriorityhighSeveritymajorReproducibilityhave not tried
Status resolvedResolutionfixed 
Product Version3.1.1 
Target VersionFixed in VersionPatch for 3.3 
Summary0006122: Response from PayPal during IPN is always 'DNS failure'
Descriptionin 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 Reproducestandard 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 Informationnot 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
 
TagsSolution Provided

Activities

QA

2015-04-16 15:02

administrator   ~0010875

Waiting for feedback from PayPal

QA

2015-04-21 16:29

administrator   ~0010892

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.

patchwork.de

2015-04-21 17:01

reporter   ~0010893

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!

QA

2015-04-21 17:07

administrator   ~0010894

Last edited: 2015-04-21 17:07

View 2 revisions

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

patchwork.de

2015-04-21 17:25

reporter   ~0010895

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

QA

2015-04-24 15:03

administrator   ~0010905

Last edited: 2015-04-24 15:04

View 2 revisions

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?

patchwork.de

2015-04-24 19:47

reporter   ~0010911

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_


Reference] =>
[0000032;] =>
[0000035;11] =>
[0000046;6d959d50] =>
[0000046;1429794319] =>
[0000046;2b33378
</BODY></HTML>
] =>
)
',
)

QA

2015-04-29 15:40

administrator   ~0010924

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.

hendrikfreytag

2015-05-15 15:16

reporter   ~0010954

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.

keywan.ghadami

2015-10-19 17:22

developer   ~0011266

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.

martinwegele

2015-12-08 16:40

reporter   ~0011370

Last edited: 2015-12-08 16:44

View 6 revisions

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:


florian.auer

2017-01-16 11:33

developer   ~0011927

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?

JaroslavHerber

2017-11-08 13:16

reporter   ~0012264

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