发信人: rhine (有雨无风), 信区: E_Commerce
标  题: 关于支付的一个案例
发信站: 哈工大紫丁香 (Sun Aug 27 16:37:17 2000), 转信

发信人: erain (红花会主), 信区: E_commerce       
发信站: BBS 水木清华站 (Mon Dec 20 17:56:58 1999)

作一门课程调查时,曾经帮助过一个公司作过一个网上支付的调查,现悉数如下:

(基本上是与8848一样的)

本支付方式在招商银行的一网通卡和在线结算方式下进行,这里更多的是技术上的实现,
先是号召用户使用招商的一网通卡,在全国的大中城市中开通了许多,而且正在快速增加
这种服务,即使没有一网通,只要用户在招商有帐号也行.

商家的帐号在招商,当用户要通过网络进行预订时,登录到招商的站点,然后添入自己的
招商帐号和商家的帐号,以及支付数额,确认,然后银行的网站服务器端开始进行处理.

银行服务器首先进行用户和商家的帐号和账上金额进行确认,通过后,就冻结用户的应付
金额数,这个时候还没有划账,同时将这条信息通过HTTP的协议发送(GET/POST)到商家的
在线服务器上,一般来说商家服务器的配置要与银行进行协调,比较常见的就是协调信息
发送的字段名和字段顺序,商家服务器上可以采用ASP或者CGI来进行处理,将来自银行的
通知信息进行检查确认,然后入库,这样这个asp就象一个对待来自银行服务器的触发器
一样进行工作.这样的方式就可以实现网上的实时订购.

也就是说,当用户在银行的网站上进行支付时,同时将支付的信息和订购的信息发送到了
商家的服务器上,这条信息是银行的动态主页完成的,所以商家也需要建立接受订购信息
的服务器,用CGI或者ASP等方式就可以解析出所有发送过来的信息项,然后在写入商家的
数据库中.

商家也可以借助一些数据库的低端功能接口,开发自己的数据库响应服务器,比如说,后台
数据库仍然采用了SQL SERVER 7.0,但是为了实现我自己的一些低端功能,可以不直接使用
SQL的服务器,而仅仅把SQL当作一个数据容器,然后自己开发一套数据库响应的服务器,让这
个自定制的服务器来完成接受来自银行的银行订购信息和用户,产品检验,并且把信息写入
数据库中的任务.

当然使用数据库本身功能,如触发器,中间件,存储过程等等啊什么的也可以实现这样的
功能,不过可能有些特殊的功能满足不了,另外还可以使得数据库能够实现一些自动向
用户发送mail,语音电话,催发帐单等等的功能,

另外,银行一般还可以提供一个商家专用的终端,利用ISDN或者是电话,商家可以直接接入
银行系统专门为商家开设的接口来(半)实时地获得用户订购数据,不过这种方式目前有
很大的缺陷,就是这种方式是从银行的库中进行数据获取,它并不是直接来自用户在
网上的订购动作,所以:
  1. 不是实时的
  2. 不是实时的到没有太大的关系,但是关键是所获得的下载信息是无法进行用户区分的
     ,因为国内所有的银行之间协调非常的不好,所以银行之间日常业务数据保存的信息项
     粒度非常的大,一般都不保存一笔交易的用户帐号,换句话说,在银行保存下的信息中
     只能够查到一笔业务的汇入点,而不能查到它的汇出点,这个问题很奇怪,这么重要的
     信息银行竟然没有保存.   不过确实是这样的,不仅仅招商如此,其他银行也是如此
     的.所以你即使收到了银行的订单信息,也判断不出是哪个用户的订单
  3. 银行之间的互通性太差,国内银行之间的互通性非常的不合理,所有银行之间的交易都
     必须通过当地的人民银行,然后报人民银行总行,由人民银行总行来解决银行之间的交易
     划账.

写得太乱了,不好意思





--
       巧者劳而智者忧,无能者无所求,饱食而遨游，泛若不系之舟。

    请稍候,正在返璞归真中......
   __________________________________________________________________
  |||||||||||                   20%                                  |
   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

--
☆ 来源:．哈工大紫丁香 bbs.hit.edu.cn．[FROM: rhine.bbs@smth.org]