CN101118628A - 利用包含ic卡的身份证进行交易的支付系统及方法 - Google Patents

Abstract

一种利用包含IC卡的身份证进行交易的支付方法，包括：(1)身份证读卡器读取用户身份证上包含用户身份证号的身份信息，并将之发送至请求子系统；(2)请求子系统的客户端将包含所述身份信息和本次订单信息的支付请求发送至服务器；(3)服务器根据所述身份信息从预先保存的数据信息找到对应的账号，对所述帐户进行扣款处理，并将处理结果返回至对应的客户端，所述数据信息为服务器定周期或事件触发式从支付验证子系统下载的。上述方式能够避免使用银行卡、利用现有第二代身份证的安全措施，达到交易的安全性高、成本低的技术效果。为此，本发明还对应地提供了支付系统。

Description

利用包含IC卡的身份证进行交易的支付系统及方法

技术领域

本发明涉及数据处理领域，尤其涉及利用包含IC卡的身份证进行交易的支付系统及方法。

背景技术

由于现金交易存在携带不方便、安全性低等缺陷，所以银行卡被广泛地应用在各种交易场合，因此越来越多的人习惯采用银行卡进行消费。请参阅图1，其为现有的一种利用银行卡进行交易的系统的原理框图。它包括用于读取银行卡信息的终端13、商户子系统12和收单子系统11。商户子系统11包括服务器和若干客户端，客户端连接终端，商户子系统12的服务器通过专线连接收单行的收单子系统11。当收单行不是发卡行时，还需要通过银联的跨行交易子系统连接发卡行的发卡子系统。

当用户利用银行卡进行消费时，终端(如收银机等)先通过能否读取银行卡来识别银行卡的真伪，然后客户端再将用户输入的表征用户身份的身份信息、银行卡卡号信息以及本次交易的交易信息传送至商户子系统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元时，拒绝此用户的交易请求。对于账户也可以分为两种：一种账户可以象信用卡一样进行透支，一种账户可以像借记卡不能透支。若用户申请的账户类型为信用户卡型的账户，则在该用户的授信额度可以是指该用户的透支额度。另外，也可以针对不同业务品种、不同的商户设置不同的授信额度，这样，在每次处理订单时，需要判断订单是否满足授信单元规定的授信规则。还有，用户的授信额度可以是动态变化的，如用户消费金额达到某一级别后，用户的授信额度会增加。用户对应的账户金额达到某一阈值后，用户的授信额度会增加。第一授信单元中的授信内容可以根据用户的增加等发生变化，第二授信单元可以定周期从第一授信单元中下载授信内容，也可以事件触发式从第一授信单元中下载授信内容。所述事件触发比如说当检测订单的用户不是合法用户的次数为N次。

所述支付验证子系统33还包括第一风险控制单元，用于保存支付风险控制信息，所述请求子系统32包括第二风险控制单元，用于从第一风险控制单元中下载支付风险控制信息，以便处理单元在接收到支付请求后，验证所述订单是否符合保存的风险控制信息。风险控制信息是用于控制其风险的风险规则，比如一天中交易的次数限制、一天中同一用户的交易金额限制等。通常，风险控制信息包括对用户的风险控制和对商户的风险控制。对商户的风险控制包括可以针对不同的商户规定不同透支额度、设定一天内同一用户在同一商户提交消费的金额的上限等，对用户的风险控制包括同一用户在一天内消费的次数、同一用户在一天内消费的金额等

所述客户端321还包括第二用户标识输入单元，用于接收第二用户标识，并将所述第二用户标识包含在本次支付请求的身份信息；服务器322还包括第二用户标识验证单元，用于将接收到本次支付请求中第二用户标识和身份证号与预先保存或最近更新的第二用户标识和身份证号进行对比，验证所述用户身份。

对应地，本发明提供了公开了一种利用包含IC卡的身份证进行交易的方法。请参阅图3，它包括以下步骤：

S210：身份证读卡器读取用户身份证上包含用户身份证号的身份信息，并将之发送至请求子系统；

S220：请求子系统的客户端将包含所述身份信息和本次订单信息的支付请求发送至服务器；

S230：服务器根据所述身份信息从预先保存的数据信息找到对应的账号，对所述帐户进行扣款处理，并将处理结果返回至对应的客户端，所述数据信息为服务器定周期或事件触发式从支付验证子系统下载的。

步骤S230之前包括：服务器定周期从支付验证子系统中下载合法用户对应的授信额度信息，服务器接在收到支付请求后，先校验发出请求的用户对应的授信额度是否满足本次订单金额要求，若用户授信额度满足本次订单金额要求，才进行下一步处理。

