一种多渠道组合支付的方法及装置

技术领域

本申请涉及金融科技(Fintech)的网络技术领域，尤其涉及一种多渠道组合支付的方法及装置。

背景技术

近年来，随着计算机技术的发展，越来越多的技术应用在金融领域，传统金融业正在逐步向金融科技(Fintech)转变，但由于金融行业的安全性、实时性要求，也对技术提出更高的要求。如，当今的大部分购物平台的各商城都有自己的支付方式，并且各平台都会根据自己业务开发出对应的权益类支付渠道，如，积分、优惠券等；用户为了使用优惠券和积分等权益，则会在该购物平台或商城消费，商家以此来提高客户的留存率。而相应的，这种可以使用优惠券、积分和银行卡等多支付渠道的消费方式则会带来组合支付的问题。

现有技术中，针对组合支付的处理方式，是将除法币之外的优惠金额记录在交易单中，而实际上生成一笔支付单。如，当消费者提交交易时，支付平台实际上是将权益类的支付渠道完成支付之后，将权益类的支付信息记录在交易单中，并将银行支付或第三方支付等的支付信息生成一笔支付单进行支付，以此实现组合支付。其中，支付单与权益类的支付信息通过数据联动关联；但在对账时可能会出现联动出错而导致的无法对平账目，且该种方式的对账需要获取多方数据源，耗费处理资源和时间；若发生退款时，还需要根据人工进行操作，智能性灵活性差，处理效率低。

因此，现在亟需一种多渠道组合支付的方法及装置，提高组合支付处理效率，提高组合支付的智能性和灵活性。

发明内容

本发明实施例提供一种多渠道组合支付的方法及装置，提高组合支付处理效率，提高组合支付的智能性和灵活性。

第一方面，本发明实施例提供一种多渠道组合支付的方法，该方法包括：

交易系统接收业务系统发送的交易处理请求；所述交易系统根据所述交易处理请求中的交易信息，确定所述交易处理请求指示的支付渠道；所述交易系统针对任一支付渠道，根据所述交易信息生成所述支付渠道的支付单；所述交易系统通过各支付单对应的各支付渠道处理所述各支付单从而完成所述交易处理请求。

上述方法中，根据所述交易信息确定所述交易处理请求指示的支付渠道，进而确定所述交易处理请求对应的至少一个支付单。如此，使得权益类或非权益类的各支付渠道都可以分别对应一个支付单。若发生转账、充值、提现或退款等交易时；根据对应支付单进行交易处理，可以提高交易处理的准确度；根据支付单进行对账，可以只在一个数据源中获取对应的支付单，提高交易处理的效率，降低交易处理占用的资源；根据支付单进行退款可以智能且灵活的直接确定支付单对应的支付渠道，并完成退款。相比于现有技术中的只生成一笔支付单来说，本申请可以提高组合支付处理效率，提高组合支付的智能性和灵活性。

可选的，所述交易系统根据所述交易处理请求中的交易信息，确定所述交易处理请求指示的支付渠道，包括：所述交易处理请求对应的交易类型为支付类交易，所述交易系统根据所述交易信息中的支付渠道标识，确定所述交易处理请求指示的支付渠道；或所述交易处理请求对应的交易类型为退款类交易，所述交易系统根据所述交易信息中的交易单号，确定所述交易处理请求指示的支付渠道。

上述方法中，在支付场景中，即，交易类型为支付类交易，如，转账、充值、提现等；则交易信息中包括至少一个支付渠道标识，可以根据支付渠道标识获取对应的支付渠道，便于后续多渠道组合支付。在退款场景中，交易信息中包含交易单号，即可获取该交易单号在支付场景中对应的多笔支付单，根据获取的支付单信息确定交易处理请求指示的支付渠道，进一步通过支付渠道进行退款。如此，只获取一个数据源，即可完成退款，提高交易处理效率。

可选的，所述交易系统根据所述交易信息中的交易单号，确定所述交易处理请求指示的支付渠道，包括：所述交易系统根据所述交易信息中的交易单号，确定所述交易单号下的各历史支付单对应的各支付渠道；所述交易系统根据所述各支付渠道的退款规则，从支持退款的支付渠道中确定所述交易处理请求指示的支付渠道。

