我需要使用 PayPal API 开发支付解决方案。实际上我开始了文档阶段（http://developers.paypal.com）
我发现 REST APIs 是可以理解的，但我仍然不知道如何使用 SpringMVC 实现它们，所以我只是使用 cURL 来测试它们。 （对此有什么帮助吗？）
另一方面，经典 API 令人困惑。 （例如，我们可以使用自适应帐户做什么以及快速结账和自适应支付之间的区别等。）。
另一件事是，我们需要在创建隐藏表单 (html) 或使用 API 之间做出选择。 （我需要解释）
文档很长，我真的很困惑，我不知道该选择什么（显然 REST APIs 更适合简单的支付，但我真的想了解更多关于SOAP & NVP ..)
我是新手，谁能成为志愿者并帮助我解决这个问题？
谢谢！
【问题讨论】：
标签： soap paypal paypal-nvp paypal-rest-sdk
我已经做了几次 PayPal-integration-dance（尽管现在是几年前），让我总结一下我的想法（请记住，情况可能略有变化）
PayPal 提供大量 API/集成方法的原因是因为他们希望能够刺痛您支持以下付款的大量地方：
如果您只有博客、静态 HTML 托管、现成的电子商务网站或其他一些“原始”网络技术，submitting hidden HTML forms 几乎是您唯一的选择。我怀疑这是 PayPal 使用的原始机制，虽然他们必须永远继续支持它，但您今天不想在现代 Web 框架中使用这种方法，例如SpringMVC。
NVP API 是另一种长期存在的集成方案，适用于将参数有效地拼接到 URL 中是您的客户所能做的所有事情的时候。如今，当 REST JSON API 可用时，没有充分的理由使用此 API - 大多数人发现 JSON 比 URL 编码的参数更容易阅读。
我怀疑接下来按时间顺序介绍，SOAP API 反映了 XML 将统治世界的时代。在一些（非常严格和/或传统的）地方，它仍然存在。同样，如今，如果您有选择，您可能不会走这条路 - 使用 Java 通常涉及与 SOAP 框架（如 Apache CXF 和大量机器生成的 .java 文件）的紧密集成。
REST API 是 Java 领域最现代和 (恕我直言) 最好用的，也是我推荐的选项。看起来 PayPal 也希望您使用它，所以我将在本答案的其余部分讨论它。
作为 Java 开发人员，当您选择 REST API 时，您可以进一步选择使用 PayPal's SDK 或滚动您自己的集成方案。在以下情况下考虑使用 SDK：
您可以预见您的 PayPal 集成将变得非常庞大和/或使用高级 API 功能
您没有任何其他 HTTP 集成点，因此还没有从您的代码中调用 HTTP 方法的基础设施（例如 Apache HttpClient 或 Spring 3 中内置的 RestTemplate 功能）
您没有（或不想拥有）可用的 JSON 解析器
由于您已经通过 cURL 使用 API，并且您了解调用及其顺序，因此您可能对此还没有决定。如果您没有太多时间压力，我建议您使用（和学习）Apache HttpClient 以及像 Jackson 这样的 JSON 库沿着自己的路径走下去 - 它们是您的武器库中很有价值的工具，您几乎肯定会在未来的集成中再次使用它们。
另一个开发技巧，适用于任一 REST API 选项 - 如果您使用“存根服务器”（例如 this one）来模拟 PayPal 的连接结束，它会记录收到并响应的每个请求的详细信息适当地。这对于准确调试“通过网络”输出的内容和/或重复测试内容来说是天赐之物。
【讨论】：
REST API 相当新，不像 Classic 那样功能丰富。我仍然推荐 Classic，因为它没有任何问题或过时。 PayPal 想与 Facebook 这样的酷孩子一起运行，因此他们制作了一个 oauth API（我怀疑它在移动设备上更容易，但您也可以轻松实现另一个 API。）。
经典的 NVP（名称值对）易于理解，是我使用过的最佳文档之一。您的调用都是您发布到 API 端点的查询字符串。
METHOD=DoDirectPayment&AMT=1.00&EXPDATE=012015
除非你睡在印有 WSDL 的毯子里，否则我不会走 SOAP 路线。 SOAP 很难理解和使用。
Classic 支持 REST 仍然不支持的多个调用（MassPay、Buttons API、大多数自适应调用等）。我预计 PayPal 最终会赶上来，但就目前而言，Classic 是某些功能的唯一选择。
关于所有的电话
HTML 支付标准解决方案和 API 的最大区别在于，使用 API，您必须符合 PCI 标准。大多数情况下，这意味着您不记录敏感数据（如 CVV2），在您的网站上具有安全性，并且您拥有 SSL 证书，但未来可能会对您提出其他要求。好处是你可以完全控制这个过程。 Payments Standard 让您无法控制，但您也没有 PCI 合规性。
【讨论】：
我已经阅读了大部分 PayPal Classic API
在我的拙见中：我可以说 Express Checkout 是 Adaptive Payments 的一部分（在 Adaptive Payments 中，客户可以使用 PayPal 登录并支付物品，这样他们就不需要输入他们的送货地址，信用卡详细信息等，因为它们已经记录在他们的 PayPal 帐户中） 其实，我有一些注意事项要说：
最后，我要告诉你，我的老板想开发一个不使用 PayPal 功能登录的支付解决方案（换句话说，他希望客户直接填写他们的银行/信用卡详细信息，我们不需要运费信息，因为我们正在销售数字商品）所以我认为选择的最佳解决方案将是自适应支付 API（我们必须考虑到我们是非美国开发人员的事实）
你怎么看？
【讨论】：
自 2017 年 1 月起，NVP 和 SOAP 方法现已弃用。https://developer.paypal.com/docs/classic/express-checkout/
【讨论】：