CN116757696A - 基于电子信用卡的信用支付方法及相关设备 - Google Patents

Abstract

本申请公开了一种基于电子信用卡的信用支付方法及相关设备。所述基于电子信用卡的信用支付方法包括：接收用户发送的信用支付请求；解析所述信用支付请求，得到用户身份信息、支付事件信息以及所述用户的被预先授予的电子信用卡的账号；在数据库中查找与所述电子信用卡的账号相匹配的电子信用卡的账户信息；根据所述用户身份信息、支付事件信息以及电子信用卡的账户信息判断所述用户是否符合预先设定的信用支付条件；响应于确定所述用户符合信用支付条件，调用基于电子信用卡的第一支付接口；通过所述第一支付接口进行支付。根据本申请实施例，可以实现基于电子信用卡的信用支付，方便快捷且安全性较高。

Description

基于电子信用卡的信用支付方法及相关设备

技术领域

本申请属于信用支付技术领域，尤其涉及一种基于电子信用卡的信用支付方法及相关设备。

背景技术

信用支付是指基于政府、银行、保险及其他第三方平台等信用评价体系对用户进行信用评估后，为用户发放信用卡，使用户在支付费用时可以使用信用卡对产生的费用先行扣除，然后在一定时间内一次性完成支付，可以减轻用户短期资金支付压力。

然而，相关技术中，由于在信用卡刷卡时输入密码即可完成支付，缺少针对信用卡的使用者的进一步条件核验，从而导致信用卡被盗用时无法及时发现为非本人使用等安全性问题，具有较大隐患。

发明内容

本申请实施例提供一种基于电子信用卡的信用支付方法及相关设备，实现基于电子信用卡的信用支付，方便快捷且安全性较高。

第一方面，本申请实施例提供一种基于电子信用卡的信用支付方法，该方法包括：

接收用户发送的信用支付请求；

解析所述信用支付请求，得到用户身份信息、支付事件信息以及所述用户的被预先授予的电子信用卡的账号；

在数据库中查找与所述电子信用卡的账号相匹配的电子信用卡的账户信息；

根据所述用户身份信息、支付事件信息以及电子信用卡的账户信息判断所述用户是否符合预先设定的信用支付条件；

响应于确定所述用户符合信用支付条件，调用基于电子信用卡的第一支付接口；

通过所述第一支付接口进行支付。

第二方面，本申请实施例提供了一种基于电子信用卡的信用支付装置，该装置包括：

接收模块，用于接收用户发送的信用支付请求；

解析模块，用于解析所述信用支付请求，得到用户身份信息、支付事件信息以及所述用户的被预先授予的电子信用卡的账号；

查找模块，用于在数据库中查找与所述电子信用卡的账号相匹配的电子信用卡的账户信息；

判断模块，用于根据所述用户身份信息、支付事件信息以及电子信用卡的账户信息判断所述用户是否符合预先设定的信用支付条件；

调用模块，用于响应于确定所述用户符合信用支付条件，调用基于电子信用卡的第一支付接口；

支付模块，用于通过所述第一支付接口进行支付。

第三方面，本申请实施例提供了一种电子设备，该电子设备包括：处理器以及存储有计算机程序指令的存储器；处理器执行所述计算机程序指令时实现如第一方面的任一项实施例中所述的基于电子信用卡的信用支付方法的步骤。

第四方面，本申请实施例提供了一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序指令，计算机程序指令被处理器执行时实现如第一方面的任一项实施例中所述的基于电子信用卡的信用支付方法的步骤。

第五方面，本申请实施例提供了一种计算机程序产品，计算机程序产品中的指令由电子设备的处理器执行时，使得所述电子设备执行如第一方面的任一项实施例中所述的基于电子信用卡的信用支付方法的步骤。

本申请实施例的基于电子信用卡的信用支付方法及相关设备，当接收到用户发送的信用支付请求时，对信用支付请求进行解析后得到用户身份信息以及用户的电子信用卡信息等基本信息，并将这些基本信息与所设定的信用支付条件进行判断，解决了相关技术缺少除支付密码以外的进一步条件校验而导致的信用支付安全问题。这样，在满足信用支付条件的前提下，用户可以实现基于电子信用卡的信用支付，方便快捷且安全性较高，能够提升用户体验。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例中所需要使用的附图作简单的介绍，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请实施例提供的一种基于电子信用卡的信用支付方法的流程示意图；

图2是本申请实施例提供的另一种基于电子信用卡的信用支付方法的流程示意图；

图3是本申请实施例提供的一种基于电子信用卡的信用支付装置的结构示意图；

图4是本申请实施例提供的一种信用就医系统的结构示意图；

