防止窃取电子发票的方法及装置与流程

本发明涉及数据库技术领域，具体而言，涉及一种防止窃取电子发票的方法及装置。

背景技术：

随着互联网科技的发展，大中型的线下连锁超市、餐饮商家和线上点餐等都会将开具电子发票作为服务中的重要一环。以超市为例，消费者在购买商品结账之后会拿到商品的票据，票据上会打印有开具电子发票链接的二维码，消费者用微信等工具扫二维码后，填写并提交发票抬头等信息，就能收到商家开具的电子发票。上述场景在方便商家和消费者的同时，也给一些不法分子带来了可乘之机，不法分子在消费者不知情的情况下，收集消费者没有开具发票的票据，开具电子发票进行牟利，窃取电子发票，给消费者甚至国家带来损失。

申请人在实现本发明的过程中，发现相关技术中至少存在以下技术问题。

在申请号为201810471652.1的技术方案中，公开了一种通用的电子发票解决方案，对消费者提交的开票信息进行md5等手段进行加密，并在扫码开票系统中进行了校验，这种方案并不能解决票据遗失或被盗，而导致电子发票被窃取的场景。

在申请号为201410632026.8的技术方案中，将开具的发票信息以及在开具当前发票的同时生成的验证码传输到税务服务器，并将验证码设置在发票的票面，同样无法解决票据遗失或被盗，而导致电子发票被窃取的问题。

可见，相关技术中针对上述的问题，目前尚未提出有效的解决方案。

技术实现要素：

本发明实施例提供了一种防止窃取电子发票的方法及装置，以至少解决由于相关技术中无法解决盗用消费者的票据，来窃取消费者电子发票的技术问题。

根据本发明实施例的一个方面，提供了一种防止窃取电子发票的方法，包括：接收开具发票请求，其中，所述开具发票请求中携带有身份信息；对所述身份信息进行验证；在所述身份信息验证成功的情况下，基于目标订单开具发票；以及，在所述身份信息验证失败的情况下，拒绝开具发票。

根据本发明实施例的另一方面，还提供了一种防止窃取电子发票的装置，包括：接收单元，用于接收开具发票请求，其中，所述开具发票请求中携带有身份信息；验证单元，用于对所述身份信息进行验证；处理单元，用于在所述身份信息验证成功的情况下，基于目标订单开具发票；以及，还用于在所述身份信息验证失败的情况下，拒绝开具发票。

根据本发明实施例的另一方面，还提供了一种电子设备，包括处理器，存储器及存储在所述存储器上并可在所述处理器上运行的程序或指令，所述程序或指令被所述处理器执行时实现如上所述的防止窃取电子发票的方法的步骤。

根据本发明实施例的另一方面，还提供了一种可读存储介质，所述可读存储介质上存储程序或指令，所述程序或指令被处理器执行时实现如上所述的防止窃取电子发票的方法的步骤。

在本发明实施例中，采用对开票人身份进行验证的方式，通过接收开具发票请求，对开具发票请求中的身份信息进行验证，在身份信息验证成功的情况下，基于目标订单开具发票；以及，在身份信息验证失败的情况下，拒绝开具发票。达到了提高开具电子发票安全性的目的，从而实现了防止盗用票据来窃取电子发票的技术效果，进而解决了由于相关技术中无法解决盗用消费者的票据，来窃取消费者电子发票的技术问题。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是根据本发明实施例的一种可选地防止窃取电子发票的方法的硬件环境的示意图；

图2是根据本发明实施例的一种可选的防止窃取电子发票的方法的流程示意图；

图3是根据本发明实施例的一种可选的订单列表界面的示意图；

图4是根据本发明实施例的一种可选的应用场景一的流程示意图；

图5是根据本发明实施例的一种可选的开具电子发票的流程示意图；

图6是根据本发明实施例的一种可选的应用场景二的流程示意图；

图7是根据本发明实施例的又一种可选的开具电子发票的流程示意图；

图8是根据本发明实施例的一种可选的应用场景三的流程示意图；

图9是根据本发明实施例的又一种可选的开具电子发票的流程示意图；

图10是根据本发明实施例的一种可选的防止窃取电子发票的装置的结构示意图；

图11是根据本发明实施例的一种可选的电子设备的结构示意图。

具体实施方式

为了使本技术领域的人员更好地理解本发明方案，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分的实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本发明保护的范围。

