当买家支付订阅费用时，notify_url永远不会调用 [英] notify_url never call when buyer paid for subscription

问题描述

现在，我正尝试使用Paypal沙箱从我的网站制定订阅计划.我已经在企业帐户中设置了notify_url并启用了此功能.返回和取消返回是正确的工作.但是，当使用买方(个人)帐户进行测试并同意订阅付款时，没有交易日志永远不会调用我的网站notify_url.

我的问题与[问题]类似:解决方案

如果您的帐户中启用了IPN，请登录该帐户并查看IPN历史记录.您应该可以从此处判断您的IPN是否已发送出去，或者它们是否处于重试或失败状态.如果您在此处看到IPN，则可以单击消息ID，它将显示您的服务器在重设IPN时返回的状态.这可能有助于找出问题的原因.另外，这是一些基本的故障排除步骤，可能有助于解决IPN问题.

如果您使用的是自定义脚本，请尝试使用 PayPal的示例IPN脚本.它们是非常基本的脚本，但是它们是经过测试的有效示例.这可以帮助您确定脚本或IPN是否存在问题.

IPN故障排除提示

这些是在使用IPN时影响开发人员的最常见问题.还指出了最常见的解决方案.希望这些信息可以帮助某人！

无效原因

• 确保您要回发所有变量/值.

为使PayPal返回VERIFIED，您的IPN脚本需要先回发发布到其的所有变量.换句话说，如果您的脚本仅需要操纵1或2个变量，仅将脚本所关注的变量/值发回PayPal是不够的.您的脚本应回发最初从PayPal发布到它的所有内容.这是PayPal返回VERIFIED的唯一方法

• 确保您没有发布回错误的URL.

如果您正在沙盒中进行测试，则需要确保将脚本发布回www.sandbox.paypal.com.如果您在现场站点上，该脚本应发回到www.paypal.com.如果您在沙盒中进行测试并且您的脚本回发到实时网站(反之亦然)，则会收到INVALID

• 编码

PayPal的IPN服务器希望您的脚本将回发所有发布到该脚本的变量，更重要的是，它们的编码方式与发送给您的脚本的方式相同.如果您的脚本无意中更改了字符的编码，或者将编码后的字符解释为另一个字符，然后回退，则您可能会看到INVALID.例如，这可能会偶尔发生，并倾向于发生，例如，当收到付款并且购买者的名字中可能带有重音字符或订单是针对某个商品名称中具有非标准字符的商品时.这些实例很难进行故障排除，但在此处列出了这些实例，因为当您期望VERIFIED时，它可能导致INVALID无效.当您看到某些IPN无效且其余所有IPV已验证时，请查找此问题.

麻烦的提示-IPN未发布！

• 接收帐户上的电子邮件地址.

确保已确认付款发送到的帐户上的电子邮件地址.

• 访问日志

如果您认为IPN没有发布到脚本中，则可以通过检查服务器的访问日志来验证.服务器访问日志将告诉您PayPal是否完全点击了脚本".访问日志跟踪访问服务器的计算机的IP地址和/或主机名.您能否访问服务器的访问日志取决于服务器管理员.如果您不知道日志在哪里，请与他们联系.

• 错误日志 如果运行脚本时发生错误，则大多数脚本语言会输出到错误日志.如果您在访问日志中看到PayPal正在发送IPN，但没有从脚本中看到预期的最终结果，则可能是脚本中存在逻辑或语法错误.检查您的错误日志以进行验证.同样，如果您不知道如何或在何处检查这些日志，则需要咨询服务器的管理员.

• 检查路径

一个容易犯的错误.测试/使用IPN时，请始终确保脚本路径正确无误，并且会看到没有收到IPN帖子.例如，避免使用"localhost" URL.由于这是后端服务器到服务器的通信，因此将本地主机设置为路径将导致IPN尝试将其发布到自身，而不是在网络外部发布到您自己的服务器/脚本.

• 防火墙

IPN是从PayPal启动的HTTP POST.如果您的服务器上有防火墙，请确保您的防火墙没有阻止来自PayPal的帖子.

• 进行测试以确保您的脚本可以正常工作.

如果脚本中包含语法或逻辑错误，很可能您将看不到正确的结果.一种简单的测试脚本的方法是向脚本发送虚拟"帖子，并在PayPal的响应无效的情况下编写一些代码以执行某些操作".本质上，如果将来自PayPal的响应为VERIFIED时要触发的代码复制到响应为INVALID时运行的脚本部分，则可以向该脚本发送一个虚拟帖子，以查看您的代码是否有效.由于该脚本的虚拟帖子将返回INVALID(因为该帖子并非源自PayPal)，因此这就是为什么要将代码添加到脚本的"if INVALID"部分的原因.