图5是本申请实施例提供的实现信用就医系统的的技术架构的示意图；

图6是本申请实施例提供的一种电子设备的结构示意图。

具体实施方式

下面将详细描述本申请的各个方面的特征和示例性实施例，为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及具体实施例，对本申请进行进一步详细描述。应理解，此处所描述的具体实施例仅意在解释本申请，而不是限定本申请。对于本领域技术人员来说，本申请可以在不需要这些具体细节中的一些细节的情况下实施。下面对实施例的描述仅仅是为了通过示出本申请的示例来提供对本申请更好的理解。

需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

需要说明的是，本申请实施例中对数据的获取、存储、使用和处理等，均符合国家法律法规的相关规定。

信用支付是指基于政府、银行、保险及其他第三方平台等信用评价体系对用户进行信用评估后，为用户发放信用卡，使用户在支付费用时可以使用信用卡对产生的费用先行扣除，然后在一定时间内一次性完成支付，可以减轻用户短期资金支付压力。

然而，相关技术中，由于在信用卡刷卡时输入密码即可完成支付，缺少针对信用卡的使用者的进一步条件核验，从而导致信用卡被盗用时无法及时发现为非本人使用等安全性问题，具有较大隐患。

为了解决相关技术的问题，本申请实施例提供了一种基于电子信用卡的信用支付方法及相关设备。

下面结合附图，通过具体的实施例及其应用场景对本申请实施例提供的基于电子信用卡的信用支付方法进行详细地说明。

图1示出了本申请实施例的基于电子信用卡的信用支付方法100的流程示意图。如图1所示，该基于电子信用卡的信用支付方法100具体可以包括以下步骤：

S101、接收用户发送的信用支付请求；

S102、解析所述信用支付请求，得到用户身份信息、支付事件信息以及所述用户的被预先授予的电子信用卡的账号；

S103、在数据库中查找与所述电子信用卡的账号相匹配的电子信用卡的账户信息；

S104、根据所述用户身份信息、支付事件信息以及电子信用卡的账户信息判断所述用户是否符合预先设定的信用支付条件；

S105、响应于确定所述用户符合信用支付条件，调用基于电子信用卡的第一支付接口；

S106、通过所述第一支付接口进行支付。

由此，当接收到用户发送的信用支付请求时，对信用支付请求进行解析后得到用户身份信息以及用户的电子信用卡信息等基本信息，并将这些基本信息与所设定的信用支付条件进行判断，解决了相关技术缺少除支付密码以外的进一步条件校验而导致的信用支付安全问题。这样，在满足信用支付条件的前提下，用户可以实现基于电子信用卡的信用支付，方便快捷且安全性较高，能够提升用户体验。

下面介绍上述各个步骤的具体实现方式。

需要说明的是，本申请实施例中的电子信用卡可以是虚拟信用卡。对于该电子信用卡，除无卡特征外，其可以实现实体信用卡所具有的全部功能或部分功能，例如消费支付、信用贷款、转账结算、存取现金等。

另外，对于电子信用卡的发行方或者发卡方，可以包括银行金融机构(例如，商业银行)和非银行金融机构(例如，保险公司、证券公司等)，本申请实施例对此不做限定。

在一些实施例中，在步骤S101之前，可以为用户办理和授予电子信用卡。具体的，电子信用卡的办理和授予过程可以包括：接收用户发送的电子信用卡申请请求；根据所述电子信用卡申请请求，判断所述用户是否满足电子信用卡的授予资格；响应于确定所述用户满足电子信用卡的授予资格，生成电子信用卡，并将所述电子信用卡发送至所述用户。

然而，相关技术中，基于实体信用卡进行信用支付，则对于无信用卡用户，需要首先申请信用卡并等待发卡、领卡、激活、绑定等，且对于上述部分流程还需要用户线下到达指定地点才能实现，操作繁琐并且全过程周期较长，导致用户无法基于信用卡及时实现信用支付，便捷性和效率均较低，用户体验较差。因此，本申请实施例根据用户针对电子信用卡的申请请求进行实时在线反馈，实现电子信用卡的快速生成，从而可以使用户基于电子信用卡实现信用支付。

具体实施时，在接收到用户发送的电子信用卡申请请求后，可以解析该电子信用卡申请请求，得到用户的用户名称、身份证图像信息、当前人脸图像、信用信息等用户身份信息，并将这些信息存储于数据库。

具体实施时，可以通过预先训练得到的信用评定模型来判断用户是否满足电子信用卡的授予资格。具体的，该信用评定模型的类型可以包括神经网络模型等，并且可以是通过以下操作预先训练得到的：构建网络模型，以及将历史用户信用数据(用户身份信息)按照不同的组分占比分为训练集和测试集，例如，训练集和测试集的组分占比可以是1:2；分别将训练集和测试集输入到网络模型中进行训练和检验，并通过多次迭代最终得到信用评定模型。