需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

方法实施例1

根据本发明实施例的一个方面，提供了一种防止窃取电子发票的方法，可选地，作为一种可选地的实施方式，上述防止窃取电子发票的方法可以但不限于应用于如图1所示的环境中，其中，图1是根据本发明实施例的防止窃取电子发票的方法的硬件环境的示意图。如图1所示，终端10可以与订单服务器20之间可以进行数据交互，订单服务器20中可以包括但不限于存储器202和处理器204，终端10中包括但不限于处理器102、存储器104以及图像采集装置106。

在该实施例中，终端10通过图像采集装置106扫描票据中的二维码来获取订单服务器20的地址信息，处理器102根据存储器104中存储的身份信息以及地址信息生成开具发票请求，将开具发票请求发送至订单服务器20，订单服务器20中的处理器204根据存储器202中的存储的目标订单的信息对开具发票请求中的身份信息进行验证，在验证信息验证通过的情况下，根据目标订单开具发票，在验证信息未通过的情况下，拒绝开票。在本实施例中，通过对开具发票请求中的身份信息进行验证，保证了电子发票的安全性，避免了窃取电子发票的现象。

根据本发明实施例，提供了一种防止窃取电子发票的方法，如图2所示，该方法具体可以包括以下步骤：

s202，接收开具发票请求，其中，开具发票请求中携带有身份信息；

具体地，在本实施例中，通过预设终端发送开具发票请求至预设服务器，或者由预设客户端发送开具发票请求至订单系统。

在一个例子中，在用户拿到消费后的票据后，通过预设终端中的预设应用程序扫描票据中的二维码，二维码对应的信息包括但不限于预设订单服务器的地址信息(例如网络链接)以及目标订单的订单信息，其中，订单信息包括但不限于订单号、消费金额、消费账户等。根据预设应用程序当前登录或者绑定的账号信息生成开具发票请求，并通过预设订单服务器的地址信息向预设订单服务器发送开具发票请求。

需要说明的是，身份信息包括但不限于支付账户、订单所对应的会员id、手机号等，在本实施例中，对此不做任何限定。

s204，对身份信息进行验证；

具体地，在本实施例中，用户的开具电子发票分为多种情况，例如一个场景中，针对存在订单系统且支持用户在订单系统中直接开具发票的情况下，仅需要将用户的身份信息通过预设客户端发送至订单系统，订单系统对用户身份信息进行验证。在身份信息验证成功后，在预设客户端上展示用户的可以开具电子发票的订单，然后根据用户选取的目标订单以及发票抬头信息开具对应的电子发票。

而在另一个场景中，不存在能够开具发票的订单系统的情况下，用户通过预设应用程序扫描票据上的二维码后，获取票据编号或者目标订单编号，然后根据预设应用程序上的登录或绑定的账号信息以及目标订单的编号生成开具发票请求，将开具发票请求发送至预设订单服务器。预设订单服务器获取目标订单的相关信息，对开具发票请求中的身份信息进行验证。

s206，在身份信息验证成功的情况下，基于目标订单开具发票；以及，在身份信息验证失败的情况下，拒绝开具发票。

具体地，在本实施例中，例如在上述第一个场景中，在身份信息验证成功后，在预设客户端上展示用户的可以开具电子发票的订单，然后根据用户选取的目标订单以及发票抬头信息开具对应的电子发票。在身份信息验证失败的情况下，在预设客户端上展示身份信息验证失败的提醒。

而在上述另一个场景中，在开具发票请求中包含了目标订单的信息，因此在身份信息验证通过后，直接基于目标订单开具对应的电子发票。在身份验证失败的情况下，拒绝开具发票。可选地，向预设终端返回身份信息验证失败的提醒。

需要说明的是，通过本实施例，接收开具发票请求，对开具发票请求中的身份信息进行验证，在身份信息验证成功的情况下，基于目标订单开具发票；以及，在身份信息验证失败的情况下，拒绝开具发票。达到了提高开具电子发票安全性的目的，从而实现了防止盗用票据来窃取电子发票的技术效果，进而解决了由于相关技术中无法解决盗用消费者的票据，来窃取消费者电子发票的技术问题。

可选地，在本实施例中，开具发票请求是由第一预设终端基于第一预设地址信息发送至第一订单服务器的，开具发票请求中还包括目标订单，其中，对身份信息进行验证，包括但不限于：在目标订单存在关联的会员id的情况下，通过会员id对身份信息进行验证。

