CN117875951A - 基于支付场景的钱包支付接入方法、装置、设备及介质 - Google Patents

Abstract

本申请涉及金融科技技术领域，具体公开了一种基于支付场景的钱包支付接入方法、装置、设备及介质。其中方法通过对支付请求的解析，确定当前支付场景对应的场景类型，从而通过策略模式配置该场景类型对应的场景支付流程，进而基于标准支付流程和场景支付流程，接入支付钱包进行支付，由此，将标准支付流程和场景支付流程进行区分，开发者只需要针对不同支付场景的差异性开发对应的场景支付流程，而不需要对标准支付流程进行重复开发，从而减少支付代码的开发数据量，降低代码冗余，提高代码支付效率以及钱包接入效率。

Description

基于支付场景的钱包支付接入方法、装置、设备及介质

技术领域

本申请涉及金融科技技术领域，尤其涉及一种基于支付场景的钱包支付接入方法、装置、设备及介质。

背景技术

电子钱包产品与微信、支付宝等支付平台相同，作为第三方支付方式，可以实现开户、绑卡、理财、支付等多种功能，并可以关联多种支付平台，提供多样性的支付方式，提高用户的网络支付便捷性。比如，车主钱包可以应用于车主商城、话费支付、油卡充值、货基购买、车险保险支付、非车保险支付等多种支付场景。

但是，不同的支付场景接入电子钱包进行支付的方式各不相同，比如，有些支付场景可以支持组合支付，或者可以使用抵用券抵扣部分费用，或者不同的支付场景可支持的账户体系不通等。现有技术中，针对不同支付场景下的电子钱包接入方式，都是针对各支付场景的支付逻辑进行定制化开发。由此，使得每接入一个新的支付场景，需要重新开发一套支付相关的代码，从而产生很大的代码冗余，使得支付代码的开发效率低下。因此，如何解决目前支付代码的开发效率低下成为了亟待解决的技术问题。

发明内容

本申请提供了一种基于支付场景的钱包支付接入方法、装置、设备及介质，以提高支付代码的开发效率。

第一方面，本申请提供了一种基于支付场景的钱包支付接入方法，所述方法包括：

在接收到客户端发起的当前支付场景的支付请求时，基于对所述支付请求的解析，确定所述当前支付场景对应的场景类型；

基于预设的策略模式，配置所述场景类型对应的场景支付流程；

基于预设的标准支付流程和所述场景支付流程，接入所述客户端绑定的支付钱包，以执行对所述当前支付场景的验证支付。

第二方面，本申请还提供了一种基于支付场景的钱包支付接入装置，所述装置包括：

场景类型确定模块，用于在接收到客户端发起的当前支付场景的支付请求时，基于对所述支付请求的解析，确定所述当前支付场景对应的场景类型；

场景支付流程配置模块，用于基于预设的策略模式，配置所述场景类型对应的场景支付流程；

钱包支付模块，用于基于预设的标准支付流程和所述场景支付流程，接入所述客户端绑定的支付钱包，以执行对所述当前支付场景的验证支付。

第三方面，本申请还提供了一种计算机设备，所述计算机设备包括存储器和处理器；所述存储器用于存储计算机程序；所述处理器，用于执行所述计算机程序并在执行所述计算机程序时实现如上述的基于支付场景的钱包支付接入方法。

第四方面，本申请还提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时使所述处理器实现如上述的基于支付场景的钱包支付接入方法。

本申请公开了一种基于支付场景的钱包支付接入方法、装置、设备及介质，该方法包括：在接收到客户端发起的当前支付场景的支付请求时，基于对所述支付请求的解析，确定所述当前支付场景对应的场景类型；基于预设的策略模式，配置所述场景类型对应的场景支付流程；基于预设的标准支付流程和所述场景支付流程，接入所述客户端绑定的支付钱包，以执行对所述当前支付场景的验证支付。通过上述方式，本申请通过对支付请求的解析，确定当前支付场景对应的场景类型，从而通过策略模式配置该场景类型对应的场景支付流程，进而基于标准支付流程和场景支付流程，接入支付钱包进行支付，由此，将标准支付流程和场景支付流程进行区分，开发者只需要针对不同支付场景的差异性开发对应的场景支付流程，而不需要对标准支付流程进行重复开发，从而减少支付代码的开发数据量，降低代码冗余，提高代码支付效率以及钱包接入效率。