• 发布到您的返回网址(返回方法)

某些商家的设置使其希望将IPN数据发布到其按钮代码(返回)中的返回变量的值.这是在完成PayPal付款后，买家会转到的URL.要将IPN数据发布到返回URL，必须在按钮代码中将rm变量设置为等于"2"，否则您可能看不到任何IPN数据发布到您的返回URL.有关更多信息，请参见这篇文章. **请注意，此信息是有关IPN数据的信息，可以通过回传以及如何与回传URL(按钮代码变量"return")一起使用.如果启用了PDT自动返回功能，则此信息不适用于您，因为PDT是其自身的独立功能.有关PDT的更多信息，请点击此处.

故障排除提示-IPN延迟

在大多数情况下，当您的服务器未对许多事务IPN作出200ok响应时，会导致IPN持续出现延迟.例如，当您的服务器未回复200ok PayPal时，将尝试重新发布数据.在大量的数据重新发送未收到200ok后，您的IPN被移到了速度较慢的循环服务器上，因此出现了延迟.

首先检查您的IPN日志以了解POST的状态:

在您的帐户的历史记录"部分下，您应该有一个"IPN历史记录"部分，您可以在其中查看最近28天的IPN值，某些情况下可以重新发送它们.如果您没有找到此链接，请转到此处: https://www.paypal.com/us/cgi -bin/webscr?cmd = _display-ipns-history

这些日志将具有几种不同的状态:

已发送-表示贝宝已将消息发送到您的IPN侦听器 失败-表示PayPal未收到有关原始POST尝试或重新P​​OST的消息的确认(200ok) 已排队-表示贝宝已准备好发送消息 重试-表示PayPal没有收到200ok，并且该消息在1至15次之间被重新发送，并且PayPal正在继续重新发送该消息 已禁用-表示由于IPN/该帐户已被禁用，因此将不会重新发送该邮件

如果您看到失败或重试"，很可能是解决此问题的原因，则您将需要遍历服务器日志以确定为什么未将200ok发送回PayPal IPN.一旦确定并纠正了该错误，并且您的服务器以200ok的响应做出响应，它将使该百分比/计数低于该限制，并且它将开始从正常周期服务器中发布IPN.

如果没有失败，则可能会延迟PayPal服务器本身，在这种情况下，您将需要创建PayPaal商家技术服务的票证，作为paypal.com/mts进行进一步的审查.

Curl vs fsockopen: 这通常是个人喜好，但是在某些情况下，您要使用的主机提供程序不支持其中之一，因此您可能需要在两者之间进行切换.这是使用fsockopen的示例:

$header = "POST /cgi-bin/webscr HTTP/1.1\r\n";
$header .= "Host: www.paypal.com\r\n";
$header .= "Content-Type: application/x-www-form-urlencoded\r\n";
$header .= "Content-Length: " . strlen($req) . "\r\n";
$header .= "Connection: Close\r\n\r\n";
$fp = fsockopen ('ssl://www.paypal.com', 443, $errno, $errstr, 30);

这是同一件事，但使用curl:

$url= 'https://www.sandbox.paypal.com/cgi-bin/webscr';

$curl_result=$curl_err='';
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL,$url);
curl_setopt($ch, CURLOPT_RETURNTRANSFER,1);
curl_setopt($ch, CURLOPT_POST, 1);
curl_setopt($ch, CURLOPT_POSTFIELDS, $req);
curl_setopt($ch, CURLOPT_HTTPHEADER, array("Content-Type: application/x-www-form-urlencoded", "Content-Length: " . strlen($req)));
curl_setopt($ch, CURLOPT_HEADER , 0);   
curl_setopt($ch, CURLOPT_VERBOSE, 1);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, FALSE);
curl_setopt($ch, CURLOPT_TIMEOUT, 30);
$res = @curl_exec($ch);
$curl_err = curl_error($ch);
curl_close($ch);

基本上，如果您在使用一种方法时遇到麻烦，而您认为主机/服务器不支持一种方法，而不是简单地将另一种方法替换为另一种方法.

本地测试:
这可能是生产和测试任何脚本中最重要的步骤之一.关于IPN，它可以用来将您需要的任何参数传递给您自己的脚本，以测试语法以及该脚本如何与预期的变量一起工作.真正需要做的就是在您自己的IPN处理程序上设置一个带有post操作的表单，并为要测试的变量/值提供隐藏的输入.