上述方法中，在退款场景中，根据交易单号确定各历史支付单，并确定各历史支付单对应的支付渠道后，还可以分别向各支付渠道发送规则获取请求，确定该支付渠道是否支持退款等退款规则。如此，提高退款的成功率和可靠性。

可选的，从支持退款的支付渠道中确定所述交易处理请求指示的支付渠道，包括：所述交易系统根据各支付渠道的退款权重，确定各支付渠道的退款优先级；所述退款权重为各支付渠道预设的，或根据历史时间段内的各支付渠道的交易状况确定的；所述交易系统根据各支付渠道的退款优先级，从支持退款的支付渠道中确定满足退款金额的支付渠道作为所述交易处理请求指示的支付渠道。

上述方法中，开发人员可以根据历史经验为各支付渠道设置退款权重，或者也可以设置退款权重相关规则，根据支付渠道在历史时间段内的交易状况确定退款权重；如此，获取各支付渠道的退款权重，进一步，根据各支付渠道的退款权重确定各支付渠道的退款优先级。依据各支持退款的支付渠道的退款优先级，依次完成退款。如此，可以防止退款交易集中在一个支付渠道导致交易处理效率下降，保证交易处理优良性能。

可选的，所述交易系统针对任一支付渠道，根据所述交易信息生成所述支付渠道的支付单，包括：所述交易系统根据各支付渠道对应的历史支付单中的支付金额，基于各支付渠道的退款优先级，确定各支付渠道的退款金额，从而生成各支付渠道的支付单。

上述方法中，还可以根据各支付渠道对应的历史支付单中的支付金额和自身退款优先级确定各支付渠道的退款金额，进一步，生成各支付渠道的支付单。如此，可以根据各支付渠道的退款优先级调控退款金额，提高退款政策的灵活性。

可选的，交易系统接收业务系统发送的交易处理请求之后，还包括：所述交易系统根据所述交易处理请求中的业务类型，确定所述交易处理请求的业务单号；所述交易系统根据所述交易信息和所述业务单号，生成交易单号；每个交易单号对应至少一个支付单号。

上述方法中，根据所述业务类型确定业务单号。如此，提高根据业务类型进行交易数据分析的效率。一个业务单号可以对应至少一个交易单号，同笔交易中的多个支付单号对应一个交易单号。如此，可以将预设时段内的同种业务类型的多笔交易通过业务单号关联，便于后续针对业务类型和交易发生时间的相关分析；且使得同笔交易的多笔支付单同属一个交易单号，便于交易处理。

可选的，所述交易系统通过各支付单对应的各支付渠道处理所述各支付单，包括：针对任一支付单，所述交易系统生成所述支付单的用户账务记录指令、渠道支付指令和渠道账务记录指令；所述交易系统通过所述用户账务记录指令更新所述用户的账务信息、通过所述渠道支付指令指示所述支付单对应的支付渠道完成支付、通过所述渠道账务记录更新所述支付渠道的账务信息。

上述方法中，通过用户账务记录指令、渠道账务记录指令更新用户侧和渠道侧的账务信息；并通过渠道支付指令完成打款。如此，保证支付渠道打款的可靠性，以及用户侧和渠道侧的账务信息的准确性。

可选的，所述方法还包括：所述交易系统基于事件驱动型有限状态机对所述交易处理请求的处理过程进行监测。

上述方法中，通过事件驱动对交易处理请求的处理进行监测。相比于现有技术中通过具有原子性的事务方式对交易处理请求进行处理，导致交易若出现异常，需要回滚数据量大，占用资源，降低交易设备的性能；且若数据中存在脏数据，导致交易处理的准确性降低。另一方面，本申请还可以通过有限状态机对交易处理请求的处理过程进行监测。如此，当交易处理发生异常时，可以直接根据当前处理异常的流程步骤，发起处理补偿，重新启动当前异常流程步骤。提高交易处理成功率和速度。

第二方面，本发明实施例提供一种多渠道组合支付的装置，该装置包括：

收发模块，用于接收业务系统发送的交易处理请求；

处理模块，用于根据所述交易处理请求中的交易信息，确定所述交易处理请求指示的支付渠道；