附图说明

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

图1是本申请的实施例提供的一种基于支付场景的钱包支付接入方法第一实施方式的示意流程图；

图2是本申请的实施例提供的一种钱包支付过程的流程示意图；

图3是本申请的实施例提供的一种基于支付场景的钱包支付接入方法第二实施方式的示意流程图；

图4是本申请的实施例提供的一种基于支付场景的钱包支付接入方法第三实施方式的示意流程图；

图5是本申请的实施例提供一种基于支付场景的钱包支付接入装置的示意性框图；

图6是本申请的实施例提供的一种计算机设备的结构示意性框图。

具体实施方式

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

附图中所示的流程图仅是示例说明，不是必须包括所有的内容和操作/步骤，也不是必须按所描述的顺序执行。例如，有的操作/步骤还可以分解、组合或部分合并，因此实际执行的顺序有可能根据实际情况改变。

应当理解，在此本申请说明书中所使用的术语仅仅是出于描述特定实施例的目的而并不意在限制本申请。如在本申请说明书和所附权利要求书中所使用的那样，除非上下文清楚地指明其它情况，否则单数形式的“一”、“一个”及“该”意在包括复数形式。

还应当进理解，在本申请说明书和所附权利要求书中使用的术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合，并且包括这些组合。

本申请的实施例提供了一种基于支付场景的钱包支付接入方法、装置、计算机设备及存储介质。其中，该基于支付场景的钱包支付接入方法可以应用于服务器中，该服务器可以为独立的服务器，也可以为服务器集群。

下面结合附图，对本申请的一些实施方式作详细说明。在不冲突的情况下，下述的实施例及实施例中的特征可以相互组合。

请参阅图1，图1是本申请的实施例提供的一种基于支付场景的钱包支付接入方法第一实施方式的示意流程图。该基于支付场景的钱包支付接入方法可应用于服务器中。

如图1所示，该基于支付场景的钱包支付接入方法具体包括步骤S101至步骤S103。

S101、在接收到客户端发起的当前支付场景的支付请求时，基于对所述支付请求的解析，确定所述当前支付场景对应的场景类型；

在一实施例中，支付场景可以包括商城、话费支付、油卡充值、货基购买、车险保险支付、非车险保险支付等。

在一实施例中，用户通过客户端发起支付请求时，获取该支付请求对应的当前支付场景，通过对支付请求的解析，确定当前支付场景的场景类型，进而判断当前支付场景的支付流程是否具有特殊化支付逻辑。

在一实施例中，不同的场景接入钱包支付的情况各有不同，有的支付场景可以支持组合支付，或者可以使用消费平台方活动券进行减免，有的支付场景可支持的支付方式和账户体系有限定，比如理赔打款不支持一户通用户，保险自动续保功能要提供产品信息等。这些场景类型下，用户不能直接通过普通的支付流程直接支付，而需要根据各支付场景对应的支付要求进行信息完善和验证等。

在一实施例中，场景类型可以包括普通场景类型和特殊场景类型。

示例性的，普通场景类型的支付场景，用户可以直接执行标准支付流程进行支付，即对支付请求进行合法性验证和核对，在验证通过之后，直接接入到钱包进行支付。而特殊场景类型则可以根据不同特征场景的支付逻辑执行对应的支付流程，比如消费平台方活动验证、可支持支付方式验证、账户支付资格验证等。

S102、基于预设的策略模式，配置所述场景类型对应的场景支付流程；

在一实施例中，在确定当前支付场景对应的场景类型之后，根据预设的策略模式，配置当前支付场景的场景支付流程。

