专利名称：利用包含ic卡的身份证进行交易的支付系统及方法
技术领域：
本发明涉及数据处理领域，尤其涉及利用包含IC卡的身份证进行交易的支付系统及方法。
背景技术：
由于现金交易存在携带不方便、安全性低等缺陷，所以银行卡被广泛地 应用在各种交易场合，因此越来越多的人习惯采用银行卡进行消费。请参阅 图l，其为现有的一种利用银行卡进行交易的系统的原理框图。它包括用于读取银行卡信息的终端13、商户子系统12和收单子系统11。商户子系统ll包 括服务器和若干客户端，客户端连接终端，商户子系统12的服务器通过专线 连接收单行的收单子系统ll。当收单行不是发卡行时，还需要通过银联的跨 行交易子系统连接发卡行的发卡子系统。当用户利用银行卡进行消费时，终端(如收银机等)先通过能否读取银 行卡来识别银行卡的真伪，然后客户端再将用户输入的表征用户身份的身份 信息、银行卡卡号信息以及本次交易的交易信息传送至商户子系统12的服务 器；随后商户子系统12的服务器将该些信息传送至收单子系统11;若收单行 是发卡行，则收单子系统直接处理此交易，否则通过跨行交易子系统发送至 发卡行处理。发卡子系统利用银行卡卡号信息和身份信息验证此用户的身 份，若身份验证通过，则对该卡号对应的账户进行扣款处理，并将扣款处理 结果返回，否则返回身份验证不通过信息。当商户子系统12接收到扣款处理 成功的消息后，商户可以让消费者在签购单上签名确认。上述公开的是现有技术中最常见的一种交易过程，在这种过程下，存在 以下缺陷在整个交易过程，利用"账户名+密码，，以及银行卡来完成整个交易过程 的身份认证。现有技术通常通过终端(如POS机、ATM机)能否读取银行卡
来识别银行卡的真伪存在很大的风险。现有的银行卡采用磁条卡技术制成 的，仿造难度低，很容易被仿造。为此，目前提出了银行卡由智能卡替代磁条卡的方案。比如，采用EMV技术制成的智能卡。EMV是由欧陆Europay、 万事达Master、维萨Visa等三大国际银行卡组织共同发起制定的一项智能IC 银行卡技术标准，该标准要求银行卡CPU芯片要具有独立运算、加解密和存 储能力，从而达到更高的安全性。但是，银行卡从磁条卡向智能卡转换过程 中，成本非常高 一张智能卡几十块的成本，并且POS机、ATM机要读取该 智能卡就要对其进行改造需要大量成本。即使花费大量的人力和物力完成银 行卡从》兹条卡向智能卡的转换，但是，由于巨大的利益存在，不法分子还是 能够伪造出相应的智能卡。也就是说，通过ATM机、POS机等终端能否读取 银行卡只能简单判断银行卡是否是伪卡，根本无法证实所述银行卡是否是用 户本人使用由金融机构颁发的银行卡。若不法分子获得用户信息(如密码) 后，由于没有其它可行性强的验证用户身份的手段，还是容易造成用户或商 户财务上的损失。从另一个角度来说，银行卡从磁条卡向智能卡转换不是一 朝一夕的，在这过程中，更需要有其它可行性强的验证用户身份的手段来进 一步保证交易的安全性。 发明内容本发明的 一 目的在于提供一种能够提升交易安全性且投入成本低的支付 系统。对应地，本发明的另一目的在于提供一种能够提升交易安全性且投入成 本低的支付方法。为了达到上述目的，本发明提供了 一种利用包含IC卡的身份证进行交 易的支付系统，包括身份证读卡器、请求子系统和支付验证子系统，其中身份证读卡器，用于读取至少包含用户身份证号的用户身份信息；支付验证子系统包括数据库单元，用于保存用户身份信息和对应账号 信息的绑定关系；
请求子系统至少包括一服务器和若干客户端，所述客户端连接身份证 读卡器，用于向服务器发起支付请求，所述支付请求中包含本次订单信息及 包含身份证号的用户身份信息；所述服务器中至少包括处理单元，所述处理 单元定期或事件触发式从所述支付验证子系统下载数据库单元的数据信息， 以及从接收到的支付请求中获得身份证号，并根据身份证号找到对应的账 号，进行扣款操作后，将处理结果返回至对应的客户端。所述支付验证子系统还包括第一授信单元用于保存合法用户/商户对应 的授信额度信息，所述请求子系统还包括第二授信单元，用于根据第一授信 单元更新本端的合法用户/商户对应的授信额度，以便处理单元在接收到支付 请求后，校验发出请求的用户对应的授信额度是否满足本次订单金额要求。所述支付验证子系统还包括第一风险控制单元，用于保存支付风险控制 信息，所述请求子系统包括第二风险控制单元，用于从第一风险控制单元中 下载支付风险控制信息，以便处理单元在接收到支付请求后，验证所述订单 是否符合保存的风险控制信息。所述客户端还包括第二用户标识输入单元，用于接收第二用户标识，并 将所述第二用户标识包含在本次支付请求的身份信息；服务器还包括第二用 户标识验证单元，用于将接收到本次支付请求中第二用户标识和身份证号与 预先保存或最近更新的第二用户标识和身份证号进行对比，验证所述用户身 份。所述支付验证子系统还包括通知用户单元，所述通知用户单元向用户终端 发送交易处理结果。一种利用包含IC卡的身份证进行交易的方法，包括 (1 )身份证读卡器读取用户身份证上包含用户身份证号的身份信息，并将 之发送至请求子系统；(2)请求子系统的客户端将包含所述身份信息和本次订单信息的支付请求 发送至服务器；(3)服务器根据所述身份信息从预先保存的数据信息找到对应的账号，对 所述帐户进行扣款处理，并将处理结果返回至对应的客户端，所述数据信息 为服务器定周期或事件触发式从支付验证子系统下载的。步骤(3)之前包括服务器定周期从支付验证子系统中下载合法用户对应 的授信额度信息；步骤(3)还包括服务器接在收到支付请求后，先校验发出 请求的用户对应的授信额度是否满足本次订单金额要求，若用户授信额度满 足本次订单金额要求，才进行相应扣款处理。步骤(3)之前包括服务器定周期从支付验证子系统中下载风险控制信 息；步骤(3)还包括服务器在收到支付请求后，验证所述订单是否符合保存 的风险控制信息，当订单符合规则的风险控制，才进行相应的扣款处理。还包括所述服务器定期或事件触发式发送本服务器处理的支付处理信 息至支付验证子系统，以及，所述支付验证子系统通知用户消费信息。与现有技术相比，本发明利用包含IC卡的身份证(如第二代身份证)进 行消费交易，避免使用银行卡，不仅减少了制卡的成本，而且利用现有第二 代身份证加密效果佳、普及等特点进行消费交易，降低成本投入且安全系数 高。并且，本发明是一种离线授权模式，适用于小额快速交易。
图1为现有的 一种利用银行卡进行交易的系统的原理框图；图2为本发明公开的 一种利用包含IC卡的身份证进行交易的支付系统的结 构示意图；图3为本发明公开的 一种利用包含IC卡的身份证进行交易的支付方法的流 程图；图4是本发明支付方法的 一 实例流程图。
具体实施方式
以下结合附图，具体说明本发明。
本发明的核心在于本发明利用包含IC卡的身份证(如第二代身份证) 进行消费交易，避免使用银行卡，不仅减少了制卡的成本，而且利用现有第 二代身份证加密效果佳、普及等特点进行消费交易，降低成本投入且安全系 数高。相比与第一代身份证，第二代身份证的安全防伪性能提高。第二代身份 证是由9层构成的，最外面的这两层记载的是个人的身份信息，打印上去 的。还有一层叫做配平层，防止静电，在这层上可以看到长城烽火台图案和 "中国CHINA"的防伪膜，有橘黄色的、绿色的防伪标志，是一个比较先进的 技术。这层有一个IC芯片，长8毫米，宽5毫米，厚度0.4毫米，有两根天线， 一圈都是线圏，主要是为了避免泄漏个人信息，但是可以通过专门读卡器能 够阅读出个人信息。所以，新一代的身份证从安全性能方面来讲，主要是两 个方面的防伪措施， 一个是数字防伪措施，就是把个人的信息写入芯片，采 用数字加密的办法。 一个地区一个密码、每个公民拥有一个密码。防伪技术 是我们国家自己研制的，安全性非常高。另一个是印刷防伪技术，印刷层图 案两面都有。印刷的防伪技术采取了很多措施，由于采用了数字防伪措施、 印刷防伪措施，所以安全性得到了大大提高。请参阅图2，其为本发明提供的一种利用包含IC卡的身份证进行交易的 支付系统的结构示意图。它包括身份证读卡器31、请求子系统32和支付验证子系统33，其中 身份证读卡器31,用于读取包含用户身份证号的用户身份信息； 支付验证子系统33:包括数据库单元331，用于保存用户身份信息和对应账号信息的绑定关系；请求子系统32:至少包括一服务器322和若干客户端321，所述客户端 321连接身份证读卡器31,用于向服务器322发起支付请求，所述支付请求 中包含本次订单信息及包含身份证号的用户身份信息；所述服务器322中至 少包括处理单元3221,所述处理单元3221定期或事件触发式从所述支付验 证子系统33下载数据库单元331的数据信息，以及从接收到的支付请求中获
得身份证号，并根据身份证号找到对应的账号，进行扣款操作后，将处理结杲返回至对应的客户端321。通常客户端321和身份证读卡器31通过有线或无线方式连接。由于请求 子系统32通常设置在商户侧， 一商户可以设置一请求子系统32，或者一商 户设置若干请求子系统32，或者是若干商户设置一请求子系统32。当身份证读卡器31读取身份证时，无任何机读信息显示或机读图片信息 无法显示，则表明该身份证为假卡，可拒绝此次交易。另外，商户的工作人 员在用身份证读卡器31读取身份信息时，可以将身份证读卡器31内显示的 人像与消费者的真人进行对比，若机读信息与视读信息不相符合的，即此身 份证明显不同于消费者本人的，也可以拒绝此次交易。客户端321向服务器322发起支付请求时，除了用户身份信息和订单信 息外，还可以包含客户端321的ID号，以便服务器222返回支付请求处理结 果时能立即返回至对应的客户端321。服务器322向支付验证子系统33上传 消费数据请求清算数据中同样包含商户的商户号。另外，为了提高数据传输 的安全性，服务器322可以通过专线与支付验证子系统33连接。当然，利用 现有的加密技术，服务器322与支付验证子系统33之间的交互可以通过因特 网来实现。所述支付验证子系统33还包括第一授信单元用于保存合法用户对应 的授信额度信息，所述请求子系统32还包括第二授信单元，用于根据第一 授信单元更新本端的合法用户对应的授信额度，以便处理单元3221在接收 到支付请求后，校验发出请求的用户对应的授信额度是否满足本次订单金额 要求。授信额度信息包括每一合法用户每次交易的授信额度。比如， 一用户 的授信额度为500元，当该用户的支付请求中的订单超过500元时，拒绝此 用户的交易请求。对于账户也可以分为两种 一种账户可以象信用卡一样进 行透支， 一种账户可以像借记卡不能透支。若用户申请的账户类型为信用户 卡型的账户，则在该用户的授信额度可以是指该用户的透支额度。另外，也 可以针对不同业务品种、不同的商户设置不同的授信额度，这样，在每次处 理订单时，需要判断订单是否满足授信单元规定的授信规则。还有，用户的
授信额度可以是动态变化的，如用户消费金额达到某一级别后，用户的授信 额度会增加。用户对应的账户金额达到某一阈值后，用户的授信额度会增 加。第一授信单元中的授信内容可以根据用户的增加等发生变化，第二授信 单元可以定周期从第 一授信单元中下载授信内容，也可以事件触发式从第一 授信单元中下载授信内容。所述事件触发比如说当>^测订单的用户不是合法用户的次凄t为N次。所述支付验证子系统33还包括第一风险控制单元，用于保存支付风险控 制信息，所述请求子系统32包括第二风险控制单元，用于从第一风险控制 单元中下载支付风险控制信息，以便处理单元在接收到支付请求后，验证所 述订单是否符合保存的风险控制信息。风险控制信息是用于控制其风险的风 险规则，比如一天中交易的次数限制、 一天中同一用户的交易金额限制等。 通常，风险控制信息包括对用户的风险控制和对商户的风险控制。对商户的 风险控制包括可以针对不同的商户规定不同透支额度、设定一天内同一用户 在同一商户提交消费的金额的上限等，对用户的风险控制包括同一用户在一 天内消费的次数、同一用户在一天内消费的金额等所述客户端321还包括第二用户标识输入单元，用于接收第二用户标 识，并将所述第二用户标识包含在本次支付请求的身份信息；服务器322 还包括第二用户标识验证单元，用于将接收到本次支付请求中第二用户标识 和身份证号与预先保存或最近更新的第二用户标识和身份证号进行对比，验 证所述用户身份。对应地，本发明提供了公开了 一种利用包含IC卡的身份证进行交易的方 法。请参阅图3，它包括以下步骤S21 (h身份证读卡器读取用户身份证上包含用户身份证号的身份信息， 并将之发送至请求子系统；S220:请求子系统的客户端将包含所述身份信息和本次订单信息的支付 请求发送至服务器；
S230:服务器根据所述身份信息从预先保存的数据信息找到对应的账 号，对所述帐户进行扣款处理，并将处理结果返回至对应的客户端，所述数 据信息为服务器定周期或事件触发式从支付验证子系统下载的。步骤S230之前包括服务器定周期从支付验证子系统中下栽合法用户对 应的授信额度信息，服务器接在收到支付请求后，先校验发出请求的用户对 应的授信额度是否满足本次订单金额要求，若用户授信额度满足本次订单金 额要求，才进行下一步处理。步骤S230之前还包括服务器定周期从支付验证子系统中下载风险控制 信息，在步骤S230中，服务器验证所述订单是否符合保存的风险控制信 息，当订单符合规则的风险控制，才进行相应的扣款处理。所述服务器定期或事件触发式发送本服务器处理的支付处理信息至支付 验证子系统。比如，服务器每天上传本服务器的消费数据，以便商户和验证 子系统进行清算，服务器也可以在达到某一消费域值后，上传本服务器的消 费数据，在上传的消费数据中至少包括本服务器所在的商号信息。在进行扣款时，若是借记卡型的账户，先判断账户中的金额是否大于等 于此次交易金额，若否，则返回交易金额不足的处理结果，否则进行扣款操 作，并返回交易成功的处理结果，若是信用卡型的账户，若账户中的金额小 于此次交易金额，可以按照预先设定的透支额度对其进行透支，同时也返回 交易成功的处理结果。当客户端接收到交易成功的处理结果后，进行交易，否则拒绝与本用户的交易。客户端将处理结果为扣款成功的交易进行打印，以便用户在其上进 4亍签名确iL并且，支付验证子系统还可以向用户终端返回本次支付的消费信息。或 者，定期返回本用户消费的消费信息。比如，支付验证子系统33设置有与 无线通信系统进行通信的接口单元，支付验证子系统33将用户的每次交易 处理结果通过短信方式发送至用户的手机上。支付验证子系统33也可将用 户的交易处理结果定周期通过短信方式发送至用户的手机上。再比如，支付 验证子系统33连接因特网。支付验证子系统33将用户的每次交易处理结果
通过因特网发送至用户的邮箱中。或者，支付验证子系统33将用户的交易 处理结果定周期发送至用户的邮箱中。实现方式很多，上述公开仅为本发明 的几个实例，可以根据用户的要求进行相应的操作。为了提高安全性，步骤S220之前还包括请求子系统接收表征用户身份信 息的第二用户标识；在步骤S230还包括在进行交易时，将接收到支付请求 中的第二用户标识和身份证号与预先存储的身份证号及对应的第二用户标识 进行对比，对比通过后才进行扣款处理。比如，用户申请开通此业务时，在 支付验证子系统保存该用户的身份证号对应的密码。在数据更新时，将用户 的身份证号对应的密码一同更新到本地的服务器上。当进行支付请求时，输 入用户的密码，服务器将用户的密码与身份证号与预先保存的用户密码与身 份证号进行比对，比对通过后，才进行后续处理。本发明只需要增设身份证读卡器31，进行很少的硬件和软件更新即可完 成本发明的交易处理，投入少，可操作性强。本发明主要是离线授权模式交 易，适用于小额快速成交易。这种交易模式，处理非常速度快。通常，请求子系统是设置在商户端，支付验证子系统是设置在支付服务 提供商端。支付服务提供商的支付验证子系统下设置多个商户的请求子系 统，每一商户在支付服务提供商处设置一用于标识商户的支付号标识。当商 户与支付服务提供商交互时，都需携带支付号标识，支付服务提供商通过该 标识识别不同的商户。比如，可以通过该标识设置不同的商户对应不同的授 信额度，可以给不同的商户设置不同风险控制规则，当不同商户向支付服务 提供商下载授信信息和风险控制信息时，根据该商户的标识下载本商户对应 的授信信息和风险控制信息。商户的请求子系统定期上传消费数据请求清算 给支付服务提供商时，同样包含商户的支付号标识。这样，在商户和支付服 务提供商之间通过商户的支付号标识进行双方的清算。以下就以支付服务提供商的支付验证子系统和一商户的请求子系统为例， 来形象说明本发明的支付过程。请参阅图4，支付过程包括以下步骤在支付之前，商户需要向支付服务提供商下载除了用户的身份信息和账户 信息之外，还需要下载本商户的授信信息、用户的授信信息以及本商户的风
险控制规则及用户的风险控制规则。由于支付服务提供商内的数据是变化的，所以可以定期下载用户的身份信息和账户信息、风险控制信息和授信信 自支付时需要进行以下步骤(1) 消费者出示身份证(如第二代身份证)进行消费，商户的服务人员通 过身份证读卡器读身份证数据，根据能否读出数据来判断身份证的真伪，通 过读出的数据与消费者真人进行对比，服务人员判断是否是身份证持卡人进 行消费；(2) 身份证读卡器将读取的数据发送至商户的请求子系统；(3) 对订单进行授信判断，判断订单是否满足授信要求，若是，则进行步 骤(4)，否则返回不满足授信要求的处理结果；(4) 校验订单是否符合风险控制规则，若订单位于风险控制之内，则通过 身份证号找到对应的账户，若是，借记卡型账户，判断账户中的余额是否足 够，若不够，则返回余额不足的处理结果，若足够，则进行扣款处理，返回 的扣款成功的处理结果。若是信用卡型账户，当账户中的余额不够时，判断 订单金额是否在透支额度内，若是，则返回扣款成功的处理结果，否则返回 透支额度不够的处理结果；(5) 商户接收到扣款成功的处理结果后，允许消费者消费，并要求消费者 在签购单上签名确认；(6) 支付服务提供商通知消费者相应的消费信息。商户也可以自行决定是否要进行步骤(5),同时，支付服务提供商也可以 自行决定是否通知消费者以及以何种方式何时告知消费者消费信息。另外， 商户也需要定期上传消费数据请求清算，以便和支付服务提供商之间定期进 行清算步骤(步骤(7))。以上公开的仅为本发明的几个具体实施例，但本发明并非局限于此，任 何本领域的技术人员能思之的变化，都应落在本发明的保护范围内。
权利要求
1、一种利用包含IC卡的身份证进行交易的支付系统，其特征在于包括身份证读卡器、请求子系统和支付验证子系统，其中身份证读卡器，用于读取至少包含用户身份证号的用户身份信息；支付验证子系统包括数据库单元，用于保存用户身份信息和对应账号信息的绑定关系；请求子系统至少包括一服务器和若干客户端，所述客户端连接身份证读卡器，用于向服务器发起支付请求，所述支付请求中包含本次订单信息及包含身份证号的用户身份信息；所述服务器中至少包括处理单元，所述处理单元定期或事件触发式从所述支付验证子系统下载数据库单元的数据信息，以及从接收到的支付请求中获得身份证号，并根据身份证号找到对应的账号，进行扣款操作后，将处理结果返回至对应的客户端。
2、 如权利要求l所述的系统，其特征在于，所述支付验证子系统还包 括第一授信单元用于保存合法用户/商户对应的授信额度信息，所述请求子 系统还包括第二授信单元，用于根据第一授信单元更新本端的合法用户/商户 对应的授信额度，以便处理单元在接收到支付请求后，校验发出请求的用户 对应的授信额度是否满足本次订单金额要求。
3、 如权利要求l或2所述的系统，其特征在于，所述支付验证子系统还包括第一风险控制单元，用于保存支付风险控制信息，所述请求子系统包括第二风险控制单元，用于从第一风险控制单元中下载支付风险控制信息，以便处理单元在接收到支付请求后，验证所述订单是否符合保存的风险控制信 自
4、 如权利要求l所述的系统，其特征在于，所述客户端还包括第二用户 标识输入单元，用于接收第二用户标识，并将所述第二用户标识包含在本次 支付请求的身份信息；服务器还包括第二用户标识验证单元，用于将接收到 本次支付请求中第二用户标识和身份证号与预先保存或最近更新的第二用户 标识和身份证号进行对比，验证所述用户身份。
5、 如权利要求l所述的系统，其特征在于，所述支付验证子系统还包括 通知用户单元，所述通知用户单元向用户终端发送交易处理结果。
6、 一种利用包含IC卡的身份证进行交易的方法，其特征在于，包括(1) 身份证读卡器读取用户身份证上包含用户身份证号的身份信息，并将 之发送至请求子系统；(2) 请求子系统的客户端将包含所述身份信息和本次订单信息的支付请求 发送至服务器；(3) 服务器根据所述身份信息从预先保存的数据信息找到对应的账号，对 所述帐户进行扣款处理，并将处理结果返回至对应的客户端，所述数据信息 为服务器定周期或事件触发式从支付验证子系统下载的。
7、 如权利要求6所述的方法，其特征在于，步骤(3)之前包括服务器定周期从支付验证子系统中下载合法用户对应 的授信额度信息；步骤(3)还包括服务器接在收到支付请求后，先校验发出请求的用户对 应的授信额度是否满足本次订单金额要求，若用户授信额度满足本次订单金 额要求，才进行相应扣款处理。
8、 如权利要求6或7所述的方法，其特征在于， 步骤(3)之前包括服务器定周期从支付验证子系统中下载风险控制信自 步骤(3)还包括服务器在收到支付请求后，验证所述订单是否符合保存 的风险控制信息，当订单符合规则的风险控制，才进行相应的扣款处理。
9、 如权利要求6所述的方法，其特征在于，还包括 所述服务器定期或事件触发式发送本服务器处理的支付处理信息至支付验证子系统。
10、 如权利要求6所述的方法，其特征在于，还包括 所述支付验证子系统通知用户消费信息。
全文摘要
一种利用包含IC卡的身份证进行交易的支付方法，包括(1)身份证读卡器读取用户身份证上包含用户身份证号的身份信息，并将之发送至请求子系统；(2)请求子系统的客户端将包含所述身份信息和本次订单信息的支付请求发送至服务器；(3)服务器根据所述身份信息从预先保存的数据信息找到对应的账号，对所述帐户进行扣款处理，并将处理结果返回至对应的客户端，所述数据信息为服务器定周期或事件触发式从支付验证子系统下载的。上述方式能够避免使用银行卡、利用现有第二代身份证的安全措施，达到交易的安全性高、成本低的技术效果。为此，本发明还对应地提供了支付系统。
文档编号G06Q30/00GK101118628SQ200610104029
公开日2008年2月6日 申请日期2006年7月31日 优先权日2006年7月31日
发明者袁雷鸣 申请人:阿里巴巴公司