CN110060049A - 支付方法、装置及设备 - Google Patents

Abstract

本说明书实施例提供一种支付方法、装置及设备，本说明书实施例通过支付服务端、收费端和医保系统的交互，在接收到交易支付请求时，基于预设的支付方与医保支付卡的绑定关系，获取与支付方信息对应的医保支付卡信息，将医保支付卡信息、交易信息和收费端信息发送至医保系统，以供医保系统依据所接收信息对本次交易进行结算处理和医保费用支付处理，并根据医保系统反馈的处理结果执行向收费端支付自费费用的支付处理，从而实现通过一次支付行为完成医保费用和自费费用的混合支付，提高支付效率。

Description

支付方法、装置及设备

技术领域

本说明书涉及数据处理领域，尤其涉及支付方法、装置及设备。

背景技术

医疗保险可以是为了补偿劳动者因疾病风险造成的经济损失而建立的一项社会保险制度。通过用人单位与个人缴费，建立医疗保险基金，参保人员患病就诊发生医疗费用后，由医疗保险机构对其给予一定的经济补偿。医保支付卡可以是进行医疗相关费用报销的卡，持卡人可以凭医保支付卡就医或在定点零售药店买药等。例如，医保支付卡可以是社会保障卡、医保卡等。以社会保障卡为例，社会保障卡也可以简称为社保卡，是由人力资源和社会保障部统一规划，由各地人力资源和社会保障部门面向社会发行，用于人力资源和社会保障各项业务领域的集成电路(IC)卡。在很多情况下，持卡人可以凭医保支付卡就医或在定点零售药店买药等，并进行医疗保险实时结算。然而，并非所有医疗费用或药品费用等都属于能利用医保进行报销的费用，因此，用户在医保支付卡支付医保费用后，还需采用其他支付方式支付自费费用，操作繁琐，支付效率低。

发明内容

为克服相关技术中存在的问题，本说明书提供了支付方法、装置及设备。

根据本说明书实施例的第一方面，提供一种支付方法，所述方法包括：

支付服务端接收交易支付请求，所述交易支付请求至少包括：支付方信息、消费方与收费端的交易信息、以及收费端信息；

支付服务端基于预设的支付方与医保支付卡的绑定关系，获取与所述支付方信息对应的医保支付卡信息，将所述医保支付卡信息、交易信息和收费端信息发送至医保系统；

医保系统依据所接收信息对本次交易进行结算，获得本次交易的医保费用和自费费用，基于所述收费端信息执行向收费端支付医保费用的支付处理，并向支付服务端反馈处理结果；

支付服务端根据所述处理结果执行向收费端支付自费费用的支付处理。

在一个实施例中，所述方法还包括：收费端通过调用支付服务端的支付接口，向支付服务端发送交易支付请求，所述交易支付请求中还携带有用于表示利用医保进行支付的医保支付标识。

在一个实施例中，所述交易支付请求还包括医保系统标识，所述方法还包括：支付服务端将携带有所述医保支付卡信息、交易信息和收费端信息的预结算请求发送至与所述医保系统标识对应的医保系统，并接收医保系统反馈的本次交易的医保费用和自费费用，向支付客户端发送包含医保费用和自费费用的支付提醒信息；

所述将所述医保支付卡信息、交易信息和收费端信息发送至医保系统，包括：在接收到支付客户端反馈的确认付款指令时，将携带有所述医保支付卡信息、交易信息和收费端信息的结算请求发送至与所述医保系统标识对应的医保系统。

在一个实施例中，所述交易支付请求还包括医保系统标识，所述方法还包括：支付服务端通过调用医保系统的预结算接口，将所述医保支付卡信息、交易信息和收费端信息发送至与所述医保系统标识对应的医保系统，并接收医保系统反馈的本次交易的医保费用和自费费用，向支付客户端输出包含医保费用和自费费用的支付提醒信息；

所述将所述医保支付卡信息、交易信息和收费端信息发送至医保系统，包括：在接收到支付客户端反馈的确认付款指令时，通过调用医保系统的结算接口，将所述医保支付卡信息、交易信息和收费端信息发送至所述医保系统标识对应的医保系统。

在一个实施例中，支付方与医保支付卡的绑定关系在支付客户端上进行配置，所述方法还包括：

支付客户端确定医保支付卡的卡主与支付方为同一用户；对当前操作者进行身份验证，若通过验证判定当前操作者为所述用户，则确定支付方和设备保障卡具有绑定关系。

根据本说明书实施例的第二方面，提供一种支付方法，所述方法包括：

接收交易支付请求，所述交易支付请求至少包括：支付方信息、消费方与收费端的交易信息、以及收费端信息；

基于预设的支付方与医保支付卡的绑定关系，获取与所述支付方信息对应的医保支付卡信息，将所述医保支付卡信息、交易信息和收费端信息发送至医保系统，以供医保系统依据所接收信息对本次交易进行结算处理和医保费用支付处理；

根据医保系统反馈的处理结果执行向收费端支付自费费用的支付处理。

在一个实施例中，所述交易信息中包括隐私加密信息，所述隐私加密信息是对交易过程中产生的指定类型的隐私信息进行加密后的信息、且该隐私信息是医保系统进行结算时所需的信息。

在一个实施例中，所述交易支付请求还包括消费方信息，所述将所述医保支付卡信息、交易信息和所述收费端信息发送至医保系统之前，还包括：

依据所述支付方信息和消费方信息判定消费方与支付方为同一用户。

在一个实施例中，所述交易支付请求还包括医保系统标识，所述方法还包括：将携带有所述医保支付卡信息、交易信息和收费端信息的预结算请求发送至与所述医保系统标识对应的医保系统，并接收医保系统反馈的本次交易的医保费用和自费费用，向支付客户端发送包含医保费用和自费费用的支付提醒信息；