在一实施例中，场景支付流程为各当前支付场景对应的差异性信息或处理逻辑对应的支付流程，正常的支付流程是在客户端发起支付请求之后，对该支付请求进行核验，在核验通过时则根据客户端的账户信息，接入到该账户信息绑定的钱包进行支付即可，而场景支付流程还包括对各种差异性信息或处理逻辑的验证等，比如对特定信息的验证，或者对消费平台方活动的验证等。

示例性的，车险续保时需要产品信息，即车险保单，用户在通过客户端请求支付时，不能直接支付保险金额，而需要提交保单信息和个人信息，在保单信息和个人信息核验通过时，才能根据用户的账号信息，接入到该账号信息对应的支付钱包进行支付。即，在车险续保支付流程中还包括保单信息和个人信息的核验流程。

S103、基于预设的标准支付流程和所述场景支付流程，接入所述客户端绑定的支付钱包，以执行对所述当前支付场景的验证支付。

在一实施例中，根据场景支付流程，向客户端提供公共的获取钱包支付方式方法，在选择钱包支付方式时，根据当前支付场景，针对该当前支付场景的支付差异点进行特殊处理，比如车险理赔时，理赔打款时不支持一户通用户，根据场景剔除调这种用户，比如保险自动续保一定要有产品信息，根据场景做特殊判断。

其中，一户通是指通过一个账户，一套密码，通过添加账户的方式，即可整合用户名下归属于同一家银行或保险公司的所有金融产品或账户，比如保险、银行卡、信用卡、证券等。

在一实施例中，不同场景支付流程对应的支付差异点不同，比如保险续保需要在用户提供保单信息和用户身份信息等，该流程可以是在支付请求发起之后，获取支付方式之前执行。而车险理赔是对用户的账号信息进行限定，即该处理节点是在获取用户钱包支付方式之后执行的。因此，针对不同支付场景，可以根据各支付场景对应的场景类型，对标准支付流程和场景支付流程进行结合。

在一实施例中，客户端向钱包后台发起支付请求，钱包后台向客户端返回钱包支付方式，在用户通过客户端选定钱包支付方式之后，跳转到对应的的钱包支付页执行支付。

在一实施例中，在钱包支付页进行支付的时候，对于每种场景而言最终调用的核心支付都是相似的，即支付验证和支付。因此对于任意支付场景，都需要执行标准支付流程。

在一实施例中，所述标准支付流程，包括：获取所述当前支付场景的支付信息；基于预设的支付验证项目，对所述支付信息进行支付验证；在所述支付信息的支付验证通过时，基于所述支付请求中的支付渠道，调用所述支付渠道对应的支付接口进行支付操作。

在一实施例中，所述支付验证项目包括支付信息验证、支付渠道验证、订单信息验证、账户信息验证以及支付活动验证。

在一实施例中，标准支付流程执行过程中，钱包后台在接收到支付请求时，对于一般支付场景，可以根据标准支付流程依次执行：核对支付信息、验真支付渠道的合法性、订单状态及提交校验、账户状态校验、支付信息校验以及调用公共支付接口进行支付等操作。

其中，一般支付场景是指不需要提供额外的证明或验证信息，可以直接根据支付请求调用钱包接口进行验证支付的支付场景，比如在无活动的商品购买、话费支付、油卡充值等支付场景。

在一实施例中，在支付页进行支付时，不同的支付场景也会存在差异，比如部分场景支持组合支付或者支持使用万里通支付，此时，根据支付场景要求可以执行对应的场景支付流程，比如使用商品券抵扣部分金额，剩余金额通过钱包支付等。

在一实施例中，在支付页支付时，场景支付流程可以检测当前支付场景是否有支付优惠活动、用户账号中是否具备当前支付场景可支持使用的优惠券、抵扣券、支付券等信息。有则执行场景支付流程，没有则直接在支付页进行支付。

在一实施例中，场景支付流程可以是基于标准支付流程执行的，根据不同支付场景的支付逻辑，在标准支付流程的基础上执行特定的支付流程，比如可支持支付方式验证、可用账户验证、商品活动核验、优惠活动核验、组合支付等。