这样，基于训练得到的信用评定模型，将解析得到的用户身份信息输入到该信用评定模型，即可得到模型的输出，然后根据模型的输出确定用户的信用评定结果。

具体的，信用评定模型的输出可以是“是否通过评定”，也可以是“个人信用评分”，或者“个人信用指数”等。这样，当模型的输出为“是否通过评定”时，模型的输出可以直接作为用户的信用评定结果；当模型的输出为“个人信用评分”时，基于预先设定的分数阈值，当所输出的个人信用评分大于或等于该分数阈值时则用户的信用评定结果为通过评定，否则未通过；当模型的输出为“个人信用指数”时，基于预先设定的指数百分比阈值，当所输出的个人信用指数大于或等于该指数百分比阈值时则用户的信用评定结果为通过评定，否则未通过。

进一步的，若用户的信用评定结果为通过评定，根据用户身份信息生成用户专属的电子信用卡，并将电子信用卡对应的账号以及账户名称(即用户名称)存储于数据库，以及将电子信用卡发送给用户。需要说明的是，所生成的电子信用卡的账号具有全局唯一性。

另外，在一些实施例中，响应于确定用户满足电子信用卡的授予资格，即，若用户的信用评定结果为通过评定，向该用户发送电子信用卡申请请求成功的第二提示信息。然后，可以进一步接收用户发送的信用支付额度设定信息；从而根据所述信用支付额度设定信息和所述用户身份信息，确定电子信用卡的信用支付额度，并将该信用支付额度反馈给用户以及存储于数据库。也就是说，可以根据用户自身设定的额度以及用户身份信息所包含的信用情况等进行综合评估以确定该电子信用卡的信用支付额度。这样，对于信用支付额度的设定，不仅是由发卡方(即基于电子信用卡的信用支付装置)单方面确定的，并且通过发卡方与用户的交互而确定，从而使得对于信用支付额度的设定更加客观，能够提升用户体验。

在一些实施例中，在步骤S101中，对于具有电子信用卡的用户，在支付时可以将自身的身份信息、支付事件信息以及电子信用卡的账号进行打包生成请求数据，以提起信用支付请求，也就是说，当用户想要基于电子信用卡进行信用支付时，会发送信用支付请求，则接收该信用支付请求。

在一些实施例中，在步骤S102中，当接收到用户发送的信用支付请求时，对该信用支付请求进行解析，以还原用户的请求数据。具体的，解析后的信用支付请求信息包括：用户身份信息、支付事件信息以及该用户的被预先授予的电子信用卡的账号；其中，支付事件信息可以包括支付对象和支付金额等；用户身份信息可以包括用户名称、身份证图像信息、当前人脸图像、信用信息等。

在一些实施例中，在步骤S103中，由于数据库中预先存储有(在前述实施例的电子信用卡的办理和授予过程中进行存储的)电子信用卡对应的账号、账户名称、信用支付额度以及电子信用卡的所属用户的身份信息等，并且账户名称、信用支付额度以及电子信用卡的所属用户的身份信息等信息均存储于相匹配的电子信用卡账号所对应的存储区域。即，这些存储信息与电子信用卡账号之间建立有相互对应的关联关系，并且这些存储信息可以统称为该电子信用卡的账户信息。这样，当解析得到用户的电子信用卡账号之后，可根据该账号在数据库中查找该账号下的电子信用卡的全部账户信息。

在一些实施例中，在步骤S104中，所预先设定的信用支付条件可以包括：上述解析得到的用户身份信息与在数据库中查找到的电子信用卡的账户信息中的账户名称一致，即用户名称与账户名称一致，并且解析得到的身份证图像信息、当前人脸图像等与在数据库中查找到的电子信用卡的账户信息中的其他同类型信息均一致；以及，信用支付条件还可以包括：上述解析得到的支付对象为医药机构、支付金额小于或等于信用支付额度。

这样，由于信用支付条件包括支付对象为医药机构，可以有效识别用户所支付订单的结算商户类型，并当且仅当用户在处于针对医药机构的支付场景的前提下才能够实现基于电子信用卡的信用支付，可以保证电子信用卡及其信用支付额度的专款专用。本实施例解决了相关技术中由于信用卡并非特定于医药场景而缺少专用性从而导致便捷性和效率均较低的问题，并且，由于仅涉及对支付对象的判定，则用户只要在支付对象为医药机构的前提下即可实现基于电子信用卡的信用支付，无需在特定地点(例如，医院、药店等)才能实现信用支付。