具体地，在本实施例中，第一预设地址信息包括但不限于二维码，二维码中的信息包括但不限于第一订单服务器的地址信息以及目标订单的订单编号。第一预设终端通过预设应用程序扫描二维码，来获取二维码中的信息，基于目标订单的订单编号以及预设应用程序中当前登录或绑定的账号信息，生成开具发票请求并将开具发票请求发送至第一订单服务器。第一订单服务器在接收到开具发票请求的情况下，根据开具发票请求中的目标订单的订单编号获取目标订单的信息。若未获取到目标订单的信息，则向第一终端返回目标订单不存在的提示信息，在获取到目标订单的信息的情况下，首先判断目标订单是否存在关联的会员id，在目标订单存在会员的id的情况下，则对第一终端中预设应用程序中当前登录或绑定的账号信息进行匹配。

可选地，在本实施例中，在目标订单存在关联的会员id的情况下，通过会员id对身份信息进行验证，包括但不限于：获取身份信息中的用户id；若用户id与会员id匹配，则确定身份信息验证成功；若用户id与会员id不匹配，则获取会员id关联的第一联系方式，以及身份信息关联的第二联系方式；若第一联系方式与第二联系方式匹配，则确定身份信息验证成功；若第一联系方式与第二联系方式不匹配，则确定身份信息验证失败。

具体地，在本实施例中，首先通过目标订单绑定的会员id对开具发票请求中的身份信息进行验证，在会员id验证不通过的情况下，则通过目标订单对应的第一联系方式对身份信息关联的第二联系方式进行验证。其中，第二联系方式可以包含在开具发票请求中，也可以通过订单服务器向第一终端进行联系方式请求，在本实施例中，对具体的联系请求方式不做限定。需要说明的是，第一联系方式以及第二联系方式包括但不限于邮箱地址、固定电话号码、移动电话号码、社交账号id等。

此外，第一联系方式以及第二联系方式的匹配过程，还可以通过第一联系方式的二维码以及第二联系方式的二维码进行匹配。

在一个例子中，通过预设应用程序扫描票据中的二维码，获取二维码中包含的第一订单服务器的地址信息，根据预设应用程序中的用户id(即预设应用程序的登录账号)以目标订单的订单编号生成开具发票请求，按照第一订单服务器的地址信息发送开具发票请求至第一订单服务器。第一订单服务器接收到开具发票请求后，判断目标订单是是否绑定对应的会员，若目标订单绑定了对应的会员，获取目标订单绑定的会员id，判断用户id与会员id是否匹配，若用户id与会员id匹配，则确定身份信息验证成功；若用户id与会员id不匹配，则获取会员id关联的第一手机号码，以及用户id关联的第二手机号码。然后，对第一手机号码以及第二手机号码进行匹配，在第一手机号码与第二手机号码匹配的情况下，确定身份信息验证成功；在第一手机号码与第二手机号码不匹配的情况下，确定身份信息验证失败。

作为一种优选地实施方式，在本实施例中，还可以在第一终端中展示目标订单关联的第一联系方式的部分信息，以使用户输入字符信息对第一联系方式进行补全。通过对字符信息进行比对，以实现对身份信息进行验证。

通过上述实施例，在目标订单存在关联的会员id的情况下，对身份信息中的用户id进行验证，在用户id验证不存在的情况下，通过目标订单关联的第一联系方式对身份信息进行验证，保证了对身份信息验证的准确性。

可选地，在本实施例中，对身份信息进行验证，还包括但不限于：在目标订单不存在关联的会员id的情况下，通过目标订单对应的第一支付信息对身份信息进行验证。

具体地，在本实施例中，在目标订单不存在关联的会员id的情况下，若目标订单存在对应的第一支付信息，则通过第一支付信息对身份信息进行验证，通过向第一终端进行发送支付账号获取请求以获取第一终端的支付账号，通过第一支付信息对地动仪终端的支付账号进行匹配。

可选地，在本实施例中，在目标订单不存在关联的会员id的情况下，通过目标订单对应的第一支付信息对身份信息进行验证，包括但不限于：确定与第一支付信息对应的第一账号；根据身份信息向第一预设终端发送支付账号获取请求，以及接收第一预设终端返回的支付账号答复请求；根据支付账号答复请求中确定有身份信息关联的第二账号；若第一账号与第二账号匹配，则确定身份信息验证成功；若第一账号与第二账号不匹配，则确定身份信息验证失败。