在一实施例中，在执行场景支付流程时，可以根据支付场景适配活动，比如，若某个支付场景有满减抵扣券等活动，提前根据该支付场景及金额动态配置Apollo数据，比如该支付场景的活动生效时间，抵扣券的有效期限，以及满减要求的最低限额等。还可以根据支付场景适配商品券使用情况，如万里通及支付券等，某些支付场景需要提前apollo配置才支持使用万里通及支付券。

其中，Apollo(阿波罗)是携程框架部门研发的分布式配置中心，能够集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性，适用于微服务配置管理场景。

在一实施例中，在钱包后台提交支付时，对于每个支付场景，在支付时涉及到的信息及处理逻辑也会有些许差异，比如，优惠券的使用是在采用特定的支付方式时才能生效等。此时，可以根据支付场景及支付平台来源来创建不同的数据类，而后不同的支付场景分别处理对应数据类的支付逻辑，最终调用钱包的公共支付接口进行支付。

在一实施例中，所述执行对所述当前支付场景的支付，包括：获取钱包支付方式；基于所述钱包支付方式，确定钱包支付地址；基于所述钱包支付地址，跳转至钱包支付页面进行支付，获得支付结果。

在一实施例中，钱包支付方式可以包括钱包快付(“子钱包”更名)、H5支付(微信支付)、App(应用程序)拉起支付等线上支付方式；还可以包括扫码支付和碰一碰/NFC(NearField Communication，近场通信)支付等线下支付方式。

在一实施例中，如图2所示，用户打开商城，获取可用的钱包支付方式，然后选择支付方式，并根据选择的支付方式，获得钱包支付地址，跳转到支付页面中进行网关校验，向钱包后台转发支付请求，钱包后台根据支付请求进行支付，并返回支付结果，包括支付完成或支付失败。

本实施例提供了一种基于支付场景的钱包支付接入方法，该方法通过对支付请求的解析，确定当前支付场景对应的场景类型，从而通过策略模式配置该场景类型对应的场景支付流程，进而基于标准支付流程和场景支付流程，接入支付钱包进行支付，由此，将标准支付流程和场景支付流程进行区分，开发者只需要针对不同支付场景的差异性开发对应的场景支付流程，而不需要对标准支付流程进行重复开发，从而减少支付代码的开发数据量，降低代码冗余，提高代码支付效率以及钱包接入效率。

请参阅图3，图3是本申请的实施例提供的一种基于支付场景的钱包支付接入方法第二实施方式的示意流程图。

如图3所示，本实施例中，所述方法还包括：

S201、获取至少一种支付场景；

在一实施例中，可以通过大数据筛选所有与支付有关的数据，并对支付数据进行分类，得到多个支付场景。

在一实施例中，支付场景可以包括标准支付场景、理赔类支付场景、活动类支付场景、商品券类支付场景等。

其中，标准支付场景是指基础支付场景，该支付场景下不具备任何支付活动、抵扣券等支付数据的判断，即客户端向钱包后台发起支付请求，钱包后台核验支付信息和账号信息等，在核验通过时即执行支付。

S202、基于所述支付场景的钱包支付逻辑，编译所述支付场景对应的所述场景支付流程；

在一实施例中，不同的支付场景，其支付流程虽然存在一定的差异性，但是大多数支付场景一般都是基于标准支付流程进行差异性的支付处理，比如活动判断、支付证明的核验等，所以对于不同场景的支付，可以针对支付差异点编译对应的支付流程，再结合标准支付流程执行支付。

在一实施例中，支付场景还可以包括多类型支付场景结合，比如，满减活动和抵扣券同时存在时，那么需要判断满减和抵扣券能否同时使用。如果不能同时使用，则需要用户选择使用哪一种方式，再执行下一步的支付流程；如果能够同时使用，则需要根据满减活动和抵扣券的抵扣金额重新计算需要支付的实际支付金额。

