基于移动终端条码的支付以及业务处理方法及装置与流程

本申请涉及互联网
技术领域：
，尤其涉及一种基于移动终端条码的支付方法及装置，以及一种基于移动终端条码的业务处理方法及装置。
背景技术：
：随着移动互联网的发展和移动终端的普及，移动支付等移动业务越来越多地出现在餐厅、超市等各种公共场所。由于条码中包含了信息，所以在实际应用中只需扫码就可以处理业务。所以，由于利用条码处理业务使用便捷，从而得到了广泛应用。这里所说的利用条码处理业务是指利用条码扫码器扫描移动终端生成的条码，并将扫到的条码上传给服务器，由服务器端通过解析验证等过程最终完成业务处理。目前这种利用条码处理业务的方式已经占据了很多公共场所。现有技术，服务器根据扫码器扫到的移动终端中的条码进行业务处理时，会以与该移动终端绑定的账号的业务规则进行处理。比如在支付时，会以账号的控制额度为上限，控制移动终端的支付行为，控制额度就是单位时间内该账号可以支付的总额度。然而，在移动终端丢失后的较短时间内，如果还以对应的账户的控制额度为上限控制该移动终端的支付行为，就可能会造成较为严重的财产损失。所以亟需增强对移动终端业务行为的控制。另外，在现有技术中，一个账号也只能在该账号所属的移动终端外绑定一个移动终端，使这个绑定的移动终端可以根据条码请求业务。技术实现要素：本申请实施例提供一种基于移动终端条码的支付方法，用于加强对移动终 端支付行为地控制。本申请实施例提供一种基于移动终端条码的支付装置，用于加强对移动终端支付行为地控制。本申请实施例提供一种基于移动终端条码的支付装置，用于加强对移动终端支付行为地控制。本申请实施例提供一种基于移动终端条码的支付装置，用于加强对移动终端支付行为地控制。本申请实施例采用下述技术方案：一种基于移动终端条形码的支付方法，包括：接收扫码器扫描到的第一移动终端中用于支付的二维条形码，所述二维条码是根据第一移动终端唯一标识以及与第一移动终端具有绑定关系账号的账号信息生成的；解析所述二维条码，并根据解析到的账号信息以及第一移动终端唯一标识，进行身份验证；当验证通过后，根据第一移动终端唯一标识查询可支付额度，所述可支付额度为与第一移动终端具有绑定关系的账号针对第一移动终端预先设置的单位时间内可支付的最大额度；根据查询到的可支付额度进行支付。优选地，所述方法还包括：支付完成后，更新可支付额度，所述可支付额度为控制额度与记账额度的差值，所述控制额度为与第一移动终端具有绑定关系的账号针对第一移动终端预先设置的单位时间内可支付的总额度，所述记账额度为第一移动终端单位时间内已经完成支付的额度。优选地，所述方法还包括：支付完成后，保存支付信息，所述支付信息包括支付时间、完成支付的额度。优选地，解析所述二维条码，并根据解析到的账号信息以及第一移动终 端唯一标识，进行身份验证，包括：解析所述二维条码，得到账号信息以及第一移动终端唯一标识；根据账号信息以及第一移动终端唯一标识，查询账号针对第一移动终端预先设置的支付状态；当支付状态为开通时，根据账号信息以及第一移动终端唯一标识进行身份验证。优选地，所述账号通过第二移动终端与第一移动终端进行绑定。优选地，所述第一移动终端为穿戴式智能设备。优选地，所述账号与两个以上第一移动终端进行绑定。一种基于移动终端条码的支付装置，包括：接收单元、验证单元、查询单元以及支付单元，其中，所述接收单元，用于接收扫码器扫描到的第一移动终端中用于支付的条码，所述条码是根据第一移动终端唯一标识以及与第一移动终端具有绑定关系账号的账号信息生成的；所述验证单元，用于解析所述条码，并根据解析到的账号信息以及第一移动终端唯一标识，进行身份验证；所述查询单元，用于当验证通过后，根据第一移动终端唯一标识查询可支付额度，所述可支付额度为与第一移动终端具有绑定关系的账号针对第一移动终端预先设置的单位时间内可支付的最大额度；所述支付单元，用于根据查询到的可支付额度进行支付。优选地，所述装置还包括：更新单元，所述更新单元，用于支付完成后，更新可支付额度，所述可支付额度为控制额度与记账额度的差值，所述控制额度为与第一移动终端具有绑定关系的账号针对第一移动终端预先设置的单位时间内可支付的总额度，所述记账额度为第一移动终端单位时间内已经完成支付的额度。优选地，所述装置还包括：记录单元，所述记录单元，用于支付完成后，保存支付信息，所述支付信息包括支付时间、完成支付的额度。优选地，验证单元包括：验证子单元，具体用于：解析所述条码，得到账号信息以及第一移动终端唯一标识；根据账号信息以及第一移动终端唯一标识，查询账号针对第一移动终端预先设置的支付状态；当支付状态为开通时，根据账号信息以及第一移动终端唯一标识进行身份验证。一种基于移动终端条码的业务处理方法，其特征在于，同一账号与多个移动终端进行绑定，并针对每个移动终端预先设置了业务规则，所述方法包括：接收扫码器扫描到的移动终端中用于业务处理的条码，所述条码是根据所述移动终端唯一标识以及与所述移动终端具有绑定关系账号的账号信息生成的；解析所述条码，并根据解析到的账号信息以及所述移动终端唯一标识，验证所述移动终端是否为与所述账号绑定的多个移动终端中的其中一个；当是其中一个时，根据所述移动终端唯一标识查询所述账号针对所述移动终端预先设置的业务规则；根据所述针对所述移动终端预先设置的业务规则，进行业务处理。优选地，所述业务规则中包括业务状态，则根据所述针对所述移动终端预先设置的业务规则，进行业务处理，包括：查询所述业务规则中的业务状态；当业务状态为开通时，根据所述针对所述移动终端预先设置的业务规则，进行业务处理。一种基于移动终端条码的业务处理装置，同一账号与多个移动终端进行绑定，并针对每个移动终端预先设置了业务规则，装置包括：条码接收单 元、终端验证单元、业务规则查询单元以及业务处理单元，其中，所述条码接收单元，用于接收扫码器扫描到的移动终端中用于业务处理的条码，所述条码是根据所述移动终端唯一标识以及与所述移动终端具有绑定关系账号的账号信息生成的；所述终端验证单元，用于解析所述条码，并根据解析到的账号信息以及所述移动终端唯一标识，验证所述移动终端是否为与所述账号绑定的多个移动终端中的其中一个；所述业务规则查询单元，用于当是其中一个时，根据所述移动终端唯一标识查询所述账号针对所述移动终端预先设置的业务规则；所述业务处理单元，用于根据所述针对所述移动终端预先设置的业务规则，进行业务处理。优选地，所述业务规则中包括业务状态，则所述业务处理单元，具体用于：查询所述业务规则中的业务状态；当业务状态为开通时，根据所述针对所述移动终端预先设置的业务规则，进行业务处理。本申请实施例采用的上述至少一个技术方案能够达到以下有益效果：在服务器接收到用于支付的移动终端中的条码，并验证通过后，可以根据与该移动终端具有绑定关系的账号对该移动终端预先设置可用于支付的额度来进行支付，也就账号实现了对每个移动终端基于条码的支付行为地控制，从而解决了现有技术只能在针对账号的支付行为进行控制，导致的对移动终端支付行为控制较弱的问题，同时还提供了同一账号绑定多个移动终端在业务处理过程中的处理方法。附图说明此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：图1为本申请实施例1提供的一种基于移动终端条码的支付方法的流程示意图；图2为本申请实施例2提供的一种基于移动终端条码的支付装置的结构框图；图3为本申请实施例3提供的一种基于移动终端条码的业务处理方法的流程示意图；图4为本申请实施例4提供的一种基于移动终端条码的业务处理装置的结构框图；图5为本申请实施例5提供的一种儿童智能手表基于二维码的支付方法的流程示意图。具体实施方式为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。在进行本申请的技术方案的详细介绍之前，为了明确起见，这里先对几个术语作简要说明。在本申请实施例中将涉及扫码器，控制额度、可支付额度、记账额度等。其中，扫码器是一种读取条码的机器。控制额度是指单位时间内可以支付的总额度，比如，控制额度为1天1000元，则在每天的00:00至24:00内，可以支付的总额度的为1000元；可支付额度是指单位时间内可用于支付的额度，记账额度是指单位时间内已经完成支付的额度，在同一单位时间内，控制额度为可支付额度与记账额度之和。比如，控制额度为一天1000元，在这一天内，第一次支付了300元，则记账额度为300元，可支付额度为700元，第二次支付了500元，则记账额度变为800元，可支付额度变为200元。以下结合附图，详细说明本申请各实施例提供的技术方案。实施例1如前所述，条码支付由于使用便捷，已经有很多公共场所通过使用扫码器扫描移动终端中的条码进行完成支付。但是，目前通过这种方式进行支付时，会以与移动终端具有绑定关系的账号的控制额度为上限，比如，账号的控制额度为一天2000元，那么与该账号绑定的所有移动终端在这一天能够支付的总和就为不超过2000元，但是，如果与该账号绑定的某个移动终端遗失或被窃，则他人可以在禁止账号进行支付之前的时间内通过该移动终端进行支付，从而造成不必要的财产损失。所以亟需一种支付方案，加强对移动终端基于条码进行支付的支付行为地控制。鉴于此缺陷，本发明人提出了一种基于移动终端条码的支付方法，用于加强对移动终端支付行为地控制。假设执行主体是用于完成支付操作的服务器。该方法的具体流程示意图如图1所示，包括下述步骤：步骤11：接收扫码器扫描到的第一移动终端中用于支付的条码。该步骤中，用于支付的条码是扫码器扫描用于支付的移动终端中的条码后并发送给服务器的。比如，想用某一手机进行条码支付，则扫码器应扫描该手机中生成的条码，并将该条码发送给用于完成支付操作的服务器。移动终端中的条码，是根据移动终端唯一标识以及与移动终端具有绑定关系账号的账号信息生成的。在移动终端与账号进行绑定的过程，账号可以通过另一个移动终端上安装的应用程序与用于支付的移动终端进行绑定。所以，账号可以通过第二移动终端与第一移动终端进行绑定。比如：账号利用智能手机上安装的应用程序与智能手表进行绑定，此时智能手表就是第一移动终端，智能手机就是第二终端。为了方便理解，可以将第一移动终端称为支付终端(用于支付的移动终端)，第二移动终端称为账号终端(账号所在的移动终端)。支付终端唯一标识(下文简称id)是指唯一能够标识支付终端的标识码，比如mac(mediaaccesscontrol，介质访问控制)地址，是一种硬件地址；又 如uuid(universallyuniqueidentifier，通用唯一识别码)，它是指在一台终端上生成的数字，用于保证对在同一时空中的所有终端都是唯一的。支付终端id可以直接是mac地址或uuid或者两者的整合，也可以是将两者通过特定的转码算法生成的。id除了可以包含mac和uuid，还可以包含移动终端的硬件类型(智能手机、智能手表等)，型号，硬件参数(屏幕尺寸、颜色)等，但意义都是为了区别其它移动终端，使该id能够表示该终端的唯一性。在绑定时，需要将支付终端id通过账号终端与账号进行绑定，使两者具有映射关系。并将该支付终端id以及与之具有绑定关系的账号的账号信息保存在服务器中，以便支付时进行身份验证。比如，支付终端id为abcd，与其具有绑定关系的账号的账号名为1234，那么就将abcd与1234以映射的关系保存在服务器中，以便支付时进行身份验证。需要说明的是，同一个账号可以绑定多个支付终端，比如，支付终端id为abcd和efgh均与账号名为1234的账号进行了绑定，则abcd以及efgh均与1234以映射的关系保存在服务器中。生成条码时，就可以根据支付终端id以及与该支付终端具有绑定关系账号的账号信息来生成，具体将信息生成为条码的过程是本领域技术人员的公知常识，此处不多赘述。接收的过程就是在扫码器与服务器之间通过网络建立连接，并传输(可以通过有线或无线)，是基本的数据传输技术。需要说明的是，条码可以包括一维条码以及二维条码。一维条码，也称条形码(barcode)是将宽度不等的多个黑条和空白，按照一定的编码规则排列，用以表达一组信息的图形标识符。二维条码，也称二维码，是在一维条码(即条形码)的基础上扩展出另一维具有可读性的条码，使用黑白(两对比度明显颜色)矩形图案表示二进制数据，被扫描并解析后可获取其中包含的信息。所以，在本申请中，不管是一维条码还是二维条码，都可以作为一种条码来存储信息，并可以根据信息来进行支付或处理业务。步骤12：解析条码，并根据解析到的账号信息以及支付终端唯一标识，进行身份验证。该步骤中，对条码进行解析的过程就是获取条码中包含的信息的过程，可以看作是根据信息生成条码的逆向过程。在条码中，可以包含如步骤11中介绍的支付终端id以及与该其具有绑定关系账号的账号信息。但是，为了提高安全性，会加入另外的验证信息，比如，可以包括时间戳，用于验证该条码是否在有效的时间范围内，该时间戳可以由服务器下发到账户终端中，再由账户终端传输到支付终端中，也可以直接下发给支付终端(前提是该支付终端具有网络连接功能)。具体比如，时间戳的有效时长为24小时，那么若当前时间距离时间戳的时长大于24小时，则判断出该条码无效。在实际应用中，为了防止条码信息被拦截篡改，往往需要将用于生成条码的信息进行加密，并且在验证过程中，可以进行至少一次验证。比如，支付终端生成条形码时，可以将支付终端id，时间戳，以及账号信息等信息，利用服务器发送过来的私钥进行加密，并标记加密的算法。在服务器对其进行验证时，根据标记的加密算法，利用了私钥数字签名，公钥验证的关系，先确定出条形码中的内容，再利用公钥进行解析，这是第一次验证，如果无法解析，则无法支付。接着根据解析到的支付终端id，时间戳，以及账号信息等信息，验证时间戳的有效性，这是第二次验证，最后根据移动终端id以及账号信息，与保存在服务器中的映射关系，进行第三次验证，从而完成三次验证。在一种实施方式中，为了进一步控制支付终端的支付行为，解析条码，并根据解析到的账号信息以及第一移动终端唯一标识，进行身份验证，可以包括：解析条码，得到账号信息以及支付终端唯一标识；根据账号信息以及支付终端唯一标识，查询账号针对支付终端预先设置的支付状态；当查询到的支付状态为开通时，根据账号信息以及支付终端唯一标识，进行身份验证。具体地，账号可以针对支付终端预先设置支付状态，并将支付状态保存在服务器中，该支付状态可以包括开通和禁止。在将解析条码后，会得到账号信息以及支付终端id，再根据支付终端id查询账号针对该终端预设的支付状态，如果是开通，就可以进行身份验证，如果禁止，就可以直接返回支付失败信息。采用这样方式可以更好的控制支付终端的支付行为，即可以随时变更支付终端是否可以利用条码进行支付。步骤13：当验证通过后，根据支付终端的唯一标识查询可支付额度。该步骤中，可支付额度为与支付终端具有绑定关系的账号针对该终端预先设置的单位时间内可支付的最大额度。在前文介绍术语中已经介绍，控制额度是指单位时间内可支付的总额度，可支付额度是指单位时间内可进行支付的额度，记账额度是指单位时间内已经完成支付的额度，在单位时间内，控制额度为可支付额度与记账额度之和。如表1所示，为账号1234针对与之具有绑定关系的两个支付终端abcd和efgh预先设定的额度。账号名支付终端id控制额度记账额度可支付额度单位时间1234abcd1000100日efgh50010490周表1(额度单位：元)由此表，可以查询到支付终端abcd和efgh的可支付额度分别为100元和490元。该步骤中针对与账号具有绑定关系的支付终端预先设置的控制额度对控制该终端支付行为具有重要作用。步骤14：根据查询到的可支付额度进行支付。在该步骤中，当支付请求的金额不大于可支付额度时，可以完成支付。以上表1为例，如果支付终端abcd支付50元，则可以完成支付，如果支付150元，则无法完成支付。由于控制额度是不变的，在完成一次支付后，随着记账额度的增加，可支付额度必然减少，下一次支付时，就需要查询最新的可支付额度，所以在一种实施方式中，该方法还可以包括步骤15：支付完成后，更新可支付额度。该步骤中，由于可支付额度为控制额度与记账额度的差值，所以在完成支付后，可以根据自动变更的记账额度以及控制额度，更新可支付额度。比如，以表1为例，移动终端abcd在一天内完成一笔50元的支付后，这一天的记账额度即为50元，由于控制额度为每天100元，所以这一天的可支付额度为50元。在实际应用中，可以有多样的设置，比如，当支付请求的金额大于可支付额度时，完成支付，但根据超出可支付额度的额度，扣除下个单位时间内的控制额度。还可以当支付请求的金额大于可支付额度时，完成支付，但将支付状态修开通修改为禁止，从而起到了加强对支付行为地控制，并可以延长禁止的时间(如在10个单位时间后修改为开通)，进一步加强对支付行为地控制。为了方便账号更详细的了解移动终端的支付行为，在一种实施方式中，该方法还可以包括步骤16：支付完成后，保存支付信息。该步骤中，支付信息可以包括支付时间、完成支付的额度。比如，18:00：00，支付了50元。此外，还可以包括支付的商家信息，交易单号，交易类型等。在一种实施方式中，该实施例的支付终端可以是穿戴式智能设备，比如，智能手表，智能腕带，运动手环(带有屏幕)。而且尤其适合儿童佩戴的智能手表，通过针对儿童智能手表预先设置单位时间内的控制额度，加强对儿童智能手表支付行为地控制。并可以通过步骤15中介绍的对支付的多样设置，培养儿童的自律意识。在步骤11中已经介绍，在绑定时，支付终端id可以包含硬件类型，所以，可以不同的硬件类型，也可以有不同的控制额度设置方案。可以在服务器中保 存针对不同硬件类型对应的不同设置方案，比如，可以通过支付终端id建立与儿童智能手表(老人智能手表)对应的设置方案。采用这种方式，就可以针对不同的支付终端的，进行不同的控制。采用实施例1提供的该方法，在服务器接收到用于支付的移动终端中的条码，并验证通过后，可以根据与该移动终端具有绑定关系的账号对该移动终端预先设置可用于支付的额度来进行支付，也就账号实现了对每个移动终端基于条码的支付行为地控制，从而解决了现有技术只能在针对账号的支付行为进行控制，导致的对移动终端支付行为控制较弱的问题。此外，还可以通过设置移动终端的支付状态，更加灵活并且及时地控制移动终端的支付行为。实施例2基于相同的发明构思，实施例2提供了一种基于移动终端条码的支付装置，用于加强对移动终端支付行为地控制。如图2所示，该装置包括：接收单元21、验证单元22、查询单元23以及支付单元24，其中，接收单元21，可以用于接收扫码器扫描到的第一移动终端中用于支付的条码，条码是根据第一移动终端唯一标识以及与第一移动终端具有绑定关系账号的账号信息生成的；验证单元22，可以用于解析条码，并根据解析到的账号信息以及第一移动终端唯一标识，进行身份验证；查询单元23，可以用于当验证通过后，根据第一移动终端唯一标识查询可支付额度，可支付额度为与第一移动终端具有绑定关系的账号针对第一移动终端预先设置的单位时间内可支付的最大额度；支付单元24，可以用于根据查询到的可支付额度进行支付。在一种实施方式中，该装置还可以包括：更新单元，该更新单元可以用于支付完成后，更新可支付额度，可支付额度为控制额度与记账额度的差值，控制额度为与第一移动终端具有绑定关系的账号针 对第一移动终端预先设置的单位时间内可支付的总额度，记账额度为第一移动终端单位时间内已经完成支付的额度。在一种实施方式中，该装置还可以包括：记录单元，该记录单元可以用于支付完成后，保存支付信息，支付信息可以包括支付时间、完成支付的额度，可以包括支付的商家信息，交易单号，交易类型等。在一种实施方式中，验证单元22包括：验证子单元，该验证子单元可以用于：解析条码，得到账号信息以及第一移动终端唯一标识；根据账号信息以及第一移动终端唯一标识，查询账号针对第一移动终端预先设置的支付状态；当支付状态为开通时，根据账号信息以及第一移动终端唯一标识进行身份验证。在一种实施方式中，账号通过第二移动终端与第一移动终端进行绑定。在一种实施方式中，第一移动终端为穿戴式智能设备，比如：智能手表。在一种实施方式中，其特征在于，账号与两个以上第一移动终端进行绑定。采用实施例2提供的该装置，在服务器接收到用于支付的移动终端中的条码，并验证通过后，可以根据针对与该移动终端具有绑定关系的账号对该移动终端预先设置可用于支付的额度来进行支付，也就账号实现了对每个移动终端基于条码的支付行为地控制，从而解决了现有技术只能在针对账号的支付行为进行控制，导致的对移动终端支付行为控制较弱的问题。此外，还可以通过设置移动终端的支付状态，更加灵活并且及时地控制移动终端的支付行为。实施例3如前所述，现有技术一个账号只能在该账号所属的移动终端外绑定一个移动终端，使这个绑定的移动终端可以根据条码请求业务。比如，一个账号通过 自己的手机，只能绑定一个智能手表，该智能手表可以通过条码完成各种业务。但随着智能设备的普及，更多的需求是一个账号绑定多个移动终端，并对每个移动终端进行管理。所以，本实施例提供一种基于移动终端条码的业务处理方法，应用于一个账号绑定多个移动终端时的业务处理场景。该实施例中，同一账号可以与除该账号所属智能终端以外的多个(至少2个)移动终端进行了绑定，绑定的过程可以是账号利用手机终端上的应用程序调用手机的蓝牙功能，分别与多个移动终端进行连接，并获取每个移动终端的唯一标识码，并将账号与多个移动终端的唯一标识码建立映射关系，保存在服务器中。为了控制每个移动终端的业务行为，为每个终端都预先设置了一套业务规则(比如，可以/不可以执行的业务等)，一同保存在服务器中。该方法如图3所示，包括下述步骤：步骤31：接收扫码器扫描到的移动终端中用于业务处理的条码。该条码可以是根据该移动终端唯一标识以及与该移动终端具有绑定关系账号的账号信息生成的。比如，同一账号可以与除该账号所属手机以外的两个智能手表以及一个智能手机进行绑定。具体实现方式，就可以是将智能手表和智能手机的id分别与该账号建立映射关系，并保存在服务器中。当某个移动终端申请执行某个业务时，就可以根据该移动终端的id以及该账号的账号信息，再加上业务信息，生成条码，以供扫码器来扫描。本实施例中的条码也可以是一维条码或二维条码。步骤32：解析条码，并根据解析到的账号信息以及移动终端唯一标识，验证该移动终端是否为与该账号绑定的多个移动终端中的其中一个。当接收到条码后，就可以对它进行解析，解析的过程不是本申请终点，所以不再赘述。在解析到条码中包含的账号信息，以及移动终端id时，就可以去服务器中查询，两者是否具有映射关系，由于该账号绑定了多个移动终端，所以就需要查询该移动终端id是否是与该账号具有映射关系的其中一个。步骤33：当是其中一个时，根据该移动终端唯一标识查询该账号针对该移动终端预先设置的业务规则。当查询到这个移动终端是与账号绑定的其中一个时，就可以查询该账号为该移动终端设置的业务规则。该业务规则可以是预先设定的，比如，如果移动终端是儿童智能手表，就可以设置支付的额度(1天20元)等。如果是老人的智能手机，还可以设置家庭住址，以便出租车可以将老人送回家，更可以添加老人的病历，身体情况，以便医院可以通过条码查询老人的病历。步骤34：根据针对移动终端预先设置的业务规则，进行业务处理。在查询到针对移动终端预先设置的业务规则后，就可以进行业务处理。比如在实施例1中介绍的步骤14中已经介绍了支付业务的处理方法，又如，某个银行通过移动终端二维码查询身份证等个人信息时，可以根据预先为该移动终端设定的业务规则进行业务处理，该业务规则可以是：当查询个人信息为银行时，可以查询。为了进一步控制支付终端的支付行为，在一种实施方式中，该步骤还包括：查询业务规则中的业务状态；当业务状态为开通时，执行该步骤。具体介绍可以参照实施例1中步骤12的说明，此处不再赘述。采用实施例3提供的该方法，在服务器接收到用于处理业务的移动终端中的条码，并验证通过后，可以根据针对与该移动终端具有绑定关系的账号对该移动终端预先设置的业务规则进行业务处理，也就账号实现了对多个移动终端基于条码的业务行为地分别管理。实施例4基于相同的发明构思，实施例4提供了一种基于移动终端条码的业务处理方法，应用于一个账号绑定多个移动终端时的业务处理场景，该实施例中，同一账号与多个移动终端进行绑定，并针对每个移动终端预先设置了业务规则。如图4所示，该装置包括：条码接收单元41、终端验证单元42、业务规则查 询单元43以及业务处理单元44，其中条码接收单元41，可以用于接收扫码器扫描到的移动终端中用于业务处理的条码，条码是根据移动终端唯一标识以及与移动终端具有绑定关系账号的账号信息生成的；终端验证单元42，可以用于解析条码，并根据解析到的账号信息以及所述移动终端唯一标识，验证移动终端是否为与所述账号绑定的多个移动终端中的其中一个；业务规则查询单元43，可以用于当是其中一个时，根据移动终端唯一标识查询账号针对移动终端预先设置的业务规则；业务处理单元44，可以用于根据针对移动终端预先设置的业务规则，进行业务处理。在一种实施方式中，业务规则中包括业务状态，则业务处理单元44，可以用于：查询业务规则中的业务状态；当业务状态为开通时，根据针对移动终端预先设置的业务规则，进行业务处理。采用实施4提供的该装置，在服务器接收到用于处理业务的移动终端中的条码，并验证通过后，可以根据针对与该移动终端具有绑定关系的账号对该移动终端预先设置的业务规则进行业务处理，也就账号实现了对多个移动终端基于条码的业务行为地分别管理。实施例5基于相同的发明构思，实施例5提供了一种儿童智能手表基于二维码的支付方法，用于加强对儿童手表基于二维码的支付行为地控制。假设一个家长有两个孩子a和b，两个孩子各有一个智能手表，绑定时，该家长在指定的应用程序中通过手机的蓝牙功能，与智能手表建立连接，并获取智能手表的mac 地址、uuid、手表型号生成智能手表id(abcd和efgh)，并与账号1234建立映射关系，保存在服务器中，从而完成了账号1234与两个智能手表的绑定。还对两个智能手表进行了控制额度的预先设置，如下表2所示，为家长m对两个智能手表控制额度的设置。账号名智能手表id备注控制额度单位时间支付状态1234abcd宝贝a60日开通efgh宝贝b50日开通表2(额度单位：元)该方法为孩子a用智能手表通过二维码进行支付的示意图，假设执行肢体为用于完成支付操作的服务器，如图5所示，包括下述步骤：步骤51：接收扫码器扫描到的智能手表abcd中用于支付的二维码。该二维码是智能手表接收手机传输的智能手表id、账号名、服务器下发给手机的时间戳、算法标识以及私钥，并根据算法标识，利用私钥对智能手表id、账号名以及时间戳进行加密，再根据加密后的信息生成得到的。步骤52，解析二维码，得到二维码中包含的信息，并利用与下发给手机的私钥对应的公钥进行解密，做第一次验证。步骤53，通过验证后，得到智能手表id、账号名以及时间戳，验证时间戳是否有效，做第二次验证。步骤54，通过验证后，根据智能手表id、账号名，查询该智能手表的支付状态。步骤55，支付状态为开通时，根据智能手表id(abcd)、账号名(1234)，验证绑定关系是否正确，做第三次验证。根据上表2，则可判断绑定关系正确。步骤56，通过验证后，根据智能手表id(abcd)，查询可支付额度。如下表3，为服务器保存的智能手表的账务信息。智能手表id备注控制额度记账额度可支付额度单位时间abcd宝贝a60060日efgh宝贝b501040日表3(额度单位：元)步骤57，根据查询到的可支付额度进行支付，智能手表abcd的可支付额度为60元，接收到的支付请求的33元，则支付成功。步骤58，支付完成后，更新可支付额度。如下表4所示，为更新后的账务信息。表4(额度单位：元)步骤59，支付完成后，保存支付信息，如下表5，为智能手表abcd的支付信息。智能手表id时间地点单号记账额度abcd2015/10/2517:45xx餐厅1000100033表5采用实施例5提供的该方法，由于可以针对与账号具有绑定关系的儿童智能手表预先设置可用于支付的额度，也就实现了对每个儿童智能手表基于二维码支付的支付行为地控制，也就是加强了对儿童消费意识的把控。从而解决了现有技术只能在家长账号维度对儿童智能手表基于二维码的支付行为进行控制，导致的控制较弱的问题，如家长不太可能将额度设置为100，但应该对儿童消费行为进行控制。此外，还通过设置儿童智能手表的支付状态，更加灵活并且的及时的控制儿童的支付行为。本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。在一个典型的配置中，计算设备包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flashram)。内存是计算机可读介质的示例。计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任 何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitorymedia)，如调制的数据信号和载波。还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括要素的过程、方法、商品或者设备中还存在另外的相同要素。本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。以上仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。当前第1页12