具体地，在本实施例中，根据身份信息向第一预设终端发送支付账号获取请求，该请求可以是在第一预设终端中展示输入页面，以使用户输入与第一预设终端的身份信息关联的第二账号。在另一种优选地实施方式中，可以根据第一支付信息确定对应的支付应用程序，通过支付账号获取请求来请求调用支付应用程序，获取支付应用程序中登录或绑定的与第一预设终端的身份信息关联的第二账号。第一订单服务器通过第一预设终端返回的支付账号答复请求获取第二账号。

然后，基于目标订单对应的第一账号对第二账号进行匹配，在第一账号与第二账号匹配的情况下，确定第一预设终端发送的身份信息验证成功；否则，确定身份信息验证失败。

通过上述实施例，在目标订单没有关联的会员id的情况下，通过目标订单关联第一账号对第一预设终端的身份信息进行验证，进一步保证了对身份信息验证的准确性，避免了电子发票的窃取现象。

可选地，在本实施例中，对身份信息进行验证，还包括但不限于：在目标订单不存在关联的会员id，且目标订单不存在第一支付信息的情况下，通过目标订单关联的第三联系方式对身份信息进行验证。

具体地，在本实施例中，若目标订单不存在关联的会员id，且目标订单不存在关联的第一支付信息，判断目标订单是否存在关联的第三联系方式。若目标订单存在关联的第三联系方式，则通过第三联系方式对身份信息进行验证。验证方式可以是获取身份信息关联的联系方式，对第三联系方式以及身份信息关联的联系方式进行匹配。此外，还可以通过在第一预设终端对第三联系方式进行补全的方式，来对身份信息进行验证。需要说明的是，第三联系方式包括但不限于包括但不限于邮箱地址、固定电话号码、移动电话号码、社交账号id等。

可选地，在本实施例中，通过目标订单关联的第三联系方式对身份信息进行验证，包括但不限于：向第一预设终端发送联系方式验证请求；获取第一预设终端返回的第一组成信息；若第一组成信息与第三联系方式匹配，则确定身份信息验证成功；若第一组成信息与第三联系方式不匹配，则确定身份信息验证失败。

具体地，通过第一订单服务器向第一预设终端发送联系方式验证请求，第一预设终端在接收到联系方式验证请求后，在第一预设终端的显示界面上显示第三联系方式的部分信息，提示用户输入第三联系方式缺失的第一组成信息。例如电话号码中的尾号、邮箱地址的前缀字段、社交账号id中的部分字段等。将第一组成信息发送至第一订单服务器。第一订单服务器通过对第一组成信息与第三联系方式进行匹配，若第一组成信息与第三联系方式匹配，则确定身份信息验证成功；若第一组成信息与第三联系方式不匹配，则确定身份信息验证失败。

可选地，在本实施例中，对身份信息进行验证，还包括但不限于：在目标订单不存在关联的会员id，且目标订单不存在第一支付信息，以及目标订单不存在关联的第三联系方式的情况下，向第一预设终端发送联系方式获取请求消息；获取第一预设终端返回的联系方式答复消息，其中，联系方式答复消息中携带有第四联系方式；对第四联系方式进行验证。

具体地，在目标订单不存在与之关联的任何信息的情况下，只能够对用户开具电子发票，而在较短周期内开具大量电子发票的用户可能存在异常情况，例如非法获取他人票据窃取电子发票。因此在接收基于目标订单的票据的二维码生成的开具发票请求的情况下，获取开具发票的用户的联系方式，对联系方式进行记录，来限制开具的电子发票的数量，来筛除具有异常开具电子发票记录的用户。在一个例子中，身份信息中包括第四联系方式，用户直接获取身份信息中的第四联系方式。

在本实施例的一个优选地实施方案中，第一订单服务器通过向第一预设终端发送联系方式获取请求消息，第一预设终端在接收到联系方式获取请求消息之后，在第一预设终端上展示预设界面，用于提示用户输入第四联系方式。在用户输入完成后将携带有第四联系方式的联系方式答复消息发送至第一订单服务器，第一订单服务器根据第四联系方式的开具电子发票记录来对第四联系方式进行验证。