所述将所述医保支付卡信息、交易信息和收费端信息发送至医保系统，包括：在接收到支付客户端反馈的确认付款指令时，将携带有所述医保支付卡信息、交易信息和收费端信息的结算请求发送至与所述医保系统标识对应的医保系统。

在一个实施例中，所述交易支付请求还包括医保系统标识，所述方法还包括：通过调用医保系统的预结算接口，将所述医保支付卡信息、交易信息和收费端信息发送至与所述医保系统标识对应的医保系统，并接收医保系统反馈的本次交易的医保费用和自费费用，向支付客户端输出包含医保费用和自费费用的支付提醒信息；

所述将所述医保支付卡信息、交易信息和收费端信息发送至医保系统，包括：在接收到支付客户端反馈的确认付款指令时，通过调用医保系统的结算接口，将所述医保支付卡信息、交易信息和收费端信息发送至所述医保系统标识对应的医保系统。

在一个实施例中，所述方法还包括：

若基于支付方信息以及预设的支付方与医保支付卡的绑定关系，确定支付方未绑定医保支付卡，输出交易失败的提醒信息，或，输出是否进行全自费支付的提醒信息。

在一个实施例中，所述方法还包括：

若所述处理结果中指示本次交易不能使用医保进行支付，输出是否进行全自费支付的提醒信息。

根据本说明书实施例的第三方面，提供一种支付装置，所述装置包括：

请求接收模块，用于：接收交易支付请求，所述交易支付请求至少包括：支付方信息、消费方与收费端的交易信息、以及收费端信息；

信息发送模块，用于：基于预设的支付方与医保支付卡的绑定关系，获取与所述支付方信息对应的医保支付卡信息，将所述医保支付卡信息、交易信息和收费端信息发送至医保系统，以供医保系统依据所接收信息对本次交易进行结算处理和医保费用支付处理；

费用支付模块，用于：根据医保系统反馈的处理结果执行向收费端支付自费费用的支付处理。

根据本说明书实施例的第四方面，提供一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，所述处理器执行所述程序时实现如下方法：

接收交易支付请求，所述交易支付请求至少包括：支付方信息、消费方与收费端的交易信息、以及收费端信息；

基于预设的支付方与医保支付卡的绑定关系，获取与所述支付方信息对应的医保支付卡信息，将所述医保支付卡信息、交易信息和收费端信息发送至医保系统，以供医保系统依据所接收信息对本次交易进行结算处理和医保费用支付处理；

根据医保系统反馈的处理结果执行向收费端支付自费费用的支付处理。

本说明书的实施例提供的技术方案可以包括以下有益效果：

本说明书实施例通过支付服务端和收费端和医保系统的交互，在接收到交易支付请求时，基于预设的支付方与医保支付卡的绑定关系，获取与支付方信息对应的医保支付卡信息，将医保支付卡信息、交易信息和收费端信息发送至医保系统，以供医保系统依据所接收信息对本次交易进行结算处理和医保费用支付处理，并根据医保系统反馈的处理结果执行向收费端支付自费费用的支付处理，从而实现通过一次支付行为完成医保费用和自费费用的混合支付，提高支付效率。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本说明书。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本说明书的实施例，并与说明书一起用于解释本说明书的原理。

图1是本说明书根据一示例性实施例示出的一种支付方法的应用场景图。

图2是本说明书根据一示例性实施例示出的一种支付方法的流程图。

图3是本说明书根据一示例性实施例示出的一种电子社保卡生成过程示意图。

图4是本说明书根据一示例性实施例示出的另一种支付方法的流程图。

图5A是本说明书根据一示例性实施例示出的另一种支付方法的流程图。

图5B是本说明书根据一示例性实施例示出的另一种支付方法的应用场景图。

图5C是本说明书根据一示例性实施例示出的一种支付客户端页面示意图。

图6是本说明书支付装置所在计算机设备的一种硬件结构图。

图7是本说明书根据一示例性实施例示出的一种支付装置的框图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本说明书相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本说明书的一些方面相一致的装置和方法的例子。

在本说明书使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本说明书。在本说明书和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本说明书可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本说明书范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

在某些应用场景中，医保账户可以分为医保个人账户和医保统筹账户。医保个人账户的全称为基本医疗保险个人账户，简称个人账户。个人账户主要用于记录、存储个人账户资金，并按规定用于个人医疗消费。个人账户通常被用来支付参保人的特定医疗费用，包括定点医疗机构发生的门诊费用、定点零售药店的购药支出、定点医院住院、门诊特定项目等基本医疗费用中。甚至个人账户还可以用于购买其他医疗保险等。医保统筹账户基金属于全体参保人员，由社会保险经办机构集中管理，统一使用。主要用于支付参保人员发生的医药费、手术费、护理费、基本检查费等。不管是个人账户还是统筹账户，在使用过程中都有限制条件，当一笔费用产生时，能否利用个人账户或统筹账户进行支付，可以由相应的医保系统进行判断和支付。而针对不能使用医保进行支付的自费费用，消费方采用其他支付方式支付自费费用。以去医院就诊为例，用户在支付医疗费用时，需要先出示社保卡，由收费人员利用医保系统计算医保费用和自费费用。针对医保费用，可以由医保系统直接划扣。针对自费费用，由用户采用其他支付方式进行支付。可见，针对一笔交易需要通过两种支付方式进行支付，操作繁琐，支付效率低。

鉴于此，本说明书实施例提供一种支付方案，可以通过一次支付行为完成医保费用和自费费用的混合支付。以下结合附图对本说明书支付方案的实施例进行示例说明。

