以下为支付服务设计过程中，自己思考及借鉴所记【完善中】

幂等性

对于可能存在的并发支付回调，实际更新支付结果应只有一次，这个可以通过加数据锁的方式去实现。和第三方支付系统交互。对外的 商户订单号是衔接起两边服务的桥梁。

分布式锁

加锁时机

第三方支付触发回调接口时，将 商户订单号 拼接特定的前缀如pay:${out_order_no} 作为key，如果当前有锁，根据实际业务情况选择等待或者抛异常，而没锁的情况下，则加锁后进行业务逻辑操作

锁的释放

由于支付逻辑及网络的不可确定性，需考虑加锁后对锁的释放

• 出现异常时应该释放锁
• 超出一定时间后主动释放锁

数据锁

事实上付款单的更新场景并不多，可以在 事务内 select for update , 然后再 update 。 只有在事务提交或者回滚的情况下，后面新的更新操作才能进行。

回调结果验证

以下验证通过后，才能更新支付状态及订单状态

• 验证回调参数签名
• 验证回调付款金额与订单金额是否一致
• 验证回调收款账号是否与支付时收款账号一致
• 验证应用id是否为支付时应用

支付状态不可逆

• 待付款 → 支付成功
• 待付款 → 关闭支付