摘要

  • CyberCash 0.8 版让顾客软件加密并签署卡资料，商户转交消息，服务器再与收单银行完成授权；1996 年 2 月的 RFC 说明这套信用卡系统当时已投入运作。
  • 商户收到的回执可以只有卡号前两位和后四位，也可以包含完整号码，由商户的银行决定；争议处理另有附密码的取号请求，并留下请求记录。

收银台只看见封好的信封

顾客在网页上点下付款，商户当然需要知道交易能否通过，却未必需要看见整串卡号。RFC 1898 把这笔交易拆成连续的动作：顾客软件签署并加密卡资料及账单摘要，商户补上自己的授权资料，CyberCash 服务器核验签名，再把信息送往收单银行。银行的答复沿原路回来。商户是消息的中转者，银行仍是信用卡授权的执行者。

这份文件最初于 1995 年 7 月 8 日以互联网草案公开，1996 年 2 月作为 Informational RFC 发布；它明确说 0.8 版处理的是信用卡支付，电子现金属于后续计划。这一区分挡住了一个容易写错的历史故事：网上出现了付款按钮，不等于信用卡从原有银行体系里独立出来。

协议的隐私段落说，商户通常不会得知卡号，却写明两扇门：商户的银行可以放行，交易争议也可能要求披露。真正的分界线落在 CM6 回执里。普通回执可给 card-prefix，即前两位和后四位；被银行允许接收完整卡号的商户则可拿到 card-number。协议还提供加盐的卡号哈希，让商户认出同一张卡的多笔交易，而不必拿到号码本身。识别交易、识别重复顾客、掌握完整凭证，被刻意拆成不同权限。

争议发生后，商户还能再敲一次门

拒付或争议需要核对原交易时，商户可保存顾客最初的加密消息，再向服务器发出 CD1 取号请求。协议要求另输密码，CD2 回应可返回卡资料。文件称商户会留下取号记录，过多的 CD1 请求可以被标记。它没有附上运行日志，说明这条异常通道在现实中被用过多少次、拦住过多少滥用。这样的日志会改变对控制效果的判断。

CyberCash 的设计把“少看一点”变成了具体的操作安排。收银台平时拿到足以完成买卖的答复；银行能决定回执是否放出完整号码；事后查争议则必须走另一条留痕通道。卡号穿过商户系统时可以封存，但打开封套的权力并未消失，只是转移到了银行和支付服务器。

来源