PayPal文档（REST，Classic：SOAP＆NVP）选择哪个？

Question

PayPal文档（REST，Classic：SOAP＆NVP）选择哪个？

soappaypalpaypal-nvppaypal-rest-sdk

18

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

我觉得REST APIs很容易理解，但我还不知道如何在SpringMVC中实现它们，所以我只是用cURL测试它们。（关于这个有帮助吗？）

另一方面，Classic APIs很令人困惑。（例如，我们可以用Adaptive Accounts做什么，Express Checkout和Adaptive Payments之间有什么区别等等。）

另一件事是，我们需要选择创建一个隐藏的表单（html）还是使用APIs。（我需要解释）

文档非常长，我真的很困惑，不知道该选择什么（显然REST APIs对于简单的支付更好，但我真的想更多地了解SOAP和NVP..）。

我是新手，有人可以自愿帮助我吗？

谢谢！

- YellowStrawHatter

4个回答

8

REST API是相对较新的，并不像Classic那样功能丰富。尽管如此，我仍然推荐使用Classic，因为它并没有任何问题或过时之处。PayPal希望跟上像Facebook这样的“酷孩子”，所以他们制作了一个OAuth API（我猜这对移动端来说更容易，但你也可以很容易地实现另一个API）。Classic NVP（名称-值对）易于理解，是我用过的最好文档化的API之一。你的请求全部都是查询字符串，你需要将其POST到API端点。

METHOD=DoDirectPayment&AMT=1.00&EXPDATE=012015

如果你不是在睡觉时盖着印有WSDL的毯子，我就不建议你使用SOAP。SOAP很难理解和操作。

Classic支持多个调用，而REST仍然不支持（MassPay、Buttons API、大多数Adaptive调用等）。我预计PayPal最终会赶上来，但目前来说，对于某些功能，Classic是唯一的选择。

至于所有的调用

DoDirectPayment - 直接处理信用卡。需要订阅Payments Pro才能使用，但它是一个功能齐全的卡处理系统
Express Checkout - 免费使用。允许您接受PayPal账户作为支付方式。基本上，您调用API，获取令牌，重定向用户，他们登录，PayPal重定向到您，然后您使用令牌获得付款。
Adaptive Payments - 这是您可以创建创意支付系统的地方。比如说，您有一个第三方运行卡片，但您想要销售额的一部分。链式支付就可以做到这一点。

HTML Payments Standard解决方案和API的最大区别在于，使用API必须符合PCI标准。主要意味着您不记录敏感数据（如CVV2），网站具有安全性，并且您拥有SSL证书，但未来可能会对您施加其他要求。好处是您完全控制整个过程。Payments Standard不提供任何控制，但您也不需要符合PCI标准。

- Machavity

现在看来，REST API 提供了 NVP 库没有（或者不是那么明显的）功能。例如，复杂的账单协议。 - Ryall

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

2

我已经阅读了大部分PayPal Classic APIs。

根据我的理解：我可以说Express Checkout是Adaptive Payments的一部分（在Adaptive Payments中，客户有可能通过PayPal登录并支付物品，因此他们不需要输入自己的送货地址、信用卡信息等，因为这些信息已经记录在他们的PayPal账户中）。

实际上，我有一些需要说明的地方：

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

最后，我必须告诉你，我的老板想开发一种不需要通过PayPal登录的支付解决方案（换句话说，他希望客户直接填写他们的银行/信用卡详细信息，我们不需要运输信息，因为我们销售的是数字商品），因此我认为最好的选择是Adaptive Payments API（我们必须考虑到我们是非美国开发人员）。

你怎么看？

- YellowStrawHatter

哪个国家？另外，您需要的是Payments Pro，而不一定是Adaptive。Adaptive是针对我提到的那些特殊情况，例如分割付款。请注意，您不能仅实现Payments Pro而不实现Express Checkout（至少曾经是这样的规定）。 - Machavity

我们的客户目前是欧洲人。使用付款专业版需要支付每月30美元的费用，我们想要免费的标准解决方案。通过快速结账，我的客户可以直接支付（设置信用卡/银行卡详细信息），而无需登录PayPal吗？ - YellowStrawHatter

Payments Standard确实支持无需登录即可处理信用卡，但它有些棘手。如果您在美国、加拿大、英国或爱尔兰，我建议使用Stripe。虽然未来的处理费用会更高，但没有月费。 - Machavity

不，我们不属于这些国家之一。谢谢你的回答。 - YellowStrawHatter

1

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

- Sadee

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- millhouse · Accepted Answer

由于我已经进行了几次PayPal集成工作（虽然是几年前的事情），所以让我总结一下我的想法（请注意，事情可能略有变化）。

PayPal拥有如此众多的API / 集成方法的原因在于他们希望能够从各种不同的地方支持付款。

如果你只有博客、静态HTML托管、现成的电子商务网站或其他“原始”Web技术，那么提交隐藏的HTML表单几乎是你唯一的选择。我认为这是PayPal最初使用的机制，虽然他们必须永远支持它，但你不会想从像SpringMVC这样的现代Web框架中使用这种方法。 NVP API是另一种长期存在的集成方案，在你的客户端只能有效地将参数拼接成URL时是合适的。当REST JSON API可用时，没有太大的理由使用此API-大多数人发现JSON比URL编码的参数更容易阅读。

按时间顺序引入的下一个我怀疑是SOAP API，它反映了XML将统治世界的时代。在某些（非常严格和/或传统的）场合，它仍然如此。同样，在有选择的情况下，这些天你可能不会走这条路-与Java的使用通常涉及与SOAP框架（如Apache CXF）的紧密集成和大量机器生成的.java文件。 REST API是最现代化和（在我的意见中）从Java-land中使用最好的选项，也是我推荐的选项。看起来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选项 - 如果您使用“存根服务器”（例如this one）来模拟PayPal连接的一端，它将记录接收到的每个请求的详细信息并做出适当的响应。这对于调试“通过电线”传输的确切内容和/或反复测试事物非常有用。