招商银行网上支付商户
手册
公司内部编号：（GOOD-TMMT-MMUT-UUPTY-UUYY-DTTI-
招商银行网上支付商户手册修订日期：2005年8月1日
目录
手册说明
1．本手册的读者范围
本手册适用于希望成为招商银行网上支付商户，或者已经成为招商银行网上支付商户的业务管理人员、电脑系统开发人员。
2．前提条件和相关信息
前提条件是对Internet、电脑有初步的了解，对一些常见的技术名词有一定的认识。
3．相对以前版本的更新
相对以前版本，本文更新了商户内部管理模式，增加了新的管理功能，增强了连接方式。
一．招商银行网上支付简介
1．什么是招商银行网上支付
招商银行网上支付是招商银行提供的网上付款结算平台，通过这个平台，数千万招商银行持卡人可以向特约商户进行网上付款，全国联网，实时到帐。
2．如何成为招商银行网上支付特约商户
（1）商户与当地招商银行的分行个人银行部联系，申请成为我行的网上特约商户，填写相关资料。联系方式及联系人，请查阅招商银行网
站（）。
（2）办理签定合约手续。
（3）商户在我行开立结算帐户。结算帐户设立浮动备付金，备付金比例按照商户资信情况确定。
（4）根据银行提供的技术接口，商户联通与我行的支付网络。
3．如何使用招商银行网上支付系统
（5）付款通道。付款通道是持卡人进行网上付款的界面，商户系统以Internet超链接的方式，从商户网站转到银行的付款通道，对商户
电脑系统没有特殊要求。
（6）商户管理。商户可以通过以下几种方式管理招商银行的定单：
[1]商户业务管理网站：Web界面，人工管理定单，为特约商户提供
全面
的网上支付业务管理功能。
[2]定单下载工具：方便特约商户下载自己的定单数据，进行进一步
处理。
[3]支付软件开发包：提供二次开发接口，在商户系统中嵌入支付管
理功
能，自动、实时管理定单。
4．加入招商银行网上支付，对商户电脑系统有什么要求
招商银行提高多种方式供商户使用，商户可根据自己的情况选择。
最简单的方式，商户以网页中的Internet超链接转到银行的付款通道，以商户业务管理网站管理定单。在这种情况下，商户甚至可以没有自己的电脑系统。
如果商户不具备程序开发能力，但有常见的办公处理软件使用经验，可以通过定单下载工具下载数据，结合商户业务管理网站，自己在办公处理软件中处理。
如果商户开发能力较强，可以通过银行提供的软件开发包开发软件，把自己的系统和银行对接，就可以全自动、实时地处理业务。
5．如何与招商银行联系
请到招商银行网站（）查阅。
6．招商银行网上支付的安全措施
基本的网上交易的传输安全控制手段采用SSL(SecureSocketLayer)，SSL是一种被广泛使用的INTERNET传输加密标准。银行端的WEBSERVER将安装一个证书(Certificate)，客户端的浏览器发送CGI请求时使用https 协议。所有用https发送的请求以及WebServer返回的结果都会自动使用
SSL加密。
对商户来说，商户在其管理电脑上登录时，要提供登录密码。为了增加商户登录的安全性,在登录页之前增加了一个预登录页,商户需先输入预登
录密码才能进入到登录页，预登录密码不能修改。
每个商户可以设置多个操作员，每个操作员拥有不同的密码，其权限以岗位的方式组织，每个岗位有不同的权限，以实现企业内部的安全管理。
对风险较高的操作，如退款，还要求配合企业证书IC卡操作。
二．系统管理
1．实体关系
商户的系统管理包括以下内容：
（1）店铺
店铺是生成定单的基础实体，每个商户至少有一个由银行自动生成的店铺，也可以由商户自行设置多个店铺，以便区分不同的交
易，以及不同的定单管理，等等。
注意，这里的店铺并非某些支付平台网站上的“店铺”概念，这里的“店铺”纯粹是为了商户分权限管理定单，例如为冲值类型支
付分配一个“店铺”，为购物类型支付分配另一个“店铺”，等
等，数目不会很大，否则商户内部管理这些权限将是非常烦琐的。
而支付平台网站上“店铺”，可能是某个公司，甚至某个人在支付
平台上注册的基本单位，其数目是相当庞大的。
（2）定单
每笔交易视为一个定单，由商户生成定单号，以后可对该定单进行后续处理，如结帐（包括结帐、部分结帐、撤消）、退款、查询
等。
（3）岗位
岗位实际上是权限的组合，可以精细到对不同店铺生成的定单进行不同的操作权限，例如A岗位能对0001店铺定单查询，B岗位能对0001、0002店铺定单结帐、退款，等等。每个岗位可以管理多个店铺，每个店铺也可以由多个岗位管理。
（4）操作员
操作员是商户管理定单的直接操作者，每个操作员有一个4位数字的操作员号，每个操作员必须赋予至少一个岗位，也可以赋予
多个岗位，以适应企业内部灵活的管理方式。操作员的权限由其岗
位决定。
（5）系统管理员
系统管理员可以对店铺、岗位、操作员等进行增加、修改、删除等操作。
以上实体的关系可用下图说明：
2．系统管理
系统管理指商户系统管理员对店铺、岗位、操作员等进行增加、修改、删除等操作。通过系统管理，商户可以灵活配置自己的业务模式，适应自己的业务需求。
（1）系统管理员登录
每个商户有一个系统管理员，商户开通招商银行网上支付后，银行自动生成一个系统管理员。系统管理员登录需要选择开户分行，
输入商户号和管理员密码。
（2）店铺管理
系统管理员可以增加、修改、删除店铺。一般来说，一个商户只需一个店铺即可，但如果需要对定单区别处理，可以增加新店铺。
例如跨地区的商户需要把北京、上海的定单分开处理；再如需要分
配不同的操作员管理不同类型的定单，等等。但是，店铺不宜太
多，一般不要超过5个，否则商户内部的管理、权限的分配调整等
等将比较烦琐。
（3）岗位管理
系统管理员可以增加、修改、删除岗位。岗位实际上是权限的组合，因此岗位不宜太多，否则商户内部的管理、权限的分配调整
等等将比较烦琐。
（4）操作员管理
系统管理员可以增加、修改、删除操作员。每个操作员必须赋予至少一个岗位，也可以赋予多个岗位。
三．支付交易
1．连接方式1
在网上交易过程中，用户先在商户网页中选择商品。当用户在支付网页中
选择招商银行网上支付付款时，商户支付网页向银行WEB 系统发出支付命令(见图一)。银行WEB 系统处理完支付请求后，将回送用户支付结果页面。
连接方式1 支付命令格式如下：
CBranchID=xxxx&
CoNo=xxxxxx&BillNo=xxxxxx&Amount=xxx.xx&Date=YYYYMMDD
参数说明：
BranchID: 商户开户分行号，请咨询开户的招商银行分支机构；
CoNo: 商户号，6位数字，由银行在商户开户时确定； BillNo: 定单号，6位或10位数字，由商户系统生成，一天内不能重复；
Amount: 定单总金额，格式为：xxxx.xx 元；
Date: 交易日期，格式：YYYYMMDD 。 支付页面提交的FORM 格式示例如下：
连接方式1的特点是商户WEB系统通过支付页面把控制引导到银行WEB系统，银行WEB系统处理完支付请求后回送支付结果页面给用户，控制没有再回到商户WEB系统。
商户在银行网站进行定单管理时可以知道定单的付款情况。如果商户系统需要立刻核实定单付款情况，可以使用一个银行提供的开发包中的定单状态查询接口向银行WEB系统查询某个定单的状态。有关直联定单状态查询接口请见附录。
2．连接方式2
某些商户在用户完成支付过程后希望控制能够从银行WEB 系统自动转回商
户WEB 系统，并且商户WEB 系统能够知道用户的付款情况。比如，出售信息产品的商户，在支付成功的情况下，商户的结果页除包含支付成功通知信息外，还可以包含用户购买的信息产品。
为了解决这个问题，要求商户WEB 系统必须提供一个支付结果通知命令。
银行WEB 系统在收到支付网页发出的支付命令后，先执行扣款操作，然后调用商户WEB 系统的支付结果通知命令，把支付结果通知商户WEB 系统，同时取得商户WEB 系统生成的支付结果页面(由支付结果通知命令生成)。最后，银行WEB 系统把由商户WEB 系统的支付结果通知命令生成的支付结果页返回用户的浏览器。这就是连接方式2(见下图)。
支付结果通知命令格式型如：
Succeed=..&BillNo=..&Amount=..&Date=..&Msg=..&signature=..
其中，path 和ProcResult.dll 由商户任意确定，并且支付命令中可包含多个path ，即可有path1/path2/path3。
参数说明：
Succeed ： 取值Y(成功)或N(失败)；
BillNo:
定单号(由支付命令送来)； Amount:
实际支付金额(由支付命令送来)；
商户 (1)生成支付网(3)支付结果通知命
Date: 交易日期(主机交易日期)；
Msg: 银行通知用户的支付结果消息。信息的前38个字符格式为：4位分行号＋6位商户号＋8位银行接受交易的日期＋20位银行流水
号；可以利用交易日期＋银行流水号对该定单进行结帐处理；
Signature: 银行用自己的PrivateKey对通知命令的签名。
注意:
(1)商户系统如果对银行通知命令的真实性有较高要求，必须用银行提供的开
发包中的函数，结合银行的PublicKey（可从网上下载或向银行索取）验
证。具体用法请参考附录。
(2)在Succeed为Y时，商户在支付结果通知命令中必须判断Amount的值，该值
为用户的实际支付金额，以此金额为准。不能以之前系统产生定单时的金
额为准！这是为了防止用户在得到支付页面后修改支付金额。
(3)银行返回的交易日期是银行主机的交易日期，对于每天重复使用定单号的
商户，可能会在0点左右与商户日期有1天的差别，按日期+定单号对帐时，可能和商户自己的定单记录有冲突。如果生成定单号永远不重复，则可以
按定单号和商户自己的定单记录对帐，无须核对日期，因此不会有冲突问
题，但是，永远不重复的6位定单号，部分商户可能不够用，建议这些商户使用10位的定单号。
(4)在正式交易中不要使用000000的定单号，因为测试接口在发通知时，定单
号固定为000000。
连接方式2的支付命令格式有别于连接方式1，其格式为：
C1BranchID=xxxx&
CoNo=..&BillNo=..&Amount=..&Date=..&MerchantUrl=..
前五个参数同连接方式1，第六个参数MerchantUrl为支付结果通知命令中参数部分之前的部分，也就是。注意：MerchantUrl不能带商户参数。
在方式2中，若用户付款后银行WEB系统或者商户WEB系统出现故障，则可能出现用户已付款但是商户WEB系统不知道的情况，或者出现用户已付款但是用户浏览器未接收到结果页的情况。这类情况属于正常情况，商户可以主动从银行系统查询该定单的真正状况。商户系统应当考虑相应的解决办法，而不能依赖于这个通知到达与否，决定是否给消费者提供商品或服务。
和方式1比较，方式2在用户完成支付操作后控制又回到商户的系统(用户处于商户WEB系统生成的支付结果页中)，增加了银行WEB系统调用商户WEB 系统的支付结果通知命令的过程。方式2比方式1复杂，并且商户WEB系统必须处理异常情况。但是方式2功能较强，使支付过程变得平滑无缝。
在商户的Web系统向银行返回结果网页时，网页中应当有
考虑到方式2比较复杂，并且需要连接商户端程序，我们提供了测试接口以方便商户开发程序时测试。使用该测试接口模拟真实的数据流程，但无须真实的商户代码和付款卡号，银行系统也不记录交易数据（商户不能查询或结帐使用该测试接口产生的交易数据）。测试接口的使用方法和真实接口一致，只需由真实接口的PrePayC1改为测试接口的TestPrepayC1。即
C1BranchID=xxxx&
CoNo=..&BillNo=..&Amount=..&Date=..&MerchantUrl=..
改为
TestPrePayC1BranchID=xxxx&CoNo=..&BillNo=..&Amount=..&Date=..&Mer chantUrl=..。
注意：为防止用户利用测试接口扰乱商户正式运行的服务器，银行的测试接口通知信息中，BillNo始终为“000000”。
建议：
在本方式中，虽然在消费者付款成功后向商户发通知，但由于Internet线路问题、商户网络配置改变问题、商户服务器问题、商户程序问题等原因，商户最终接收银行通知的程序可能收不到银行通知，因此，商户不能仅仅凭是否收到银行通知确定是否给消费者提供服务，在商户作系统设计时也应当考虑到这个因素。另外，接收通知的程序应当能处理重复通知的情况。
3．连接方式3
某些商户在使用连接方式2后，还需要在银行的支付结果通知命令中带上
商户自己的参数，比如商户希望知道是哪个分支机构的定单，定单在商户内部处理的不同于定单号的流水号，或者商户希望借助这个参数建立完整的
session ，等等。
为了解决这个问题，在连接方式2的基础上，招商银行提供带商户参数的
连接方式。这就是连接方式3。
图三、连接方式3
由图示可知，方式3的流程与方式2完全一样，只是在命令格式上增加了商户参数。
连接方式3的支付命令格式有别于连接方式2，其格式为：
C2BranchID=xxxx&
CoNo=..&BillNo=..&Amount=..&Date=..&MerchantUrl=..&MerchantPar
a=..
参数说明：
BranchID: 商户开户分行号，请咨询开户的招商银行分支机构；
CoNo: 商户号，6位数字，由银行在商户开户时确定；
(5)支付结果
BillNo: 定单号，6位或10位数字，由商户系统生成，一天内不能重复；
Amount: 定单总金额，格式为：xxxx.xx元；
Date: 交易日期，格式：YYYYMMDD。
MerchantUrl 支付结果通知命令中参数部分之前的部分，例如
cgi_bin/function.asp。
注意：MerchantUrl自身不能带商户参数。
MerchantPara 商户需要银行在支付结果通知中转发的商户参数。
支付结果通知命令格式型如：
Succeed=..&CoNo=..&=BillNo=..&
Amount=..&Date=...&MerchantPara=...&Msg=..&signature=..
参数说明：
Succeed：取值Y(成功)或N(失败)；
CoNo: 商户号，6位长数字，由银行在商户开户时确定；
BillNo: 定单号(由支付命令送来)；
Amount: 实际支付金额(由支付命令送来)；
Date: 交易日期(由支付命令送来)；
Msg: 银行通知用户的支付结果消息。信息的前38个字符格式为：4位分行号＋6位商户号＋8位银行接受交易的日期＋20位银行流水号；可以利用交易日期＋银行流水号＋定单号对该定单进行结帐处理；
MerchantPara：商户自己的参数；
Signature: 银行用自己的PrivateKey对通知命令的签名。
注意:
(1)商户系统如果对银行通知命令的真实性有较高要求，必须用银行提供的开
发包中的函数，结合银行的PublicKey（可从网上下载或向银行索取）验证。具体用法请参考附录。
(2)在Succeed为Y时，商户在支付结果通知命令中必须判断Amount的值，该值
为用户的实际支付金额，以此金额为准。不能以之前系统产生定单时的金额为准！这是为了防止用户在得到支付页面后修改支付金额。
(3)商户如果需要不止一个参数，可以自行把参数组合、拼装，但组合后的结
果不能带有’&’字符（如果带有’&’字符，银行收到这样的支付请求时将认为其后是另一个参数，其他可能被浏览器转义的特殊字符也应当避免），总长不能超过128个字节。例如，商户需要银行通知中转发
则可以在PrePayC2中写成
MerchantPara=
(4)银行返回的交易日期是银行主机的交易日期，对于每天重复使用定单号的
商户，可能会在0点左右与商户日期有1天的差别，按日期+定单号对帐时，可能和商户自己的定单记录有冲突。如果生成定单号永远不重复，则可以按定单号和商户自己的定单记录对帐，无须核对日期，因此不会有冲突问题，但是，永远不重复的6位定单号，部分商户可能不够用，建议这些商户使用10位的定单号。
(5)在正式交易中不要使用000000的定单号，因为测试接口在发通知时，定单
号固定为000000。
在方式2中，若用户付款后银行WEB系统或者商户WEB系统出现故障，则可能出现用户已付款但是商户WEB系统不知道的情况，或者出现用户已付款但是用户浏览器未接收到结果页的情况。这类情况属于正常情况，商户可以主动从银
行系统查询该定单的真正状况。商户系统应当考虑相应的解决办法，而不能依赖于这个通知到达与否，决定是否给消费者提供商品或服务。
和方式1比较，方式3在用户完成支付操作后控制又回到商户的系统(用户处于商户WEB系统生成的支付结果页中)，增加了银行WEB系统调用商户WEB 系统的支付结果通知命令的过程。方式3比方式1复杂，并且商户WEB系统必须处理异常情况。但是方式3功能较强，使支付过程变得平滑无缝。
考虑到方式3比较复杂，并且需要连接商户端程序，我们提供了测试接口以方便商户开发程序时测试。使用该测试接口模拟真实的数据流程，但无须真实的商户代码和支付卡号，银行系统也不记录交易数据（商户不能查询或结帐使用该测试接口产生的交易数据）。测试接口的使用方法和真实接口一致，只需由真实接口的PrePayC2改为测试接口的TestPrepayC2。即由
C2BranchID=xxxx&
CoNo=..&BillNo=..&Amount=..&Date=..&MerchantUrl=..&MerchantP ara=..
改为
TestPrePayC2BranchID=xxxx&
CoNo=..&BillNo=..&Amount=..&Date=..&MerchantUrl=..&MerchantPara=。
注意：为防止用户利用测试接口扰乱商户正式运行的服务器，银行的测试接口通知信息中，BillNo始终为“000000”。
建议：
虽然在消费者付款成功后向商户发通知，但由于Internet线路问题、商户网络配置改变问题、商户服务器问题、商户程序问题等原因，商户最终接收银
行通知的程序可能收不到银行通知，因此，商户不能仅仅凭是否收到银行通知确定是否给消费者提供服务，在商户作系统设计时也应当考虑到这个因素。商户系统必须能处理重复通知的情况。
四．人工定单管理
1．操作员登录
为方便商户业务的管理，商户有必要创建不同的的操作员并对其进行权限分配。操作员创建后，就可以以定单操作员的身份登录商户系统，在其权限范围内进行查询、结账、部分结账、撤销、退款等不同的操作，完成定单管理工作。
2．结帐
对冻结结账的商户，需要商户自己手动处理定单的结账操作。以定单操作员登录，先选择要结账的未结账定单，再进行提交。
3．部分结帐
以定单操作员登录，先选择要部分结账的未结账定单，输入部分结账金额，再进行提交。
4．撤销
以定单操作员登录，先选择要撤销的未结账定单，再进行提交。