PayPal文档(REST,Classic:SOAP和NVP)选择什么？

完成了PayPal-integration-dance几次(虽然几年前现在)让我总结一下我的想法(并记住,事情可能略有改变)

PayPal丰富的API /集成方法的原因是他们希望能够通过以下方式激励您支持支付的大量地方:

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

该NVP API是这是在合适的时候,当有效参数拼接成一个网址为所有的客户端可以一起做的另一个长期的集成方案.现在,当REST JSON API可用时,没有什么理由可以使用这个API - 大多数人发现JSON比URL编码参数更容易阅读.

接下来我怀疑,按时间顺序介绍,SOAP API反映了XML统治世界的时间.在一些(非常严格和/或传统)的地方,它仍然存在.如今,如果您有选择的话,您可能不会走这条路 - 使用Java通常涉及与Apache CXF和大量机器生成的.java文件等SOAP框架的紧密集成.

该REST API是最现代的和(恕我直言)最好从Java的土地使用,而且是我推荐的选项.它看起来就像是PayPal更喜欢你使用的东西,所以我会用这个答案的其余部分来讨论.

作为Java开发人员,当您选择REST API时,您可以选择使用PayPal的SDK或滚动自己的集成方案.在以下情况下考虑使用SDK:

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

您没有任何其他HTTP集成点,因此还没有用于从代码中调用HTTP方法的基础结构(例如Apache HttpClient或Spring 3中内置的RestTemplate功能)

您没有(或者不想拥有)可用的JSON解析器

由于您已经通过cURL使用了API,并且您了解了调用及其顺序,因此您可能尚未对此做出决定.如果你没有太大的时间压力,我建议你使用(和学习)Apache HttpClient以及像杰克逊这样的JSON库来实现自己的路径- 它们是你工具库中的宝贵工具,你会几乎可以肯定在未来的集成中再次使用它们.

另外一个发展尖端,它适用于任何REST API选项-如果你使用一个"存根服务器",比如这一个模拟连接的PayPal的结束,每一个请求它接收并做出适当的反应,它会记录详细信息.这可能是一个天赐,用于调试"通过电线"和/或反复测试的内容.

REST API相当新,并不像Classic那样充满功能.我仍然推荐Classic,因为它没有任何错误或过时.PayPal希望与像Facebook这样的酷孩子一起运行,因此他们制作了一个oauth API(我怀疑它对移动设备来说更容易,但你也可以轻松实现另一个API.).

经典的NVP(名称值对)很容易理解,也是我工作过的最好的文档之一.您的调用是您发布到API端点的所有查询字符串.

METHOD=DoDirectPayment&AMT=1.00&EXPDATE=012015

我不会去SOAP路线,除非你睡在毯子上,上面印有WSDL.SOAP只是一种理解和使用的痛苦.

Classic支持REST仍然没有的几个调用(MassPay,Buttons API,大多数自适应调用等).我预计PayPal最终会迎头赶上,但就目前来说,Classic是一些功能的唯一选择.

至于那里的所有电话

DoDirectPayment - 直接处理信用卡.需要订阅Payments Pro才能使用,但它是一个全功能的卡处理系统

快速结账 - 免费使用.允许您接受PayPal帐户作为付款方式.基本上你调用API,获取令牌,重定向用户,他们登录,PayPal重定向到你,然后你使用令牌来获得报酬.

自适应付款 - 您可以在这里制作一些有趣的东西来制作创意付款系统.假设你有第三方为你开卡,但你想减少他们的销售.链式支付就是这样做的.

HTML Payments标准解决方案和API的最大区别在于,使用API​​时,您必须符合PCI标准.大多数情况下,这意味着您不会记录敏感数据(如CVV2),在您的网站上拥有安全性并且您拥有SSL证书,但可能会有其他要求.好处是你可以完全控制这个过程.付款标准为您提供无法控制,但您也没有PCI合规性.