总结：我想使用 returnUrl 作为交易已被 PayPal 接受的证明。
我正在实施一个基于 PayPal 的非常基本的购买工作流程。
一切正常，用户点击 pay，用户转到 PayPal，PayPal 将用户发送到我的 returnURL...我接受付款在这最后一步。
我知道我必须实现一个 IPN 端点并在那里接受付款，但是这个项目非常基础，我太老或太懒了，无法实现所有这些异步行为地狱般的极端情况。
如果我能让 returnUrl 更加自信、难以伪造，那就太好了。
我在想有可能在 returnURL 中包含一个 checksum 签名，该签名基于存储的 密钥在 PayPal 账户和实际交易中token
我不知道这是否存在，我没有在文档中找到任何这些内容，欢迎提出任何让 returnUrl 更有信心的建议。
另外，如果有人认为我完全错了，并且 returnUrl 永远不会成为交易已被接受的证据，请表达你自己。
【问题讨论】：
当您只是执行返回 URL 时，您需要再次发布到 PayPal 以使用您的 PDT 令牌验证交易。
假设您的返回 URL 是Thanks.aspx：
“从Thanks.aspx 的代码隐藏中，您将解析tx 值并使用以下参数向https://www.paypal.com/cgi-bin/webscr 发出HTTP POST：cmd=_notify-synch&tx=[TransactionID]&at=[PDTIdentityToken]。 "
这将响应该请求是否有效。
问题是不能保证此页面会被点击。用户可以关闭他们的浏览器，或者他们的互联网可能会被切断，或者其他任何事情。
IPN 将受到 PayPals 服务器的攻击，而你真的无法击败它。
设置起来非常容易，但我建议通读本文档，该文档将解释 PDT 和 IPN 方法，并提供一种简单的方法来确定您需要什么。
【讨论】：
完成 Express Checkout 的安装后，我意识到如何利用它。
即使我正在创建一个唯一的发票编号并返回以将其标记为已付款，但我发现用户更改返回链接中的发票参数仍然可以利用它。当然，已经有检查确保任何发票只能支付一次，但我需要证明它是黑客攻击的。
所以我最后要做的是添加一些额外的检查，以确保有问题的发票是分配给该用户的最后一张发票。是的，在访问 Paypal 并返回后，仍会保持相同的会话 ID。
【讨论】：