例如:

<form target="_new" method="post" action="https://www.YourDomain.com/Path/IPNhandler.php">
<input type="hidden"  name="SomePayPalVar" value="SomeValue1"/>
<input type="hidden"  name="SomeOtherPPVar" value="SomeValue2"/>

Than etc for all  other variables you want to test with.

</br>
<input  type="submit"/>
</form>

正如在angelleye的许多主题中列出的那样，这里是指向本地测试.

Now i am trying to make subscription plan from my website with paypal sandbox. I was already setup notify_url in business account and turn on this feature. return and cancel return is correctly work. But when test with buyer(personal)account and agree subscription payment, no transaction log never call to my website notify_url.

My problem is similar with [question]:notify_url is not reached or may be false response in sandbox paypal

Thank for help.

解决方案

If you have IPN enabled in your account, log into the account and look at the IPN history. You should be able to tell from here if your IPN's are being sent out, or if they are in a retrying or failed status. If you see your IPN's in here, you can click on the message id and it will show you what status is being returned by your server if it is returing one. This may help to isolate the cause of the issue. Also, here are some basic troubleshooting steps that may help with IPN issues.

Also if you are using a custom script, try using one of PayPal’s sample IPN scripts. They are very basic scripts, but they are tested working examples. This can help to determine if it’s an issue with your script or with IPN in general.

IPN troubleshooting tips

These are the most common problems affecting developers when working with IPN. The most common solutions are noted as well. Hope this information helps someone out there!

REASONS FOR INVALID

• Make sure you are posting back ALL variables/values.

For PayPal to return VERIFIED, your IPN script needs to post back ALL the variables that were posted to it in the first place. In other words, if your script only needs to manipulate 1 or 2 variables, it is not enough to post back to PayPal only the variables/values your script is concerned with. Your script should post back EVERYTHING that was initially posted to it from PayPal. This is the only way PayPal will return VERIFIED

• Make sure you are not posting back to the wrong URL.

If you are testing in the Sandbox, you need to ensure your script posts back to www.sandbox.paypal.com. If you are on the live site, the script should post back to www.paypal.com. You will receive INVALID if you are testing in the Sandbox and your script posts back to the live site (or vice versa)

• Encoding

PayPal's IPN server expects that your script will POST back all variables that were posted to it and more importantly, that they are encoded the same way as they were sent to your script. If your script inadvertently changed the encoding of a character or interprets an encoded character as another character and POSTs back, you will likely see INVALID. This can happen sporadically and tends to occur, for example, when a payment is received and the buyer may have an accented character in their name or the order is for some item with a non-standard character in the item name. These instances are tricky to troubleshoot but it is listed here as it can cause INVALID when you would expect VERIFIED. Look for this issue when you are seeing that certain IPNs are INVALID and all the rest are VERIFIED.

TROUBLESHOOTING TIPS - IPN is not POSTing!

• Email address on receiving account.

Make sure you've confirmed the e-mail address on the account the payment is being sent to.

• Access Logs

If you feel IPN is not posting to your script, you can verify this by checking your server's access logs. The server access logs will tell you if PayPal is "hitting your script" at all. An access log tracks the IP addresses and/or hostnames of computers that access the server. That you can access your server's access logs is up to the server admin. Check with them if you do not know where the logs are.

• Error logs Most scripting languages output to error logs if an error occurs when running the script. If you see in your access logs that PayPal is sending the IPN but you are not seeing the intended end result from your script, odds are you have a logic or syntax error in the script. Check your error logs to verify. Again, if you don't know how or where to check these logs, you would need to consult your server's administrator.

• Check Paths

An easy mistake to make. Always ensure the path to your script is correct when testing/using IPN and you see that you are not getting an IPN post. For example avoid using "localhost" urls. Since this is a back end server to server communication setting a path to localhost will cause the IPN to try to post to itself rather than outside the network to your own server/script.

• Firewalls

IPN is an HTTP POST initiated from PayPal. If you have a firewall on your server, make sure your firewall is not blocking the post from PayPal.

• Test to make sure your script works as intended.

If your script has a syntax or logic error in it, odds are you will not see the correct result. An easy way to test your script is by sending a "dummy" post to the script and writing some code to "do something" if the response from PayPal is INVALID. Essentially, if you copy the code that you want to fire when the response from PayPal is VERIFIED to the part of the script that runs if the response is INVALID, you can send a dummy post to the script to see if your code works. Since a dummy post to the script will return INVALID (since the post was not originated from PayPal), this is why you want to add the code to the 'if INVALID' part of your script.