所述处理模块还用于，针对任一支付渠道，根据所述交易信息生成所述支付渠道的支付单；

所述处理模块还用于，通过各支付单对应的各支付渠道处理所述各支付单从而完成所述交易处理请求。

第三方面，本申请实施例还提供一种计算设备，包括：存储器，用于存储程序；处理器，用于调用所述存储器中存储的程序，按照获得的程序执行如第一方面的各种可能的设计中所述的方法。

第四方面，本申请实施例还提供一种计算机可读非易失性存储介质，包括计算机可读程序，当计算机读取并执行所述计算机可读程序时，使得计算机执行如第一方面的各种可能的设计中所述的方法。

本申请的这些实现方式或其他实现方式在以下实施例的描述中会更加简明易懂。

附图说明

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

图1为本发明实施例提供的一种多渠道组合支付的架构示意图；

图2为本发明实施例提供的一种多渠道组合支付的业务系统的架构示意图；

图3为本发明实施例提供的一种多渠道组合支付的交易系统的架构示意图；

图4为本发明实施例提供的一种多渠道组合支付的渠道系统的架构示意图；

图5为本发明实施例提供的一种多渠道组合支付的方法的流程示意图；

图6为本发明实施例提供的一种多渠道组合支付的单号关联关系示意图；

图7为本发明实施例提供的一种多渠道组合支付的方法的流程示意图；

图8为本发明实施例提供的一种多渠道组合支付的方法的流程示意图；

图9为本发明实施例提供的一种多渠道组合支付的装置示意图。

具体实施方式

为了使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明作进一步地详细描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本发明保护的范围。

图1为本发明实施例提供的一种多渠道组合支付的系统架构，业务系统101接收处理请求，并根据处理请求中包含的业务类型确定业务单号；业务系统101根据该处理请求生成包含业务单号的交易处理请求，并将该交易处理请求发送至交易系统102。交易系统102根据该交易处理请求中的交易信息确定该交易处理请求指示的支付渠道，交易系统102根据各支付渠道生成对应的支付单，以及各支付单对应的用户账务记录指令、渠道支付指令、渠道账务记录指令，并将各支付单对应的用户账务记录指令、渠道支付指令、渠道账务记录指令依次发送至渠道系统103，使得渠道系统103根据指令完成交易处理。

基于上述图1中的系统架构，如图2所示，业务系统101中可以包括多个业务单生成模块，每个业务单生成模块可以分别用于生成一种业务类型的业务单号。例如：图2中的业务系统101中包含电商业务单生成模块、理财业务单生成模块等等。业务系统101接收处理请求后，根据处理请求中的业务类型，将该处理请求发送至对应业务类型的业务单生成模块生成业务单号；例如：若该处理请求中的业务类型为电商业务，则业务单号为01+20210402(可以包含日期信息等)，若该处理请求中的业务类型为理财业务，则业务单号为02+20210402(可以包含日期信息等)，这里的业务单号只是一种示例，业务单号也可以是随机编号，上述业务单号的生成方法并不对本申请中的业务单号的具体生成方法做限定。

基于上述图1中的系统架构，如图3所示，交易系统102接收业务系统发送的交易处理请求后，根据该交易处理请求中的交易类型，将该交易处理请求发送至对应的交易类型接口，每种类型的交易类型接口对应该种交易类型对应的交易处理模块。本申请图3中示出一种包含转账交易处理模块、充值交易处理模块、提现交易处理模块、退款交易处理模块的交易系统102，其中，转账交易处理模块、充值交易处理模块、提现交易处理模块、退款交易处理模块分别包含组装交易信息单元、生成交易单单元、生成支付单单元、风险评估单元、生成支付指令单元；退款交易处理模块中生成交易单单元还用于确定历史交易单，生成支付单单元还用于确定历史支付单，还包含退款规则查询单元。