示例性的，理赔类支付场景一般需要根据理赔中心的赔付要求进行支付信息外的信息核验，比如车险理赔需要核验事故案件信息、定损报告、理赔方案等信息，在核验通过之后，再执行支付流程。

活动类支付场景是指待支付商品参与的消费平台方活动等，比如加油优惠立减活动、节假日优惠活动、满减活动等，如满减活动需要核验用户购买商品的总金额是否满足满减金额要求，如果不满足，则支付时不能参与满减，而如果满足要求，则需要判断是否具备多个满减金额等级，当前用户购买商品的总金额满足哪一等级的满减活动要求，进而根据其满足要求的满减活动等级，计算满减之后的支付金额，再进行支付。

商品券类支付场景是指用户单独购买或领取到一定金额的抵扣券，而抵扣券的使用一般会存在一定的使用要求，比如在规定时限内、可支持使用的商品类型、消费平台等，在客户端发起支付请求时，如果客户端的账号信息中有未使用的商品券，则需要对该支付请求的当前支付场景进行识别，判断当前支付场景是否满足该商品券的使用要求。如果该商品券可以用于当前支付场景，则可以提醒用户使用，如果用户选择使用，则根据商品券的抵扣金额和支付请求的总金额，重新计算当前需要支付的实际金额。而如果该商品券不可以用于当前支付场景，则直接执行该支付请求总金额的支付流程。

S203、基于所述支付场景的退款逻辑，编译所述支付场景对应的场景退款流程。

在一实施例中，支付场景还包括退款流程。一般地，钱包后台在接收到退款请求时，如果消费方和消费平台方都对该退款请求无异议，钱包后台即可执行退款，按支付地址将款项退回到消费方的钱包中。但是，在不同支付场景，对于退款流程也是存在差异性的。

示例性的，部分消费平台方对于商品退货退款可以支持如“七天无理由退换”等活动；部分商品则需要消费者先退货，消费平台方检测商品无破损才可以退款；或者对于使用了商品券的用户还需要针对商品券进行处理等。

进一步地，在接收到所述客户端发起所述当前支付场景的退款请求时，基于所述当前支付场景的场景类型，确定所述当前支付场景对应的所述场景退款流程；基于预设的标准退款流程和所述场景退款流程，调用所述支付钱包的支付接口，以响应所述退款请求。

在一实施例中，退款的发起方不是钱包，需要关联方(消费方和消费平台方)发起退款之后调用用户钱包的退款，退款的流程可以包括：校验退款(订单及金额等)信息、校验退款请求(流水等)信息以及提交退款请求。

在一实施例中，提交退款请求可以根据支付场景及平台来源来创建不同的数据类，而后针对不同的支付场景分别处理对应的退款逻辑，最终调用钱包的公共支付接口进行最终的退款。

本实施例中，标准支付流程部分的代码只需要开发一次，后续只需要针对不同支付场景，将对应的场景支付流程和标准支付流程结合使用，从而减少代码冗余。针对新的支付场景，只需新建一个场景支付流程的宿主策略类，标准支付流程的业务功能代码都是可以复用的，大大提升了代码复用率。

请参阅图4，图4是本申请的实施例提供的一种基于支付场景的钱包支付接入方法第三实施方式的示意流程图。

如图4所示，基于上述图1所示实施例，所述步骤S101之后，还包括：

步骤S301、在预设的场景类型数据库中不存在所述当前支付场景对应的所述场景类型时，基于对所述支付请求的解析，确定所述当前支付场景的差异性支付逻辑。

在一实施例中，场景类型数据库可以用于保存已开发的场景支付流程对应的支付代码，如果当前支付场景与已有各场景类型均不匹配时，则对该支付请求的支付逻辑进行分析，对比标准支付流程的支付逻辑，判断当前支付场景的支付流程和标准支付流程的差异性，从而确定当前支付场景的差异性支付逻辑。

