整理一下，我关于闪付不安全的评论

ahamard · 发表于 2012-5-9 22:14

feng 发表于 2012-5-9 19:30
"pos机信号不好，卡片损坏或者老化都可能造成连接不稳定"
这个可能性不大。
因为之前的几次“握手”就是解 ...

不知道你试过公交卡刷卡没有

有些公交卡终端信号不好，经常刷不上

多蹭几次就刷上了

ahamard · 发表于 2012-5-9 22:17

feng 发表于 2012-5-9 19:37
是卡先扣款，POS再确认。还是POS先确认成功，卡再扣款。本人不知道。
但这2种方式其实都可以做到的。
POS ...

你还是没看清楚我说的流程啊

是卡先扣款，再发消息给pos
但是pos机没收到扣款成功的消息，认为交易没有成功，所以不会去找银联请款，也不会给银联汇报“争议款”
或者说，对银联来说，根本感觉不到这笔交易存在。

feng · 发表于 2012-5-9 22:19

awing 发表于 2012-5-9 21:48
真能猜想！数据处理有个最基本的概念，事务处理。其特点是，要么全部成功，要么全部失败，回滚到初始状态， ...

按照你的说法，就不应该出现POS显示交易失败，而卡扣款成功的事情。
只能用“有人在说慌”解释了。

ahamard · 发表于 2012-5-9 22:19

feng 发表于 2012-5-9 20:12
至于安全不安全，要看这种事情发生的概率。
概率小到一定程度就是安全的了。
世上没有绝对的安全。

技术就是保证安全的

只要一定概率上保证安全就可以了

emv首先保证的是用户的安全，风险大部分在卡组织这里

pboc优先保证的是银联和银行的安全，将风险转嫁给了消费者

问题在于，卡组织和银行收了费，而且卡组织的规模大，是可以承担一定风险的
但是对用户来说，承担风险的代价很大

feng · 发表于 2012-5-9 22:20

ahamard 发表于 2012-5-9 22:12
注销要45天

挂失要交保护费（实际就是保险）

注销45天后的卡，离线支付一定会失败吗？

awing · 发表于 2012-5-9 22:22

ahamard 发表于 2012-5-9 22:14
问题是，对pboc的离线支付而言，扣钱不是服务器数据库操作，而是扣圈存里的钱

就算是pos机要回滚，出问 ...

pos想回滚，没有得到卡的回应确认，事务就是失败的。整个事务中的操作取消，回滚到初始状态。

ahamard · 发表于 2012-5-9 22:22

feng 发表于 2012-5-9 22:20
注销45天后的卡，离线支付一定会失败吗？

比如说，你挂失身份证，会怎样呢？理论流程你需要登报声明，你这张身份证失效。

实际上注销卡也是如此，卡组织会广播一个黑名单，告诉各pos，这张卡是失效卡

feng · 发表于 2012-5-9 22:23

ahamard 发表于 2012-5-9 22:14
不知道你试过公交卡刷卡没有

有些公交卡终端信号不好，经常刷不上

不管刷多少次，刷不上就不扣钱，这是正常的。说明交易开始就对话不成功。
不正常的是：没成功，但扣钱了。这才是交易过程中出的问题。

ahamard · 发表于 2012-5-9 22:24

awing 发表于 2012-5-9 22:22
pos想回滚，没有得到卡的回应确认，事务就是失败的。整个事务中的操作取消，回滚到初始状态。

你仔细看我前面写的内容
交易失败后，pos机不会向银联请款

但是卡里圈存的钱已经扣了，对用户来说是丢钱了

你应该理解圈存的概念

feng · 发表于 2012-5-9 22:28

ahamard 发表于 2012-5-9 22:17
你还是没看清楚我说的流程啊

是卡先扣款，再发消息给pos

我看清了。
我是说设计者也可以把顺序倒过来呀：POS先认为交易成功，然后再给卡发送扣款指令。
如果卡没收到扣款指令，就把这笔款项作为争议款保存。
等下次联机时再对帐纠错就可以了。

ahamard · 发表于 2012-5-9 22:29

feng 发表于 2012-5-9 22:23
不管刷多少次，刷不上就不扣钱，这是正常的。说明交易开始就对话不成功。
不正常的是：没成功，但扣钱了 ...

公交卡相对简单，基本上可以认为是联机支付的，数据在服务器端，只是传输不是完全实时。

但是圈存不一样。对圈存来说，你有多少钱，是存在卡上，而不是服务器上

好比你卡里有1000，交易完后，卡里没钱了，下次你在闪付就不成功，因为卡认为上次交易已经成功，钱已经扣了。但是对pos来说，交易失败，所以pos认为交易没成功。