基于上述图1中的系统架构，如图4所示，渠道系统103中包含账户系统、内部支付渠道系统和外部支付渠道系统。其中，内部支付渠道系统可以是基于本申请的多渠道组合支付系统，进行包括发放权益活动和消费权益活动的各权益类支付渠道系统；例如，ST快递在本申请的多渠道组合支付系统中的ST快递系统中存储一万元，用作满减、红包或用户余额等权益；针对该一万元的满减、红包或用户余额等权益，本申请的多渠道组合支付系统根据接收的针对该ST快递的交易处理请求进行发放或消费；各权益类支付渠道系统可以包括：ST快递、DD出行、HM电影、FZ售票、TB酒店、市民中心等等。账户系统中包含用户账户模块，用于记录使用本申请多渠道组合支付系统的用户账务信息；账户系统中还包含各内部支付渠道系统的支付渠道账户模块，用于记录使用本申请多渠道组合支付系统的内部支付渠道系统的账务信息。另外，渠道系统103中的外部支付渠道系统为本申请多渠道组合支付系统包含的支付渠道以外的支付渠道，该外部支付渠道可以不包含在本申请多渠道组合支付系统中。例如，外部支付渠道系统可以是银行类支付渠道系统，即，用户的交易支付金额来源于本申请多渠道组合支付系统外部的该银行类支付渠道系统。如此，基于以上图4中的渠道系统103，渠道系统103在接收支付指令后，若该支付指令针对本申请多渠道组合支付系统内部的支付渠道，则通过内部支付渠道系统对该支付指令进行处理；若该支付指令针对本申请多渠道组合支付系统外部的支付渠道，则通过外部支付渠道系统对该支付指令进行处理。上述多渠道组合支付系统、及其业务系统、交易系统和渠道系统的系统架构只是本申请提供的一种实施例，并不对本申请的具体实施做限制。

基于此，本申请实施例提供了一种多渠道组合支付的方法流程，如图5所示，包括：

步骤501、交易系统接收业务系统发送的交易处理请求；

步骤502、所述交易系统根据所述交易处理请求中的交易信息，确定所述交易处理请求指示的支付渠道；

步骤503、所述交易系统针对任一支付渠道，根据所述交易信息生成所述支付渠道的支付单；

步骤504、所述交易系统通过各支付单对应的各支付渠道处理所述各支付单从而完成所述交易处理请求。

上述方法中，根据所述交易信息确定所述交易处理请求指示的支付渠道，进而确定所述交易处理请求对应的至少一个支付单。如此，使得权益类或非权益类的各支付渠道都可以分别对应一个支付单。若发生转账、充值、提现或退款等交易时；根据对应支付单进行交易处理，可以提高交易处理的准确度；根据支付单进行对账，可以只在一个数据源中获取对应的支付单，提高交易处理的效率，降低交易处理占用的资源；根据支付单进行退款可以智能且灵活的直接确定支付单对应的支付渠道，并完成退款。相比于现有技术中的只生成一笔支付单来说，本申请可以提高组合支付处理效率，提高组合支付的智能性和灵活性。

本申请实施例提供了一种支付渠道的确定方法，所述交易系统根据所述交易处理请求中的交易信息，确定所述交易处理请求指示的支付渠道，包括：所述交易处理请求对应的交易类型为支付类交易，所述交易系统根据所述交易信息中的支付渠道标识，确定所述交易处理请求指示的支付渠道；或所述交易处理请求对应的交易类型为退款类交易，所述交易系统根据所述交易信息中的交易单号，确定所述交易处理请求指示的支付渠道。也就是说，若交易处理请求为支付类交易的交易处理请求，则可以在交易处理请求包含的交易信息中设置支付渠道标识，使得交易系统根据分析获得的支付渠道标识确定交易处理请求指示的支付渠道。例如，支付类交易可以包括：转账、充值、提现，以转账为例：用户在APP中下订单时，若选择了红包、满减、优惠券和余额等权益类的支付渠道，则交易处理请求中会包含用户选择的红包、满减、优惠券和余额等多个支付渠道标识；交易系统获取到交易处理请求中的多个支付渠道标识，则确定对应的支付渠道。若交易处理请求为退款类交易，则可以在交易处理请求中包含退款交易对应的支付交易的交易单号，使得交易系统根据交易单号确定交易处理请求指示的支付渠道。在上述示例中，用户将在APP中下的订单上申请退款，则生成包含该订单的交易单号的交易处理请求，交易系统获取到交易处理请求中的交易单号，进一步根据交易单号获取交易单号对应的多个支付单，每个支付单对应一个支付渠道，则交易系统可以确定对应的支付渠道。