步骤S302、基于所述差异性支付逻辑，编译所述差异性支付逻辑对应的逻辑代码，确定所述当前支付场景对应的所述场景支付流程。

在一实施例中，钱包后台针对该差异性进行支付代码的开发，从而生成当前支付场景对应的场景支付流程，然后将该场景支付流程和标准支付流程进行结合，执行当前支付场景的支付操作。

本实施例中，对于新的支付场景，开发者只需要针对该支付场景的特殊支付逻辑进行开发，而不需要开发标准支付流程部分的代码，减少代码开发数据量，使得接入钱包的时效大大降低。同时，开发者只需要改动支付场景中与标准支付流程存在差异的部分逻辑，减少维护成本。

请参阅图5，图5是本申请的实施例提供一种基于支付场景的钱包支付接入装置的示意性框图，该基于支付场景的钱包支付接入装置用于执行前述的基于支付场景的钱包支付接入方法。其中，该基于支付场景的钱包支付接入装置可以配置于服务器。

如图5所示，该基于支付场景的钱包支付接入装置400，包括：

场景类型确定模块401，用于在接收到客户端发起的当前支付场景的支付请求时，基于对所述支付请求的解析，确定所述当前支付场景对应的场景类型；

场景支付流程配置模块402，用于基于预设的策略模式，配置所述场景类型对应的场景支付流程；

钱包支付模块403，用于基于预设的标准支付流程和所述场景支付流程，接入所述客户端绑定的支付钱包，以执行对所述当前支付场景的验证支付。

在一个实施例中，所述基于支付场景的钱包支付接入装置400还包括场景支付流程编译模块，所述场景支付流程编译模块包括：

支付场景获取单元，用于获取至少一种支付场景；

场景支付流程编译单元，用于基于所述支付场景的钱包支付逻辑，编译所述支付场景对应的所述场景支付流程；

场景退款流程编译单元，用于基于所述支付场景的退款逻辑，编译所述支付场景对应的场景退款流程。

在一个实施例中，所述基于支付场景的钱包支付接入装置400还包括退款流程执行模块，所述退款流程执行模块具体包括：

场景退款流程确定单元，用于在接收到所述客户端发起所述当前支付场景的退款请求时，基于所述当前支付场景的场景类型，确定所述当前支付场景对应的所述场景退款流程；

退款执行单元，用于基于预设的标准退款流程和所述场景退款流程，调用所述支付钱包的支付接口，以响应所述退款请求。

在一实施例中，所述钱包支付模块403包括：

支付信息获取单元，用于获取所述当前支付场景的支付信息；

支付验证单元，用于基于预设的支付验证项目，对所述支付信息进行支付验证；

支付接口调用单元，用于在所述支付信息的支付验证通过时，基于所述支付请求中的支付渠道，调用所述支付渠道对应的支付接口进行支付操作。

在一实施例中，所述支付验证项目包括支付信息验证、支付渠道验证、订单信息验证、账户信息验证以及支付活动验证。

在一实施例中，所述钱包支付模块403还包括：

钱包支付方式获取单元，用于获取钱包支付方式；

钱包支付地址确定单元，用于基于所述钱包支付方式，确定钱包支付地址；

支付结果获取单元，用于基于所述钱包支付地址，跳转至钱包支付页面进行支付，获得支付结果。

在一实施例中，所述基于支付场景的钱包支付接入装置400，还包括：

差异性支付逻辑确定单元，用于在预设的场景类型数据库中不存在所述当前支付场景对应的所述场景类型时，基于对所述支付请求的解析，确定所述当前支付场景的差异性支付逻辑；

场景支付流程开发单元，用于基于所述差异性支付逻辑，编译所述差异性支付逻辑对应的逻辑代码，确定所述当前支付场景对应的所述场景支付流程。

需要说明的是，所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，上述描述的装置和各模块的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

上述的装置可以实现为一种计算机程序的形式，该计算机程序可以在如图6所示的计算机设备上运行。

请参阅图6，图6是本申请的实施例提供的一种计算机设备的结构示意性框图。该计算机设备可以是服务器。

