CN110415069A - 基于金融业务的订单处理方法、装置、系统和存储介质 - Google Patents

Abstract

本申请涉及一种基于金融业务的订单处理方法、装置、系统和存储介质，其中方法包括：获取用户通过终端输入的登录信息，若登录信息有效，则返回与登录信息对应的业务信息列表；接收根据业务信息列表选择的业务标识，根据业务标识获取对应的业务需求信息；根据业务需求信息生成待购清单，获取根据待购清单选择的订单请求，其中，订单请求中包括对应的业务标识及业务明细信息；根据业务标识及业务明细信息对订单请求进行校验，若校验通过则生成订单。使得用户可以方便的根据待购清单发起对若干业务的购买操作，通过订单模式实现对金融业务的交付，以简化金融业务的处理流程，极大的提高了金融业务的办理效率。

Description

基于金融业务的订单处理方法、装置、系统和存储介质

技术领域

本申请涉及互联网技术领域，特别是涉及一种基于金融业务的订单处理方法、装置、系统和存储介质。

背景技术

随着互联网系统的高速发展，金融业业务由单纯的线下业务逐步向线上拓展，形成了线下、线上混合经营的发展趋势。但是，由于金融业务种类繁多，后台系统数量庞大，不同的业务有各自的交易形式，且业务规则也各不相同。因此，目前无论是通过线下渠道还是线上渠道办理业务，业务办理过程中填单多、签字多、输密多，其流程较为复杂。

发明内容

基于此，有必要针对上述金融业务处理流程复杂的问题，提供一种简化的基于金融业务的订单处理方法、装置、系统和存储介质。

为了实现上述目的，一方面，本申请实施例提供了一种基于金融业务的订单处理方法，包括：获取用户通过终端输入的登录信息，若登录信息有效，则返回与登录信息对应的业务信息列表；接收根据业务信息列表选择的业务标识，根据业务标识获取对应的业务需求信息；根据业务需求信息生成待购清单，获取根据待购清单选择的订单请求，其中，订单请求中包括对应的业务标识及业务明细信息；根据业务标识及业务明细信息对订单请求进行校验，若校验通过则生成订单。

另一方面，本申请实施例还提供了一种基于金融业务的订单处理装置，包括：

信息获取模块，用于获取用户通过终端输入的登录信息，若登录信息有效，则返回与登录信息对应的业务信息列表；以及接收根据业务信息列表选择的业务标识，根据业务标识获取对应的业务需求信息；

待购清单生成模块，用于根据业务需求信息生成待购清单，获取根据待购清单选择的订单请求，其中，订单请求中包括对应的业务标识及业务明细信息；

订单生成模块，用于根据业务标识及业务明细信息对订单请求进行校验，若校验通过则生成订单。

又一方面，本申请实施例还提供了一种基于金融业务的订单处理系统，包括存储器和处理器，其中，存储器存储有计算机程序，处理器执行计算机程序时实现如上所述方法的步骤。

再一方面，本申请实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现如上所述方法的步骤。

上述基于金融业务的订单处理方法、装置、系统和存储介质，服务器根据用户的登录信息返回对应的业务信息列表，进而根据用户的选择调用对应的业务接口以获取业务需求信息，并生成待购清单，使得用户可以方便的根据待购清单发起对若干业务的购买操作，通过订单模式实现对金融业务的交付，以简化金融业务的处理流程，极大的提高了金融业务的办理效率。

附图说明

图1为一个实施例中基于金融业务的订单处理方法的应用环境图；

图2为一个实施例中基于金融业务的订单处理方法的流程示意图；

图3为一个实施例中登录页面的示意图；

图4为一个实施例中查询页面的示意图；

图5为一个实施例中配置信息的页面示意图；

图6为一个实施例中购物车页面的示意图；

图7为另一个实施例中基于金融业务的订单处理方法的流程示意图；

图8为一个实施例中根据业务标识及业务明细信息对订单请求进行校验的步骤的流程示意图；

图9为又一个实施例中基于金融业务的订单处理方法的流程示意图；

图10为再一个实施例中基于金融业务的订单处理方法的流程示意图；

图11为一个实施例中基于金融业务的订单处理方法的流程示意图；

图12为一个实施例中基于金融业务的订单处理方法应用的系统架构示意图；

图13为一个实施例中基于金融业务的订单处理装置的结构框图；

图14为一个实施例中计算机设备的内部结构图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。

由于目前无论是通过线下渠道还是线上渠道办理金融业务，业务办理过程中填单多、签字多、输密多，且目前单次只能办理一个业务，导致其业务办理流程较为复杂。而同一业务相对于线上渠道、线下渠道又相互独立，这又使得线上、线下业务之间无法互通，导致业务上下架开发工作量大。