本申请实施例提供了一种支付渠道的确定方法，所述交易系统根据所述交易信息中的交易单号，确定所述交易处理请求指示的支付渠道，包括：所述交易系统根据所述交易信息中的交易单号，确定所述交易单号下的各历史支付单对应的各支付渠道；所述交易系统根据所述各支付渠道的退款规则，从支持退款的支付渠道中确定所述交易处理请求指示的支付渠道。基于图3中交易系统的系统架构，交易系统接收交易处理请求后，根据交易类型将该交易处理请求发送至对应的退款交易处理模块接口；退款交易处理模块中的组装交易信息单元将该交易处理请求中的交易信息进行组装，并通过生成交易单单元获取历史交易单号和生成退款交易的交易单号，通过生成支付单单元获取交易单号对应的各历史支付单，通过退款规则查询单元分别向各历史支付单对应的支付渠道发送退款规则请求，获取各支付渠道对应的退款规则，进一步，该生成支付单单元根据各支付渠道对应的退款规则确定各支持退款的支付渠道并生成支付单，进一步，生成支付指令单元根据各支付单生成支付指令发送至渠道系统的对应账户系统和支付渠道完成退款。在交易系统的整个处理过程中，风险评估单元可以在交易信息生成后和支付前的任一流程步骤进行风险评估，若交易风险评估确定该交易异常，则停止交易处理，否则继续执行剩余流程。还可以生成异常通知消息返回至用户。

本申请实施例提供了一种支付渠道的确定方法，从支持退款的支付渠道中确定所述交易处理请求指示的支付渠道，包括：所述交易系统根据各支付渠道的退款权重，确定各支付渠道的退款优先级；所述退款权重为各支付渠道预设的，或根据历史时间段内的各支付渠道的交易状况确定的；所述交易系统根据各支付渠道的退款优先级，从支持退款的支付渠道中确定满足退款金额的支付渠道作为所述交易处理请求指示的支付渠道。

在退款场景中，根据各历史支付单分别生成退款规则查询请求，并将该退款规则查询请求分别发送至对应的支付渠道，获取该支付渠道对应的退款规则后，即获取支持退款的支付渠道。这里提供三种退款方式：

第一种：若确定各支付渠道的退款规则都没有限制，且用户退款为订单的全部交易金额，则各支付渠道将该订单在渠道内的交易金额退回。

第二种：若确定各支付渠道的退款规则都没有限制，且用户退款为订单的部分交易金额，则可以通过水位漏斗模式进行退款，即，根据各支付渠道预设历史时间段内的对应的交易状况确定各支付渠道的退款优先级。该交易状况可以通过水位漏斗模式获得的退款权重值的大小顺序，确定各退款支付渠道的退款优先级。

水位漏斗模式：可以通过以下公式确定各支持退款的支付渠道的退款优先级：

其中，E表示退款权重值；K(Success)和K(Fail)分别表示预设历史时间段内整个支付渠道的交易成功数和交易失败数；t表示退款权重因子，该值由开发人员根据预设历史时间段内的退款数据进行动态配置。根据预设历史时间段内的交易成功率和退款权重因子实现支付渠道的退款权重值的动态配置，可以防止退款权重值不变导致的退款交易集中在一个支付渠道，使得交易处理效率下降，保证交易处理优良性能。其中，退款权重因子t可以根据该支付渠道的预设历史时间段内的交易退款率和交易成功率的总占比的正态分布确定；退款权重因子t可以通过如下公式获得：

其中，x为交易成功率，σ为交易退款率，t为退款权重因子。

另外，在多渠道组合支付系统最开始应用时，即，还不能获取‘交易退款率和交易成功率的总占比的正态分布’这一特征，此时数据处于正态分布的前期，接近于正相关的关系，可以将退款权重因子设置为0.5，后续系统会根据预设历史时间段内实际交易数据进行动态调整。在一种示例中，可以根据交易成功率和交易退款率比等参数动态调整退款权重因子，交易成功率和交易退款率比等参数可以通过专业知识和经验获取；则假设前一日交易成功率较高，交易退款率同样较高，交易成功率和交易退款率比对应较低的退款权重因子，那么第二天的退款权重因子则配置为该较低的退款权重因子，在业务上保证支付和退款比稳定，防止出现某日某一支付渠道集中退款的现象。例如：前一日的交易成功率为百分之九十，但是退款比例高达百分之五十，此时的退款权重因子可以动态调整为前一日的退款权重因子的三分之一(此数值根据系统多次压力测试得出)。