首先从交互的角度对支付方案进行示例说明。如图1所示，是本说明书根据一示例性实施例示出的一种支付方法的应用场景图。在该应用场景中，可以包括支付服务端和医保系统，进一步的，还可以包括收费端和用户端。在一个例子中，用户端可以安装有用于与收费端和支付服务端进行交互的客户端，例如，可以是支付客户端。支付服务端可以是与支付客户端相对应的服务端。例如，支付客户端可以是支付宝，则支付服务端可以是与支付宝对应的支付平台。医保系统可以是用于进行结算处理和医保费用支付处理的系统。在医保系统中可以配置有判断待支付费用是否属于医保费用或是否包含医保费用的医保报销策略。例如，如果诊间缴费，医保系统可以判断该笔交易对应的挂号费是否满足医保报销策略的条件，如果挂号费属于专家号，则判定不满足条件，不允许诊间使用医保缴费。具体策略由医保系统而定，在此不做限制。结算处理可以是利用医保报销策略确定待支付费用中的医保费用和自费费用。收费端可以是交易发生时收取费用的一端，也可以理解为提供服务的一端。收费端可以是医院、可利用社保卡进行消费的产品的销售端(诸如，药物销售端，医疗保险销售端)等。相应的，消费方可以是交易发生时享受服务的一方，消费方可以是就诊方、药物购买方、医疗保险购买方等。

如图2所示，是本说明书根据一示例性实施例示出的一种支付方法的流程图，所述方法包括：

在步骤202中，支付服务端接收交易支付请求，所述交易支付请求至少包括：支付方信息、消费方与收费端的交易信息、以及收费端信息。

在步骤204中，支付服务端基于预设的支付方与医保支付卡的绑定关系，获取与所述支付方信息对应的医保支付卡信息，将所述医保支付卡信息、交易信息和收费端信息发送至医保系统。

其中，医保支付卡可以是社保卡、医保卡等可以用于进行医疗相关费用保险的卡。

在步骤206中，医保系统依据所接收信息对本次交易进行结算，获得本次交易的医保费用和自费费用，基于所述收费端信息执行向收费端支付医保费用的支付处理，并向支付服务端反馈处理结果；

在步骤208中，支付服务端根据所述处理结果执行向收费端支付自费费用的支付处理。

关于交易支付请求，可以是针对消费方和收费端所发生的交易进行费用支付的请求。交易支付请求可以是由收费端主动向支付服务端发起的，也可以由其他端代收费端向支付服务端发起的。

举例说明，在一种应用场景中，支付方可以利用支付客户端展示付款码，收费端通过扫描付款码获得支付方信息后，可以向支付服务端发送交易支付请求。在这种应用场景中，可以在收费端铺设当面付机具，支持医保消费者能进行医保当面付。

在另一种应用场景中，可以针对人社局配置医保客户端和医保服务端。医保客户端用于提供医保在线支付服务。支付方可以通过医保客户端展示携带医保系统信息的图形码(如二维码)，收费端通过扫描图形码获得医保系统信息后，可以向对应的医保服务端发送交易相关信息，医保服务端向医保客户端推送待缴费明细，以便在医保客户端展示待缴费明细的页面。医保客户端监听到确认缴费事件后，可以直接向支付服务端发送交易支付请求，或者通过医保服务端向支付服务端发送交易支付请求。又或者，医保客户端监听到确认缴费事件后，通知收费端，由收费端向支付服务端发送交易支付请求。

针对由收费端向支付服务端发送交易支付请求的情况，在一个实施例中，支付服务端可以为收费端提供支付接口，当该实施例应用在当面付场景中时，支付接口可以是当面付接口。所述方法还包括：收费端通过调用支付服务端的支付接口，向支付服务端发送交易支付请求。

其中，所述交易支付请求中还携带有用于表示利用医保进行支付的医保支付标识。支付服务端可以根据医保支付标识判定本次交易的费用期望用医保进行支付。收费端还可以通过调用支付服务端的支付接口，向支付服务端发送携带非医保支付标识的交易支付请求，非医保支付标识用于表示不利用医保进行支付，从而，可以实现普通支付和医保支付可以共用同一个支付接口，节省开发成本。由于支付服务端为消费端提供支付接口，双方还可以签一个销售方案。

在另一个实施例中，针对普通支付和医保支付提供不同的支付接口，例如，利用支付服务端提供的医保支付接口进行医保支付的相关操作；利用支付服务端提供的普通支付接口进行非医保支付的相关操作。可见，该实施例通过医保支付接口和非医保支付接口区分当前支付属于医保支付还是普通支付，无需利用参数进行区分。

交易支付请求中至少包括支付方信息、消费方与收费端的交易信息、以及收费端信息。

关于消费方和支付方，消费方可以是消费收费端所提供服务的一方，如就诊方。消费方信息可以是消费方身份信息，例如，姓名、证件类型、证件号等。支付方是对交易所产生费用进行支付的一方。支付方信息可以是支付方身份信息，例如，支付账号。以支付客户端提供付款码为例，收费端可以通过扫描付款码而获得支付账号。

消费方和支付方可能是同一个用户，也可能是不同用户。为了避免出现套保的现象，实现对套保的多重防范，在一个实施例中，所述交易支付请求中还包括消费方信息，在将所述医保支付卡信息、交易信息和所述收费端信息发送至医保系统之前，还包括：依据所述支付方信息和消费方信息判定消费方与支付方为同一用户。例如，可以根据支付方信息中表示用户身份的信息以及消费方中表示用户身份的信息是否一致，来判断消费方与支付方为同一用户。消费方与支付方为同一用户时，才将医保支付卡信息、交易信息和收费端信息发送至医保系统。若消费方与支付方不是同一用户，可以输出支付失败的提醒信息。所谓输出，可以是向收费端输出，也可以是向支付客户端输出。提醒信息可以是错误码、失败详情等信息。

可见，该实施例增加了对支付方和消费方是否为同一用户的判断，从而避免出现套保的现象。