在一些实施例中，在步骤S105中，当用户符合上述全部信用支付条件，则调用基于电子信用卡的第一支付接口。需要说明的是，本实施例包括若干个连接有不同支付渠道的支付接口，例如，基于电子信用卡的第一支付接口，以及基于银行卡或医保卡等的其他支付接口。

在一些实施例中，在步骤S106中，基于调用的第一支付接口，可以直接通过该接口进行支付，以实现基于电子信用卡的信用支付。

在一些实施例中，在步骤S106之后，可以生成针对信用支付的历史交易记录，并将所述历史交易记录存储于数据库，以用于后续当用户有其他申请需求时可以调取该历史交易记录作为评定是否接受用户申请的参考。应当理解的是，该历史交易记录与前述实施例中的电子信用卡的账户信息存储于相同的存储区域，即存储于用户对应的电子信用卡的账号下。

作为本申请的另一种实现方式，为了使用户在不符合信用支付条件时，可以通过重新申请的方式最终实现基于电子信用卡的信用支付，本申请还提供了基于电子信用卡的信用支付的另一种实现方式，具体参见以下实施例。

参考图2，为本申请提供的基于电子信用卡的信用支付的另一种实现方法200，该方法200包括以下步骤：

S201、接收用户发送的信用支付请求；

S202、解析所述信用支付请求，得到用户身份信息、支付事件信息以及所述用户的被预先授予的电子信用卡的账号；

S203、在数据库中查找与所述电子信用卡的账号相匹配的电子信用卡的账户信息；

S204、根据所述用户身份信息、支付事件信息以及电子信用卡的账户信息判断所述用户是否符合预先设定的信用支付条件；

S205、响应于确定所述用户不符合所述信用支付条件，向所述用户发送信用支付请求失败的第一提示信息；

S206、接收用户发送的临时额度申请请求；在数据库中查找与所述电子信用卡的账户信息相匹配的历史交易记录；根据所述历史交易记录判断是否接受所述临时额度申请请求；响应于接受所述临时额度申请请求，将临时额度发放至所述用户的电子信用卡。

在一些实施例中，在步骤S205中，当用户不符合上述信用支付条件的任意一个条件时，则表明该用户针对信用支付的请求失败。为了不影响用户的支付进展，需要使得用户及时知晓信用支付请求的结果以及当结果为请求失败时的具体原因。也就是说，当用户不符合信用支付条件时向该用户发送信用支付请求失败的第一提示信息，并且，该第一提示信息包括用户不符合信用支付条件的原因。

在一些实施例中，在步骤S206中，当第一提示信息表明用户不符合信用支付条件的原因为信用支付额度不足时(即信用支付额度小于支付金额)，用户可以根据自身需求选择是否进一步申请临时额度，若申请则根据当前电子信用卡的信用支付额度与支付金额之间的差值确定临时额度，并发送临时额度申请请求。

进一步的，在一些实施例中，当接收到用户发送的临时额度申请请求时，可以基于该用户对应的历史申请中查找到其对应的电子信用卡账号，并根据电子信用卡账号在数据库中查找到该账号下的历史交易记录。从而，根据历史交易记录评定该用户的临时额度申请是否可以通过，具体的评定方式可以采用预先训练得到的临时额度评定模型，也可以采用其他方式，本实施例对此不做限定。

这样，如果接受用户的临时额度申请请求，则将临时额度发放至所述用户的电子信用卡，相当于对用户的电子信用卡的信用支付额度进行了更新，以使更新后的信用支付额度符合信用支付条件，从而在用户再次发起信用支付请求时，可以成功实现基于电子信用卡的信用支付。

应当理解的是，由于S201-S204与上述实施例中的S101-S104相同，因此为了简要起见，对于S201-S204各自对应的具体实现方式在此不再详细描述。

这样，用户可以基于电子信用卡的信用支付对医药费用先行扣除而无需等待缴费后才能进行就诊、开药等医疗环节，从而通过实现信用支付进一步实现了信用就医；并且在就诊结束后一定时间内一次性还清信用支付的费用即可，可以减少付费环节及排队等候，

另外，在一些实施例中，为保证用户在一定期限内针对信用支付费用完成还款，还设定了信用支付额度调整机制和警告提示机制。具体的，如果用户在规定的期限到达时，还未完成还款，则其电子信用卡账户被冻结，处于冻结状态的电子信用卡对应的用户无法再次进行基于电子信用卡的信用支付的申请请求，相应的，其电子信用卡的信用支付额度也会进行调整而降低。当用户完成还款后，将其电子信用卡恢复为正常状态。

