一种医保支付方法、装置及设备与流程

1.本申请涉及互联网技术领域，尤其涉及一种医保支付方法、装置及设备。


背景技术：

2.医保支付是基本医保管理和深化医改的重要环节，是调节医疗服务行为、引导医疗资源配置的重要杠杆。作为第三方支付，医保支起了公众健康和产业利益的天平，不求端平，但权衡观和系统观成为发展的关键。随着医疗科技的发展、人民经济水平的提高以及参保人员安全、健康意识的增强，医疗费用不断攀升，使用医保支付医疗费用的情况也越来越多。
3.随着互联网技术的飞速发展，手机支付在生活中占据着重要的地位。为了进一步方便人们进行医保支付，将医保支付转移到线上，用户无需携带医保电子凭证到店进行医保刷卡支付，直接使用手机就能完成医保支付。
4.基于此，需要提供一种更为可靠的医保支付方法。


技术实现要素：

5.本说明书实施例提供一种医保支付方法、装置及设备，以解决现有的医保支付方法存在的医保支付效率低的问题。
6.为解决上述技术问题，本说明书实施例是这样实现的：
7.本说明书实施例提供的一种医保支付方法，包括：
8.第一平台获取第二平台针对目标订单发起的医保支付请求；所述医保支付请求中至少包括所述目标订单对应的用户标识；
9.确定所述用户标识对应的医保电子凭证的状态信息；所述状态信息用于表示所述医保电子凭证的激活状态；
10.当所述状态信息表示所述医保电子凭证属于未激活状态时，生成提示信息；所述提示信息用于提示所述用户授权所述第一平台激活所述医保电子凭证；
11.将所述提示信息通过所述第二平台发送至用户终端进行显示。
12.本说明书实施例提供的一种医保支付方法，包括：
13.第二平台接收用户针对目标订单的支付方式进行选择的操作信息；
14.当所述操作信息表示用户选择的针对目标订单的支付方式为医保支付时，向第一平台发送对于所述目标订单的医保支付请求；所述医保支付请求中至少包括所述目标订单对应的用户标识；
15.接收所述第一平台生成的提示信息；所述提示信息用于提示所述用户授权所述第一平台激活所述医保电子凭证；
16.将所述提示信息发送至所述用户的终端进行显示。
17.本说明书实施例提供的一种医保支付装置，包括：
18.医保支付请求发起模块，用于第一平台获取第二平台针对目标订单发起的医保支
付请求；所述医保支付请求中至少包括所述目标订单对应的用户标识；
19.医保电子凭证状态信息确定模块，用于确定所述用户标识对应的医保电子凭证的状态信息；所述状态信息用于表示所述医保电子凭证的激活状态；
20.提示信息生成模块，用于当所述状态信息表示所述医保电子凭证属于未激活状态时，生成提示信息；所述提示信息用于提示所述用户授权所述第一平台激活所述医保电子凭证；
21.提示信息显示模块，用于将所述提示信息通过所述第二平台发送至用户终端进行显示。
22.本说明书实施例提供的一种医保支付装置，包括：
23.操作信息接收模块，用于第二平台接收用户针对目标订单的支付方式进行选择的操作信息；
24.医保支付请求发送模块，用于当所述操作信息表示用户选择的针对目标订单的支付方式为医保支付时，向第一平台发送对于所述目标订单的医保支付请求；所述医保支付请求中至少包括所述目标订单对应的用户标识；
25.提示信息接收模块，用于接收所述第一平台生成的提示信息；所述提示信息用于提示所述用户授权所述第一平台激活所述医保电子凭证；
26.提示信息发送模块，用于将所述提示信息发送至所述用户的终端进行显示。
27.本说明书实施例提供的一种医保支付设备，包括：
28.至少一个处理器；以及，
29.与所述至少一个处理器通信连接的存储器；其中，
30.所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够：
31.第一平台获取第二平台针对目标订单发起的医保支付请求；所述医保支付请求中至少包括所述目标订单对应的用户标识；
32.确定所述用户标识对应的医保电子凭证的状态信息；所述状态信息用于表示所述医保电子凭证的激活状态；
33.当所述状态信息表示所述医保电子凭证属于未激活状态时，生成提示信息；所述提示信息用于提示所述用户授权所述第一平台激活所述医保电子凭证；
34.将所述提示信息通过所述第二平台发送至用户终端进行显示。
35.本说明书实施例提供的一种医保支付设备，包括：
36.至少一个处理器；以及，
37.与所述至少一个处理器通信连接的存储器；其中，
38.所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够：
39.第二平台接收用户针对目标订单的支付方式进行选择的操作信息；
40.当所述操作信息表示用户选择的针对目标订单的支付方式为医保支付时，向第一平台发送对于所述目标订单的医保支付请求；所述医保支付请求中至少包括所述目标订单对应的用户标识；
41.接收所述第一平台生成的提示信息；所述提示信息用于提示所述用户授权所述第
一平台激活所述医保电子凭证；
42.将所述提示信息发送至所述用户的终端进行显示。
43.本说明书实施例提供的一种计算机可读介质，其上存储有计算机可读指令，所述计算机可读指令可被处理器执行以实现一种医保支付方法。
44.本说明书一个实施例能够达到以下有益效果：通过第一平台获取第二平台针对目标订单发起的医保支付请求，确定所述用户标识对应的医保电子凭证的状态信息，所述状态信息用于表示所述医保电子凭证的激活状态，当所述状态信息表示所述医保电子凭证属于未激活状态时，生成提示信息，将所述提示信息通过所述第二平台发送至用户终端进行显示。上述方法中，第二平台在接收到用户的医保支付请求时，向第一平台发送医保支付请求，由第一平台基于医保支付请求判断用户是否具有医保电子凭证以及用户具有的医保电子凭证是否激活，之后也是由第一平台引导用户完成医保电子凭证的激活以及后续的支付，在第一平台上展示支付前置组件，组件里展示用户业务前置的相关授权内容，用户同意后可以直接完成前置业务的办理，极大程度优化了用户使用支付服务的链路和体验。从而减少用户理解成本，提高用户操作效率，减少跳转及整个链路的用户流失。
附图说明
45.为了更清楚地说明本说明书实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
46.图1为现有的医保支付过程中绑定医保电子凭证的过程示意图；
47.图2为本说明书实施例提供的一种医保支付方法的场景交互示意图；
48.图3为本说明书实施例提供的第一平台侧的医保支付方法的流程示意图；
49.图4为本说明书实施例提供的医保支付流程的界面示意图；
50.图5为本说明书实施例提供的第二平台侧的医保支付方法的流程示意图；
51.图6是本说明书实施例提供的第一平台侧的医保支付装置示意图；
52.图7是本说明书实施例提供的第二平台侧的医保支付装置示意图；
53.图8是本说明书实施例提供的一种医保支付设备示意图。
具体实施方式
54.为使本说明书一个或多个实施例的目的、技术方案和优点更加清楚，下面将结合本说明书具体实施例及相应的附图对本说明书一个或多个实施例的技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本说明书的一部分实施例，而不是全部的实施例。基于本说明书中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本说明书一个或多个实施例保护的范围。
55.医保电子凭证也称医疗保险卡，是含有芯片的功能卡，用于就医或药店消费时身份确认及医保个人账户支付用。它以个人身份证为识别码，储存记载着个人身份证号码、姓名以及消费情况等详细资料信息。
56.随着社会经济的发展，医保支付从传统的由用户携带医保电子凭证进行刷卡支付
发展到线上医保支付，用户无需再携带医保电子凭证，使用绑定有医保电子凭证的手机终端即可完成医保支付。
57.医保电子凭证，可以表示由国家医保局信息平台统一签发，基于医保基础信息库为全体参保人员生成的医保身份识别电子介质。医保电子凭证通过实名/实人认证技术，采用加密算法形成电子标识，具备安全可靠、认证唯一等重要特点。参保人可通过电子凭证享受各类在线医疗保障服务，包括医保业务办理、医保账户查询、医保就诊和购药支付等。
58.医保电子凭证具有身份凭证、信息记录、自助查询、医保结算、缴费及待遇领取、办理医保业务等功能，确保群众能够在互联网上高效、安全地享受医疗保障部门的各项公共服务。参保人可通过国家医保服务app，或者通过其他经由国家医保局认证授权的第三方平台激活使用。
59.线上支付场景主要包含线上购药医保支付和医院小程序医保支付。在支付场景中，有很多特定支付服务需要有前置依赖，比如：线上医保支付。线上医保支付需要用户在手机具有支付功能的应用程序中提前绑定医保电子凭证，比如社保线上缴费需要用户绑定电子社保卡等，而这些前置业务在业务场景上需要在支付前先单独引导用户进行医保电子凭证等服务的绑定。
60.在具有支付功能的应用程序中绑定医保电子凭证时，用户在理解支付平台功能的基础上，还需要理解绑定医保电子凭证流程，并且单独完成绑卡行为。
61.图1为现有的医保支付过程中绑定医保电子凭证的过程示意图。整个过程中涉及的平台有购药平台以及支付平台。
62.如图1所示，整个采用医保支付完成对药品进行结算的过程，需要用户进行操作的过程分为五个操作界面，可以分别是预支付界面101、医保绑定引导界面103、身份验证界面105、支付核对界面107以及密码输入界面109。其中，预支付界面101中，包括用户选择购买的药品信息、金额信息、用户地址信息、支付方式信息、协议信息以及同意支付的确认信息。
63.用户点击预支付界面101中的“立即支付”的按钮时，支付平台先判断该用户是否具有医保支付的条件(用户具有医保电子凭证并且激活了医保电子凭证)；若用户目前不具备医保支付的条件，为用户显示医保绑定引导界面103，医保绑定引导界面103中可以包括提示用户授权激活医保电子凭证的确认信息(如图中的“同意协议并领取”)，还可以包括激活医保电子凭证对应的医保电子凭证相关协议等信息。
64.当用户点击医保绑定引导界面103中的“同意协议并领取”的按钮时，为用户显示身份验证界面105，在身份验证界面105中，会显示用户的姓名缩写以及证件号码缩写，并提示用户进行人脸拍摄，用户点击“采集本人人脸”即可完成拍摄。
65.但是，在完成身份验证之后，还需要重新跳转至预支付界面中，在预支付界面中拉起支付收银台，即对应支付核对界面107，支付核对界面107中可以包括支付账号以及付款方式，用户核对完成点击该界面中的“立即支付”，跳转到密码输入界面109中，输入密码完成支付。
66.上述整个过程中，用户需要两次跳转到支付平台，即如果医保电子凭证未绑定，用户需要退出当前支付操作，跳转到绑定医保电子凭证的界面中按照提示完成医保电子凭证的绑定。然后再返回支付界面中，使用医保支付方式完成订单支付。例如：支付平台与购药平台合作线上购药医保支付结算业务。按照国家医保机构和地方医保机构等机构要求，用
户在购药平台上发起医保结算必须先到支付平台激活医保电子凭证。因此，用户在购药平台中购买药品进行支付时，购药平台需先引导用户完成医保电子凭证激活，否则用户无法发起医保支付。购药平台需要额外理解医保电子凭证的业务逻辑，对接成本较高；而对于用户来说，用户需要从购物平台多次跳转到支付平台进行绑卡以及完成支付，导致用户体验不好。
67.因此，本说明书实施例中提供了一种更为可靠的医保支付方法，以简化业务链路，将绑卡的业务前置结合到支付平台的支付动作中，从而减少用户理解成本，提高用户绑卡的操作效率，减少跳转及整个链路导致的用户流失。
68.以下结合附图，详细说明本说明书各实施例提供的技术方案。
69.接下来，将针对说明书实施例提供的一种医保支付方法结合附图进行具体说明：
70.图2为本说明书实施例提供的一种医保支付方法的场景交互示意图。
71.如图2所示，医保支付场景中涉及的对象有：用户201、购药平台203、线上或线下药店205、支付平台207以及医保机构209。其中，线上或线下药店205平台203中与购药平台203具有合作关系，线上或者线下药店205可以入驻购药平台203，具体地，各药店可以签署入驻协议，并将商家信息提交到购药平台203，经购药平台203审核药店资质通过后，同意药店入驻。用户201可以在购药平台203中选购已入驻的各药店的药品，需要进行医保支付时，由购药平台203向支付平台207发起医保支付请求，并拉起支付平台的收银台，支付平台207判断用户201的医保电子凭证的状态信息，若用户201未激活医保电子凭证，则支付平台207调用医保行业激活服务，提示用户完成人脸验证，通过后完成医保电子凭证的快捷激活。已激活医保电子凭证的用户201由支付平台207向医保机构209发起医保结算业务。然后支付平台207将结算结果返回给购药平台203，购药平台203基于结算结果安排相应的药店完成医保药品的配送服务。
72.其中，收银台可以指商户调用支付应用程序的收单支付产品时在用户端拉起的收银台，收银台会展示具体收银金额、付款方式和支付账户，用户确认支付后验证用户身份可完成支付。
73.实施例1
74.图3为本说明书实施例提供的第一平台侧的医保支付方法的流程示意图。从程序角度而言，流程的执行主体可以为搭载于应用服务器的程序或应用客户端。在该实施例中，涉及的交互对象可以包括用户、第一平台、第二平台以及医保机构。其中，第一平台可以是具有支付功能的平台。第二平台可以是外卖生活平台、购物平台或其他能够购买药品或使用医保支付购买物品的平台。在本实施例中，执行主体可以是具有支付功能的平台。
75.如图3所示，该流程可以包括以下步骤：
76.步骤310：第一平台获取第二平台针对目标订单发起的医保支付请求；所述医保支付请求中至少包括所述目标订单对应的用户标识。
77.以购买药品为例，目标订单可以表示用户在第二平台上选择购买的药品进行支付对应的订单。
78.用户在第二平台中选择“医保支付”的支付方式，第二平台在接收到用户选择“医保支付”的支付方式。但是在支付时，购物平台需要向支付平台发送订单信息，由支付平台完成支付。因此，在用户选择了医保支付方式并且点击支付按钮时，购物平台可以向支付平
台发送医保支付请求。该医保支付请求可以表示请求支付平台采用医保支付的方式对该目标订单完成支付。具体地，购物平台向支付平台发送的医保支付请求中至少可以包括目标订单对应的用户标识。
79.需要说明的是，用户标识信息可以表示用于唯一标识用户身份的信息，例如：用户标识信息可以是用户id。其中，用户id可以是用户在支付平台注册的账号，或者是用户在购物平台发起支付请求时由购物平台的系统为该用户分配的账号。这类账号例如可以是一串字符。用户id应当可以唯一的标识一位用户。对于个人用户来说，如果证件类型统一采用身份证的话，用户id也可以是身份证号码。
80.步骤320：确定所述用户标识对应的医保电子凭证的状态信息；所述状态信息用于表示所述医保电子凭证的激活状态。
81.状态信息可以表示医保电子凭证是否被激活，具体地，医保电子凭证的状态信息可以包括激活状态以及未激活状态。
82.步骤330：当所述状态信息表示所述医保电子凭证属于未激活状态时，生成提示信息；所述提示信息用于提示所述用户授权所述第一平台激活所述医保电子凭证。
83.当支付平台检测到目标订单对应的用户的医保电子凭证未激活时，需要引导用户完成电子医保凭证的激活。
84.提示信息可以是支付平台的系统生成的，而提示信息的展示可以在用户终端上进行展示。第一提示信息中可以包括付款方式、付款金额、“开通电子医保电子凭证”的选项按钮以及授权激活医保电子凭证的授权按钮。其中，当检测到用户未激活电子医保凭证时，“开通电子医保电子凭证”的选项按钮自动打开。
85.步骤340：将所述提示信息通过所述第二平台发送至用户终端进行显示。
86.提示信息的生成是由支付平台完成的，而提示信息的显示是由用户的手机终端进行显示，因此，支付平台可以将生成的提示信息发送至用户终端，由用户终端对提示信息进行展示。
87.应当理解，本说明书一个或多个实施例所述的方法其中部分步骤的顺序可以根据实际需要相互交换，或者其中的部分步骤也可以省略或删除。
88.图3中的方法，通过第一平台获取第二平台针对目标订单发起的医保支付请求，确定所述用户标识对应的医保电子凭证的状态信息，所述状态信息用于表示所述医保电子凭证的激活状态，当所述状态信息表示所述医保电子凭证属于未激活状态时，生成提示信息，将所述提示信息通过所述第二平台发送至用户终端进行显示。上述方法中，第二平台在接收到用户的医保支付请求时，向第一平台发送医保支付请求，由第一平台基于医保支付请求判断用户是否具有医保电子凭证以及用户具有的医保电子凭证是否激活，之后也是由第一平台引导用户完成医保电子凭证的激活以及后续的支付，在第一平台上展示支付前置组件，组件里展示用户业务前置的相关授权内容，用户同意后可以直接完成前置业务的办理，极大程度优化了用户使用支付服务的链路和体验。从而减少用户理解成本，提高用户操作效率，减少跳转及整个链路的用户流失。
89.其中，支付前置组件可以表示用于激活医保电子凭证的组件。
90.基于图3的方法，本说明书实施例还提供了该方法的一些具体实施方案，下面进行说明。
91.可选的，所述将所述提示信息通过所述第二平台发送至用户终端进行显示之后，还可以包括：
92.接收用户对于所述提示信息的确认操作信息；
93.基于所述确认操作信息激活所述医保电子凭证；
94.基于所述医保电子凭证，完成医保支付。
95.需要说明的是，用户在终端界面中授权开通电子医保凭证之后，支付平台激活用户标识对应的医保电子凭证，激活后，基于已激活的医保电子凭证完成支付。
96.进一步地，所述基于所述确认操作信息激活所述医保电子凭证，具体可以包括：
97.基于所述确认操作信息，对所述用户进行身份核验，得到核验结果；
98.当所述核验结果表示所述用户的身份核验通过时，激活所述用户的医保电子凭证。
99.具体地，在激活用户的电子医保凭证时，处于安全性的考虑，需要对用户进行身份核验，身份核验成功后，即可完成用户的电子医保凭证的激活。
100.需要说明的是，医保可以划分为城镇职工基本医疗保险、新农合医疗保险、城镇居民基本医疗保险以及离休干部医疗保险。对应的。医保电子凭证也有多种类型。因此，在激活用户的电子医保凭证时，可以先基于目标订单对应的用户标识，从区块链网络中查询该用户标识对应的医保电子凭证的类型；然后支付平台再基于医保电子凭证的类型，激活用户对应的医保电子凭证。例如：用户a对应新农合医疗保险，那么，在激活时，智能激活用户a的新农合医疗保险对应的医保电子凭证。
101.可选的，所述基于所述确认操作信息，对所述用户进行身份核验，得到核验结果，具体可以包括：
102.采集所述用户的生物特征信息；
103.基于所述生物特征信息与区块链网络中预先存储的生物特征信息进行匹配，得到匹配结果；所述区块链网络中存储有所述用户标识与生物特征信息之间的对应关系；
104.当所述匹配结果表示所述生物特征信息与所述区块链网络中预先存储的生物特征信息一致时，确定所述用户的身份核验通过。
105.在进行身份核验时，可以基于用户的生物特征信息进行核验。需要说明的是，生物特征可以包括用户的身体特征，如指纹、静脉、掌型、视网膜、虹膜、人脸等信息。用户在第一平台中注册账户时，可以预先录入生物特征信息，以完成身份认证。在后续过程中，第一平台需要核验用户的身份时，可以采集用户的生物特征信息，与预先存储的生物特征信息进行比对，一致则可以确定用户的身份验证通过，不一致则确定用户的身份验证不通过。
106.而用户在第一平台中预先录入的生物特征信息以及用户的身份认证信息可以保存在区块链网络中，具体在保存时，可以将用户标识与用户的生物特征信息之间的映射关系进行存储。
107.上述步骤中，将用户标识与生物特征信息之间的对应关系存储在区块链网络中，应用了区块链网络的技术，以保证存储信息的安全性。
108.区块链网络(block chain network)，是利用块链式数据结构来验证与存储数据、利用分布式节点共识算法来生成和更新数据、利用密码学的方式保证数据传输和访问的安全、利用由自动化脚本代码组成的智能合约来编程和操作数据的一种全新的分布式基础架
构与计算方式。区块链网络是由多个节点组成的，每个节点向区块链网络广播信息或者区块时，所有节点都能接收到，并对接收到的区块进行验证。在对该区块验证通过的节点数在整个区块链网络总节点数中的占比大于预设阈值时，则确定为区块链网络对该区块验证通过，所有节点接收该区块并存储在本地的节点空间中。节点可以理解为是服务器、终端等具有存储功能的电子设备。其中，区块链网络主要分为公有链、联盟链和私有链。
109.区块链(block chain)，可以理解为是多个区块顺序存储构成的数据链，每个区块的区块头都包含有本区块的时间戳、前一个区块信息的哈希值和本区块信息的哈希值，由此实现区块与区块之间的相互验证，构成不可篡改的区块链。每个区块都可以理解为是一个数据块(存储数据的单元)。区块链作为一种去中心化的数据库，是一串使用密码学方法相互关联产生的数据块，每一个数据块中包含了一次网络交易的信息，用于验证其信息的有效性(防伪)和生成下一个区块。区块与区块首尾相连形成的链，即为区块链。若需要修改块内数据，则需要修改此区块之后所有区块的内容，并将区块链网络中所有节点备份的数据进行修改。因此，区块链具有难以篡改、删除的特点，在数据已保存至区块链后，其作为一种保持内容完整性的方法具有可靠性。
110.区块链技术主要具有去中心化、不可篡改性、公开透明与可溯源性、集体维护性等性质。区块链核心关键技术主要涉及到以下几个方面：
111.(1)共识机制：由于区块链网络中没有一个中心，因此需要有一个预设的规则来指导各方节点在数据处理上达成一致，所有的数据交互都要按照严格的规则和共识进行。
112.(2)密码学技术：密码学技术是区块链的核心技术之一，目前的区块链应用中采用了很多现代密码学的经典算法，主要包括：哈希算法、对称加密、非对称加密、数字签名等。
113.(3)分布式存储：区块链是一种点对点网络上的分布账本，每个参与的节点都将独立完整地存储写入区块数据信息。分布式存储区别于传统中心化存储的优势主要体现在两个方面：一、每个节点上备份数据信息，避免了由于单点故障导致的数据丢失。二、每个节点上的数据都独立存储，可以有效规避他人恶意篡改历史数据。
114.(4)智能合约：智能合约允许在没有第三方的情况下进行可信交易，只要一方达成了协议预先设定的目标，合约将会自动执行交易。这些交易可追踪且不可逆转。智能合约具有透明可信、自动执行、强制履约的优点。
115.基于区块链的性质以及核心技术，将用户标识与生物特征信息的对应关系存储到区块链网络中，可以基于支付平台与区块链网络之间的交互，利用区块链的性质，保证用户数据的安全性。除此之外，用户的医保电子凭证的状态信息也可以存储在区块链网络中，具体地，所述激活所述用户的医保电子凭证之后，还可以包括：
116.将所述医保电子凭证的激活状态信息发送至所述区块链网络中，以供所述区块链网络更新所述医保电子凭证的状态信息。
117.随着支付平台的用户日益增多，支付平台的数据库存储的数据量越来越大，从而加重了支付平台中服务器的运行压力，因此，为了减少支付平台的存储压力，也为了用户数据安全性，可以将用户数据存储到区块链网络中，支付平台与区块链网络之间可以具有交互。支付平台在激活医保电子凭证之后，可以将原本的未激活状态修改为激活状态，并将对应的医保电子凭证的状态信息上传至区块链网络中进行存储。
118.可选的，所述区块链网络中还可以存储有用户标识与医保电子凭证标识之间的映
射关系；
119.所述确定所述用户标识对应的医保电子凭证的状态信息，具体可以包括：
120.从所述区块链网络中确定所述用户标识对应的医保电子凭证标识；
121.从所述区块链网络中确定所述医保电子凭证标识对应的状态信息。
122.所述提示信息至少包括激活界面；所述激活界面中包含处于开启状态的激活按钮。
123.通过上述方法，通过从区块链中获取医保电子凭证的状态信息，可以保证获取的状态信息的真实有效性。以便支付平台更为准确地基于其医保电子凭证的状态信息，确定是否需要激活用户的医保电子凭证。
124.所述提示信息至少可以包括激活界面；所述激活界面中包含处于开启状态的激活按钮。激活界面可以指的是引导用户进行医保电子凭证激活的界面。
125.可选的，所述基于所述医保电子凭证，完成医保支付，具体可以包括：
126.基于所述医保电子凭证，向医保机构发送医保结算请求；所述医保结算请求中至少包括用户标识、医保电子凭证信息以及金额信息。
127.可选的，所述向医保机构发送医保结算请求之后，还可以包括：
128.接收所述医保机构返回的结算结果；
129.将所述结算结果发送给所述第二平台。
130.需要说明的是，在需要进行医保支付时，医疗机构(如医院或药店)或者可以售卖药品的购药平台通过线上医保支付的方式将参保人信息和消费信息发送给医保管理机构(如：医保局)，医保管理机构根据获取的信息确定医保可以报销的金额，并进行结算，计算完成后，将结算结果告知医疗机构或购药平台。
131.可选的，所述基于所述医保电子凭证，完成医保支付之前，还可以包括：
132.接收所述用户在密码输入界面中输入的密码指令；
133.从区块链网络中获取预先存储的所述医保电子凭证对应的密码信息；
134.将所述用户输入的所述密码指令与所述密码信息进行比对；
135.当所述用户输入的密码指令与所述密码信息一致时，基于所述医保电子凭证完成支付。
136.区块链网络中预先存储有各个医保电子凭证对应的密码信息。在对于用户的目标订单进行医保支付时，可以基于用户标识，从区块链网络中获得该用户标识对应的医保电子凭证，以及该医保电子凭证对应的支付密码。
137.在支付时，要求用户输入支付密码，以进一步核对用户的身份信息，核对一致后，完成针对目标订单的支付。
138.通过上述方法，可以避免医保电子凭证被盗刷的风险。
139.为例更好地解释实施例1中的方法步骤，可以结合图3作进一步说明：
140.图4为本说明书实施例提供的医保支付流程的界面示意图。
141.如图4所示，本说明书实施例提供的医保支付流程界面图中可以对应四个界面：预支付界面401、医保激活引导界面403、身份核验界面405以及密码输入界面407。其中，预支付界面401可以包括用户选择购买的药品信息、金额信息、用户地址信息、支付方式信息、协议信息以及同意支付的确认信息。在预支付界面401中直接调用支付平台的收银台，支付平
台收银台中可以包括用户的支付账号、付款方式、医保凭证相关协议以及“开通电子医保凭证”的功能按钮，同样的，该功能按钮在用户未激活以医保电子凭证的情况下，自动开启。当用户已激活医保电子凭证时，该功能按钮以及医保电子凭证相关协议均不会显示。
142.身份核验界面405中可以包括用于采集用户人脸信息的人脸采集区域409，用户将人脸移动到该采集区域中，按照提示信息，做出指定动作，例如：眨眨眼。密码输入界面407中，可以包括供用户点击的数字键盘区域411以及供用户输入的密码输入区域413，用户通过点击数字键盘区域411中的相应数字，完成密码输入。支付平台基于用户输入的密码，与预存信息进行核对，核对成功后，完成医保支付。
143.上述实施例1中的方法，通过支付平台发起支付的用户，若支付场景有相关业务前置，针对无满足业务前置的用户，将支付平台中的收银台和业务前置服务进行整合，即在收银台上展示支付前置组件，组件里展示用户业务前置的相关授权内容，用户同意后可以直接完成前置业务的办理，极大程度优化了用户使用支付服务的链路和体验，减少了用户因前值业务办理造成的用户流程。
144.实施例2
145.图5为本说明书实施例提供的第二平台侧的医保支付方法的流程示意图。从程序角度而言，流程的执行主体可以为搭载于应用服务器的程序或应用客户端。在该实施例中，涉及的交互对象可以包括用户、第一平台、第二平台以及医保机构。其中，第一平台可以是具有支付功能的平台。第二平台可以是外卖生活平台、购物平台或其他能够购买药品或使用医保支付购买物品的平台。在本实施例中，执行主体可以是具有支付功能的平台。
146.如图5所示，该流程可以包括以下步骤：
147.步骤510：第二平台接收用户针对目标订单的支付方式进行选择的操作信息。
148.以购药平台作为第二平台为例，进行后续实施例的说明：用户基于购药平台选择需要购买的药品，然后在购药平台的界面中选择“医保支付”的支付方式。
149.步骤520：当所述操作信息表示用户选择的针对目标订单的支付方式为医保支付时，向第一平台发送对于所述目标订单的医保支付请求；所述医保支付请求中至少包括所述目标订单对应的用户标识。
150.步骤530：接收所述第一平台生成的提示信息；所述提示信息用于提示所述用户授权所述第一平台激活所述医保电子凭证。
151.步骤540：将所述提示信息发送至所述用户的终端进行显示。
152.图5中描述的方法流程与图3中描述的方法流程具有对应关系。上述步骤中，与图3中的方法的内容相同或相应的部分，在此不再重复解释。
153.通过上述方法，将收银台与支付前置的业务进行融合，在收银台拉起时，除了展示具体收银金额、付款方式和支付账户时，同时展示授权绑卡等前置业务，用户在确认支付的同时，完成前置的绑卡动作。购药平台仅需对接支付平台“医保支付”这个服务，当用户正常在购药平台发起医保支付结算时，由支付平台判断用户医保电子凭证激活状态，并引导未激活用户激活并完成医保结算业务。减小购药平台对接成本同时优化用户侧支付体验，提高用户操作效率，减少跳转及整个链路的用户流失。
154.基于同样的思路，本说明书实施例还提供了上述实施例1中的方法对应的装置。图6是本说明书实施例提供的第一平台侧的医保支付装置示意图。如图6所示，该装置可以包
括：
155.医保支付请求发起模块610，用于第一平台获取第二平台针对目标订单发起的医保支付请求；所述医保支付请求中至少包括所述目标订单对应的用户标识；
156.医保电子凭证状态信息确定模块620，用于确定所述用户标识对应的医保电子凭证的状态信息；所述状态信息用于表示所述医保电子凭证的激活状态；
157.提示信息生成模块630，用于当所述状态信息表示所述医保电子凭证属于未激活状态时，生成提示信息；所述提示信息用于提示所述用户授权所述第一平台激活所述医保电子凭证；
158.提示信息显示模块640，用于将所述提示信息通过所述第二平台发送至用户终端进行显示。
159.基于图6的装置，本说明书实施例还提供了该装置的一些具体实施方案，下面进行说明。
160.可选的，所述装置，还可以包括：
161.确认操作信息接收模块，用于接收用户对于所述提示信息的确认操作信息；
162.医保电子凭证激活模块，用于基于所述确认操作信息激活所述医保电子凭证；
163.医保支付模块，用于基于所述医保电子凭证，完成医保支付。
164.可选的，所述医保电子凭证激活模块，具体可以包括：
165.身份核验单元，用于基于所述确认操作信息，对所述用户进行身份核验，得到核验结果；
166.医保电子凭证激活单元，用于当所述核验结果表示所述用户的身份核验通过时，激活所述用户的医保电子凭证。
167.可选的，所述身份核验单元，具体可以包括：
168.生物特征信息采集子单元，用于采集所述用户的生物特征信息；
169.生物特征信息匹配子单元，用于基于所述生物特征信息与区块链网络中预先存储的生物特征信息进行匹配，得到匹配结果；所述区块链网络中存储有所述用户标识与生物特征信息之间的对应关系；
170.身份核验通过子单元，用于当所述匹配结果表示所述生物特征信息与所述区块链网络中预先存储的生物特征信息一致时，确定所述用户的身份核验通过。
171.可选的，所述身份核验单元，还可以包括：
172.激活状态信息发送子单元，用于将所述医保电子凭证的激活状态信息发送至所述区块链网络中，以供所述区块链网络更新所述医保电子凭证的状态信息。
173.可选的，所述区块链网络中可以存储有用户标识与医保电子凭证标识之间的映射关系；
174.所述医保电子凭证状态信息确定模块620，具体可以包括：
175.医保电子凭证标识确定单元，用于从所述区块链网络中确定所述用户标识对应的医保电子凭证标识；
176.状态信息确定单元，用于从所述区块链网络中确定所述医保电子凭证标识对应的状态信息。
177.可选的，所述提示信息至少可以包括激活界面；所述激活界面中可以包含处于开
启状态的激活按钮。
178.可选的，所述医保支付模块，具体可以包括：
179.医保结算请求发送单元，用于基于所述医保电子凭证，向医保机构发送医保结算请求；所述医保结算请求中至少包括用户标识、医保电子凭证信息以及金额信息。
180.可选的，所述医保支付模块，还可以包括：
181.结算结果接收单元，用于接收所述医保机构返回的结算结果；
182.结算结果发送单元，用于将所述结算结果发送给所述第二平台。
183.可选的，所述装置，还可以包括：
184.密码指令接收模块，用于接收所述用户在密码输入界面中输入的密码指令；
185.预先存储密码信息获取模块，用于从区块链网络中获取预先存储的所述医保电子凭证对应的密码信息；
186.比对模块，用于将所述用户输入的所述密码指令与所述密码信息进行比对；
187.支付模块，用于当所述用户输入的密码指令与所述密码信息一致时，基于所述医保电子凭证完成支付。
188.基于同样的思路，本说明书实施例还提供了上述实施例2中的方法对应的装置。图7是本说明书实施例提供的第二平台侧的医保支付装置示意图。如图7所示，该装置可以包括：
189.操作信息接收模块710，用于第二平台接收用户针对目标订单的支付方式进行选择的操作信息；
190.医保支付请求发送模块720，用于当所述操作信息表示用户选择的针对目标订单的支付方式为医保支付时，向第一平台发送对于所述目标订单的医保支付请求；所述医保支付请求中至少包括所述目标订单对应的用户标识；
191.提示信息接收模块730，用于接收所述第一平台生成的提示信息；所述提示信息用于提示所述用户授权所述第一平台激活所述医保电子凭证；
192.提示信息发送模块740，用于将所述提示信息发送至所述用户的终端进行显示。
193.基于同样的思路，本说明书实施例还提供了上述方法对应的设备。
194.图8是本说明书实施例提供的一种医保支付设备示意图。如图8所示，设备800可以包括：
195.至少一个处理器810；以及，
196.与所述至少一个处理器通信连接的存储器830；其中，
197.所述存储器830存储有可被所述至少一个处理器810执行的指令820.
198.对应于实施例1，所述指令被所述至少一个处理器810执行，以使所述至少一个处理器810能够：
199.第一平台获取第二平台针对目标订单发起的医保支付请求；所述医保支付请求中至少包括所述目标订单对应的用户标识；
200.确定所述用户标识对应的医保电子凭证的状态信息；所述状态信息用于表示所述医保电子凭证的激活状态；
201.当所述状态信息表示所述医保电子凭证属于未激活状态时，生成提示信息；所述提示信息用于提示所述用户授权所述第一平台激活所述医保电子凭证；
202.将所述提示信息通过所述第二平台发送至用户终端进行显示。
203.对应于实施例2，所述指令被所述至少一个处理器810执行，以使所述至少一个处理器810能够：
204.第二平台接收用户针对目标订单的支付方式进行选择的操作信息；
205.当所述操作信息表示用户选择的针对目标订单的支付方式为医保支付时，向第一平台发送对于所述目标订单的医保支付请求；所述医保支付请求中至少包括所述目标订单对应的用户标识；
206.接收所述第一平台生成的提示信息；所述提示信息用于提示所述用户授权所述第一平台激活所述医保电子凭证；
207.将所述提示信息发送至所述用户的终端进行显示。
208.基于同样的思路，本说明书实施例还提供了上述方法对应的计算机可读介质。计算机可读介质上存储有计算机可读指令。
209.对应于实施例1，所述计算机可读指令可被处理器执行以实现以下方法：
210.第一平台获取第二平台针对目标订单发起的医保支付请求；所述医保支付请求中至少包括所述目标订单对应的用户标识；
211.确定所述用户标识对应的医保电子凭证的状态信息；所述状态信息用于表示所述医保电子凭证的激活状态；
212.当所述状态信息表示所述医保电子凭证属于未激活状态时，生成提示信息；所述提示信息用于提示所述用户授权所述第一平台激活所述医保电子凭证；
213.将所述提示信息通过所述第二平台发送至用户终端进行显示。
214.对应于实施例2，所述计算机可读指令可被处理器执行以实现以下方法：
215.第二平台接收用户针对目标订单的支付方式进行选择的操作信息；
216.当所述操作信息表示用户选择的针对目标订单的支付方式为医保支付时，向第一平台发送对于所述目标订单的医保支付请求；所述医保支付请求中至少包括所述目标订单对应的用户标识；
217.接收所述第一平台生成的提示信息；所述提示信息用于提示所述用户授权所述第一平台激活所述医保电子凭证；
218.将所述提示信息发送至所述用户的终端进行显示。
219.本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于设备实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
220.在20世纪90年代，对于一个技术的改进可以很明显地区分是硬件上的改进(例如，对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件(programmable logic device,pld)(例如现场可编程门阵列(field programmable gate array，fpga))就是这样一种集成电路，其逻辑功能由用户对器件编程来确定。由设计人员
自行编程来把一个数字符系统“集成”在一片pld上，而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且，如今，取代手工地制作集成电路芯片，这种编程也多半改用“逻辑编译器(logic compiler)”软件来实现，它与程序开发撰写时所用的软件编译器相类似，而要编译之前的原始代码也得用特定的编程语言来撰写，此称之为硬件描述语言(hardware description language，hdl)，而hdl也并非仅有一种，而是有许多种，如abel(advanced boolean expression language)、ahdl(altera hardware description language)、confluence、cupl(cornell university programming language)、hdcal、jhdl(java hardware description language)、lava、lola、myhdl、palasm、rhdl(ruby hardware description language)等，目前最普遍使用的是vhdl(very
‑
high
‑
speed integrated circuit hardware description language)与verilog。本领域技术人员也应该清楚，只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中，就可以很容易得到实现该逻辑方法流程的硬件电路。
221.控制器可以按任何适当的方式实现，例如，控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(application specific integrated circuit，asic)、可编程逻辑控制器和嵌入微控制器的形式，控制器的例子包括但不限于以下微控制器：arc625d、atmelat91sam、microchip pic18f26k20以及silicone labs c8051f320，存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。
222.上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的，计算机例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字符助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。
223.为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。
224.本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd
‑
rom、光学存储器等)上实施的计算机程序产品的形式。
225.本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产
生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
226.这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
227.这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
228.在一个典型的配置中，计算设备包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。
229.内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flash ram)。内存是计算机可读介质的示例。
230.计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd
‑
rom)、数字符多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带式磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
231.还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
232.本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd
‑
rom、光学存储器等)上实施的计算机程序产品的形式。
233.本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。
234.以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员
来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。