步骤S230之前还包括：服务器定周期从支付验证子系统中下载风险控制信息，在步骤S230中，服务器验证所述订单是否符合保存的风险控制信息，当订单符合规则的风险控制，才进行相应的扣款处理。

所述服务器定期或事件触发式发送本服务器处理的支付处理信息至支付验证子系统。比如，服务器每天上传本服务器的消费数据，以便商户和验证子系统进行清算，服务器也可以在达到某一消费域值后，上传本服务器的消费数据，在上传的消费数据中至少包括本服务器所在的商号信息。

在进行扣款时，若是借记卡型的账户，先判断账户中的金额是否大于等于此次交易金额，若否，则返回交易金额不足的处理结果，否则进行扣款操作，并返回交易成功的处理结果，若是信用卡型的账户，若账户中的金额小于此次交易金额，可以按照预先设定的透支额度对其进行透支，同时也返回交易成功的处理结果。

当客户端接收到交易成功的处理结果后，进行交易，否则拒绝与本用户的交易。客户端将处理结果为扣款成功的交易进行打印，以便用户在其上进行签名确认。

并且，支付验证子系统还可以向用户终端返回本次支付的消费信息。或者，定期返回本用户消费的消费信息。比如，支付验证子系统33设置有与无线通信系统进行通信的接口单元，支付验证子系统33将用户的每次交易处理结果通过短信方式发送至用户的手机上。支付验证子系统33也可将用户的交易处理结果定周期通过短信方式发送至用户的手机上。再比如，支付验证子系统33连接因特网。支付验证子系统33将用户的每次交易处理结果通过因特网发送至用户的邮箱中。或者，支付验证子系统33将用户的交易处理结果定周期发送至用户的邮箱中。实现方式很多，上述公开仅为本发明的几个实例，可以根据用户的要求进行相应的操作。

为了提高安全性，步骤S220之前还包括请求子系统接收表征用户身份信息的第二用户标识；在步骤S230还包括在进行交易时，将接收到支付请求中的第二用户标识和身份证号与预先存储的身份证号及对应的第二用户标识进行对比，对比通过后才进行扣款处理。比如，用户申请开通此业务时，在支付验证子系统保存该用户的身份证号对应的密码。在数据更新时，将用户的身份证号对应的密码一同更新到本地的服务器上。当进行支付请求时，输入用户的密码，服务器将用户的密码与身份证号与预先保存的用户密码与身份证号进行比对，比对通过后，才进行后续处理。

本发明只需要增设身份证读卡器31，进行很少的硬件和软件更新即可完成本发明的交易处理，投入少，可操作性强。本发明主要是离线授权模式交易，适用于小额快速成交易。这种交易模式，处理非常速度快。

通常，请求子系统是设置在商户端，支付验证子系统是设置在支付服务提供商端。支付服务提供商的支付验证子系统下设置多个商户的请求子系统，每一商户在支付服务提供商处设置一用于标识商户的支付号标识。当商户与支付服务提供商交互时，都需携带支付号标识，支付服务提供商通过该标识识别不同的商户。比如，可以通过该标识设置不同的商户对应不同的授信额度，可以给不同的商户设置不同风险控制规则，当不同商户向支付服务提供商下载授信信息和风险控制信息时，根据该商户的标识下载本商户对应的授信信息和风险控制信息。商户的请求子系统定期上传消费数据请求清算给支付服务提供商时，同样包含商户的支付号标识。这样，在商户和支付服务提供商之间通过商户的支付号标识进行双方的清算。

以下就以支付服务提供商的支付验证子系统和一商户的请求子系统为例，来形象说明本发明的支付过程。请参阅图4，支付过程包括以下步骤：

在支付之前，商户需要向支付服务提供商下载除了用户的身份信息和账户信息之外，还需要下载本商户的授信信息、用户的授信信息以及本商户的风险控制规则及用户的风险控制规则。由于支付服务提供商内的数据是变化的，所以可以定期下载用户的身份信息和账户信息、风险控制信息和授信信息。

支付时需要进行以下步骤：

(1)消费者出示身份证(如第二代身份证)进行消费，商户的服务人员通过身份证读卡器读身份证数据，根据能否读出数据来判断身份证的真伪，通过读出的数据与消费者真人进行对比，服务人员判断是否是身份证持卡人进行消费；

(2)身份证读卡器将读取的数据发送至商户的请求子系统；

(3)对订单进行授信判断，判断订单是否满足授信要求，若是，则进行步骤(4)，否则返回不满足授信要求的处理结果；