在另一个实施例中，在步骤S205之后，还可以包括以下步骤：接收用户发送的个人支付请求；解析所述个人支付请求，得到目标支付接口的名称；根据所述目标支付接口的名称调用目标支付接口；通过所述目标支付接口进行支付。这样，当用户接收到第一提示信息后可以根据自身需求选择不再重新申请基于电子信用卡的信用支付，则发起个人支付请求，从而在接收到用户的个人支付请求之后可以解析得到对应的支付接口名称，进而调用对应的支付接口以进行支付。这样，可以使用户通过非信用支付的其他支付渠道来完成支付，提供给用户更多选择渠道，提升用户体验。

需要说明的是，上述对本申请的一些实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于上述实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

基于同一技术构思，与上述任一实施例方法相对应的，本申请还提供了一种基于电子信用卡的信用支付装置300。

如图3所示，该基于电子信用卡的信用支付装置300可以包括：

接收模块301，用于接收用户发送的信用支付请求；

解析模块302，用于解析所述信用支付请求，得到用户身份信息、支付事件信息以及所述用户的被预先授予的电子信用卡的账号；

查找模块303，用于在数据库中查找与所述电子信用卡的账号相匹配的电子信用卡的账户信息；

判断模块304，用于根据所述用户身份信息、支付事件信息以及电子信用卡的账户信息判断所述用户是否符合预先设定的信用支付条件；

调用模块305，用于响应于确定所述用户符合信用支付条件，调用基于电子信用卡的第一支付接口；

支付模块306，用于通过所述第一支付接口进行支付。

在一些实施例中，基于电子信用卡的信用支付装置300，还包括第一发送模块(图3中未示出)，该第一发送模块用于响应于确定所述用户不符合所述信用支付条件，向所述用户发送信用支付请求失败的第一提示信息。

在一些实施例中，基于电子信用卡的信用支付装置300，还包括发放模块(图3中未示出)，该发放模块用于接收用户发送的临时额度申请请求；在数据库中查找与所述电子信用卡的账户信息相匹配的历史交易记录；根据所述历史交易记录判断是否接受所述临时额度申请请求；响应于接受所述临时额度申请请求，将临时额度发放至所述用户的电子信用卡。

在一些实施例中，基于电子信用卡的信用支付装置300，还包括第一生成模块(图3中未示出)，该第一生成模块用于生成历史交易记录，并将所述历史交易记录存储于数据库。

在一些实施例中，基于电子信用卡的信用支付装置300，还包括第二发送模块(图3中未示出)，该第二发送模块用于接收用户发送的电子信用卡申请请求；根据所述电子信用卡申请请求，判断所述用户是否满足电子信用卡的授予资格；响应于确定所述用户满足电子信用卡的授予资格，向所述用户发送电子信用卡申请请求成功的第二提示信息。

在一些实施例中，基于电子信用卡的信用支付装置300，还包括第二生成模块(图3中未示出)，该第二生成模块用于响应于确定所述用户满足电子信用卡的授予资格，根据所述用户身份信息生成电子信用卡；将所述电子信用卡发送至所述用户。

在一些实施例中，基于电子信用卡的信用支付装置300，还包括确定模块(图3中未示出)，该确定模块用于接收用户发送的信用支付额度设定信息；根据所述信用支付额度设定信息和所述用户身份信息，确定电子信用卡的信用支付额度。

需要说明的是，为了描述的方便，描述以上装置时以功能分为各种模块分别描述。当然，在实施本申请时可以把各模块的功能在同一个或多个软件和/或硬件中实现。

上述实施例的装置用于实现前述任一实施例中相应的基于电子信用卡的信用支付方法，并且具有相应的方法实施例的有益效果，在此不再赘述。

进一步的，参考图4，本申请还提供了一种信用就医系统400，且该信用就医系统400包括基于电子信用卡的信用支付装置300。

如图4所示，该信用就医系统400还包括接入模块401、数据切分模块402和管理模块403。

在一些实施例中，接入模块401可以用于根据预先建立的统一对接标准，支持医院公众号、小程序、APP、政务平台、医院HIS系统、银行支付结算系统等渠道的接入；以及，接入医保服务从而以医保提供的身份认证体系为基础。这样，基于该接入模块401，通过信用就医系统400可以实现预约挂号、门诊缴费、医保统筹报销、专用医疗信用额度及提额申请、诊间无感支付结算、住院押金出院结算、亲情付和聚合支付等。

在一些实施例中，数据切分模块402可以用于建立完善的数据切分机制，即根据不同的应用场景执行数据库分库，提高系统处理高并发的读写访问效率。具体的，可以包括：管理数据库(Administrative database)、生产数据库(Operational database)、查询数据库(Query database)、历史交易数据库(Historical transaction database)和数据仓库(Data warehouse)。

