我仍然试图围绕这一切，所以如果我犯了一个错误，我很抱歉，但似乎现在无法在12月1日注册的旧NVP应用程序有一些功能可用无法在新的REST世界秩序中复制...
这就是我想要/需要的东西：我需要能够将买方的交易ID转换为我的卖方交易ID，我希望能够在安全的网络服务器上执行此操作，但我不能希望它拥有对我的帐户的完全访问权限，所以我想为这台服务器提供细粒度的authz。
看起来我实际上得到我想要/需要的时间太晚了。基本上，GetTransactionDetails完全符合我的要求（将买方转换为卖方交易ID，并返回剩余的交易信息以获得良好的衡量标准）。而且，虽然我还没有让它工作，但看起来Permissions SDK加上一个NVP AppID可以让我在这个服务上只有TRANSACTION_DETAILS permission，这正是我想要的。
然而，截至星期五显然我无法获得经典NVP API的AppID？如果是这样，我的时机无可挑剔。
试图弄清楚如何在REST API中执行此操作已经证明是困难的。 This thread谈论销售记录，确实采用了买方的交易ID，但它实际上并没有将其转化为卖方方面的交易ID。它确实有自定义字段，这对我有所帮助，但我真的需要卖方的交易ID。看起来销售回报中的parent_payment URL可能会有所帮助，但是即使以前成功的查询，API也开始向我返回PERMISSION_DENIED，所以我现在无法准确测试。并且，即使这确实有效，看起来REST API上的权限与Permissions SDK相比非常粗糙，例如销售端点在/ v1 / payments下，似乎还包括退款和各种其他东西我不要暴露。看起来有一个交易搜索权限，但它标记为测试版，但它不适用于查询我的销售。但也许这意味着他们正在研究它？
我有什么选择？
谢谢， 克里斯
答案 0 :(得分：0)
好的，所以我玩了一段时间，看起来PayPal REST API并不是很好。因此，我使用AWS Lambda及其细粒度的IAM权限解决了这里的局限性。我创建了一个Lambda函数，它将我的PayPal NVP凭证作为加密的env vars，以及一个只能调用我的Lambda函数的IAM帐户，所以现在我有一个微服务，它将转换事务ID并返回一些额外的信息（自定义和电子邮件）从事务到启动。
我希望我没有必要使用AWS来解决PayPal的限制（使用REST API似乎越来越糟糕，如果我能够获得并使用AppID并使用权限SDK，则NVP api会很好） ，但是很好。
克里斯