交易信息是消费方与收费端发生交易时所产生的信息。以应用在就诊的场景中为例，交易信息可以包括：就诊人挂号信息、病历、门诊费用清单、诊间支付的预结算ID等信息。实际应用中，消费方可能并不期望某部分交易信息被泄露，因此，交易信息中可以包括隐私加密信息，该隐私加密信息还可以称为医保透传结构体。所述隐私加密信息是对交易过程中产生的指定类型的隐私信息进行加密后的信息、且该隐私信息是医保系统进行结算时所需的信息。收费端与医保系统可以事先约定所需加密的隐私信息的类型，以及加密算法。结算时所需的信息，可以包括用来判断交易费用是否为医保费用的相关信息。而交易信息中的某些信息无需加密，例如，业务流水号、业务单据号等，这类交易信息可以直接携带在交易支付请求中。

收费端可以是医院、可利用医保支付卡进行消费的产品的销售端(诸如，药物销售端，医疗保险销售端)等。收费端信息可以是收费端的标识，例如，可以是机构名称、机构编码等。

在获得交易支付请求后，可以基于支付方信息以及预设的支付方与医保支付卡的绑定关系，判断支付方信息所指示的支付方是否绑定医保支付卡，若支付方绑定医保支付卡，则获取与支付方信息对应的医保支付卡信息。若支付方未绑定医保支付卡，则输出交易失败的提醒信息，例如，向收费端和支付客户端发送交易失败的提醒信息。或者，若支付方未绑定医保支付卡，输出是否进行全自费支付的提醒信息。例如，向支付客户端发送进行全自费支付的提醒信息，以供用户选择是否继续支付。

在医保系统中往往会对支付方和消费方进行判断，以确保是否为同一用户。然而实际应用中，可能因为消费方的身份作假出现套保的现象，在一个实施例中，还可以限制绑定关系中医保支付卡的卡主与支付方为同一用户，从而进一步避免出现套保的情况。

为了提高用户可操作性，还提供一种支付方与医保支付卡的绑定服务。在一个实施例中，为了节约研发成本，以支付客户端与付费端和支付服务端进行交互为例，支付方与医保支付卡的绑定关系可以在支付客户端上进行配置，并为了确保本次绑定为合法绑定，还可以对当前操作者的身份进行验证，以提高绑定关系的有效性。具体的，在支付客户端可以执行如下步骤：

确定医保支付卡的卡主与支付方为同一用户；

对当前操作者进行身份验证，若通过验证判定当前操作者为所述用户，则确定支付方和设备保障卡具有绑定关系。

其中，可以将医保支付卡的卡主身份信息与支付方信息进行匹配，从而判断医保支付卡的卡主与支付方是否为同一用户。关于身份验证，可以包括对当前操作者的生物特征信息进行验证、对输入的个人隐私信息进行验证、对输入的手机验证码进行验证等中的一种或多种。对当前操作者的生物特征信息进行验证可以是人脸识别、指纹识别等。对输入的个人隐私信息进行验证可以是判断输入的个人隐私信息与所述用户(支付方)的标准个人隐私信息是否匹配。个人隐私信息可以是身份证、手机号码、银行卡号等。进一步的，在通过验证判定当前操作者为所述用户时，还可以将支付方和设备保障卡具有绑定关系发送至支付服务端，并获取该用户的医保支付卡信息，并存储支付方信息与医保支付卡信息的映射关系，以供用户查询医保支付卡信息。如果医保支付卡为实体卡，支付方与医保支付卡的绑定服务，也可以作为电子医保支付卡的生成服务。

以医保支付卡为社保卡为例，如图3所示，图3是本说明书根据一示例性实施例示出的一种电子社保卡生成过程示意图。在支付客户端中增加电子社保卡的生成服务，支付客户端可以安装在手机、平板等用户端上。用户可以通过支付客户端提供的电子社保卡开通页面开通电子设备卡。为了确保当前操作者、社保卡的卡主以及支付方为同一用户，可以将社保卡信息与支付方信息进行匹配，以及对当前操作者进行身份验证。该示例采用人脸识别、活物检测等手段对当前操作者进行身份验证，在判定采集的人物图像为活物、且与预存用户图像相匹配，则获取该用户的设备卡信息，建立支付方与社保卡的映射关系，并生成电子社保卡。

结合交易支付请求还包括消费方信息的情况，在判定支付方绑定有医保支付卡、且依据支付方信息和消费方信息判定消费方与支付方为同一用户时，将医保支付卡信息、交易信息和收费端信息发送至医保系统。

关于如何发送至医保系统，若医保系统只有一个，则直接将医保支付卡信息、交易信息和收费端信息发送至医保系统。而某些应用场景中，医保系统也可能有多个，例如，每个区域可以配置相应的医保系统。区域的划分方式可以是按地级市进行划分等。相应的，为了能对医保系统进行区分，交易支付请求还可以携带医保系统标识，例如，医保系统标识可以是医保系统方的结构名称、机构编码等。利用医保系统标识来区分不同医保系统。步骤204中的将所述医保支付卡信息、交易信息和所述收费端信息发送至医保系统，可以是，将医保支付卡信息、交易信息和收费端信息发送至与医保系统标识对应的医保系统。

在一个实施例中，支付服务端可以将医保支付卡信息、交易信息和收费端信息发送至医保系统，由医保系统直接进行结算处理和医保费用的支付处理。例如，将携带有医保支付卡信息和所述交易信息的结算请求发送至医保系统，医保系统依据所接收信息对本次交易进行结算，获得本次交易的医保费用和自费费用，基于收费端信息执行向收费端支付医保费用的支付处理，并向支付服务端反馈处理结果。

该实施例由医保系统直接进行结算处理和医保费用的支付处理，可以提高支付效率。

关于医保系统执行医保费用的支付处理，以医保支付卡为社保卡为例，医保系统执行医保费用的支付处理可以是从医保统筹账户或医保个人账户划扣相应费用到收费端，具体处理手段在此不一一赘述。具体划扣医保统筹账户还是医保个人账户，可以由医保报销策略而定。在一个实施例中，针对利用医保个人账户支付医保费用的情况，还可以通过支付客户端提醒用户选择是否利用医保个人账户支付医保费用，进而医保系统根据选择结果确定是否利用医保个人账户支付医保费用。

