paypal 支付事项

再不疯狂就老了，疯狂过后发现老的更快。

 

查询paypal 开发手册，paypal 集成三种方式

1、Client-side integration(客户端集成)

　　特点:
　　　　主要支付流程是在客户端完成，需要客户端集成PayPal SDK，以及需要集成PayPal自带的支付按钮，对代码的侵入性比较强，不需要服务端参与
　　缺点:
　　　　整个下单支付流程是在客户端完成，服务端没有感知，因此在弱网环境下会有掉单的风险

 

2、Server-side integration(服务端集成)

　　特点
　　　　主要支付流程是在服务端完成，客户端没有什么工作两，服务端需要集成PayPal SDK，主要主动查询订单状态，发起扣款(ReturnUrl)和事件通知回调这些手段来保证调单的情况
　　　　整个订单支付流程可靠
　　缺点:
　　　　需要服务段对接的工作稍多

 

3、Programmatically start the SDK(客户端集成)

　　特点:
　　　　和第一种客户端集成方式类似，主要支付流程在客户端完成， 可以自定义相关的UI
　　缺点:
　　　　整个下单支付流程是在客户端完成，服务端没有感知，因此在弱网环境下会有掉单的风险

 

支付时间顺序（时序），交互步骤

1、创建订单: /v2/checkout/orders

 　　调用时机：用户下单，服务端请求PayPal生成预支付订单
　　 功能：类似与国内微信/支付宝的预支付接口，这个接口会返回创建订单的状态，如果订单创建成功还会在approve属性中返回一串链接，用于返回给客户端打开这个链接，进行支付
　　 注意：这个接口会传递给PayPal returnUrl 和 cancelUrl 分别用于在支付完成后和支付取消后重定向到服务端，用于下一步操作

2、捕获订单: /v2/checkout/orders/{order_id}/capture

　　调用时机：用户支付完成后，PayPal会重定向到服务端的returnUrl，这时可以请求PayPal进行扣款(这一步和国内微信/支付宝有点差异)
　　功能：用于当前用户支付完成后，在服务端要进行捕获订单的操作

3、查询支付状态: /v2/payments/captures/{capture_id}

　　调用时机：查询订单的支付状态
　　功能：查询订单的支付状态
　　注意：如果配置了支付完成的事件回调，则应该使用回调作为订单最终支付完成确认的方式，改接口，可以作为服务端主动发起查询的手段，
　　例如超时主动查询，防止调单的情况；由于这里主要介绍支付对接流程，对于调单补单情况就不做赘述，网上刚博客也有很多方案

4、支付完成(Payment capture completed)-事件通知回调: 用户配置在PayPal后台的链接

　　调用时机：用户在支付完成后，服务端也完成了订单捕获，这时就会发起Payment capture completed 回调
　　功能：异步回调实现订单支付完成通知
　　注意：事件通知回调需要在PayPal后台开启，并配置服务端通知URL ，如果开启了通知，所有的PayPal通知都会回调到这个URL，
　　　　　　 如果不需要关注其他事件，这里有两种处理方式
　　　　　　1.默认配置全部事件通知：服务端则要根据回调的事件名，return跳过其他事件，仅处理支付完成回调的事件（具体见后续的代码Demo）
　　　　　　2.配置指定的事件通知 （项目中使用这一种）

5、事件回调签名验证

　　调用时机：事件回调后，验证本次回调的有效性

 

paypal 支付完成2种确认方式

1、同步通知，简称PTD

2、异步通知，简称IPN