第三种：若确定各支付渠道的退款规则都没有限制，在设定业务场景中，则可以人工预设各支付渠道的退款权重值(退款权重值可以由专业人员的经验或数据分析等确定)确定各支付渠道的退款优先级，以及各支付渠道对应的退款金额。

本申请实施例提供了一种支付渠道的确定方法，所述交易系统针对任一支付渠道，根据所述交易信息生成所述支付渠道的支付单，包括：所述交易系统根据各支付渠道对应的历史支付单中的支付金额，基于各支付渠道的退款优先级，确定各支付渠道的退款金额，从而生成各支付渠道的支付单。也就是说，还可以根据退款权重值确定退款金额，例如，若用户下订单的交易金额100元；支付渠道1的交易金额为60元，退款权重值为0.6、支付渠道2的交易金额为20元，退款权重值为0.5、支付渠道3的交易金额为20元，退款权重值为0.4；支付渠道1的退款优先级大于支付渠道2的退款优先级(支付渠道1的退款权重值0.6大于支付渠道2的退款权重值0.4)、支付渠道2的退款优先级大于支付渠道3的退款优先级(支付渠道2的退款权重值0.5大于支付渠道3的退款权重值0.4)。用户退款金额为40元，则确定该支付渠道1需要退款，确定退款金额为60*0.6＝36元，该支付渠道退款36元即可；确定该支付渠道2需要退款，确定可以退款金额为20*0.5＝8元，8元大于(40-36)元，该支付渠道退款(40-36)元即可；支付渠道3可以不用进行退款。如此，根据各支付渠道对应的商家的业务发展，动态调整退款业务的分担。可以在多数场景的退款中都选择退内部货币、内部积分或者内部优惠券，如此种退款方式，可以提高用户的留存率和用户粘性。

本申请实施例提供了一种多渠道组合支付的方法，交易系统接收业务系统发送的交易处理请求之后，还包括：所述交易系统根据所述交易处理请求中的业务类型，确定所述交易处理请求的业务单号；所述交易系统根据所述交易信息和所述业务单号，生成交易单号；每个交易单号对应至少一个支付单号。如图6所示，对应业务类型的交易处理请求生成一个业务单号，该业务单号对应预设时间内的多笔交易，即交易单号，每笔交易单号又可以对应多个支付单号。例如，交易处理请求发生在对应业务类型的预设时间段内，对应的交易单号为01，若交易信息包括：交易金额-100元、交易类型-转账、至少一个支付渠道标识-XX银行、AA红包、TD积分。则对应该交易生成的交易单号可以分别为：交易单号-01-001，对应XX银行生成支付单的支付单号01-001-1、对应AA红包生成支付单的支付单号01-001-2、对应TD积分生成支付单的支付单号01-001-3。

本申请实施例提供了一种多渠道组合支付的方法，所述交易系统通过各支付单对应的各支付渠道处理所述各支付单，包括：针对任一支付单，所述交易系统生成所述支付单的用户账务记录指令、渠道支付指令和渠道账务记录指令；所述交易系统通过所述用户账务记录指令更新所述用户的账务信息、通过所述渠道支付指令指示所述支付单对应的支付渠道完成支付、通过所述渠道账务记录更新所述支付渠道的账务信息。例如，用户账务记录指令可以根据交易处理请求中用户选择的对应支付渠道的红包8元进行支付的交易信息：在如图2所示的交易系统的账户系统的用户账户模块中，将用户的红包8元删除；渠道账务记录指令可以根据交易处理请求中用户选择的该支付渠道的红包8元进行支付的交易信息，在交易系统的账户系统的该支付渠道的渠道账户模块中将用户的红包8元删除；渠道支付指令可以对应将AA红包中的用户的红包8元打款至商家。该示例是渠道系统的多渠道组合支付内部支付渠道系统的支付方式；另外，该用户账务记录指令、渠道支付指令和渠道账务记录指令还可以发送至对应的外部支付渠道系统，指示外部支付渠道系统更新该用户和该渠道的账务信息，并完成将该用户在该外部支付渠道系统中的交易金额打款至商家。