在某些应用场景下，用户可能期望根据结算结果来确定是否使用医保支付，鉴于此，在另一个实施例中，还可以先通过医保系统进行预结算，并将预结算结果通知支付服务端，并在支付方同意支付时，才进行医保系统的支付处理和支付服务端的支付处理，提高用户可操作性，以及提高用户体验。例如，支付服务端在收到预结算结果后，可以向支付客户端发送包含医保费用和自费费用的支付提醒信息，在支付客户端展示该支付提醒信息，基于用户的操作可以向支付服务端反馈确认付款指令。

关于如何区分预结算和结算两次任务，在一个例子中，预结算和结算可以通过不同请求进行区分。例如，利用预结算请求表示期望医保系统进行预结算处理，结算请求表示期望医保系统进行结算处理，而预结算请求和结算请求可以通过不同参数进行区分。例如，包括预设的预结算标识的请求为预结算请求，包括预设的结算标识的请求为结算请求。相应的，所述交易支付请求还包括医保系统标识，所述方法还包括：支付服务端将携带有所述医保支付卡信息、交易信息和收费端信息的预结算请求发送至与所述医保系统标识对应的医保系统，并接收医保系统反馈的本次交易的医保费用和自费费用，向支付客户端发送包含医保费用和自费费用的支付提醒信息；

所述将所述医保支付卡信息、交易信息和收费端信息发送至医保系统，包括：在接收到支付客户端反馈的确认付款指令时，将携带有所述医保支付卡信息、交易信息和收费端信息的结算请求发送至与所述医保系统标识对应的医保系统。

在该实施例中，利用预结算请求表示期望医保系统进行预结算处理，利用结算请求表示期望医保系统进行结算处理，可以实现共用相同接口实现医保系统和支付服务端的交互。

在另一个例子中，预结算和结算可以通过医保系统提供的不同接口进行区分。例如，通过预结算接口传输的数据，指示期望医保系统进行预结算处理，利用结算接口传输的数据，指示期望医保系统进行结算处理。例如，所述交易支付请求还包括医保系统标识，所述方法还包括：支付服务端通过调用医保系统的预结算接口，将所述医保支付卡信息、交易信息和收费端信息发送至与所述医保系统标识对应的医保系统，并接收医保系统反馈的本次交易的医保费用和自费费用，向支付客户端输出包含医保费用和自费费用的支付提醒信息；

所述将所述医保支付卡信息、交易信息和收费端信息发送至医保系统，包括：在接收到支付客户端反馈的确认付款指令时，通过调用医保系统的结算接口，将所述医保支付卡信息、交易信息和收费端信息发送至所述医保系统标识对应的医保系统。

医保系统依据医保支付卡信息、交易信息和收费端信息对本次交易进行结算，获得本次交易的医保费用和自费费用，其中，具体结算策略由医保系统而定，在此不做限制。医保费用不为0的情况下，可以扣除医保费用，并向支付服务端返回支付结果和明细。如果医保支付成功，可以决定是否执行向收费端支付自费费用的支付处理。支付处理是控制支付方向收费端支付自费费用的处理，具体处理手段与相关技术中的支付手段相似，在此不一一赘述。在一个实施例中，可以获取支付平台设置的免密码额度，在自费费用小于免密码额度时，可以直接执行向收费端支付自费费用的支付处理；如果自费费用大于免密码额度时，可以通过收银台页面提醒用户完成支付。在另一个实施例中，社保局可能认为直接支付安全性低，因此，可以要求所有金额都需要用户确认后才能执行支付处理，则无需判断自费费用的大小，直接输出是否对自费费用进行支付的支付提醒信息，由用户决定是否继续进行支付。

此外，在一个实施例中，若所述处理结果中指示本次交易不能使用医保进行支付，输出是否进行全自费支付的提醒信息。可见，在确保无法使用医保时，直接进入全自费支付的处理流程，无需用户退出当前订单，可以提高支付效率。

相应的，本说明书还从支付服务端的角度对支付方法进行示例说明，如图4所示，是本说明书根据一示例性实施例示出的另一种支付方法的流程图，所述方法可以应用于支付服务端，所述方法包括：

在步骤402中，接收交易支付请求，所述交易支付请求至少包括：支付方信息、消费方与收费端的交易信息、以及收费端信息；

在步骤404中，基于预设的支付方与医保支付卡的绑定关系，获取与所述支付方信息对应的医保支付卡信息，将所述医保支付卡信息、交易信息和收费端信息发送至医保系统，以供医保系统依据所接收信息对本次交易进行结算处理和医保费用支付处理；

在步骤406中，根据医保系统反馈的处理结果执行向收费端支付自费费用的支付处理。

可以理解的是，图4与图2中相关技术相同，在此不一一赘述。

在一个实施例中，所述交易信息中包括隐私加密信息，所述隐私加密信息是对交易过程中产生的指定类型的隐私信息进行加密后的信息、且该隐私信息是医保系统进行结算时所需的信息。

在一个实施例中，所述交易支付请求还包括消费方信息，所述将所述医保支付卡信息、交易信息和所述收费端信息发送至医保系统之前，还包括：依据所述支付方信息和消费方信息判定消费方与支付方为同一用户。

在一个实施例中，所述交易支付请求还包括医保系统标识，所述方法还包括：将携带有所述医保支付卡信息、交易信息和收费端信息的预结算请求发送至与所述医保系统标识对应的医保系统，并接收医保系统反馈的本次交易的医保费用和自费费用，向支付客户端发送包含医保费用和自费费用的支付提醒信息。所述将所述医保支付卡信息、交易信息和收费端信息发送至医保系统，包括：在接收到支付客户端反馈的确认付款指令时，将携带有所述医保支付卡信息、交易信息和收费端信息的结算请求发送至与所述医保系统标识对应的医保系统。