基于此，本申请提供了一种基于金融业务的订单处理方法，可以应用于如图1所示的应用环境中。其中，终端102通过网络与服务器104进行通信。在本实施例中，当用户需要办理金融业务时，可以通过终端102输入登录信息，服务器104对登录信息的有效性进行验证，进而返回对应的业务信息列表，并接收用户通过终端102显示的业务信息列表而选择的业务标识，服务器104则根据用户选择的业务标识获取对应的业务需求信息，进而根据业务需求信息生成待购清单，并获取用户通过终端102在待购清单中选择的订单请求，服务器104对订单请求进行校验，当校验通过时则生成对应的订单。从而通过订单模式实现对金融业务的交付，以简化金融业务的处理流程。

在本实施例中，终端102可以但不限于是各种个人计算机、笔记本电脑、智能手机、平板电脑和便携式可穿戴设备，服务器104可以用独立的服务器或者是多个服务器组成的服务器集群来实现，当然，服务器104也可以采用云服务器实现。

在一个实施例中，如图2所示，提供了一种基于金融业务的订单处理方法，以该方法应用于图1中的服务器为例进行说明，具体可以包括以下步骤：

步骤202，获取用户通过终端输入的登录信息。

在本实施例中，当用户需要办理金融业务时，可以通过终端输入登录信息，服务器则根据终端传输的登录信息进行有效性判断，其中，登录信息可以是用户的唯一标识，如具有唯一性的用户名(帐号)、证件号码等(如图3所示的登录界面，通过帐号可关联对应的客户类型信息，通过输入帐号和证件号码可生成排队号，并自动计算等待时间以及等待人数。具体的，服务器中存储有注册用户的用户信息，该用户信息中包括与用户对应的登录信息，服务器根据获取的登录信息在预先存储的用户信息中进行查找，当存在与登录信息匹配的用户信息时，则表示登录信息有效，顺次执行步骤204。当用户信息中不存在与登录信息匹配的信息时，则表示登录信息无效，从而结束流程。

步骤204，返回与登录信息对应的业务信息列表。

通常，对于金融业务来说，既包括具有实体产品的产品业务，如银行卡开卡业务、密码盘申请业务等，也包括没有实体产品的虚拟产品业务，如修改密码服务业务、网银签约服务业务等。在本实施例中，每一种业务在上线时都会根据注册用户的等级或权限设置对其开放或是不开放。因此，服务器根据用户的登录信息查询对其开放的业务，并通过列表的形式将查询到的业务返回至终端(如图4所示的界面，返回的业务列表包括业务编号、业务名称以及业务分类等信息)。

步骤206，接收根据业务信息列表选择的业务标识，并根据业务标识获取对应的业务需求信息。

具体的，用户可以根据自身需求在终端显示的业务信息列表中选择待办理业务的业务标识(可通过如图4所示的选择框进行选择)，服务器则根据终端传输的用户选择的业务标识调用对应的业务接口，从而根据预先对业务的配置信息而获取对应业务的业务需求信息，其中，业务需求信息可以是与业务相关的个性化要求。假设用户根据图4的界面选择了“综合签约”的业务，服务器则调用对应的业务接口，通过业务接口返回如图5所示的预先对此业务的配置信息界面，从而引导用户根据预先对业务的配置信息完善业务需求信息。例如，对应的划扣日期和划扣周期可根据用户的实际需求进行个性化设定，操作类型可以根据下拉菜单进行选择，帐号和户名信息可以通过终端录入其中任意一项，另一项即可产生自动关联。服务器则获取此类信息作为对应的业务需求信息。可以理解的是，对应于实际业务的不同，对应的业务需求信息也不同，例如，对于更新证件信息的业务，其业务需求信息则包括待更新证件的相关信息以及待更新证件的复印件或扫描件等。

步骤208，根据业务需求信息生成待购清单，获取根据待购清单选择的订单请求。

其中，待购清单是指用户有意向购买的若干个业务的业务列表，其包括用户的唯一标识、业务标识(如业务编号以及业务名称等)以及业务明细信息等。如图6所示，其对应于图5所示的“综合签约”业务的待购清单。服务器生成待购清单后，可以通过终端显示对应的待购清单(即图6中的购物车)，使得用户可以根据显示的待购清单进一步发起对业务的购买操作。如用户可以根据显示的待购清单选择一个或多个业务进行购买(即创建订单)，终端则根据用户选择的业务向服务器发起订单请求，其中，订单请求中包括对应的业务标识及业务明细信息等。

步骤210，根据业务标识及业务明细信息对订单请求进行校验，若校验通过则生成订单。

具体的，服务器接收到订单请求后，根据订单请求中的业务标识以及相应的业务明细信息对其合法性进行校验，只有当校验合法时则根据订单请求生成对应的订单。

上述基于金融业务的订单处理方法，服务器可以根据用户的登录信息返回对应的业务信息列表，进而根据用户的选择调用对应的业务接口以获取业务需求信息，并生成待购清单，使得用户可以方便的根据待购清单发起对若干业务的购买操作，并且以用户和订单为视角，将原本单一渠道的交易服务拆解，通过订单的形式展现在多渠道上，并以订单模式实现对金融业务的交付，以简化金融业务的处理流程，且一个订单中可以发起对若干个业务的操作请求，极大的提高了金融业务的办理效率。

在一个实施例中，如图7所示，在根据业务需求信息生成待购清单之前，还包括如下步骤：

步骤702，根据业务需求信息映射对应的产品信息以确定对应的库存是否充足。

其中，产品信息包括在服务器中实时更新的产品业务的库存情况。在本实施例中，服务器根据业务需求信息映射服务器中的产品信息，从而判断与业务需求对应的产品业务的库存是否充足。举例来说，对于实体产品业务来说，产品业务的库存数量是指产品的实际在库数量，若库存产品的数量大于零，则表示对应产品业务的库存充足。对于虚拟产品业务来说，某些业务的办理次数受限，则对应产品业务的库存数量是指相应的剩余办理次数，若剩余办理次数大于零，则表示对应产品业务的库存充足。在本实施例中，当确定与业务需求对应的产品业务的库存充足时，则顺次执行步骤704，否则结束流程，不生成与业务需求信息对应的待购清单。

步骤704，根据预先存储的报价信息计算与业务需求信息对应的业务的价格。

其中，预先存储的报价信息是指产品业务上架时一并配置的标准价格(如交易金额、工本费、手续费以及税费等)和对应产品业务的促销规则。具体的，服务器根据预先存储的报价信息计算与业务需求信息对应的产品业务的价格，进而将对应的产品业务以及相关信息添加至待购清单，如产品业务的相关信息可以包括对应的业务标识、业务需求信息以及上述计算的价格等。

在本实施例中，通过在生成待购清单之前，对产品业务的库存进行校验，并在库存充足时，进一步计算对应产品业务的价格，从而使得用户能够提前获知对应产品业务的库存情况以及价格信息，对于后续是否办理此业务的决策起到辅助的作用。

在一个实施例中，在根据业务需求信息生成待购清单之前，服务器还可以根据预先存储的产品关系数据校验当前业务与待购清单中的其他业务之间是否存在互斥关系，若不存在互斥关系，则将对应的业务添加至待购清单，否则不添加至待购清单。

其中，产品关系数据包括产品业务之间的逻辑关系数据，对于金融产品业务来说，某些产品业务之间具有较为严格的先后逻辑顺序，不能在同一订单中发起对这两种产品业务的操作(比如开户和销户)，即这两种产品业务之间存在互斥关系。因此，在本实施例中，服务器根据预先存储的产品关系数据校验当前待加入待购清单的产品业务与待购清单中已经存在的其他产品业务之间是否存在上述互斥关系，只有在确定其不存在互斥关系时，才将对应的产品业务添加至待购清单中。

在一个实施例中，如图8所示，根据业务标识及业务明细信息对订单请求进行校验，具体可以包括如下步骤：

步骤802，根据业务标识及业务明细信息映射对应的产品信息以确定当前的库存是否充足。

步骤804，当确定当前的库存充足时，则校验通过。

通常，生成待购清单只是表示用户对相应的产品业务感兴趣，但此时并未与产品业务的提供方达成契约，只有生成订单后，才表示与产品业务的提供方达成契约。而且，当用户提交订单请求与生成待购清单的时间间隔较大时，产品业务库存变化往往也较大，因此，在本实施例中，当用户提交订单请求时，需要再次对相应的产品业务的库存量进行校验。具体的，本实施例中对于库存的具体校验过程与上述步骤702相类似，此处不再赘述。

在一个实施例中，服务器还可以根据预先存储的黒名单信息对与订单请求对应的登录信息进行校验。具体的，服务器中还存储有黑名单信息，如用户违规操作或逾期未还款等，对应的用户则会被纳入黑名单中。在本实施例中，服务器根据用户提交的订单请求，对与订单请求对应的登录信息进行校验，从而判断对应的用户是否属于黑名单中的用户。只有当用户不属于黑名单中的用户时，则检验通过，否则校验不通过。

在本实施例中，只有当校验通过后，服务器才根据订单请求生成对应的订单信息，其中，订单信息中包括相应的订单号、业务标识及对应的业务明细信息、还可以包括与登录信息对应的用户标识以及订单费用等。具体的，订单费用可以是根据对应的产品业务在生成待购清单时计算的价格进行汇总后的费用，当然，在汇总费用时还应考虑产品业务提供方的促销规则，以进行一并汇总。

在本实施例中，通过在生成订单之前，对产品业务的库存进行再次校验、以及对发起订单请求的用户进行校验，只有在校验通过时，才生成订单，以与产品业务的提供方达成有效的契约。且用户可以通过生成的订单信息获知相关的费用等信息，产品业务的提供方则可以根据生成的订单信息安排后续的订单交付工作，且无论是进行线上的交付还是线下的交付都能融合贯通。

在一个实施例中，如图9所示，在若校验通过则生成订单之后，本申请的方法还包括如下步骤：

步骤902，根据订单返回支付信息列表。

步骤904，接收根据支付信息列表选择的支付方式，根据选择的支付方式调用对应的支付接口。

在本实施例中，当服务器根据校验结果生成订单之后，还可以根据订单返回对应的支付信息列表，具体的，支付信息列表中包括对应的订单号、订单费用以及多种支付方式，从而使得用户可以根据支付信息列表选择适合的支付方式。在本实施例中，对于每一种支付方式都预设有相应的支付接口，因此，当服务器接收到用户选择的支付方式后，则根据支付方式调用对应的支付接口，该支付接口用于指示终端完成相应的支付。

步骤906，接收终端完成对应的支付后返回的支付应答消息，根据支付应答消息生成支付结果。

具体的，终端完成支付后，还可以向服务器返回支付应答消息，其中，支付应答消息可以是对本次支付成功与否的消息。服务器则根据支付应答消息生成支付结果，在本实施例中，支付结果具体可以包括对应的订单号、支付金额、支付流水号、支付成功与否等信息。

在上述实施例中，促销规则可以是根据用户群体、产品业务、支付方式、销售渠道、地区等不同维度制定的优惠规则，使得对应产品业务的销售更具灵活性。

本实施例通过将产品业务和支付分离，并可实现将用户需要办理的多笔业务添加到待购清单中，同时可以查看待购清单内产品业务的关系、费用明细、订单费用、促销规则及明细，核准后通过一次支付完成订单对应的全部产品业务的支付，从而减少用户签字、输密等重动作，精简冗杂的操作程序，缩短业务办理时间，提升服务质量。

在一个实施例中，如图10所示，在上述根据订单返回支付信息列表之前，还可以包括如下步骤：

步骤1002，调用预先设置的核验接口对订单的有效性进行核验。

具体的，由于金融业务的特殊性，对于某些特定的产品业务，在对订单进行支付之前，业务提供方需要进一步对用户的实物资料进行核验，从而确保金融业务办理的安全性及有效性。在本实施例中，当订单费用中涉及的现金费用为零时，在对订单进行支付之前，服务器还需要调用预先设置的核验接口对订单的有效性进行核验，即需要对订单内对应的业务的有效性进行核验。其中，预先设置的核验接口可以是对应的系统接口。例如，当订单中对应某一业务为更新证件信息，其不涉及到现金交易，因此，在对订单进行支付之前，服务器则调用预先设置的核验接口对该业务对应的业务需求信息进行核验，当核验完成时，则对订单内的其他业务进行核验，当核验未完成时，则引导用户重新录入对应的业务需求信息，以进行再次核验，当服务器未接收到用户重新录入的业务需求信息时，则取消对应的订单。

步骤1004，若对订单对应的部分业务或全部业务核验有效，则根据核验有效的业务重新计算订单对应的费用。

具体的，核验接口在对某一业务核验完成时，会记录对当前业务的检验结果是否有效，服务器则根据订单对应的核验结果为有效的部分业务或全部业务重新计算订单对应的费用，即在原有订单费用的基础上删除核验无效的业务对应的费用，并根据重新计算的订单的费用返回支付信息列表，在确保订单内业务有效性的同时也维护了用户利益。

在本实施例中，当终端按照上述方法完成对应的支付后返回的支付应答消息为支付成功时，则服务器还可以根据核验有效的业务对应的业务明细信息调用预先设置的交付网关完成对应订单的交付。例如，若对应业务为实体的产品业务，则通过交付网关将对应业务分发至相关部门，以对相应实体的产品业务进行货运；若对应业务为虚拟产品业务，则通过交付网关完成对虚拟产品业务的交付。当订单对应的有效的业务全部交付成功后，服务器还可以向终端返回与该订单对应的交付凭证，以便于用户及时了解订单的执行情况。本实施例通过对实体的产品业务和虚拟产品业务集中运营交付，从而灵活的产品组合和销售，满足特色化产品服务，进一步提升了原有业务价值。

在一个实施例中，当订单费用中涉及的现金费用大于零时则需要先完成对应的支付且支付成功后，服务器才调用预先设置的核验接口对订单的有效性进行核验。具体的核验过程如上述实施例所述，本实施例中不再赘述。在本实施例中，由于是先支付后核验，因此，当服务器对订单中的部分业务核验无效时，则无法完成对此部分业务的交付，服务器则根据核验无效的部分业务调用预先设置的退款接口，退款接口用于指示终端完成相应的退款。具体的，服务器根据核验无效的部分业务计算无效业务对应的费用，进而通过退款接口完成相应费用的退还，从而极大程度的保障了用户的利益。在本实施例中，服务器还可以根据核验有效的业务对应的业务明细信息调用预先设置的交付网关完成对应订单的交付。并在订单对应的有效的业务全部交付成功后，向终端返回与该订单对应的交付凭证，以便于用户及时了解订单的执行情况。

在一个实施例中，通过一个具体的实施例进一步说明本申请的方法，如图11所示，包括如下步骤：

步骤1101，获取用户的登录信息以识别用户，并在识别用户有效后返回对应的业务信息列表。

步骤1102，接收用户选择的业务标识。

步骤1103，根据业务标识获取对应的业务需求信息。

步骤1104，根据业务需求信息对相应业务的库存以及是否存在互斥关系进行识别，若库存充足且不存在互斥关系时，执行步骤1105，否则结束流程。

步骤1105，将对应的业务添加至待购清单中。

步骤1106，接收订单请求，订单请求中包括若干个业务对应的业务标识及业务明细信息。

步骤1107，根据订单请求对相应业务的库存以及用户的有效性进行识别，若库存充足且用户有效时，执行步骤1108，否则结束流程。

步骤1108，生成订单，包括相应的订单信息：订单号、业务标识及对应的业务明细信息、与所述登录信息对应的用户标识以及订单费用等。

步骤1109，判断订单对应的订单费用中涉及的现金费用是否大于零，若是则执行步骤1110，否则执行步骤1112。

步骤1110，展示支付方式，调用对应的支付接口进行支付。

步骤1111，若支付成功则判断是否完成核验。若支付成功但未完成对订单的核验则执行步骤1112，若支付成功且已完成对订单的核验则执行步骤1115，若支付不成功则重新发起支付或结束流程。

步骤1112，调用核验接口核验订单的所有业务。

步骤1113，根据订单的核验结果重新计算费用，如需退费则执行步骤1114，如需支付则执行步骤1110。

步骤1114，调用退款接口进行退费处理。

步骤1115，调用交付网关对核验有效的业务进行交付。

步骤1116，交付完成则返回与订单对应的交付凭证。

上述基于金融业务的订单处理方法，通过对订单的创建、核验、支付、交付的业务支持，对产品服务进行集中运营，规范了对用户业务办理的流程，实现了对用户需求响应的快速匹配支撑以及对产品服务的全流程管理。

应该理解的是，虽然图2-11的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，图2-11中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些子步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。

在一个实施例中，上述基于金融业务的订单处理方法可以应用于如图12所示的系统架构，具体的，该系统架构包括标准应用组件层、行业化组件层以及服务层，其中：

标准应用组件层由金融服务商的科技系统作为工厂端提供标准的、原子化的、模块化的接口服务，主要包括客户管理(客户信息的管理)、产品管理(可进行产品信息的管理、产品关系数据的管理)、订单管理(包括对购物车中待购清单的管理、订单的管理、报价管理、库存管理、货运管理以及对应的统计分析等)、账务管理(包括支付网关及支付接口的管理、交付网关的管理等)以及内容管理等基础功能的实现。

行业化组件层则通过对标准应用组件层提供的原子服务进行组装，以实现通用的行业模型，如根据标准应用组件层中的产品管理对产品关系进行试算，根据标准应用组件层中的产品管理和订单管理生成对应的订单费用等。

服务层通过行业化组件层的支撑，提供用于金融服务商与客户进行交互的桥梁，提供面向客户的服务，主要功能包括购物车管理(即待购清单的管理)、订单查询、支付工具的查询、运营数据管理等。

在一个实施例中，提供了一种基于金融业务的订单处理装置，如图13所示，包括信息获取模块1301、待购清单生成模块1302以及订单生成模块1303，其中，信息获取模块1301用于获取用户通过终端输入的登录信息，若登录信息有效，则返回与登录信息对应的业务信息列表；以及接收根据业务信息列表选择的业务标识，根据业务标识获取对应的业务需求信息；待购清单生成模块1302用于根据业务需求信息生成待购清单，获取根据待购清单选择的订单请求，其中，订单请求中包括对应的业务标识及业务明细信息；订单生成模块1303用于根据业务标识及业务明细信息对订单请求进行校验，若校验通过则生成订单。

具体的，信息获取模块1301可以配置在如图12所示的服务层中，待购清单生成模块1302以及订单生成模块1303可以配置在如图12所示的行业化组件层中。

在一个实施例中，还包括产品库存查询模块，用于在根据所述业务需求信息生成待购清单之前，根据业务需求信息映射对应的产品信息以确定对应的库存是否充足；当库存充足时，根据预先存储的报价信息计算与业务需求信息对应的业务的价格；则待购清单生成模块1302还用于当库存充足时，将业务需求信息以及价格对应的业务添加至所述待购清单。

在一个实施例中，还包括产品关系计划处模块，用于在将业务需求信息以及价格对应的业务添加至待购清单之前，根据预先存储的产品关系数据校验所述业务需求信息对应的业务与待购清单中的其他业务之间是否存在互斥关系；则则待购清单生成模块1302还用于：当确定不存在互斥关系时，则将业务需求信息对应的业务添加至所述待购清单。

在一个实施例中，根据业务标识及业务明细信息对订单请求进行校验，包括：根据业务标识及业务明细信息映射对应的产品信息以确定当前的库存是否充足；当确定当前的库存充足时，则校验通过。

在一个实施例中，根据业务标识及业务明细信息对订单请求进行校验，包括：根据预先存储的黒名单信息对与订单请求对应的登录信息进行校验；若预先存储的黒名单信息中不存在对应的登录信息，则校验通过；若校验通过则根据订单请求生成对应的订单信息，其中，订单信息包括订单号、业务标识及对应的业务明细信息、与登录信息对应的用户标识以及订单费用。

在一个实施例中，还包括订单支付模块，用于在若校验通过则生成订单之后，根据订单返回支付信息列表；接收根据支付信息列表选择的支付方式，根据选择的支付方式调用对应的支付接口，其中，支付接口用于指示终端完成相应的支付；接收终端完成对应的支付后返回的支付应答消息，根据支付应答消息生成支付结果。

在一个实施例中，根据订单返回支付信息列表之前，还包括：调用预先设置的核验接口对订单的有效性进行核验；若对订单对应的部分业务或全部业务核验有效，则根据核验有效的业务重新计算订单对应的费用；并根据订单以及重新计算的费用返回支付信息列表。

在一个实施例中，还包括订单交付模块，用于若终端完成对应的支付后返回的支付应答消息为支付成功时，则根据核验有效的业务对应的业务明细信息调用预先设置的交付网关完成对应订单的交付。

在一个实施例中，若订单费用中涉及的现金费用大于零，且终端完成对应的支付后返回的支付应答消息为支付成功时，则调用预先设置的核验接口对订单的有效性进行核验；若对订单对应的部分业务核验无效，则根据核验无效的部分业务调用预先设置的退款接口，其中，退款接口用于指示终端完成相应的退款。

在一个实施例中，若对订单对应的全部业务核验有效或对订单对应的部分业务核验有效，则根据核验有效的业务对应的业务明细信息调用预先设置的交付网关完成对应订单的交付。

在一个实施例中，根据核验有效的业务对应的业务明细信息调用预先设置的交付网关完成对应订单的交付之后，还包括：若订单对应的有效的业务全部交付成功，则返回与订单对应的交付凭证。

关于基于金融业务的订单处理装置的具体限定可以参见上文中对于基于金融业务的订单处理方法的限定，在此不再赘述。上述基于金融业务的订单处理装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。

在一个实施例中，提供了一种计算机设备，该计算机设备可以是服务器，其内部结构图可以如图14所示。该计算机设备包括通过系统总线连接的处理器、存储器、网络接口和数据库。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统、计算机程序和数据库。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的数据库用于存储金融业务相关的数据。该计算机设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种基于金融业务的订单处理方法。

本领域技术人员可以理解，图14中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

在一个实施例中，提供了一种基于金融业务的订单处理系统，包括存储器和处理器，存储器中存储有计算机程序，该处理器执行计算机程序时实现以下步骤：

获取用户通过终端输入的登录信息，若登录信息有效，则返回与登录信息对应的业务信息列表；接收根据业务信息列表选择的业务标识，根据业务标识获取对应的业务需求信息；根据业务需求信息生成待购清单，获取根据待购清单选择的订单请求，其中，订单请求中包括对应的业务标识及业务明细信息；根据业务标识及业务明细信息对订单请求进行校验，若校验通过则生成订单。

在一个实施例中，在根据所述业务需求信息生成待购清单之前，还包括：根据业务需求信息映射对应的产品信息以确定对应的库存是否充足；当库存充足时，根据预先存储的报价信息计算与业务需求信息对应的业务的价格；其中，根据业务需求信息生成待购清单，包括：当库存充足时，将业务需求信息以及价格对应的业务添加至所述待购清单。

在一个实施例中，将业务需求信息以及价格对应的业务添加至待购清单之前，还包括：根据预先存储的产品关系数据校验所述业务需求信息对应的业务与待购清单中的其他业务之间是否存在互斥关系；则根据业务需求信息生成待购清单，包括：当确定不存在互斥关系时，则将业务需求信息对应的业务添加至所述待购清单。

在一个实施例中，根据业务标识及业务明细信息对订单请求进行校验，包括：根据业务标识及业务明细信息映射对应的产品信息以确定当前的库存是否充足；当确定当前的库存充足时，则校验通过。

在一个实施例中，根据业务标识及业务明细信息对订单请求进行校验，包括：根据预先存储的黒名单信息对与订单请求对应的登录信息进行校验；若预先存储的黒名单信息中不存在对应的登录信息，则校验通过；若校验通过则生成订单，包括：根据订单请求生成对应的订单信息，其中，订单信息包括订单号、业务标识及对应的业务明细信息、与登录信息对应的用户标识以及订单费用。

在一个实施例中，在若校验通过则生成订单之后，还包括：根据订单返回支付信息列表；接收根据支付信息列表选择的支付方式，根据选择的支付方式调用对应的支付接口，其中，支付接口用于指示终端完成相应的支付；接收终端完成对应的支付后返回的支付应答消息，根据支付应答消息生成支付结果。

在一个实施例中，根据订单返回支付信息列表之前，还包括：调用预先设置的核验接口对订单的有效性进行核验；若对订单对应的部分业务或全部业务核验有效，则根据核验有效的业务重新计算订单对应的费用；则根据订单返回支付信息列表，包括：根据订单以及重新计算的费用返回支付信息列表。

在一个实施例中，若终端完成对应的支付后返回的支付应答消息为支付成功时，则该方法还包括：根据核验有效的业务对应的业务明细信息调用预先设置的交付网关完成对应订单的交付。

在一个实施例中，若订单费用中涉及的现金费用大于零，且终端完成对应的支付后返回的支付应答消息为支付成功时，则该方法还包括：调用预先设置的核验接口对订单的有效性进行核验；若对订单对应的部分业务核验无效，则根据核验无效的部分业务调用预先设置的退款接口，其中，退款接口用于指示终端完成相应的退款。

在一个实施例中，还包括：若对订单对应的全部业务核验有效或对订单对应的部分业务核验有效，则根据核验有效的业务对应的业务明细信息调用预先设置的交付网关完成对应订单的交付。

在一个实施例中，根据核验有效的业务对应的业务明细信息调用预先设置的交付网关完成对应订单的交付之后，还包括：若订单对应的有效的业务全部交付成功，则返回与订单对应的交付凭证。

在一个实施例中，提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现以下步骤：

获取用户通过终端输入的登录信息，若登录信息有效，则返回与登录信息对应的业务信息列表；接收根据业务信息列表选择的业务标识，根据业务标识获取对应的业务需求信息；根据业务需求信息生成待购清单，获取根据待购清单选择的订单请求，其中，订单请求中包括对应的业务标识及业务明细信息；根据业务标识及业务明细信息对订单请求进行校验，若校验通过则生成订单。

在一个实施例中，在根据所述业务需求信息生成待购清单之前，还包括：根据业务需求信息映射对应的产品信息以确定对应的库存是否充足；当库存充足时，根据预先存储的报价信息计算与业务需求信息对应的业务的价格；其中，根据业务需求信息生成待购清单，包括：当库存充足时，将业务需求信息以及价格对应的业务添加至所述待购清单。

在一个实施例中，将业务需求信息以及价格对应的业务添加至待购清单之前，还包括：根据预先存储的产品关系数据校验所述业务需求信息对应的业务与待购清单中的其他业务之间是否存在互斥关系；则根据业务需求信息生成待购清单，包括：当确定不存在互斥关系时，则将业务需求信息对应的业务添加至所述待购清单。

在一个实施例中，根据业务标识及业务明细信息对订单请求进行校验，包括：根据业务标识及业务明细信息映射对应的产品信息以确定当前的库存是否充足；当确定当前的库存充足时，则校验通过。

在一个实施例中，根据业务标识及业务明细信息对订单请求进行校验，包括：根据预先存储的黒名单信息对与订单请求对应的登录信息进行校验；若预先存储的黒名单信息中不存在对应的登录信息，则校验通过；若校验通过则生成订单，包括：根据订单请求生成对应的订单信息，其中，订单信息包括订单号、业务标识及对应的业务明细信息、与登录信息对应的用户标识以及订单费用。

在一个实施例中，在若校验通过则生成订单之后，还包括：根据订单返回支付信息列表；接收根据支付信息列表选择的支付方式，根据选择的支付方式调用对应的支付接口，其中，支付接口用于指示终端完成相应的支付；接收终端完成对应的支付后返回的支付应答消息，根据支付应答消息生成支付结果。

在一个实施例中，根据订单返回支付信息列表之前，还包括：调用预先设置的核验接口对订单的有效性进行核验；若对订单对应的部分业务或全部业务核验有效，则根据核验有效的业务重新计算订单对应的费用；则根据订单返回支付信息列表，包括：根据订单以及重新计算的费用返回支付信息列表。

在一个实施例中，若终端完成对应的支付后返回的支付应答消息为支付成功时，则该方法还包括：根据核验有效的业务对应的业务明细信息调用预先设置的交付网关完成对应订单的交付。

在一个实施例中，若订单费用中涉及的现金费用大于零，且终端完成对应的支付后返回的支付应答消息为支付成功时，则该方法还包括：调用预先设置的核验接口对订单的有效性进行核验；若对订单对应的部分业务核验无效，则根据核验无效的部分业务调用预先设置的退款接口，其中，退款接口用于指示终端完成相应的退款。

在一个实施例中，还包括：若对订单对应的全部业务核验有效或对订单对应的部分业务核验有效，则根据核验有效的业务对应的业务明细信息调用预先设置的交付网关完成对应订单的交付。

在一个实施例中，根据核验有效的业务对应的业务明细信息调用预先设置的交付网关完成对应订单的交付之后，还包括：若订单对应的有效的业务全部交付成功，则返回与订单对应的交付凭证。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器(ROM)、可编程ROM(PROM)、电可编程ROM(EPROM)、电可擦除可编程ROM(EEPROM)或闪存。易失性存储器可包括随机存取存储器(RAM)或者外部高速缓冲存储器。作为说明而非局限，RAM以多种形式可得，诸如静态RAM(SRAM)、动态RAM(DRAM)、同步DRAM(SDRAM)、双数据率SDRAM(DDRSDRAM)、增强型SDRAM(ESDRAM)、同步链路(Synchlink)DRAM(SLDRAM)、存储器总线(Rambus)直接RAM(RDRAM)、直接存储器总线动态RAM(DRDRAM)、以及存储器总线动态RAM(RDRAM)等。

以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。

Claims (10)

1.一种基于金融业务的订单处理方法，其特征在于，所述方法包括：

获取用户通过终端输入的登录信息，若所述登录信息有效，则返回与所述登录信息对应的业务信息列表；

接收根据所述业务信息列表选择的业务标识，根据所述业务标识获取对应的业务需求信息；

根据所述业务需求信息生成待购清单，获取根据所述待购清单选择的订单请求，所述订单请求中包括对应的业务标识及业务明细信息；

根据所述业务标识及业务明细信息对所述订单请求进行校验，若校验通过则生成订单。

2.根据权利要求1所述的基于金融业务的订单处理方法，其特征在于，在所述根据所述业务需求信息生成待购清单之前，还包括：

根据预先存储的产品关系数据校验所述业务需求信息对应的业务与所述待购清单中的其他业务之间是否存在互斥关系；

根据所述业务需求信息映射对应的产品信息以确定对应的库存是否充足；

当所述库存充足时，根据预先存储的报价信息计算与所述业务需求信息对应的业务的价格；

所述根据所述业务需求信息生成待购清单，包括：

当确定不存在互斥关系且库存充足时，则将所述业务需求信息对应的业务添加至所述待购清单。

3.根据权利要求2所述的基于金融业务的订单处理方法，其特征在于，在所述若校验通过则生成订单之后，还包括：

根据所述订单返回支付信息列表；

接收根据所述支付信息列表选择的支付方式，根据选择的支付方式调用对应的支付接口，所述支付接口用于指示所述终端完成相应的支付；

接收所述终端完成对应的支付后返回的支付应答消息，根据所述支付应答消息生成支付结果。

4.根据权利要求3所述的基于金融业务的订单处理方法，其特征在于，所述根据所述订单返回支付信息列表之前，还包括：

调用预先设置的核验接口对所述订单的有效性进行核验；

若对所述订单对应的部分业务或全部业务核验有效，则根据核验有效的业务重新计算所述订单对应的费用；

所述根据所述订单返回支付信息列表，包括：

根据所述订单以及重新计算的费用返回支付信息列表。

5.根据权利要求3所述的基于金融业务的订单处理方法，其特征在于，若所述订单费用中涉及的现金费用大于零，且所述终端完成对应的支付后返回的支付应答消息为支付成功时，所述方法还包括：

调用预先设置的核验接口对所述订单的有效性进行核验；

若对所述订单对应的部分业务核验无效，则根据核验无效的部分业务调用预先设置的退款接口，所述退款接口用于指示所述终端完成相应的退款。

6.根据权利要求5所述的基于金融业务的订单处理方法，其特征在于，所述方法还包括：若对所述订单对应的全部业务核验有效或对所述订单对应的部分业务核验有效，则根据核验有效的业务对应的业务明细信息调用预先设置的交付网关完成对应订单的交付。

7.根据权利要求6所述的基于金融业务的订单处理方法，其特征在于，所述根据核验有效的业务对应的业务明细信息调用预先设置的交付网关完成对应订单的交付之后，还包括：

若所述订单对应的有效的业务全部交付成功，则返回与所述订单对应的交付凭证。

8.一种基于金融业务的订单处理装置，其特征在于，包括：

信息获取模块，用于获取用户通过终端输入的登录信息，若所述登录信息有效，则返回与所述登录信息对应的业务信息列表；以及接收根据所述业务信息列表选择的业务标识，根据所述业务标识获取对应的业务需求信息；

待购清单生成模块，用于根据所述业务需求信息生成待购清单，获取根据所述待购清单选择的订单请求，所述订单请求中包括对应的业务标识及业务明细信息；

订单生成模块，用于根据所述业务标识及业务明细信息对所述订单请求进行校验，若校验通过则生成订单。

9.一种基于金融业务的订单处理系统，包括存储器和处理器，所述存储器存储有计算机程序，其特征在于，所述处理器执行所述计算机程序时实现权利要求1至7中任一项所述方法的步骤。

10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至7中任一项所述方法的步骤。