其中，管理数据库用于存储信用就医系统400的管理和运营数据，例如，医院、药房等信息；生产数据库用于存储信用就医系统400的业务运行数据，支持系统的核心业务系统和工作流程，例如订单、账目、库存等数据；查询数据库用于分析和报告目的的数据集，可以定期从生产数据库和其他来源加载数据以进行数据分析和业务报告；历史交易数据库用于存储信用就医系统400的历史交易数据以进行数据分析和趋势回顾；数据仓库可以是一个集成的、时间变化的数据集合，由管理数据库、生产数据库、历史数据库和外部数据源的数据聚合而成，用于多维数据分析和挖掘。

在一些实施例中，管理模块403可以用于业务人员登录系统管理端，维护管理端用户的角色权限、配置相关参数等；管理系统内所有的用户信用就医签约/解约记录、签约状态管理以及按实际情况在安全规范下进行调整；对用户挂号订单的管理，例如，根据用户选择的医院和科室医生实现挂号订单的生成，将挂号订单传到医院侧，收到回调后，生成系统订单，从而在获得高级权限后能够实现对订单的查询、增加、修改；查看系统所有交易的实时统计、交易差错率等，并进行监控管理；完成系统日终处理，包括对账文件生成及对账单推动，系统报表生成，业务人员监控系统作业节点的完成情况；以及，对信用就医交易涉及的医药场所进行管理，例如，对医院的平台编号、状态变更、对接渠道、入网参数等以及医院信息进行管理。

应当理解的是，信用就医系统400还包括由主机、存储系统、网络系统、安全系统和软件系统构成的基础设施层，并且信用就医系统400可以部署在安全机房，遵循各方生产系统安全保障体系。

这样，基于信用就医系统400，用户在预约挂号时可以选择是否开通信用就医，如不选择开通信用就医，则直接预约挂号就诊；如选择开通信用就医，则基于该信用就医系统400的信用支付装置300实现基于电子信用卡的信用支付，从而实现信用就医。

此外，图5示出了实现上述信用就医系统400的技术架构500。由于信用就医系统400的系统结构包括客户层、应用层(包括控制层、业务层和基础服务层)和数据层(包括访问层和存储层)，则对应的，如图5所示，技术架构500包括客户端执行架构501、应用层执行架构502和数据库执行架构503。

具体的，可以采用Springboot+mybatis+mysql的技术架构，视图层用Vue开发框架进行渲染，并结合jdk((Java Development Kit Java开发工具包))、tomcat等运营环境；通过mybatis控制SQL(结构化查询语言，Structured Query Language)发送的数目，提高数据层执行效率，并且实现代码和SQL分离，降低项目风险；基于linux操作系统构建应用平台；通过nginx实现前后端分离，提高交互效率。

基于同一技术构思，与上述任一实施例方法相对应的，本申请还提供了一种电子设备。

图6示出了本实施例所提供的一种更为具体的电子设备硬件结构示意图。

在电子设备600可以包括处理器601以及存储有计算机程序指令的存储器602。

具体地，上述处理器601可以包括中央处理器(CPU)，或者特定集成电路(Application Specific Integrated Circuit，ASIC)，或者可以被配置成实施本申请实施例的一个或多个集成电路。

存储器602可以包括用于数据或指令的大容量存储器。举例来说而非限制，存储器602可包括硬盘驱动器(Hard Disk Drive，HDD)、软盘驱动器、闪存、光盘、磁光盘、磁带或通用串行总线(Universal Serial Bus，USB)驱动器或者两个或更多个以上这些的组合。在合适的情况下，存储器602可包括可移除或不可移除(或固定)的介质。在合适的情况下，存储器602可在综合网关容灾设备的内部或外部。在特定实施例中，存储器602是非易失性固态存储器。

在特定实施例中，存储器可包括只读存储器(ROM)，随机存取存储器(RAM)，磁盘存储介质设备，光存储介质设备，闪存设备，电气、光学或其他物理/有形的存储器存储设备。因此，通常，存储器包括一个或多个编码有包括计算机可执行指令的软件的有形(非暂态)计算机可读存储介质(例如，存储器设备)，并且当该软件被执行(例如，由一个或多个处理器)时，其可操作来执行参考根据本申请的一方面的方法所描述的操作。

处理器601通过读取并执行存储器602中存储的计算机程序指令，以实现上述实施例中的任意一种基于电子信用卡的信用支付方法。

在一些示例中，电子设备600还可包括通信接口603和总线610。其中，如图6所示，处理器601、存储器602、通信接口603通过总线610连接并完成相互间的通信。