在一个实施例中，所述交易支付请求还包括医保系统标识，所述方法还包括：通过调用医保系统的预结算接口，将所述医保支付卡信息、交易信息和收费端信息发送至与所述医保系统标识对应的医保系统，并接收医保系统反馈的本次交易的医保费用和自费费用，向支付客户端输出包含医保费用和自费费用的支付提醒信息。所述将所述医保支付卡信息、交易信息和收费端信息发送至医保系统，包括：在接收到支付客户端反馈的确认付款指令时，通过调用医保系统的结算接口，将所述医保支付卡信息、交易信息和收费端信息发送至所述医保系统标识对应的医保系统。

在一个实施例中，所述方法还包括：若基于支付方信息以及预设的支付方与医保支付卡的绑定关系，确定支付方未绑定医保支付卡，输出交易失败的提醒信息，或，输出是否进行全自费支付的提醒信息。

在一个实施例中，所述方法还包括：若所述处理结果中指示本次交易不能使用医保进行支付，输出是否进行全自费支付的提醒信息。

以上实施方式中的各种技术特征可以任意进行组合，只要特征之间的组合不存在冲突或矛盾，但是限于篇幅，未进行一一描述，因此上述实施方式中的各种技术特征的任意进行组合也属于本说明书公开的范围。

以下以其中一种组合进行示例说明，其中，以医保支付卡为社保卡为例。

如图5A所示，是本说明书根据一示例性实施例示出的另一种支付方法的流程图，该方法涉及支付客户端、支付服务端、收费端和医保系统。所述方法包括：

支付客户端向收费端提供付款码(步骤501)。

收费端获取支付客户端的付款码，基于付款码获得支付方信息(步骤502)，向支付服务端发送交易支付请求(步骤503)。其中，交易支付请求可以包括：支付方信息、消费方与收费端的交易信息、收费端信息、医保系统标识、以及用于表示利用医保进行支付的医保支付标识。

支付服务端若基于预设的支付方与社保卡的绑定关系，判定支付方绑定有社保卡，且依据支付方信息和消费方信息判定消费方与支付方为同一用户时，获取与支付方信息对应的社保卡信息(步骤504)，并通过调用医保系统的预结算接口，将社保卡信息、交易信息和收费端信息发送至与医保系统标识对应的医保系统(步骤505)。另外，若支付方未绑定社保卡，或者消费方与支付方不为同一用户时，向收款端和支付客户端发送交易失败的提醒信息。

医保系统依据所接收信息对本次交易进行结算，获得本次交易的医保费用和自费费用，并将医保费用和自费费用反馈至支付服务端(步骤506)。

支付服务端向支付客户端输出包含医保费用和自费费用的支付提醒信息(步骤507)，并在接收到支付客户端反馈的确认付款指令时，通过调用医保系统的结算接口，将社保卡信息、交易信息和收费端信息发送至与医保系统标识对应的医保系统(步骤508)。

医保系统依据所接收信息对本次交易进行结算处理和医保费用支付处理，并向支付服务端反馈处理结果(步骤509)。

在支付服务端，若根据处理结果确定医保支付成功，则执行向收费端支付自费费用的支付处理(步骤510)。

相应的，若自费费用支付成功时，支付服务端向支付客户端返回收费端订单支付结果和医保支付结果。同时，还可以在支付客户端支付成功页显示本次订单的总金额、自费金额、医保金额，还可以展示优惠折扣金额(如有优惠的情况下，如没有优惠不用显示)等。若自费费用支付失败，则调用医保系统的退款接口，通知医保系统进行退款操作，并通知支付客户端和收费端付款失败。

如图5B所示，是本说明书根据一示例性实施例示出的另一种支付方法的应用场景图。如图5C所示，是本说明书根据一示例性实施例示出的一种支付客户端页面示意图。该应用场景中，可以在原有的支付客户端中增加绑定服务以及医保支付服务。用户通过点击电子社保卡页面的“去刷码”按钮，即可进入包括付款码的页面。在其他实施例中，也可以通过支付客户端首页中的付款码按钮，进入包括付款码的页面。扫码台扫描付款码，并将扫描获得的信息传输至收费端。收费端获取到付款码后可以调用支付接口，传入付款条码、指示是否医保支付的标识、就诊人身份信息(包括姓名、证件类型、证件号)，医院机构名称、医院机构编码、待进行医保结算的机构名称和编码、业务流水号、业务单据号、医保透传结构体(主要是用户的挂号信息或者诊间支付的预结算ID等信息)。支付服务端判断该用户是否绑定社保卡，若没有绑定社保卡，则返回交易失败，同时给出对应的错误码。若已经绑定社保卡，则判断就诊人身份信息是否和支付客户端实名信息一致，如果一致则进入医保支付交易建立步骤。如果不一致，则返回交易失败，同时给出对应的错误码。关于创建医保支付交易，支付服务端调用医保系统的预结算接口，将机构编码、医保透传结构体(挂号明细信息、诊间预结算ID)等信息发送给医保系统做预结算。医保系统进行预结算，返回给支付服务端所需医保支付金额和自费支付金额。预结算完成后，支付服务端调用医保系统的结算接口，将机构编码、医保透传结构体(挂号明细清单或诊间明细ID)等信息发送给医保系统做结算。医保系统进行结算，扣除医保账户金额，向支付服务端返回医保支付结果和明细。如果医保支付成功，则进行自费金额支付，启动协议进行支付代扣。当面付的额度按照整个订单额度来判断，若超过额度则按照当面付的规则跳出收银台完成支付。如果自费支付成功，则订单支付成功，返回医院系统订单支付结果和医保支付结果。同时在支付客户端支付成功页显示本次订单的总金额、自费金额、医保金额、优惠折扣金额(如有优惠的情况下，如没有优惠不用显示)等信息。

与前述支付方法的实施例相对应，本说明书还提供了支付装置及其所应用的电子设备的实施例。