• Posts to your return URL (Return Method)

Some merchants are setup such that they would like to get IPN data posted to the value of their return variable in their button code (return). This is the URL the buyer is directed to after a PayPal payment has been made. To have IPN data POSTed to your return URL you must set the rm variable equal to "2" in your button code or you may not see any IPN data POSTed to your return URL. For more information see this post. ** Note that this information is about IPN data can be passed through the return and how it works with your return URL (button code variable 'return'). If you have Auto Return with PDT enabled this information does not apply to you as PDT is its own separate feature. More information on PDT can be found here.

TROUBLESHOOTING TIPS - IPN is Delayed

In most cases consistent delays in IPNs are caused when your server is not responding with a 200ok for to many of your transaction IPNs. For example, when your sever does not reply with a 200ok PayPal attempts a repost of the data. After so many reposts of the data that do not receive the 200ok your IPNs get moved to a slower cycling server, hence the delays.

First check your IPN Logs for the status of the POSTs:

In your account under the history section you should have a "IPN History" section where you can see the last 28 days worth of IPNs and is some cases can resend them. If this link doe not appear for you log into your account than go here: https://www.paypal.com/us/cgi-bin/webscr?cmd=_display-ipns-history

These logs will have a couple different statuses:

Sent - indicates that PayPal sent the message to your IPN listener Failed - indicates that PayPal did not receive an acknowledgement (200ok) to the message for the original POST attempt or re-POSTs Queued - indicates that PayPal is ready to send the message Retrying - indicates that PayPal did not receive a 200ok and the message was resent between 1 and 15 times and that PayPal is continuing to resend the message Disabled - indicates that the message will not be resent because IPN/The account has been disabled

If you see Failed or Retrying this is most likely the cause to resolve this, you will need to go through your server logs to determine why the 200ok is not being sent back to PayPal IPN. Once this is determined and remedied and your server responds with a 200ok it brings this percentage/count down from that limit and it will begin posting IPNs from the normal cycle server.

If there are no failed it may be a delay on PayPal Servers themselves in which case you will want to create a ticket to PayPal Merchant Technical Services as paypal.com/mts for further review.

Curl vs fsockopen: This is most often a personal preference but in some cases the host provider you are going to does not support one or the other so you may need to switch between the two. Here is an example of using fsockopen:

$header = "POST /cgi-bin/webscr HTTP/1.1\r\n";
$header .= "Host: www.paypal.com\r\n";
$header .= "Content-Type: application/x-www-form-urlencoded\r\n";
$header .= "Content-Length: " . strlen($req) . "\r\n";
$header .= "Connection: Close\r\n\r\n";
$fp = fsockopen ('ssl://www.paypal.com', 443, $errno, $errstr, 30);

Here is the same thing but using curl:

$url= 'https://www.sandbox.paypal.com/cgi-bin/webscr';

$curl_result=$curl_err='';
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL,$url);
curl_setopt($ch, CURLOPT_RETURNTRANSFER,1);
curl_setopt($ch, CURLOPT_POST, 1);
curl_setopt($ch, CURLOPT_POSTFIELDS, $req);
curl_setopt($ch, CURLOPT_HTTPHEADER, array("Content-Type: application/x-www-form-urlencoded", "Content-Length: " . strlen($req)));
curl_setopt($ch, CURLOPT_HEADER , 0);   
curl_setopt($ch, CURLOPT_VERBOSE, 1);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, FALSE);
curl_setopt($ch, CURLOPT_TIMEOUT, 30);
$res = @curl_exec($ch);
$curl_err = curl_error($ch);
curl_close($ch);

Basically if you are having trouble with one and you think it may be to one method not being supported by your host/server than simply replace the one you are using with the other.

Local Testing:
This is probably on of the most important steps in production and testing any script. In regards to IPN this can be used to pass any parameter you need to your own script to test syntax and how that script will function with the variables expected. All this really would need is to set up a form with a post action to your own IPN handler and the hidden inputs for the variables/values you want to test.

For example:

<form target="_new" method="post" action="https://www.YourDomain.com/Path/IPNhandler.php">
<input type="hidden"  name="SomePayPalVar" value="SomeValue1"/>
<input type="hidden"  name="SomeOtherPPVar" value="SomeValue2"/>

Than etc for all  other variables you want to test with.

</br>
<input  type="submit"/>
</form>

As listed in many of angelleye's threads here is a link to a good example of local testing that he has set up.

这篇关于当买家支付订阅费用时，notify_url永远不会调用的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！