可选地，在本实施例中，对第四联系方式进行验证，包括但不限于：获取在预设周期内第四联系方式对应的开具发票数量；在开具发票数量大于或等于预设数量阈值的情况下，确定身份信息验证失败，拒绝为第一预设终端开具发票；在开具发票数量小于预设数量阈值的情况下，确定身份信息验证成功。

具体地，第一订单服务器获取第一预设终端的第四联系方式，在一个例子中，第四联系方式为手机号码，第一订单服务器在自身数据库中获取手机号码对应的开具电子发票记录，获取该手机号码在一天内的开具电子发票的数量，若数量大于或等于预设数量阈值的情况下，确定改手机号码存在开具发票异常情况，确定身份信息验证失败，拒绝开具发票。而在手机号码一天内开具电子发票的数量小于预设数量阈值的情况下，确定第一预设终端身份验证成功。

可选地，在本实施例中，开具发票请求是由预设客户端发送至订单系统的，其中，根据开具发票请求对身份信息进行验证，包括但不限于：获取身份信息中的登录信息；通过登录信息登录订单系统；在登录信息登录订单系统成功的情况下，确定身份信息验证成功；否则，确定身份信息验证失败。

具体地，在本实施例中，通过线上系统进行消费的用户，具体可以是通过登录信息登录消费系统进行下单，后续可以消费系统关联的订单系统中显示相应的消费记录，消费系统的登录信息同样可以登录至订单系统，在订单系统中进行身份信息的验证后进行电子发票的开具。身份信息中包括但不限于订单系统的登录信息。订单系统对身份信息中的登录信息进行校验，若登录信息登录订单系统成功，则确定身份信息验证成功；否则，确定身份信息验证失败。

可选地，在本实施例中，在身份信息验证成功的情况下，基于目标订单开具发票，包括但不限于：向预设客户端发送订单列表信息，以在预设客户端中展示身份信息对应的订单列表，其中，订单列表中包括至少一个订单；获取预设客户端返回的选择请求，其中，选择请求中包括目标订单；基于目标订单开具发票。

具体地，在登录信息登录订单系统成功的情况下，向预设客户端发送订单列表信息，以在预设客户端中展示登录账号对应的订单列表，参照图3，示出一种订单列表示意图。根据用户选取的目标订单，开具电子发票。

可选地，在本实施例中，开具发票请求是由第二预设终端基于第二预设地址信息发送至第二订单服务器的，开具发票请求中还包括目标订单，目标订单包括与之关联的第五联系方式，其中，根据开具发票请求对身份信息进行验证，包括但不限于：向第二预设终端发送联系方式验证请求；获取第二预设终端返回的第二组成信息；若第二组成信息与第五联系方式匹配，则确定身份信息验证成功；若第二组成信息与第五联系方式不匹配，则确定身份信息验证失败。

具体地，在本实施例中，在用户经过登录商家线上系统下单消费，并绑定了自己的联系方式的情况下。商家的消费系统绑定用户信息、订单以及手机号。在用户无法通过商家的订单系统开具电子发票的情况下，通过扫描二维码的方式访问对应的第二订单服务器，向第二订单服务器发送开具发票请求。通过第二订单服务器向第二预设终端发送联系方式验证请求，第二预设终端在接收到联系方式验证请求后，在第二预设终端的显示界面上显示第五联系方式的部分信息，提示用户输入第五联系方式缺失的第二组成信息。例如电话号码中的尾号、邮箱地址的前缀字段、社交账号id中的部分字段等。将第二组成信息发送至第二订单服务器。第二订单服务器通过对第二组成信息与第五联系方式进行匹配，若第二组成信息与第五联系方式匹配，则确定身份信息验证成功；若第二组成信息与第五联系方式不匹配，则确定身份信息验证失败。

通过上述实施例，接收开具发票请求，对开具发票请求中的身份信息进行验证，在身份信息验证成功的情况下，基于目标订单开具发票；以及，在身份信息验证失败的情况下，拒绝开具发票。达到了提高开具电子发票安全性的目的，从而实现了防止盗用票据来窃取电子发票的技术效果，进而解决了由于相关技术中无法解决盗用消费者的票据，来窃取消费者电子发票的技术问题。

需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明并不受所描述的动作顺序的限制，因为依据本发明，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本发明所必须的。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如rom/ram、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。

方法实施例2

在本实施例中，通过三种具体的应用场景中对方法实施例1中的防止窃取电子发票的方法进行说明。

