我没有做过PP标准。我已经使用了 Gateway 和 Pro/Express Checkout，但已经有一段时间了 - 不过，您的问题可以以更“通用”的方式处理......
不幸的是，您的计划不会采取任何措施来保护您——就像网络上的任何其他 HTML 表单一样，可以使用现成的工具检查和篡改 HTTP 请求和响应。
防止篡改的常用方法是对来自任何客户端/浏览器的提交值进行服务器端验证（经验法则是“不信任任何人”）。在您的场景中，您在服务器端做事，但这仍然在数据的实际提交目标之前 - 这是 PayPal。实际将数据发送到“目标”的步骤仍然是浏览器/客户端 - 可以说存在问题。要验证的数据适用于您的系统以外的系统（因此您无法验证 PayPal）。
除非有额外的安全层，例如签名或加密，否则它总是容易被篡改（查看已成定局，可以查看）。
我不相信（但我可能是错的）PP Standard 有一个用于发布数据的服务器到服务器选项。这将有效地从客户端/浏览器中完全“隐藏”数据——没有什么可看的，也没有什么可篡改的。数据传输在后台 - 客户端/浏览器对此一无所知。
但是，他们的PayPal Payments Standard 和 Button Manager API似乎是正确/安全的方式。
本质上，您将即时创建他们所谓的“加密按钮” 。这样，对于任何检查数据的人来说，数据看起来都是胡言乱语——这只会对 PayPal 有意义，因为他们可以相应地解密数据。这就是保护/保护数据免遭篡改的方式（不是查看 - 但同样，可以看到的是胡言乱语）......
嗯...
更新：
此外，您应该考虑使用 PayPal IPN 来存储数据。您在上面做出假设（我认为），单击按钮的每个人实际上都会完成付款（或可以成功付款）。使用 IPN，您将仅在成功付款后“收听”来自 PayPal 的数据（您应该在此处存储与订单相关的数据和/或库存更新等）...。
即使我正在使用 PHP，使用 NVP API，您也可以使用只能由 paypal 使用的令牌获取重定向链接。所有链接都将如下所示https://www.sandbox.paypal.com/webscr?cmd=_express-checkout&token=TOKEN，其中TOKEN是先前通过调用 PayPal API 检索到的令牌。
我只为 ExpressCheckout 开发了它。您可以在此处查看 API：
https://cms.paypal.com/us/cgi-bin/?cmd=_render-content&content_ID=developer/howto_api_reference