当时pos机消费冲正成功,支付宝也支付成功了

网上有很多关于当时pos机消费冲正成功,支付宝也支付成功了的消费知识，也有很多人为大家解答关于当时pos机消费冲正成功的冲正成功成功问题，今天乐刷官方代理商(www.zypos.cn)为大家整理了关于这方面的支付支付知识，让我们一起来看下吧!

本文目录一览：

1、宝也当时pos机消费冲正成功

当时pos机消费冲正成功

事实上支付宝和微信的消费“当面付”产品，是冲正成功成功一款联机在线支付产品，所以不允许双方均离线的支付支付场景下支付（这一点和公交卡圈存支付不一样，公交卡的宝也近场支付事实上允许双方脱机）。

题目中所知的消费支付宝和微信没有网络，指的冲正成功成功都是消费者客户端没有网络，而不是支付支付双方都没有网络。

严格来说，宝也当面付产品（特指商户主动扫消费者钱包客户端上的消费 token 码进行支付的形态）必须要商户在线方可进行联机交易，原因有以下两点：

支付公司为了保证资金安全必须要确保每笔用户的冲正成功成功支付行为背后都真正发生了资金扣款，所以在线联机确保支付成功是支付支付必要的。（这里解释了为什么不允许双方脱机）

商户为了确保用户的支付结果可信赖，必须要自己的终端或者系统从支付公司获得支付结果，而不能以消费者的支付结果凭证作为结论。以传统 POS 业务举例，你可以认为你的刷卡信息等同于支付宝的当面付码，商户必须要看到 POS 机打出支付成功单据后才认为支付有效，如果 POS 支付超时没有回执，光凭客户手中的银行短信通知是不会让客户走的，而是会冲正掉上一笔交易让客户重新刷一笔。（这里解释了为什么要选择商户必须联机的方案）

那么，我们来看看一个标准的当面付产品的信息流是什么样的（原谅我草草画了一下）：

我们可以看到在这个图里红色圈圈部分，商户系统和支付宝系统是对接上的，所以商户系统是联机的——而用户的手机，在展示 code 的时候，我并未强调是否和支付宝服务端联机。

事实上，不论是微信还是支付宝都支持两种用户码生成模式，即在线码和离线码。

在线码其实很容易理解，用户目前是登录钱包的状态，只要点击【付款】按钮，客户端就向支付宝的服务端申请一个针对这个客户账户的支付凭证码并展现到客户手机上。

这个支付凭证码在支付宝的服务端会有一组数据库记录其与真实客户账户之间的关联，并且这份关联的有效期为 60S，超过时效即便商户上送这个码，支付宝也会认为这是作废码而不予处理。

用户每次点开【付款】、等待超过 60S、主动刷新付款码，都会触发客户端向服务器申请一个新码的请求。

这个方案的好处是：

相对安全，每次码都是服务端生成。

业务灵活，即便对码的安全算法等进行较大的调整，也不用升级客户端，因为是服务端发码。

这个方案的坏处也显而易见：

用户的手机客户端必须在线联网，如果没有网络则无法获取付款码

用户即便在线，如果网络连接不好，也会出现点了付款等好久才看到码的情况，体验会不可控。

为了解决在线码方案的问题，离线码方案就出现了。

离线码的基本技术原理其实也不复杂，可以参考 @反方向的钟 的回答，比较简单的实现方式是：

用户登录后，服务端通过可信网络向用户客户端发送一个种子数据（每个客户的种子数据唯一，换用户登录后销毁原种子，重新下载种子）本地保存，当用户点击【付款】时，客户端利用这个种子数据 + 时间戳 + 一套安全算法可以生成一串数字，即离线码。

当用户使用离线码支付时，服务端通过一定算法校验这个码的确是来自于这个用户，随即确认用户授权完成支付。

离线码的好处不言而喻：

用户无需在线，就算在地下室等没有网络的场景一样可以使用

由于不依赖网络，所有码本地生成，所以客户体验很好，一点付款码就能出来

那离线码的劣势呢，我们看看：

用户 root/ 越狱手机后，保密存储的种子数据有可能被不法分子利用恶意程序获取到，导致离线码被随意生成用于消费。

恩……怎么说呢，毕竟现在不是发烧友主动 root 越狱的用户并不多，这是其一。

即便是 root 越狱，如果用户使用手机的习惯良好，被恶意程序攻击手机的概率也很低，这是其二。

每家公司都有自己的安全团队去保障自己客户端的数据安全，并不是说 root 的用户就只能坐以待毙了，否则微信和支付宝早被搞破产了，这是其三。

当然从我个人的角度来说，普通用户我都不建议去 root 或者越狱。

这个问题最粗暴的方案就跟反方向的钟所说的一样，监测到系统被 root 了就对用户限权（很多银行的客户端方案都是这么搞的）。

作为直接面向消费者市场且充分竞争的产品，微信支付和支付宝断然不会采用上面那个方案的。

怎么能又开放离线码给用户，又能确保用户支付安全，本身也是支付公司安全竞争力的一部分，这里就省略几万字了。

数据碰撞可能导致 A 用户的码扣到 B 用户的账户

恩，这里涉及一些算法问题，业务上就是碰了巧了 A 用户码算出来和 B 用户码一模一样且都有效（两个客户端都没作弊）。

在线码之所以可以避免这个问题是因为在线码是服务端发的，可以控幂等。

离线码是客户端自己根据算法生成的，所以没法控。

其实原因和哈希算法的数据碰撞类似，是个小概率的纯技术问题，就不展开赘述了。

解决方案：优化算法（确保碰撞概率低到一定程度甚至杜绝），如果真的出现就认栽给客户赔钱（赔多了技术部门老大就肯定痛定思痛优化算法了）。

事实上这个问题发生的概率极低极低，所以可以忽略不计。

算法调整不如在线码灵活

因为离线码生成逻辑都在客户端，所以通常来说安全算法升级会导致客户端升级，比在线码升级更影响用户一些。

分析到上面这层，各位产品经理相信应该就知道如何做方案选型了。（装个逼，事实上我觉得了解到上面那个层面是支付行业产品经理的基本素质）

后话：

我在写这个答案的时候其实都在刻意回避公司实现这些业务的具体逻辑和算法。而我个人并非当面付产品的产品经理，所以大家放心，这篇文章不算泄密。

写这个答案的目的是希望能尽量站在产品和业务角度还原业务原理，希望更多的非行业内的知友知其然，也知其所以然。

以上就是关于当时pos机消费冲正成功,支付宝也支付成功了的知识，后面我们会继续为大家整理关于当时pos机消费冲正成功的知识，希望能够帮助到大家！