你要明白一点，交易过程中有两个设备，而这两个设备是不同步的，这和联机支付不一样。

awing · 发表于 2012-5-9 22:31

feng 发表于 2012-5-9 22:19
按照你的说法，就不应该出现POS显示交易失败，而卡扣款成功的事情。
只能用“有人在说慌”解释了。

POS和卡的状态是可能出现不一致的情况，但银联结算系统应该是完整的。整个支付算法我不是很了解，但我想数据库最基本的事务管理都能解决的问题不应该出现在银联的结算系统中。
每天吃饭都在用闪付，还没有遇到楼主说的情况。

ahamard · 发表于 2012-5-9 22:33

feng 发表于 2012-5-9 22:28
我看清了。
我是说设计者也可以把顺序倒过来呀：POS先认为交易成功，然后再给卡发送扣款指令。
如果卡 ...

这种情况下，风险就转嫁给卡组织了。

比如说，如果pos机确认成功后，卡没收到这个确认信息，然后不扣钱，那怎么办？然后pos机去找银联请款，银联找银行，银行发现这张卡是活卡，而且已经圈存过，就付钱了。之后这个帐怎么办？钱还在用户的卡里，用户还能继续去消费（因为闪付是离线的，另一个pos机不知道用户这个钱应该已经消费了）。

ahamard · 发表于 2012-5-9 22:35

awing 发表于 2012-5-9 22:31
POS和卡的状态是可能出现不一致的情况，但银联结算系统应该是完整的。整个支付算法我不是很了解，但我想数 ...

我之所以做出这些结论，就是tyfu卡友事实上碰到扣钱了但是交易失败的情况。

另外，这个问题跟支付算法没关系，是设计层面的问题。协议没做好，中间的算法做得再好，加密做得再好也没用。

Qiqi · 发表于 2012-5-9 22:41

思路正确。EMV是感应验证凭证，然后记账，联机时完成支付。而PBOC2.0的闪付，则是直接读写芯片完成支付扣款，从协议涉及角度讲，似乎保护的不是持卡人。任何过程，只要有时间差，只要可能出现意外，包括机器不稳定或将卡移出场外或其他卡进入场内都可能对读写过程造成影响，所以，理论上说，一手交钱一手交货是无法实现的，因为“收到钱”或“收到货”都一样需要一个指令传输来确认，这将导致时间延长，出现意外的概率更大。

feng · 发表于 2012-5-9 22:49

ahamard 发表于 2012-5-9 22:22
比如说，你挂失身份证，会怎样呢？理论流程你需要登报声明，你这张身份证失效。

实际上注销卡也是如此 ...

我想知道：
这份黒名单是下载到POS机上保存呢。还是需要联机查询。
如果是后者，还是可以拍卡成功。

awing · 发表于 2012-5-9 22:53

ahamard 发表于 2012-5-9 22:35
我之所以做出这些结论，就是tyfu卡友事实上碰到扣钱了但是交易失败的情况。

另外，这个问题跟支付算法 ...

算法就是设计出来的呀，协议等都是为整个支付算法服务的。这个算法并不复杂，公交卡都在用说明很成熟了，为什么银联就做不好？

ahamard · 发表于 2012-5-9 22:53

feng 发表于 2012-5-9 22:49
我想知道：
这份黒名单是下载到POS机上保存呢。还是需要联机查询。
如果是后者，还是可以拍卡成功。

这个我倒没研究过

如果我来设计，应该是卡组织向某一级节点广播，由节点来储存数据。

比如在hk的大型超市，自己有个服务器，这样一个终端可以刷多个组织的卡。然后这个服务器读取数据后转发给相应的卡组织。这个服务器和pos机是一直连接的，所以可以把黑名单存在这里。

ahamard · 发表于 2012-5-9 22:54

Qiqi 发表于 2012-5-9 22:41
思路正确。EMV是感应验证凭证，然后记账，联机时完成支付。而PBOC2.0的闪付，则是直接读写芯片完成支付扣款 ...

对啊，emv其实是压卡消费思路的延续，
只是把压卡这种安全程度不高的认证方式改进成了芯片加密这种技术更为先进的方式。

pboc，我不知道怎么说才好

feng · 发表于 2012-5-9 22:55

ahamard 发表于 2012-5-9 22:33
这种情况下，风险就转嫁给卡组织了。

比如说，如果pos机确认成功后，卡没收到这个确认信息，然后不扣钱 ...

这不是跟EMV的拍卡风险是一样的吗？
所以，不管EMV，还是PBOC，都会设置离线支付限额。

		自动登录	找回密码
密码			加入玩卡网