支付宝微信等离线支付场景怎么设计，底层逻辑就这么简单

极海Channel:
总监的分析很有意思，尤其是最后离线修改时间支付太好玩了，谈谈我对于这个问题的一些看法： 1. 单离线支付，技术上的难点在二维码的功能性和安全性角度考虑，功能上很简单能够识别出目标用户即可，关键在于安全性，这里又要考虑被拍照和截图与重复扫码问题（因为这里对比在线支付，无法立马通知付款方支付成功），所以这里的解决方案是灵活的，生成逻辑里应该带有时间戳或则预先分配的支付串并且用私钥进行加密，根据总监最后的测试，支付宝应该是带时间戳的生成逻辑，至于重复消费问题，服务端的幂等也是需要考虑的，而且微信也采用短信通知尽量保证用户确认付款成功这件事。 2. 双离线支付，只能用本地记账的方式+定期同步服务端，但这个过程存在很多风险，例如如何避免所谓的双花问题，这其实要从产品业务上考虑，这一点与单离线很不一样，单离线与双方在线支付体验无明显差异，单离线应该考虑一定的透支额度，采用类似信用绑定的设计，并且要促使收款方尽快与服务端同步账单，例如离线收款金额处于冻结状态，同步完才可以使用，并且在双离线支付的场景，收款方有权利要求付款方手动确认支付金额扣除付款方的离线钱包金额，避免双花纠纷，当然这里有人想采用数据恢复的方式恢复花出去的钱，信用分的方式，但是存在一种极端场景，不断的恢复钱包再找离线收款终端理论上可以无限消费，这里只能采用硬件保护，这需要支付终端内置加密芯片，我猜测这可能是至今DCEP没大规模推广的主要原因吧。 所以讨论到这里发现这绝不仅仅是技术问题，也存在很多产品设计问题，这是我区分高级开发和架构师的重要标准。 声明：以上仅个人观点。

年度吹牛大赛最佳演员:
两视频都看了，吐槽一些极海的氛围——把问题核心稀释，套一些行业术语或互联网黑话，搞的人云里雾里。比如电脑怎么开机这个问题，非要把电脑品牌、操作人是否是盲人、电源检测这些非核心因素揉在一起，生怕别人搞懂了或者这种（模板）表达会显得自己很厉害一样 事实上：做事的本质还是和Java之父余胜军一样卖课收割

it铲屎官:
路总监我感觉你说的还行，但是我比较确信你没做过支付类的业务，你说就暴露出来了

【回复】回复 @蟑螂3吃 :就比如时间戳，做过的根本就不用去验证都知道这回事
阿尤与地下城:
我还是有疑问啊，真正的离线情况下，真的有用么？打个比方，用户的手机完全无网络，这种还怎么进行支付。现在的离线支付是假离线支付还是真离线支付

【回复】类似提供了一个加密密钥，让商家去你的账号上取钱
【回复】回复 @Java陆总监 :额，，，好吧，这样确实可以。。。
【回复】回复 @阿尤与地下城 : 用户没网，收款方有网啊。。收款方传到支付宝就OK了
请看电影:
鄙人有个问题 离线支付你这个离线是怎么个离线，离线不是在非网络环境下吗？？用户id不需要联网查询吗

【回复】因为app已经是登录态了，而且都缓存了用户信息，基本上用户id不需要联网
【回复】本来支付是需要用户向支付宝发起给商家转账操作的申请，现在用户是离线的，支付变成了商家通过支付宝里的付款二维码携带的加密信息直接向支付宝申请转账操作。你可以把二维码理解成银行的支票
【回复】回复 @走进西域 :还是没懂离线，离线指的单方面离线吗？ 有具体定义吗，按照你的说法，这是一种容错机制吧
Java陆总监:
视频最后提了一个思考题，如果支付失败了，分钟级别的二维码失效了，怎么才能让用户还能让用户在这一分钟支付成功而不是等一分钟，大家可以探讨下[捂脸]

【回复】叫用户手动刷新一下[doge][笑哭]
【回复】回复 @Creamyff :这个是个解决方案，但是不是我想问的点[呲牙][呲牙]
【回复】Redis记录加密串的时候，给个失败次数，然后再记个成功记录，ttl也是一分钟，然后失败第二次以后的需要再查有没有成功记录，但是好像有点多余[藏狐]
您的網上鄰居:
[吃瓜]你可以说下将军令，谷歌微软验证器的逻辑啊[doge]

AI全文总结:
✨ 课代表总结： 本视频深入探讨了离线支付场景的设计，从底层逻辑、安全性、冗余匹配、双离线场景等方面进行了详细解析。视频通过模拟面试的情景，揭示了离线支付设计中的关键点和常见问题，并以支付宝的二维码支付为例，验证了时间因素在支付过程中的重要性。 --本消息由@AI视频总结 召唤发送，仅供参考

白烛葵gg:
我觉得本质上是让Redis可以感知到支付状态 1.可以在Redis对应记录上同时保存一个支付状态 2.直接在失败时删除Redis记录 3.用户手动刷新，或支付失败自动刷新