本说明书支付装置的实施例可以应用在计算机设备。装置实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在计算机设备的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言，如图6所示，为本说明书支付装置所在计算机设备的一种硬件结构图，除了图6所示的处理器610、网络接口620、内存630、以及非易失性存储器640之外，实施例中支付装置631所在的计算机设备通常根据该设备的实际功能，还可以包括其他硬件，对此不再赘述。

如图7所示，是本说明书根据一示例性实施例示出的一种支付装置的框图，所述装置包括：

请求接收模块72，用于：接收交易支付请求，所述交易支付请求至少包括：支付方信息、消费方与收费端的交易信息、以及收费端信息；

信息发送模块74，用于：基于预设的支付方与医保支付卡的绑定关系，获取与所述支付方信息对应的医保支付卡信息，将所述医保支付卡信息、交易信息和收费端信息发送至医保系统，以供医保系统依据所接收信息对本次交易进行结算处理和医保费用支付处理；

费用支付模块76，用于：根据医保系统反馈的处理结果执行向收费端支付自费费用的支付处理。

在一个实施例中，所述交易信息中包括隐私加密信息，所述隐私加密信息是对交易过程中产生的指定类型的隐私信息进行加密后的信息、且该隐私信息是医保系统进行结算时所需的信息。

在一个实施例中，所述交易支付请求还包括消费方信息，所述信息发送模块还用于：将所述医保支付卡信息、交易信息和所述收费端信息发送至医保系统之前，依据所述支付方信息和消费方信息判定消费方与支付方为同一用户。

在一个实施例中，所述交易支付请求还包括医保系统标识，所述信息发送模块74具体用于：

将携带有所述医保支付卡信息、交易信息和收费端信息的预结算请求发送至与所述医保系统标识对应的医保系统，并接收医保系统反馈的本次交易的医保费用和自费费用，向支付客户端发送包含医保费用和自费费用的支付提醒信息；

在接收到支付客户端反馈的确认付款指令时，将携带有所述医保支付卡信息、交易信息和收费端信息的结算请求发送至与所述医保系统标识对应的医保系统。

在一个实施例中，所述交易支付请求还包括医保系统标识，所述信息发送模块74具体用于：

通过调用医保系统的预结算接口，将所述医保支付卡信息、交易信息和收费端信息发送至与所述医保系统标识对应的医保系统，并接收医保系统反馈的本次交易的医保费用和自费费用，向支付客户端输出包含医保费用和自费费用的支付提醒信息；

在接收到支付客户端反馈的确认付款指令时，通过调用医保系统的结算接口，将所述医保支付卡信息、交易信息和收费端信息发送至所述医保系统标识对应的医保系统。

在一个实施例中，所述信息发送模块74还用于：

若基于支付方信息以及预设的支付方与医保支付卡的绑定关系，确定支付方未绑定医保支付卡，输出交易失败的提醒信息，或，输出是否进行全自费支付的提醒信息。

在一个实施例中，所述信息发送模块74还用于：

若所述处理结果中指示本次交易不能使用医保进行支付，输出是否进行全自费支付的提醒信息。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理模块，即可以位于一个地方，或者也可以分布到多个网络模块上。可以根据实际的需要选择其中的部分或者全部模块来实现本说明书方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

相应的，本说明书实施例还提供一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，所述处理器执行所述程序时实现如下方法：

支付服务端接收交易支付请求，所述交易支付请求至少包括：支付方信息、消费方与收费端的交易信息、以及收费端信息；

支付服务端基于预设的支付方与医保支付卡的绑定关系，获取与所述支付方信息对应的医保支付卡信息，将所述医保支付卡信息、交易信息和收费端信息发送至医保系统；

医保系统依据所接收信息对本次交易进行结算，获得本次交易的医保费用和自费费用，基于所述收费端信息执行向收费端支付医保费用的支付处理，并向支付服务端反馈处理结果；

支付服务端根据所述处理结果执行向收费端支付自费费用的支付处理。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于设备实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

相应的，本说明书实施例还提供一种计算机存储介质，所述存储介质中存储有程序指令，所述程序指令包括：

支付服务端接收交易支付请求，所述交易支付请求至少包括：支付方信息、消费方与收费端的交易信息、以及收费端信息；

支付服务端基于预设的支付方与医保支付卡的绑定关系，获取与所述支付方信息对应的医保支付卡信息，将所述医保支付卡信息、交易信息和收费端信息发送至医保系统；

医保系统依据所接收信息对本次交易进行结算，获得本次交易的医保费用和自费费用，基于所述收费端信息执行向收费端支付医保费用的支付处理，并向支付服务端反馈处理结果；

支付服务端根据所述处理结果执行向收费端支付自费费用的支付处理。

本说明书实施例可采用在一个或多个其中包含有程序代码的存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。计算机可用存储介质包括永久性和非永久性、可移动和非可移动媒体，可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括但不限于：相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。

本领域技术人员在考虑说明书及实践这里申请的发明后，将容易想到本说明书的其它实施方案。本说明书旨在涵盖本说明书的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本说明书的一般性原理并包括本说明书未申请的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本说明书的真正范围和精神由下面的权利要求指出。

应当理解的是，本说明书并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本说明书的范围仅由所附的权利要求来限制。

以上所述仅为本说明书的较佳实施例而已，并不用以限制本说明书，凡在本说明书的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本说明书保护的范围之内。

Claims (14)

1.一种支付方法，所述方法包括：

支付服务端接收交易支付请求，所述交易支付请求至少包括：支付方信息、消费方与收费端的交易信息、以及收费端信息；

支付服务端基于预设的支付方与医保支付卡的绑定关系，获取与所述支付方信息对应的医保支付卡信息，将所述医保支付卡信息、交易信息和收费端信息发送至医保系统；

医保系统依据所接收信息对本次交易进行结算，获得本次交易的医保费用和自费费用，基于所述收费端信息执行向收费端支付医保费用的支付处理，并向支付服务端反馈处理结果；

