支付注意事项

微信支付等支付功能开发过程中的必要流程了：

支付：创建业务订单---> 创建支付订单---> 唤起支付收银台---> 输入密码或指纹支付---> 进入支付回调处理 ---> 更改支付状态及业务状态

退款：创建退款订单---> 发起退款---> 进入退款回调处理 ---> 更改支付状态及业务状态

客户系统的支付环节有一个前提是从号源池中取号，而退款时要进行退号或销号。这里就不单单是一个微信支付的简单实现了，而是一个重要的业务逻辑实现。

们到底是要先取号再支付还是先支付再取号，同样的，退款时我们是要先退款再退号，还是先退号再退款呢？

正常的逻辑:

1）、支付时，一定要先完成支付，再处理业务系统的业务。

比如这里就是先支付再取号，这样的好处就是，正常情况下没事，异常情况下要么支付失败就不走后续，要么支付成功但后续取号失败，这样你服务的客户方没损失，损失的是用户，因为用户已经付钱了，这就是一笔长款，客户方只需要根据用户反应的情况审查一下然后退款给用户就行了。

相反，如果你写反了，导致的其中一种后果就是用户先取了号，但支付失败了，用户依然可以拿着号来用，这对客户方就是一种损失，钱没收到号还能用。

2）、退款时，一定要先完成业务确认，再执行退款。

比如这里就是先退号，再退款，这样要么退号失败不会往下走，要么退号成功，但退款失败，损失的依然是用户的钱，客户方怎样都没损失，形成一笔长款，审查过后确认情况没问题再退款给用户即可。

相反，如果你写反了，导致的后果就是先退款，但退号确认失败了，客户方的号还没退回来，但钱已经打进用户账户了，客户方就损失了，还得找用户追回来，如果用户不给你也没办法，因为是你自己的失误导致的，这就形容严重事故了。

案例分析梳理的逻辑，不仅仅在这里适用，在其他场景也是适用的，大家可以多看看仔细揣摩下，任何和钱打交道的功能开发都要谨慎，支付功能实现一点都不难，有现成的工具可以使用，难的其实还是业务，遵循一个原则：不管你的业务逻辑怎么写，只要正常及异常情况下，你服务的客户都不会亏钱，那么你的支付逻辑就是正确的。