通信接口603主要用于实现本申请实施例中各模块、装置、单元和/或设备之间的通信。

总线610包括硬件、软件或两者，将在线数据流量计费设备的部件彼此耦接在一起。举例来说而非限制，总线610可包括加速图形端口(AGP)或其他图形总线、增强工业标准架构(EISA)总线、前端总线(FSB)、超传输(HT)互连、工业标准架构(ISA)总线、无限带宽互连、低引脚数(LPC)总线、存储器总线、微信道架构(MCA)总线、外围组件互连(PCI)总线、PCI-Express(PCI-X)总线、串行高级技术附件(SATA)总线、视频电子标准协会局部(VLB)总线或其他合适的总线或者两个或更多个以上这些的组合。在合适的情况下，总线610可包括一个或多个总线。尽管本申请实施例描述和示出了特定的总线，但本申请考虑任何合适的总线或互连。

示例性的，电子设备600可以为手机、平板电脑、笔记本电脑、掌上电脑、车载电子设备、超级移动个人计算机(ultra-mobile personal computer，UMPC)、上网本或者个人数字助理(personal digital assistant，PDA)等。

基于同一技术构思，与上述任一实施例方法相对应的，本申请还提供了一种非暂态计算机可读存储介质。该计算机可读存储介质上存储有计算机程序指令；该计算机程序指令被处理器执行时实现上述实施例中的任意一种基于电子信用卡的信用支付方法。计算机可读存储介质的示例包括非暂态计算机可读存储介质，如便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件等。

基于同一技术构思，与上述任一实施例方法相对应的，本申请还提供了一种计算机程序产品，其包括计算机程序指令。在一些实施例中，所述计算机程序指令可以由计算机的一个或多个处理器执行以使得所述计算机和/或所述处理器执行所述的基于电子信用卡的信用支付方法。对应于所述的基于电子信用卡的信用支付方法各实施例中各步骤对应的执行主体，执行相应步骤的处理器可以是属于相应执行主体的。

需要明确的是，本申请并不局限于上文所描述并在图中示出的特定配置和处理。为了简明起见，这里省略了对已知方法的详细描述。在上述实施例中，描述和示出了若干具体的步骤作为示例。但是，本申请的方法过程并不限于所描述和示出的具体步骤，本领域的技术人员可以在领会本申请的精神后，作出各种改变、修改和添加，或者改变步骤之间的顺序。

以上所述的结构框图中所示的功能块可以实现为硬件、软件、固件或者它们的组合。当以硬件方式实现时，其可以例如是电子电路、专用集成电路(ASIC)、适当的固件、插件、功能卡等等。当以软件方式实现时，本申请的元素是被用于执行所需任务的程序或者代码段。程序或者代码段可以存储在机器可读介质中，或者通过载波中携带的数据信号在传输介质或者通信链路上传送。“机器可读介质”可以包括能够存储或传输信息的任何介质。机器可读介质的例子包括电子电路、半导体存储器设备、ROM、闪存、可擦除ROM(EROM)、软盘、CD-ROM、光盘、硬盘、光纤介质、射频(RF)链路，等等。代码段可以经由诸如因特网、内联网等的计算机网络被下载。

还需要说明的是，本申请中提及的示例性实施例，基于一系列的步骤或者装置描述一些方法或系统。但是，本申请不局限于上述步骤的顺序，也就是说，可以按照实施例中提及的顺序执行步骤，也可以不同于实施例中的顺序，或者若干步骤同时执行。

上面参考根据本申请的实施例的方法、装置(系统)和计算机程序产品的流程图和/或框图描述了本申请的各方面。应当理解，流程图和/或框图中的每个方框以及流程图和/或框图中各方框的组合可以由计算机程序指令实现。这些计算机程序指令可被提供给通用计算机、专用计算机、或其它可编程数据处理装置的处理器，以产生一种机器，使得经由计算机或其它可编程数据处理装置的处理器执行的这些指令使能对流程图和/或框图的一个或多个方框中指定的功能/动作的实现。这种处理器可以是但不限于是通用处理器、专用处理器、特殊应用处理器或者现场可编程逻辑电路。还可理解，框图和/或流程图中的每个方框以及框图和/或流程图中的方框的组合，也可以由执行指定的功能或动作的专用硬件来实现，或可由专用硬件和计算机指令的组合来实现。

以上所述，仅为本申请的具体实施方式，所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，上述描述的系统、模块和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。应理解，本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到各种等效的修改或替换，这些修改或替换都应涵盖在本申请的保护范围之内。

Claims (13)

1.一种基于电子信用卡的信用支付方法，其特征在于，包括：

接收用户发送的信用支付请求；