参阅图6，该计算机设备包括通过系统总线连接的处理器、存储器和网络接口，其中，存储器可以包括非易失性存储介质和内存储器。

非易失性存储介质可存储操作系统和计算机程序。该计算机程序包括程序指令，该程序指令被执行时，可使得处理器执行任意一种基于支付场景的钱包支付接入方法。

处理器用于提供计算和控制能力，支撑整个计算机设备的运行。

内存储器为非易失性存储介质中的计算机程序的运行提供环境，该计算机程序被处理器执行时，可使得处理器执行任意一种基于支付场景的钱包支付接入方法。

该网络接口用于进行网络通信，如发送分配的任务等。本领域技术人员可以理解，图6中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

应当理解的是，处理器可以是中央处理单元(CentralProcessingUnit，CPU)，该处理器还可以是其他通用处理器、数字信号处理器(DigitalSignalProcessor，DSP)、专用集成电路(ApplicationSpecificIntegratedCircuit，ASIC)、现场可编程门阵列(Field-ProgrammableGateArray，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。其中，通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

其中，在一个实施例中，所述处理器用于运行存储在存储器中的计算机程序，以实现如下步骤：

在接收到客户端发起的当前支付场景的支付请求时，基于对所述支付请求的解析，确定所述当前支付场景对应的场景类型；

基于预设的策略模式，配置所述场景类型对应的场景支付流程；

基于预设的标准支付流程和所述场景支付流程，接入所述客户端绑定的支付钱包，以执行对所述当前支付场景的支付。

在一个实施例中，所述处理器用于运行存储在存储器中的计算机程序，还用以实现：

获取至少一种支付场景；

基于所述支付场景的钱包支付逻辑，编译所述支付场景对应的所述场景支付流程；

基于所述支付场景的退款逻辑，编译所述支付场景对应的场景退款流程。

在一个实施例中，所述处理器在实现所述基于预设的标准支付流程和所述场景支付流程，接入所述客户端绑定的支付钱包，以执行对所述当前支付场景的验证支付之后，还用于实现：

在接收到所述客户端发起所述当前支付场景的退款请求时，基于所述当前支付场景的场景类型，确定所述当前支付场景对应的所述场景退款流程；

基于预设的标准退款流程和所述场景退款流程，调用所述支付钱包的支付接口，以响应所述退款请求。

在一个实施例中，所述处理器在实现所述标准支付流程时，用于实现：

获取所述当前支付场景的支付信息；

基于预设的支付验证项目，对所述支付信息进行支付验证；

在所述支付信息的支付验证通过时，基于所述支付请求中的支付渠道，调用所述支付渠道对应的支付接口进行支付操作。

在一个实施例中，所述支付验证项目包括支付信息验证、支付渠道验证、订单信息验证、账户信息验证以及支付活动验证。

在一实施例中，所述处理器在实现所述执行对所述当前支付场景的支付时，用于实现：

获取钱包支付方式；

基于所述钱包支付方式，确定钱包支付地址；

基于所述钱包支付地址，跳转至钱包支付页面进行支付，获得支付结果。

在一实施例中，所述处理器在实现所述在接收到客户端发起的当前支付场景的支付请求时，基于对所述支付请求的解析，确定所述当前支付场景对应的场景类型之后，还用于实现：

在预设的场景类型数据库中不存在所述当前支付场景对应的所述场景类型时，基于对所述支付请求的解析，确定所述当前支付场景的差异性支付逻辑；

基于所述差异性支付逻辑，编译所述差异性支付逻辑对应的逻辑代码，确定所述当前支付场景对应的所述场景支付流程。

本申请的实施例中还提供一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序中包括程序指令，所述处理器执行所述程序指令，实现本申请实施例提供的任一项基于支付场景的钱包支付接入方法。

其中，所述计算机可读存储介质可以是前述实施例所述的计算机设备的内部存储单元，例如所述计算机设备的硬盘或内存。所述计算机可读存储介质也可以是所述计算机设备的外部存储设备，例如所述计算机设备上配备的插接式硬盘，智能存储卡(SmartMediaCard，SMC)，安全数字(SecureDigital，SD)卡，闪存卡(FlashCard)等。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到各种等效的修改或替换，这些修改或替换都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。

Claims (10)

1.一种基于支付场景的钱包支付接入方法，其特征在于，包括：

在接收到客户端发起的当前支付场景的支付请求时，基于对所述支付请求的解析，确定所述当前支付场景对应的场景类型；

基于预设的策略模式，配置所述场景类型对应的场景支付流程；

基于预设的标准支付流程和所述场景支付流程，接入所述客户端绑定的支付钱包，以执行对所述当前支付场景的支付。

2.根据权利要求1所述的基于支付场景的钱包支付接入方法，其特征在于，所述方法还包括：

获取至少一种支付场景；

基于所述支付场景的钱包支付逻辑，编译所述支付场景对应的所述场景支付流程；

基于所述支付场景的退款逻辑，编译所述支付场景对应的场景退款流程。

3.根据权利要求2所述的基于支付场景的钱包支付接入方法，其特征在于，所述基于预设的标准支付流程和所述场景支付流程，接入所述客户端绑定的支付钱包，以执行对所述当前支付场景的验证支付之后，还包括：

在接收到所述客户端发起所述当前支付场景的退款请求时，基于所述当前支付场景的场景类型，确定所述当前支付场景对应的所述场景退款流程；

基于预设的标准退款流程和所述场景退款流程，调用所述支付钱包的支付接口，以响应所述退款请求。

4.根据权利要求1所述的基于支付场景的钱包支付接入方法，其特征在于，所述标准支付流程包括：

获取所述当前支付场景的支付信息；

基于预设的支付验证项目，对所述支付信息进行支付验证；

在所述支付信息的支付验证通过时，基于所述支付请求中的支付渠道，调用所述支付渠道对应的支付接口进行支付操作。

5.根据权利要求4所述的基于支付场景的钱包支付接入方法，其特征在于，所述支付验证项目包括支付信息验证、支付渠道验证、订单信息验证、账户信息验证以及支付活动验证。

6.根据权利要求1所述的基于支付场景的钱包支付接入方法，其特征在于，所述执行对所述当前支付场景的支付，包括：

获取钱包支付方式；

基于所述钱包支付方式，确定钱包支付地址；

基于所述钱包支付地址，跳转至钱包支付页面进行支付，获得支付结果。

7.根据权利要求1所述的基于支付场景的钱包支付接入方法，其特征在于，所述在接收到客户端发起的当前支付场景的支付请求时，基于对所述支付请求的解析，确定所述当前支付场景对应的场景类型之后，还包括：

在预设的场景类型数据库中不存在所述当前支付场景对应的所述场景类型时，基于对所述支付请求的解析，确定所述当前支付场景的差异性支付逻辑；

基于所述差异性支付逻辑，编译所述差异性支付逻辑对应的逻辑代码，确定所述当前支付场景对应的所述场景支付流程。

8.一种基于支付场景的钱包支付接入装置，其特征在于，包括：

场景类型确定模块，用于在接收到客户端发起的当前支付场景的支付请求时，基于对所述支付请求的解析，确定所述当前支付场景对应的场景类型；

场景支付流程配置模块，用于基于预设的策略模式，配置所述场景类型对应的场景支付流程；

钱包支付模块，用于基于预设的标准支付流程和所述场景支付流程，接入所述客户端绑定的支付钱包，以执行对所述当前支付场景的验证支付。

9.一种计算机设备，其特征在于，所述计算机设备包括存储器和处理器；

所述存储器用于存储计算机程序；

所述处理器，用于执行所述计算机程序并在执行所述计算机程序时实现如权利要求1至7中任一项所述的基于支付场景的钱包支付接入方法。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时使所述处理器实现如权利要求1至7中任一项所述的基于支付场景的钱包支付接入方法。