本申请实施例提供了一种多渠道组合支付的方法，所述方法还包括：所述交易系统基于事件驱动型有限状态机对所述交易处理请求的处理过程进行监测。也就是说，在上述交易系统和渠道系统的交易处理过程中，每笔交易以事件的形式驱动，并结合有限状态机；使得交易处理过程中的状态记录并将包含交易单号的交易状态信息发送至业务系统。则若交易处理出现异常，业务系统接收到的交易状态信息确定该笔交易状态异常，可以模拟用户重新启动交易处理流程，使得重新启动当前处于异常状态的流程步骤，如此可以提高交易成功率，且无需用户感知即可重新启动交易处理；若交易处理正常，则继续处理；若交易处理完成，则可以将交易完成状态的交易状态信息发送至业务系统，业务系统根据交易完成状态完成相应的通知等处理流程。如，可以通知商户发货，或通知用户可以催货等；若交易处理失败，则可以将交易失败状态的交易状态信息发送至业务系统，业务系统根据交易失败状态可以通知商户不发货等。其中，有限状态机可以分别对交易处理请求处理中的针对业务系统生成单号、交易系统生成交易单号、交易系统生成支付单、执行每个支付指令等流程的状态进行监测，这里对具体监测环节和方式并不限定，可以根据具体业务需求进行调节。

基于图1、图2、图3和图4的系统架构、包括图5的方法流程，以及图6的单号关联关系，本申请实施例提供了一种多渠道组合支付的支付类交易的处理方法流程，如图7所示，包括：

步骤701、业务系统接收处理请求，该处理请求中包含：收款方标识、付款方标识、交易类型、交易金额、业务类型、用户选定的至少一个支付渠道标识等交易信息。在一种示例中，处理请求可以是用户在终端的APP或小程序下单后，通过APP或小程序的后台服务系统发送的。

步骤702、业务系统接收处理请求后，根据业务类型生成业务单号。

步骤703、业务系统生成包含业务单号的交易处理请求，并将该交易处理请求发送至交易系统。

步骤704、交易系统根据该交易处理请求的交易信息中的交易类型，将该交易处理请求发送至对应的交易类型接口及交易类型接口对应类型的交易处理模块。

步骤705、该类型的交易处理模块对交易信息进行组装，并为该笔交易生成交易单号。

步骤706、该类型的交易处理模块根据交易信息中的用户选定的至少一个支付渠道标识，确定每个支付渠道标识对应的支付渠道，并生成各支付渠道对应的支付单。

步骤707、该类型的交易处理模块对该交易信息进行风控评估，若该交易信息风控评估结果为异常，则停止交易处理流程；若该交易信息风控评估结果为正常，则执行步骤708。

步骤708、该类型的交易处理模块针对每个支付单生成对应的支付指令，即，用户账务记录指令、渠道支付指令、渠道账务记录指令。

步骤709、该类型的交易处理模块将支付指令发送至渠道系统中，或对应的外部支付渠道系统，使得对应的支付渠道完成支付。

步骤710、上报交易处理请求的处理状态。

这里需要说明的是，上述流程步骤并不唯一，其中，步骤707中的风控评估可以在步骤705后，步骤709之前的任一流程步骤中执行，该流程还可以生成异常通知消息返回至用户。其中，步骤710可以在上述整个流程中的任一流程步骤中，或前后执行。

基于图1、图2、图3和图4的系统架构、包括图5、图7的方法流程，以及图6的单号关联关系，本申请实施例提供了一种多渠道组合支付的支付类交易的处理方法流程，如图8所示，包括：

步骤801、业务系统接收处理请求，该处理请求中包含：收款方标识、付款方标识、交易类型、退款金额、交易单号等交易信息。在一种示例中，处理请求可以是用户在终端的APP或小程序发起退款后，通过APP或小程序的后台服务系统发送的。

步骤802、业务系统根据该处理请求中的交易信息生成退款处理请求，并发送至交易系统。