解析所述信用支付请求，得到用户身份信息、支付事件信息以及所述用户的被预先授予的电子信用卡的账号；

在数据库中查找与所述电子信用卡的账号相匹配的电子信用卡的账户信息；

根据所述用户身份信息、支付事件信息以及电子信用卡的账户信息判断所述用户是否符合预先设定的信用支付条件；

响应于确定所述用户符合信用支付条件，调用基于电子信用卡的第一支付接口；

通过所述第一支付接口进行支付。

2.根据权利要求1所述的方法，其特征在于，所述支付事件信息包括：支付对象和支付金额；所述电子信用卡的账户信息包括：账户名称和信用支付额度；

所述信用支付条件包括：所述账户名称与所述用户身份信息一致、所述支付对象为医药机构以及所述支付金额小于或等于所述信用支付额度。

3.根据权利要求1所述的方法，其特征在于，在所述根据所述用户身份信息、支付事件信息以及电子信用卡的账户信息判断所述用户是否符合预先设定的信用支付条件之后，所述方法还包括：

响应于确定所述用户不符合所述信用支付条件，向所述用户发送信用支付请求失败的第一提示信息。

4.根据权利要求3所述的方法，其特征在于，在所述响应于确定所述用户不符合所述信用支付条件，向所述用户发送信用支付请求失败的第一提示信息之后，所述方法还包括：

接收用户发送的个人支付请求；

解析所述个人支付请求，得到目标支付接口的名称；

根据所述目标支付接口的名称调用目标支付接口；

通过所述目标支付接口进行支付。

5.根据权利要求3所述的方法，其特征在于，在所述响应于确定所述用户不符合所述信用支付条件，向所述用户发送信用支付请求失败的第一提示信息之后，所述方法还包括：

接收用户发送的临时额度申请请求；

在数据库中查找与所述电子信用卡的账户信息相匹配的历史交易记录；

根据所述历史交易记录判断是否接受所述临时额度申请请求；

响应于接受所述临时额度申请请求，将临时额度发放至所述用户的电子信用卡。

6.根据权利要求1所述的方法，其特征在于，在所述通过所述第一支付接口进行支付之后，所述方法还包括：

生成历史交易记录，并将所述历史交易记录存储于数据库。

7.根据权利要求1所述的方法，其特征在于，在所述接收用户发送的信用支付请求之前，所述方法还包括：

接收用户发送的电子信用卡申请请求；

根据所述电子信用卡申请请求，判断所述用户是否满足电子信用卡的授予资格；

响应于确定所述用户满足电子信用卡的授予资格，向所述用户发送电子信用卡申请请求成功的第二提示信息。

8.根据权利要求7所述的方法，其特征在于，所述电子信用卡申请请求包括用户身份信息；

在所述根据所述电子信用卡申请请求，判断所述用户是否满足电子信用卡的授予资格之后，所述方法还包括：

响应于确定所述用户满足电子信用卡的授予资格，根据所述用户身份信息生成电子信用卡；

将所述电子信用卡发送至所述用户。

9.根据权利要求8所述的方法，其特征在于，在所述响应于确定所述用户满足电子信用卡的授予资格，向所述用户发送电子信用卡申请请求成功的第二提示信息之后，所述方法还包括：

接收用户发送的信用支付额度设定信息；

根据所述信用支付额度设定信息和所述用户身份信息，确定电子信用卡的信用支付额度。

10.一种基于电子信用卡的信用支付装置，其特征在于，所述装置包括：

接收模块，用于接收用户发送的信用支付请求；

解析模块，用于解析所述信用支付请求，得到用户身份信息、支付事件信息以及所述用户的被预先授予的电子信用卡的账号；

查找模块，用于在数据库中查找与所述电子信用卡的账号相匹配的电子信用卡的账户信息；

判断模块，用于根据所述用户身份信息、支付事件信息以及电子信用卡的账户信息判断所述用户是否符合预先设定的信用支付条件；

调用模块，用于响应于确定所述用户符合信用支付条件，调用基于电子信用卡的第一支付接口；

支付模块，用于通过所述第一支付接口进行支付。

11.一种电子设备，其特征在于，所述设备包括：处理器以及存储有计算机程序指令的存储器；所述处理器执行所述计算机程序指令时实现如权利要求1-9中任意一项所述的基于电子信用卡的信用支付方法。

12.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序指令，所述计算机程序指令被处理器执行时实现如权利要求1-9中任意一项所述的基于电子信用卡的信用支付方法。

13.一种计算机程序产品，其特征在于，所述计算机程序产品中的指令由电子设备的处理器执行时，使得所述电子设备执行如权利要求1-9中任意一项所述的基于电子信用卡的信用支付方法。