支付服务端根据所述处理结果执行向收费端支付自费费用的支付处理。

2.根据权利要求1所述的方法，所述方法还包括：收费端通过调用支付服务端的支付接口，向支付服务端发送交易支付请求，所述交易支付请求中还携带有用于表示利用医保进行支付的医保支付标识。

3.根据权利要求1所述的方法，所述交易支付请求还包括医保系统标识，所述方法还包括：支付服务端将携带有所述医保支付卡信息、交易信息和收费端信息的预结算请求发送至与所述医保系统标识对应的医保系统，并接收医保系统反馈的本次交易的医保费用和自费费用，向支付客户端发送包含医保费用和自费费用的支付提醒信息；

所述将所述医保支付卡信息、交易信息和收费端信息发送至医保系统，包括：在接收到支付客户端反馈的确认付款指令时，将携带有所述医保支付卡信息、交易信息和收费端信息的结算请求发送至与所述医保系统标识对应的医保系统。

4.根据权利要求1所述的方法，所述交易支付请求还包括医保系统标识，所述方法还包括：支付服务端通过调用医保系统的预结算接口，将所述医保支付卡信息、交易信息和收费端信息发送至与所述医保系统标识对应的医保系统，并接收医保系统反馈的本次交易的医保费用和自费费用，向支付客户端输出包含医保费用和自费费用的支付提醒信息；

所述将所述医保支付卡信息、交易信息和收费端信息发送至医保系统，包括：在接收到支付客户端反馈的确认付款指令时，通过调用医保系统的结算接口，将所述医保支付卡信息、交易信息和收费端信息发送至所述医保系统标识对应的医保系统。

5.根据权利要求1至4任一项所述的方法，支付方与医保支付卡的绑定关系在支付客户端上进行配置，所述方法还包括：

支付客户端确定医保支付卡的卡主与支付方为同一用户；对当前操作者进行身份验证，若通过验证判定当前操作者为所述用户，则确定支付方和设备保障卡具有绑定关系。

6.一种支付方法，所述方法包括：

接收交易支付请求，所述交易支付请求至少包括：支付方信息、消费方与收费端的交易信息、以及收费端信息；

基于预设的支付方与医保支付卡的绑定关系，获取与所述支付方信息对应的医保支付卡信息，将所述医保支付卡信息、交易信息和收费端信息发送至医保系统，以供医保系统依据所接收信息对本次交易进行结算处理和医保费用支付处理；

根据医保系统反馈的处理结果执行向收费端支付自费费用的支付处理。

7.根据权利要求6所述的方法，所述交易信息中包括隐私加密信息，所述隐私加密信息是对交易过程中产生的指定类型的隐私信息进行加密后的信息、且该隐私信息是医保系统进行结算时所需的信息。

8.根据权利要求6所述的方法，所述交易支付请求还包括消费方信息，所述将所述医保支付卡信息、交易信息和所述收费端信息发送至医保系统之前，还包括：

依据所述支付方信息和消费方信息判定消费方与支付方为同一用户。

9.根据权利要求6所述的方法，所述交易支付请求还包括医保系统标识，所述方法还包括：将携带有所述医保支付卡信息、交易信息和收费端信息的预结算请求发送至与所述医保系统标识对应的医保系统，并接收医保系统反馈的本次交易的医保费用和自费费用，向支付客户端发送包含医保费用和自费费用的支付提醒信息；

所述将所述医保支付卡信息、交易信息和收费端信息发送至医保系统，包括：在接收到支付客户端反馈的确认付款指令时，将携带有所述医保支付卡信息、交易信息和收费端信息的结算请求发送至与所述医保系统标识对应的医保系统。

10.根据权利要求6所述的方法，所述交易支付请求还包括医保系统标识，所述方法还包括：通过调用医保系统的预结算接口，将所述医保支付卡信息、交易信息和收费端信息发送至与所述医保系统标识对应的医保系统，并接收医保系统反馈的本次交易的医保费用和自费费用，向支付客户端输出包含医保费用和自费费用的支付提醒信息；

所述将所述医保支付卡信息、交易信息和收费端信息发送至医保系统，包括：在接收到支付客户端反馈的确认付款指令时，通过调用医保系统的结算接口，将所述医保支付卡信息、交易信息和收费端信息发送至所述医保系统标识对应的医保系统。

11.根据权利要求6至10任一项所述的方法，所述方法还包括：

若基于支付方信息以及预设的支付方与医保支付卡的绑定关系，确定支付方未绑定医保支付卡，输出交易失败的提醒信息，或，输出是否进行全自费支付的提醒信息。

12.根据权利要求6至10任一项所述的方法，所述方法还包括：

若所述处理结果中指示本次交易不能使用医保进行支付，输出是否进行全自费支付的提醒信息。

13.一种支付装置，所述装置包括：

请求接收模块，用于：接收交易支付请求，所述交易支付请求至少包括：支付方信息、消费方与收费端的交易信息、以及收费端信息；

信息发送模块，用于：基于预设的支付方与医保支付卡的绑定关系，获取与所述支付方信息对应的医保支付卡信息，将所述医保支付卡信息、交易信息和收费端信息发送至医保系统，以供医保系统依据所接收信息对本次交易进行结算处理和医保费用支付处理；

费用支付模块，用于：根据医保系统反馈的处理结果执行向收费端支付自费费用的支付处理。

14.一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，所述处理器执行所述程序时实现如下方法：

接收交易支付请求，所述交易支付请求至少包括：支付方信息、消费方与收费端的交易信息、以及收费端信息；

基于预设的支付方与医保支付卡的绑定关系，获取与所述支付方信息对应的医保支付卡信息，将所述医保支付卡信息、交易信息和收费端信息发送至医保系统，以供医保系统依据所接收信息对本次交易进行结算处理和医保费用支付处理；

根据医保系统反馈的处理结果执行向收费端支付自费费用的支付处理。