应用场景一

如图4所示，为本实施例中应用场景一的示意图，具体可以包括以下步骤：

s41，用户登录商户订单系统，提交下单；

s42，商户后台绑定用户登录信息和订单。

针对上述应用场景一，如图5所示，为本实施例中一种用户开具电子发票的流程示意图，具体可以包括以下步骤：

s51，用户扫描票据二维码跳转或直接登录订单系统；

具体地，用户通过手机或其他移动终端中的预设应用程序，扫描票据上的二维码，获取订单系统的地址信息，将登录信息通过地址信息发送至订单系统，订单系统登录成功的情况下，在用户的手机或其他移动终端中展示订单系统的跳转过程。在登录不成功的情况下，跳转至s55。

s52，展示用户的所有线上订单；

具体地，通过线上订单系统查询用户对应的订单，并在用户的手机或其他移动终端中进行展示。

s53，用户选择相应的订单填写发票抬头等信息；

s54，线上系统开具电子发票。

s55，提示用户登录失败。

应用场景二

如图6所示，为本实施例中应用场景二的示意图，具体可以包括以下步骤：

s61，用户下单并付款；

s62，判断用户是否会员下单；

具体地，判断订单是否绑定了会员id，若是，则跳转至s63；若否，则跳转至s64。

s63，绑定会员id和订单；

具体地，绑定会员id和订单，并保存订单；

s64，获取用户的支付方式；

具体地，若用户采用了非现金的支付方式，则跳转至s65；若获取不到用户的支付方式，或用户采取了现金的支付方式，跳转至s66。

s65，绑定支付账号以及订单；

具体地，绑定支付账号以及订单，并保存订单；

s66，判断用户是否提供手机号；

具体地，若是，则跳转至步骤s67；若否，则跳转至s68。

s67，绑定手机号以及订单；

具体地，绑定手机号以及订单，并保存订单

s68，保存订单。

针对上述应用场景二，如图7所示，为本实施例中一种用户开具电子发票的流程示意图，具体可以包括以下步骤：

s701，用户扫描二维码开具发票；

具体地，用户通过终端中的预设应用程序扫描票据上的二维码，基于二维码中的地址信息以及目标订单的订单编号生成开具发票请求，向订单服务器发送开具发票请求。

s702，跳转至开票系统；

s703，判断目标订单是否绑定了会员。

具体地，判断目标订单是否绑定了会员id，若是，则跳转至s7031，若否，则跳转至s704。

s7031，获取终端中预设应用程序当前登录的账号的用户id；

s7032，判断用户id是否与会员id匹配；

具体地，若匹配，跳转至s7033；若不匹配，则跳转至s7034。

s7033，提示用户输入手机号后四位；

具体地，在用户id与会员id不匹配的情况下，终端中展示目标订单关联的手机号的前7位数字，提示用户输入手机号后四位。

s7034，判断手机号后四位能否匹配目标订单绑定的会员；

具体地，若匹配，则跳转至s708；若不匹配，则跳转至s709。

s704，判断目标订单是否存在绑定的支付方式；

具体地，判断目标订单是否存在绑定的支付账号，若是，跳转至s7041，若否，则跳转至s705。

s7041，获取目标订单绑定的支付账号以及用户的支付账号；

具体地，获取用户的支付账号可以通过支付应用程序获取支付账号，或在预设终端上提示用户输入支付账号来获取用户的支付账号。

s7042，判断目标订单绑定的支付账号以及用户的支付账号是否匹配；

具体地，若匹配，则跳转至s708；若不匹配，则跳转至s709。

s705，判断目标订单是否存在绑定的手机号；

具体地，若是，则跳转至s7051，若否，则跳转至s706。

s7051，提示用户输入手机号后四位；

具体地，在终端上展示手机号的前七位数字，以及提示用户输入手机号后四位数字。

s7052，判断用户输入的手机号与目标订单绑定的手机号匹配；

具体地，若匹配，则跳转至s708；若不匹配，则跳转至s709。

s706，引导用户输入手机号，并进行验证码验证；

具体地，若验证失败，则拒绝开具发票；若验证成功，则跳转至s707。

s707，判断当天手机号开具发票是否小于预设次数；

若是，则跳转至s708，若否，则跳转至s709。

s708，根据目标订单开具电子发票；

s709，拒绝开具电子发票。

应用场景三