(4)校验订单是否符合风险控制规则，若订单位于风险控制之内，则通过身份证号找到对应的账户，若是，借记卡型账户，判断账户中的余额是否足够，若不够，则返回余额不足的处理结果，若足够，则进行扣款处理，返回的扣款成功的处理结果。若是信用卡型账户，当账户中的余额不够时，判断订单金额是否在透支额度内，若是，则返回扣款成功的处理结果，否则返回透支额度不够的处理结果；

(5)商户接收到扣款成功的处理结果后，允许消费者消费，并要求消费者在签购单上签名确认；

(6)支付服务提供商通知消费者相应的消费信息。

商户也可以自行决定是否要进行步骤(5)，同时，支付服务提供商也可以自行决定是否通知消费者以及以何种方式何时告知消费者消费信息。另外，商户也需要定期上传消费数据请求清算，以便和支付服务提供商之间定期进行清算步骤(步骤(7))。

以上公开的仅为本发明的几个具体实施例，但本发明并非局限于此，任何本领域的技术人员能思之的变化，都应落在本发明的保护范围内。

Claims (10)

1.一种利用包含IC卡的身份证进行交易的支付系统，其特征在于：包括身份证读卡器、请求子系统和支付验证子系统，其中：

身份证读卡器，用于读取至少包含用户身份证号的用户身份信息；

支付验证子系统：包括数据库单元，用于保存用户身份信息和对应账号信息的绑定关系；

请求子系统：至少包括一服务器和若干客户端，所述客户端连接身份证读卡器，用于向服务器发起支付请求，所述支付请求中包含本次订单信息及包含身份证号的用户身份信息；所述服务器中至少包括处理单元，所述处理单元定期或事件触发式从所述支付验证子系统下载数据库单元的数据信息，以及从接收到的支付请求中获得身份证号，并根据身份证号找到对应的账号，进行扣款操作后，将处理结果返回至对应的客户端。

2.如权利要求1所述的系统，其特征在于，所述支付验证子系统还包括第一授信单元：用于保存合法用户/商户对应的授信额度信息，所述请求子系统还包括第二授信单元，用于根据第一授信单元更新本端的合法用户/商户对应的授信额度，以便处理单元在接收到支付请求后，校验发出请求的用户对应的授信额度是否满足本次订单金额要求。

3.如权利要求1或2所述的系统，其特征在于，所述支付验证子系统还包括第一风险控制单元，用于保存支付风险控制信息，所述请求子系统包括第二风险控制单元，用于从第一风险控制单元中下载支付风险控制信息，以便处理单元在接收到支付请求后，验证所述订单是否符合保存的风险控制信息。

4.如权利要求1所述的系统，其特征在于，所述客户端还包括第二用户标识输入单元，用于接收第二用户标识，并将所述第二用户标识包含在本次支付请求的身份信息；服务器还包括第二用户标识验证单元，用于将接收到本次支付请求中第二用户标识和身份证号与预先保存或最近更新的第二用户标识和身份证号进行对比，验证所述用户身份。

5.如权利要求1所述的系统，其特征在于，所述支付验证子系统还包括通知用户单元，所述通知用户单元向用户终端发送交易处理结果。

6.一种利用包含IC卡的身份证进行交易的方法，其特征在于，包括：

(1)身份证读卡器读取用户身份证上包含用户身份证号的身份信息，并将之发送至请求子系统；

(2)请求子系统的客户端将包含所述身份信息和本次订单信息的支付请求发送至服务器；

(3)服务器根据所述身份信息从预先保存的数据信息找到对应的账号，对所述帐户进行扣款处理，并将处理结果返回至对应的客户端，所述数据信息为服务器定周期或事件触发式从支付验证子系统下载的。

7.如权利要求6所述的方法，其特征在于，

步骤(3)之前包括：服务器定周期从支付验证子系统中下载合法用户对应的授信额度信息；

步骤(3)还包括：服务器接在收到支付请求后，先校验发出请求的用户对应的授信额度是否满足本次订单金额要求，若用户授信额度满足本次订单金额要求，才进行相应扣款处理。

8.如权利要求6或7所述的方法，其特征在于，

步骤(3)之前包括：服务器定周期从支付验证子系统中下载风险控制信息；

步骤(3)还包括：服务器在收到支付请求后，验证所述订单是否符合保存的风险控制信息，当订单符合规则的风险控制，才进行相应的扣款处理。

9.如权利要求6所述的方法，其特征在于，还包括：

所述服务器定期或事件触发式发送本服务器处理的支付处理信息至支付验证子系统。

10.如权利要求6所述的方法，其特征在于，还包括：

所述支付验证子系统通知用户消费信息。

Images