Kentico 10中使用Sandbox账户时PayPal IPN无法正常工作

我之前在处理Kentico项目的PayPal IPN时，也碰到过类似的定期支付场景问题。结合你已经完成的排查，这些方向可以重点检查：

• 确认定期支付IPN消息类型的处理逻辑
  定期支付（订阅）的IPN消息类型和单次支付完全不同，比如会包含txn_type=subscr_payment、txn_type=subscr_signup这类标识。要检查Kentico的IPN处理代码是否覆盖了这些订阅相关的消息类型——很多默认实现可能只处理了单次支付的web_accept类型，导致订阅类IPN被直接忽略。

• 检查Sandbox订阅的状态与IPN历史
  登录PayPal Sandbox商家账户，进入IPN历史记录页面，查看针对该定期支付的IPN是否已发送、发送状态是成功还是失败。另外，确认测试的订阅是否处于Active状态：有些测试场景下订阅会处于Pending状态（比如需要手动确认），这种情况PayPal不会触发IPN。如果IPN发送失败，Sandbox会给出具体的错误原因（比如连接超时、验证失败），这能帮你快速定位问题。

• 开启Kentico详细日志排查内部错误
  打开Kentico的Event Log，搜索与PayPal或IPN相关的条目，查看是否有参数解析失败、数据库写入异常、权限不足等报错。你也可以临时在IPN处理页面添加日志代码，把收到的所有IPN参数完整记录下来，对比模拟器和Sandbox发送的参数差异——比如订阅场景下会多出subscr_id、period_type等参数，若你的代码依赖特定参数但未处理这些新增字段，就会导致逻辑中断。

• 验证HTTPS证书与TLS版本兼容性
  虽然你提到证书有效，但PayPal Sandbox对证书的要求很严格：

  • 避免使用自签名证书，确保证书由PayPal信任的根CA颁发；
  • 用openssl s_client -connect your-notify-url-domain:443命令检查证书链是否完整；
  • 确认服务器已启用TLS 1.2及以上版本（PayPal已不再支持TLS 1.0/1.1），可以在IIS的网站SSL设置中配置。

• 检查IPN验证流程的正确性
  PayPal IPN要求必须将收到的所有参数原样（加上cmd=_notify-validate）发回Sandbox验证地址https://ipnpb.sandbox.paypal.com/cgi-bin/webscr，只有收到VERIFIED响应后才能继续处理。要确认Kentico的代码是否正确执行了这一步：

  • 是否用了Sandbox的验证地址（而非生产环境地址）；
  • 是否完整转发了所有参数（包括订阅相关的特殊参数）；
  • 是否对VERIFIED和INVALID响应做了正确的分支处理，避免验证失败后仍执行后续逻辑。

• 确认定期支付计划的IPN配置
  在PayPal Sandbox中创建的定期支付计划，其自身的IPN设置可能会覆盖订单中的Notify URL。检查计划配置页面，确认是否指定了正确的Notify URL，或者是否设置为“使用订单的Notify URL”。另外，确保计划的计费周期、金额等参数与Kentico后台的配置完全一致，参数不匹配可能导致IPN处理时的逻辑报错。

• 排查服务器防火墙/安全组拦截
  即使Notify URL可以公开访问，服务器的防火墙、WAF或安全组可能会拦截PayPal Sandbox的请求。确认服务器已放行PayPal Sandbox的IP段，同时检查主机服务商是否有防垃圾请求机制，是否将PayPal的IP误判为恶意请求。

内容的提问来源于stack exchange，提问作者Sharath