上回说了关于客户纠纷通知，我们决定使用webhook来进行处理，但是由于其他原因，导致昨天的手记没有写完，今天继续往下写。
纠正
关于昨天写了案例中，忘了交代我使用的支付模式，这里交代一下，分别是invoicing方式和checkout方式，而针对这两种不同的方式，paypal是提供了不同的回调事件的，所以昨天我们测试的时候出现一直没有回调成功，其实是由于支付模式不同，而paypal对指定的模式都只提供了指定的事件才会回调。
invoicing方式回调
对于invoicing支付方式，根据paypal官网提示，网址为：https://developer.paypal.com/docs/integration/direct/webhooks/event-names/#log-in-with-paypal，只有如下几种重发事件，也就是说，当客户对该支付方式的订单申请纠纷的时候，是不会有回调事件的，这也是我们昨天测试的时候一直没有看到回调的原因。但是退款成功的回调是有的，所以我们可以配置一个INVOICING.INVOICE.REFUNDED事件，通过该事件回调的时候提供的invoice_id来执行我们的业务逻辑。至于这种方式下的纠纷订单，也是有方式来得到的，就是使用上次文章说的paypal提供的纠纷订单的api，不过由于没有提供sdk，开发成本有点高，如果有兴趣的话可以自己去了解。
checkout方式回调
首先吐槽一下，这个方式我折腾了2小时才搞懂里面的事务id是怎么回事。这里我来理一下思路。首先该方式支付的回调是存在的，如图下所示：
所以我首先写了一个接口来接收纠纷订单创建CUSTOMER.DISPUTE.CREATED的事件，发现paypal回调时候的请求参数信息参考如下：里面有实际意义的起始只有dispute_id和seller_transaction_id，但是如果还是使用纠纷事件的api时，还是一样麻烦，所以只有研究seller_transaction_id到底是什么。
但是这个id到底代表什么，文档里面没说。经过一段折腾，最终发现使用如下api，能得到payment_id，也就是PAY-47382726FS7093137LPMUT3Q
本以为已经找到的重点，但是当我登录到paypal去查看争议订单的时候，惊奇的发现，争议订单界面提示的不是payment_id！！而是一个Transaction ID！！！这又是个什么鬼？
值得注意的是，此Transaction ID和seller_transaction_id并不是同一个值，所以现在的问题就是，我只能在回调函数里找到这个回调的是哪个订单，但是无法确认paypal争议订单里面哪个订单对应我自己系统里面的订单，不知道你们有没有听懂，反正就是我的订单记录里面少了Transaction ID，导致整个流程无法串接起来了。没办法，继续找。
最终还是让我找到了，原来，checkout支付方式时候，在转账操作的时候，如果转账成功，会生成一个Transaction ID值，获取的方式如下所示。
可能大家还没有弄懂，这里我小结一下：
checkout的方式一共有三个id值，分别是payment_id，Transaction ID，seller_transaction_id，其中payment_id是在创建订单的时候paypal返回的，Transaction ID是对订单支付的时候paypal返回的，而seller_transaction_id是在争议订单回调事件的时候返回的，而且这三个id有如下的关系：
1、当该订单没有纠纷时候：
通过payment_id可以查询出Transaction ID
2、当该订单存在纠纷时候：
通过payment_id可以查询出Transaction ID和seller_transaction_id：
Payment oldPayment = Payment.get(context, "paymentId");
通过seller_transaction_id可以查询出payment_id：
Sale sale = Sale.get(context, "seller_transaction_id");
因此，既然知道了对应关系，那么回调函数也就很简单了，这里就不写了，不过记得回调的时候记得验证哦，不要被黑客给黑了。
随时随地看视频