步骤803、交易系统根据该退款处理请求的交易信息中的交易类型，将该退款处理请求发送至退款交易处理接口及对应的退款交易处理模块。

步骤804、退款交易处理模块对交易信息进行组装，并为该笔交易查询交易单号对应的历史交易单。得到交易信息后，根据交易信息进行风控评估，若风控评估结果确定该交易为异常交易，则停止处理，否则继续执行。

步骤805、退款交易处理模块根据历史交易单获取历史交易单中的对应各支付渠道的历史支付单。

步骤806、退款交易处理模块根据各历史支付单分别生成退款规则查询请求，并将该退款规则查询请求分别发送至对应的支付渠道，获取该支付渠道对应的退款规则。

步骤807、根据各支付渠道对应的退款规则确定支持退款的支付渠道。

步骤808、确定各支持退款的支付渠道的退款优先级。

步骤809、确定各支持退款的支付渠道中的退款支付渠道，以及各退款支付渠道对应的退款金额。

步骤810、根据各退款支付渠道及其对应的退款金额生成支付单。

步骤811、根据各支付单生成支付指令，即，用户账务记录指令、渠道支付指令、渠道账务记录指令。

步骤812、将支付指令发送至渠道系统中，或对应的外部支付渠道系统，使得对应的支付渠道完成退款。

步骤813、上报交易处理请求的处理状态。

这里需要说明的是，上述流程步骤并不唯一，其中，风控评估流程可以在步骤804后，步骤812之前的任一流程步骤中执行，该流程还可以生成异常通知消息返回至用户。其中，步骤813可以在上述整个流程中的任一流程步骤中，或前后执行。

基于同样的构思，本发明实施例提供一种多渠道组合支付的装置，图9为本申请实施例提供的一种多渠道组合支付的装置示意图，如图9示，包括：

收发模块901，用于接收业务系统发送的交易处理请求；

处理模块902，用于根据所述交易处理请求中的交易信息，确定所述交易处理请求指示的支付渠道；

所述处理模块902还用于，针对任一支付渠道，根据所述交易信息生成所述支付渠道的支付单；

所述处理模块902还用于，通过各支付单对应的各支付渠道处理所述各支付单从而完成所述交易处理请求。

可选的，所述处理模块902具体用于：所述交易处理请求对应的交易类型为支付类交易，所述交易系统根据所述交易信息中的支付渠道标识，确定所述交易处理请求指示的支付渠道；或所述交易处理请求对应的交易类型为退款类交易，所述交易系统根据所述交易信息中的交易单号，确定所述交易处理请求指示的支付渠道。

可选的，所述处理模块902具体用于：所述交易系统根据所述交易信息中的交易单号，确定所述交易单号下的各历史支付单对应的各支付渠道；所述交易系统根据所述各支付渠道的退款规则，从支持退款的支付渠道中确定所述交易处理请求指示的支付渠道。

可选的，所述处理模块902具体用于：所述交易系统根据各支付渠道的退款权重，确定各支付渠道的退款优先级；所述退款权重为各支付渠道预设的，或根据历史时间段内的各支付渠道的交易状况确定的；所述交易系统根据各支付渠道的退款优先级，从支持退款的支付渠道中确定满足退款金额的支付渠道作为所述交易处理请求指示的支付渠道。

可选的，所述处理模块902具体用于：所述交易系统根据各支付渠道对应的历史支付单中的支付金额，基于各支付渠道的退款优先级，确定各支付渠道的退款金额，从而生成各支付渠道的支付单。

可选的，所述处理模块902还用于：所述交易系统根据所述交易处理请求中的业务类型，确定所述交易处理请求的业务单号；所述交易系统根据所述交易信息和所述业务单号，生成交易单号；每个交易单号对应至少一个支付单号。

可选的，所述处理模块902具体用于：针对任一支付单，所述交易系统生成所述支付单的用户账务记录指令、渠道支付指令和渠道账务记录指令；所述交易系统通过所述用户账务记录指令更新所述用户的账务信息、通过所述渠道支付指令指示所述支付单对应的支付渠道完成支付、通过所述渠道账务记录更新所述支付渠道的账务信息。

可选的，所述处理模块902还用于：所述交易系统基于事件驱动型有限状态机对所述交易处理请求的处理过程进行监测。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。