18

我需要使用 PayPal API 开发支付解决方案。实际上我开始了文档阶段（在http://developers.paypal.com上）

我发现REST API是可以理解的，但我仍然不知道如何使用 SpringMVC 实现它们，所以我只是使用 cURL 来测试它们。（对此有任何帮助吗？）

另一方面，Classic API 令人困惑。（例如，我们可以使用自适应帐户做什么以及快速结账和自适应支付之间的区别等。）。

另一件事是，我们需要在创建隐藏表单 (html) 或使用 API 之间做出选择。（我需要解释）

文档很长，我真的很困惑，我不知道该选择什么（显然REST API更适合简单支付，但我真的想了解更多关于SOAP和NVP的信息..）

我是新手，有人可以成为志愿者并帮助我吗？

谢谢 ！

4

4 回答 4

24

完成了几次 PayPal 集成（尽管现在是几年前）让我总结一下我的想法（请记住，事情可能略有变化）

PayPal 提供大量 API/集成方法的原因在于，他们希望能够在众多地方向您索取支持付款：

  • 如果您只有一个博客、静态 HTML 托管、现成的电子商务网站或其他一些“原始”网络技术，那么提交隐藏的 HTML 表单几乎是您唯一的选择。我怀疑这是 PayPal 使用的原始机制，虽然他们必须永远支持它，但您今天不想从像 SpringMVC 这样的现代 Web 框架中使用这种方法。

  • 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 的 SDK或滚动您自己的集成方案。在以下情况下考虑使用 SDK：

  • 您可以预见您的 PayPal 集成变得非常庞大和/或使用高级 API 功能

  • 您没有任何其他 HTTP 集成点，因此还没有用于从代码调用 HTTP 方法的基础架构（例如Apache HttpClient或Spring 3 内置的RestTemplate功能）

  • 您没有（或不想拥有）可用的 JSON 解析器

由于您已经通过 cURL 使用过 API，并且您了解调用及其顺序，因此您可能对此还没有决定。如果您没有太大的时间压力，我建议您使用（和学习） Apache HttpClient以及像Jackson这样的 JSON 库沿着自己的路径走下去——它们是您的武器库中很有价值的工具，您将几乎可以肯定在未来的集成中再次使用它们。

另一个开发技巧，适用于任一 REST API 选项 - 如果您使用诸如此类的“存根服务器”来模拟 PayPal 的连接结束，它将记录它接收到的每个请求的详细信息并做出适当的响应。这对于准确调试“通过网络”输出的内容和/或反复测试事物来说可能是天赐之物。

于 2014-01-07T23:28:40.750 回答
8

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 是某些功能的唯一选择。

至于外面的所有电话

  • DoDirectPayment - 直接处理信用卡。需要订阅 Payments Pro 才能使用，但它是一个功能齐全的卡处理系统
  • 快速结帐- 免费使用。允许您接受 PayPal 帐户作为付款方式。基本上，您调用 API，获取令牌，重定向用户，他们登录，PayPal 重定向到您，然后您使用令牌获得报酬。
  • 自适应支付- 在这里您可以做一些有趣的事情来制作富有创意的支付系统。假设您有第三方为您经营卡片，但您希望从他们的销售额中分得一杯羹。链式支付就是这样做的。

HTML 支付标准解决方案和 API 的最大区别在于，使用 API，您必须符合 PCI。大多数情况下，这意味着您不记录敏感数据（如 CVV2），在您的网站上具有安全性，并且您拥有 SSL 证书，但未来可能会对您提出其他要求。好处是你可以完全控制这个过程。Payments Standard 让您无法控制，但您也没有 PCI 合规性。

于 2014-01-07T23:47:46.393 回答
1

好吧，我一直在阅读大部分 PayPal Classic API

以我的谦逊理解：我可以说 Express Checkout 是 Adaptive Payments 的一部分（在 Adaptive Payments 中，客户可以使用 PayPal 登录并支付物品，因此他们不需要输入他们的送货地址、信用卡详细信息等，因为它们已经记录在他们的 PayPal 帐户中）实际上，我有一些注意事项要告诉：

  • Mass Payments 允许您向多个账户汇款，而 Adaptive Payments 也是如此，那么它们之间有什么区别？（可能是链接功能？）
  • 关于 Invocing API：客户在付款过程的什么时刻可以看到它？（在付款确认之前？），我仍然不知道它的用处..

最后，我不得不告诉你，我的老板想开发一个没有使用 PayPal 登录功能的支付解决方案（换句话说，他希望客户直接填写他们的银行/信用卡详细信息，我们不需要运输信息，因为我们正在销售数字商品）所以我认为选择的最佳解决方案将是自适应支付 API（我们必须考虑到我们是非美国开发人员的事实）

你怎么看 ？

于 2014-01-09T17:07:26.167 回答
1

自 2017 年 1 月起，NVP 和 SOAP 方法现已弃用。https://developer.paypal.com/docs/classic/express-checkout/

于 2019-05-31T11:41:23.703 回答