如图8所示，为本实施例中应用场景三的示意图，具体可以包括以下步骤：

s81，用户登录商家订单系统下单，并填写手机号；

s82，商户后台绑定用户登录信息、订单以及手机号；

具体地，商户后台绑定订单和手机号、订单和用户登录信息。

针对上述应用场景三，如图9所示，为本实施例中一种用户开具电子发票的流程示意图，具体可以包括以下步骤：

s90，用户根据商家订单系统提示判断商户能否支持线上开具发票；

具体地，若支持，则执行s910；若不支持，则执行s920。

s910，用户登录订单系统；

具体地，向订单系统发送开具发票请求，开具发票请求中的身份信息中包括登录账号及密码。

s911，查询并展示用户的所有订单；

具体地，通过订单系统查询用户对应的订单，并在用户的手机或其他移动终端中进行展示。

s912，用户选择相应的订单填写发票抬头等信息；

s913，订单系统开具电子发票。

s914，提示用户登录失败。

s920，用户扫描二维码跳转至商户订单系统；

具体地，用户通过终端中的预设应用程序扫描票据上的二维码，基于二维码中的地址信息以及目标订单的订单编号生成开具发票请求，向订单系统发送开具发票请求。

s921，提示用户输入手机号后四位，并判断用户输入的手机号与目标订单绑定的手机号匹配；

具体地，在终端上展示手机号的前七位数字，以及提示用户输入手机号后四位数字。判断用户输入的手机号与目标订单绑定的手机号匹配，若匹配，则跳转至s922；若不匹配，则跳转至s923。

s922，根据目标订单开具电子发票；

s923，拒绝开具电子发票。

综上所述，通过上述三个应用场景各自的发票开具的具体实施过程，本实施例中，接收开具发票请求，对开具发票请求中的身份信息进行验证，在身份信息验证成功的情况下，基于目标订单开具发票；以及，在身份信息验证失败的情况下，拒绝开具发票。达到了提高开具电子发票安全性的目的，从而实现了防止盗用票据来窃取电子发票的技术效果，进而解决了由于相关技术中无法解决盗用消费者的票据，来窃取消费者电子发票的技术问题。

装置实施例

根据本发明实施例，还提供了一种用于实施上述防止窃取电子发票方法的防止窃取电子装置，如图10所示，该装置包括：

1)接收单元1000，用于接收开具发票请求，其中，所述开具发票请求中携带有身份信息；

2)验证单元1002，用于对所述身份信息进行验证；

3)处理单元1004，用于在所述身份信息验证成功的情况下，基于目标订单开具发票；以及，还用于在所述身份信息验证失败的情况下，拒绝开具发票。

可选地，本实施例中的具体示例可以参考上述实施例1和实施例2中所描述的示例，本实施例在此不再赘述。

根据本申请实施例的另一个方面，提出了一种电子设备，包括处理器1110，存储器1109，存储在存储器1109上并可在所述处理器1110上运行的程序或指令，该程序或指令被处理器1110执行时实现上述图像校准方法的方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。

需要注意的是，本申请实施例中的电子设备包括上述所述的移动电子设备和非移动电子设备。

图11为实现本申请实施例的一种电子设备的硬件结构示意图。

该电子设备1100包括但不限于：射频单元1101、网络模块1102、音频输出单元1103、输入单元1104、传感器1105、显示单元1106、用户输入单元1107、接口单元1108、存储器1109、以及处理器1110等部件。

本领域技术人员可以理解，电子设备1100还可以包括给各个部件供电的电源(比如电池)，电源可以通过电源管理系统与处理器1110逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。图11中示出的电子设备结构并不构成对电子设备的限定，电子设备可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置，在此不再赘述。

根据本申请实施例的另一个方面还提供一种可读存储介质，所述可读存储介质上存储有程序或指令，该程序或指令被处理器执行时实现上述图像校准方法的方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。

其中，所述处理器为上述实施例中所述的电子设备中的处理器。所述可读存储介质，包括计算机可读存储介质，如计算机只读存储器(read-onlymemory，rom)、随机存取存储器(randomaccessmemory，ram)、磁碟或者光盘等。

上述实施例中的集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在上述计算机可读取的存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在存储介质中，包括若干指令用以使得一台或多台计算机设备(可为个人计算机、服务器或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。

在本发明的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

在本申请所提供的几个实施例中，应该理解到，所揭露的客户端，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。