支付方法和装置与流程

本发明涉及互联网技术领域，尤其涉及一种支付方法和装置。

背景技术：

随着互联网技术的不断发展，人们的出行方式、购物方式等已经发生了较大的改变，诸如网上购物、外卖订餐等线上到线下(Online To Offline，简称O2O)模式大大方便了人们的生活。

以网上购物来说，在O2O模式下，各服务提供方(比如各餐饮商户)通过与服务平台合作，将自身的商品信息在服务平台上展示，以供用户选择购买。当某用户下单购买了某商品，完成支付之后，服务平台需要基于预先约定的结算协议，将用户的支付金额按协议打款到服务提供方的账户。

技术实现要素：

目前，服务平台一般采用的向服务提供方账户进行支付的支付方式是：通过某种固定的支付方式向服务提供方进行打款，比如通过某种第三方支付方式。

采用固定的单一支付方式进行支付，若因为网络异常、支付系统异常等原因使得该单一支付方式不能正常运行，则会导致支付失败，而且限制了服务平台的支付灵活性。

有鉴于此，本发明实施例提供一种支付方法和装置，用以克服现有采用单一支付方式进行向服务提供方进行支付容易导致支付失败、支付灵活性较差的问题。

本发明实施例提供一种支付方法，包括：

根据订单生成待付款信息；

选择与所述待付款信息对应的支付方式；

采用选择出的支付方式，对所述待付款信息进行支付处理。

可选地，所述选择与所述待付款信息对应的支付方式，包括：

根据支付属性与支付方式间的映射关系，选择与所述待付款信息对应的支付方式。

可选地，所述根据支付属性与支付方式间的映射关系，选择与所述待付款信息对应的支付方式之前，还包括：

获取支付方式选择设置信息，所述支付方式选择设置信息中包括支付属性和支付方式间的第一映射关系，所述映射关系包括所述第一映射关系；

所述根据支付属性与支付方式间的映射关系，选择与所述待付款信息对应的支付方式，包括：

根据所述第一映射关系，选择与所述待付款信息对应的支付方式。

可选地，所述根据支付属性与支付方式间的映射关系，选择与所述待付款信息对应的支付方式之前，还包括：

分析历史支付记录，获取至少一种支付属性分别对应的各支付方式的分值；

根据所述至少一种支付属性分别对应的各支付方式的分值，确定支付属性与支付方式间的第二映射关系，所述映射关系包括所述第二映射关系；

所述根据支付属性与支付方式间的映射关系，选择与所述待付款信息对应的支付方式，包括：

根据所述第二映射关系，选择与所述待付款信息对应的支付方式。

可选地，若所述映射关系包括所述第一映射关系和所述第二映射关系；所述根据支付属性与支付方式间的映射关系，选择与所述待付款信息对应的支付方式，包括：

根据所述第一映射关系和所述第二映射关系的优先级配置信息，确定高优先级的映射关系；

根据高优先级的映射关系，选择与所述待付款信息对应的支付方式。

可选地，所述根据高优先级的映射关系，选择与所述待付款信息对应的支付方式之后，还包括：

若采用根据高优先级的映射关系选择出的支付方式进行支付处理失败，则切换至根据低优先级的映射关系，选择与所述待付款信息对应的支付方式。

本发明实施例提供一种支付装置，包括：

第一生成模块，用于根据订单生成待付款信息；

选择模块，用于选择与所述待付款信息对应的支付方式；

处理模块，用于采用选择出的支付方式，对所述待付款信息进行支付处理。

可选地，所述选择模块具体用于：根据支付属性与支付方式间的映射关系，选择与所述待付款信息对应的支付方式。

可选地，该支付装置还包括：获取模块，用于获取支付方式选择设置信息，所述支付方式选择设置信息中包括支付属性和支付方式间的第一映射关系，所述映射关系包括所述第一映射关系；

相应地，所述选择模块具体用于：根据所述第一映射关系，选择与所述待付款信息对应的支付方式。

可选地，该支付装置还包括：

分析模块，用于分析历史支付记录，获取至少一种支付属性分别对应的各支付方式的分值；

第一确定模块，用于根据所述至少一种支付属性分别对应的各支付方式的分值，确定支付属性与支付方式间的第二映射关系，所述映射关系包括所述第二映射关系；

相应地，所述选择模块具体用于：根据所述第二映射关系，选择与所述待付款信息对应的支付方式。

本发明实施例提供的支付方法和装置，当服务平台接收到用户提交的订单后，基于该订单生成待付款信息，即生成包括付款金额、收款方账户的待付款信息，进而，服务平台进行与该待付款信息对应的支付方式的选择，即选择出用于响应该待付款信息的支付方式，从而采用选择出的支付方式，对待付款信息进行支付处理。

本发明实施例中，当服务平台需要向比如商户进行付款时，服务平台可以自动从多种支付方式中选择一种适用于该次付款的支付方式来响应，服务平台的这种可选择性配置能够克服固定的单一支付方式对支付成功性的不利影响。由于针对每笔待付款信息，都实时地选择与其对应的某种支付方式，扩展了服务平台的支付灵活性。

附图说明

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

图1为本发明实施例提供的支付方法实施例一的流程图；

图2为本发明实施例提供的支付方法实施例二的流程图；

图3为本发明实施例提供的支付方法实施例三的流程图；

图4为图3所示实施例中步骤302的一种可选实现方式的流程图；

图5为图3所示实施例中步骤302的另一种可选实现方式的流程图；

图6为图3所示实施例中步骤304的一种可选实现方式的流程图；

图7为本发明实施例提供的支付方法实施例四的流程图；

图8为本发明实施例提供的支付装置实施例一的结构示意图；

图9为本发明实施例提供的支付装置实施例二的结构示意图；

图10为本发明实施例提供的支付装置实施例三的结构示意图；

图11为本发明实施例提供的支付装置实施例四的结构示意图。

具体实施方式

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

在本发明实施例中使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本发明。在本发明实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义，“多种”一般包含至少两种，但是不排除包含至少一种的情况。

应当理解，本文中使用的术语“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。

应当理解，尽管在本发明实施例中可能采用术语第一、第二、第三等来描述XXX，但这些XXX不应限于这些术语。这些术语仅用来将XXX彼此区分开。例如，在不脱离本发明实施例范围的情况下，第一XXX也可以被称为第二XXX，类似地，第二XXX也可以被称为第一XXX。

取决于语境，如在此所使用的词语“如果”、“若”可以被解释成为“在……时”或“当……时”或“响应于确定”或“响应于检测”。类似地，取决于语境，短语“如果确定”或“如果检测(陈述的条件或事件)”可以被解释成为“当确定时”或“响应于确定”或“当检测(陈述的条件或事件)时”或“响应于检测(陈述的条件或事件)”。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的商品或者系统不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种商品或者系统所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的商品或者系统中还存在另外的相同要素。

图1为本发明实施例提供的支付方法实施例一的流程图，本实施例提供的该支付方法可以由一支付装置来执行，该支付装置可以实现为软件，或者实现为软件和硬件的组合，该支付装置可以集成设置在服务平台侧的设备中，比如服务器中，以下在不引起歧义的情况下，将集成该支付装置的设备称为服务平台。如图1所示，该方法包括如下步骤：

步骤101、根据订单生成待付款信息。

步骤102、选择与待付款信息对应的支付方式。

步骤103、采用选择出的支付方式，对待付款信息进行支付处理。

本发明实施例中提供的支付方法可以适用于如下的应用场景中：当终端用户通过网络购物方式选择好欲购买的商品，完成支付，提交订单后，服务平台接收到该订单。由于用户购物的过程可能涉及到服务平台、商户、物流等不同角色的参与，用户支付的货款需要在这些参与角色之间分配，即服务平台需要基于一定的结算协议，分别向商户、物流方支付一定比例的款项。因此，本发明实施例中涉及到的支付过程主要是指服务平台向比如商户、物流方付款的过程。

由于服务平台接收到的订单中所包含的货款金额需要在上述不同的参与角色间分配，因此，以向商户支付为例，服务平台需要基于该订单生成与商户对应的待付款信息。

可以理解的是，订单中包含有用户购买的商品、支付的货款金额、商户名称等信息，因此，服务平台可以从订单中提取到商户名称、货款金额等信息。进而，服务平台可以基于预先与商户的约定，以及本地存储的各商户的账户，计算获得需要向该商户支付的付款金额，并确定出该商户对应的账户。从而，服务平台可以生产包含该付款金额和收款账户的待付款信息。

值得说明的是，待付款信息中包括付款金额和收款账户仅为举例，实际应用中，可以根据实际需要，待付款信息中还可以包含其他有关的数据内容。

服务平台在生成待付款信息，向收款账户支付该付款金额的过程中，需要选择一种支付方式，即选择与该待付款信息对应的支付方式。也就是说，本发明实施例中，服务平台具有从多种支付方式中选择一种适用于当前生成的该待付款信息的支付方式的能力。

具体来说，服务平台中可以设置多种可选的支付方式供服务平台自动选择。可选地，服务平台从多种支付方式中选择与当前的待付款信息对应的支付方式的选择依据可以是：根据支付属性与支付方式间的映射关系，选择与待付款信息对应的支付方式。

其中，支付属性用于表征支付方式的某种属性特征，该属性特征比如可以是：某种支付方式适用于的账户类型、交易金额上限、每笔交易的手续费用、成功率、平均到账用时等属性的一种或多种。

因此，可以理解的是，当根据支付属性与支付方式间的映射关系选择与待付款信息对应的支付方式时，可选地，可以基于待付款信息中收款账户对应的账户类型和/或付款金额，结合每种支付方式对应的账户类型、交易金额上限进行支付方式的选择；可选地，也可以基于每种支付方式对应的诸如成功率等指标选择一个较佳的支付方式，作为与该待付款信息对应的支付方式。

上述映射关系相关的具体获取方法以及如果根据映射关系选择与待付款信息对应的支付方式的过程，将在后续实施例中详细说明。本实施例中，主要是想说明服务平台被配置为具有从多种支付方式中选择一种适用于待付款信息的支付方式的能力。

服务平台在选择出与待付款信息对应的支付方式后，采用该支付方式完成待付款信息的支付处理，即将待付款信息中的付款金额打款到收款账户中。

值得说明的是，本发明实施例中，支付方式可以是某种银行支付方式，也可以是第三方支付方式，比如支付宝等。

本实施例提供的支付方法：当服务平台接收到用户提交的订单后，基于该订单生成待付款信息，即生成包括付款金额、收款方账户的待付款信息，进而，服务平台进行与该待付款信息对应的支付方式的选择，即选择出用于响应该待付款信息的支付方式，从而采用选择出的支付方式，对待付款信息进行支付处理。

本实施例中，当服务平台需要向比如商户进行付款时，服务平台可以自动从多种支付方式中选择一种适用于该次付款的支付方式来响应，服务平台的这种可选择性配置能够克服固定的单一支付方式对支付成功性的不利影响。由于针对每笔待付款信息，都实时地选择与其对应的某种支付方式，扩展了服务平台的支付灵活性。

前述实施例中提到：可以根据支付属性与支付方式间的映射关系选择与待付款信息对应的支付方式。下面将结合几个实施例详细说明该映射关系的获取方式，以及如何根据该映射关系进行支付处理。

在结合具体的实施例进行详细说明之前，首先对该映射关系的获取进行概括说明。

本发明实施例中，该映射关系的获取方式包括手动设置获取、自动分析获取两种方式，为了进行区别，以下将手动设置获取的映射关系称为第一映射关系，将服务平台自动分析获取的映射关系称为第二映射关系。这两种映射关系可以择一存在于服务平台中，也可以同时存在于服务平台中，也就是说，服务平台可以通过第一映射关系和/或第二映射关系来选择与待付款信息对应的支付方式。

下面结合图2所示实施例对手动设置获取第一映射关系的过程进行说明。

图2为本发明实施例提供的支付方法实施例二的流程图，如图2所示，该方法包括如下步骤：

步骤201、获取支付方式选择设置信息，支付方式选择设置信息中包括支付属性和支付方式间的第一映射关系。

本实施例中，支付方式选择设置信息可以是服务平台侧的工作人员通过界面配置输入到服务平台中的，通过该配置操作，工作人员将支付属性和支付方式间的第一映射关系配置到服务平台中。

可选地，该支付属性包括收款账户类型和/或交易金额上限，但是并不以此为限。

以支付属性为收款账户类型为例，相当于工作人员可以设置向什么类型的收款账户进行付款可以采用什么样的支付方式，即建立支付方式与收款账户类型间的对应关系。

以交易金额上限为例，相当于工作人员可以设置支付方式与交易金额上限间的对应关系。

在一可选的实施例中，工作人员手动设置的上述第一映射关系主要考虑待付款信息中所包含的参数内容，比如待付款信息中包含收款账户、付款金额等。

步骤202、根据订单生成待付款信息。

该步骤与图1所示实施例中的对应步骤一致，不再赘述。

步骤203、根据第一映射关系，选择与待付款信息对应的支付方式。

步骤204、采用选择出的支付方式，对待付款信息进行支付处理。

本实施例中，当服务平台中存储有手动设置的上述第一映射关系时，服务平台在生成上述待付款信息后，基于该第一映射关系，选择与该待付款信息对应的支付方式。具体地，可以基于待付款信息中收款账户对应的账户类型和/或付款金额，结合每种支付方式对应的账户类型、交易金额上限进行支付方式的选择。

举例来说，假设待付款信息中包括的付款金额为Z，收款账户的账户类型为A类型，假设第一映射关系为：

支付方式1，收款账户类型为A类型账户，交易金额上限为X；

支付方式2，收款账户类型为B类型账户，交易金额上限为Y；

支付方式3，收款账户类型为A类型账户，交易金额上限为Y；

其中，X大于Y，Z小于Y。

那么，当基于该第一映射关系选择与待付款信息对应的支付方式时，可以基于账户类型和交易金额上限从第一映射关系中包含的上述三组对应关系中选择一种适合的支付方式。在前述假设条件下，与待付款信息中的收款账户类型A对应的支付方式为支付方式1和支付方式3，并且，这两种支付方式的交易金额上限都可以适用于待付款信息中的付款金额Z。从而，可以初步确定支付方式1和支付方式3都可以用于待付款信息的支付处理。

当出现上述举例的情况，即基于第一映射关系能够匹配到至少两种可以适用于待付款信息的支付方式时，可选地，可以从这至少两种支付方式中随机选择一个；可选地，也可以基于其他的选择指标进行进一步地选择，比如选择交易金额上限高的支付方式。

值得说明的是，本实施例中仅以待付款信息中包含付款信息和收款账户为例进行了说明，但是实际应用中，待付款信息中还可以包括交易类型等信息，相应地，第一映射关系中的支付属性中也可以包括交易类型这一属性，设置什么样的支付方式适于什么样的交易类型的交易的对应关系。

本实施例中，服务平台可以基于手动设置的支付方式和支付属性间映射关系进行与待付款信息对应的支付方式的选择，使得选择出的支付方式适宜于当前生成的待付款信息，使得服务平台能够基于当前需要处理的待付款信息进行相应支付方式的灵活选择，不必局限于一种固定的支付方式。

下面结合图3所示实施例对自动分析设置获取第二映射关系的过程进行说明。

图3为本发明实施例提供的支付方法实施例三的流程图，如图3所示，该方法包括如下步骤：

步骤301、分析历史支付记录，获取至少一种支付属性分别对应的各支付方式的分值。

步骤302、根据获取的至少一种支付属性分别对应的各支付方式的分值，确定支付属性与支付方式间的第二映射关系。

步骤303、根据订单生成待付款信息。

步骤304、根据第二映射关系，选择与待付款信息对应的支付方式。

步骤305、采用选择出的支付方式，对待付款信息进行支付处理。

针对步骤301来说，本实施例中，历史支付记录可以包括当前生成待付款信息之前的、已经完成支付的任一付款信息对应的支付记录。每条支付记录中可以包括对应的支付方式、收款账户、将付款信息发送至该支付时的时刻、收到该支付方式反馈的支付完成时刻、手续费、成功/失败反馈提示等信息中的一种或多种信息。

基于上述信息，可以从不同的支付属性维度对所有或部分历史支付记录进行分析，以从不同支付属性维度度量每种支付方式。

可选地，支付属性包括如下属性中的至少一种：收款账户类型、支付成功率、平均支付完成时间、单笔手续费。

针对收款账户类型来说，通过对每条历史支付记录中收款账户对应的账户类型和采用的支付方式的分析，可以统计获得同一账户类型分别对应的支付方式，进而基于每种支付方式的累计使用次数的统计结果，可以确定每种支付方式的分值。举例来说，假设针对A类型账户，统计确定向A类型账户进行支付时采用的支付方式包括支付方式1、支付方式2和支付方式3，并且统计获得采用支付方式1向A类型账户支付的次数为C1，采用支付方式2向A类型账户支付的次数为C2，采用支付方式3向A类型账户支付的次数为C3。那么可以确定支付方式1、支付方式2、支付方式3对应的分值分别为C1、C2、C3或者是次数归一化的结果。

针对单笔手续费来说，可以通过对大量历史支付记录的分析，划定手续费的几个数值区间，针对每个数值区间，确定手续费落入该数值区间的支付方式。进而，针对落入同一数值区间的各支付方式来说，可以统计采用每种支付方式的历史支付记录占全部支付记录的比值。此时，每种支付方式的分值由其对应的数值区间的权重以及其所占的该比值确定。

针对支付成功率来说，首先可以通过对每条历史支付记录中所对应的支付方式的统计，确定每种支付方式被采用的总次数；进而可以基于每条历史支付记录中包含的支付成功/失败提示，确定每种支付方式成功支付的总次数；最后根据每种支付方式成功支付的总次数与其被采用的总次数的比值，确定每种支付方式的成功率。

针对平均支付完成时间来说，可以首先对全部历史支付记录按照采用的支付方式的不同进行分类集合的划分；对于任一支付方式对应的集合：根据其中的每条历史支付记录中包含的将付款信息发送至该支付时的时刻、收到该支付方式反馈的支付完成时刻，确定该条历史支付记录对应的该支付方式的支付完成时间；进而通过对该集合中全部历史支付记录对应的支付完成时间取平均值计算，可以确定该支付方式对应的平均支付完成时间分值。

针对步骤302来说，在确定了至少一种支付属性分别对应的各支付方式的分值之后，可以基于此，确定支付属性与支付方式间的第二映射关系。可选地，对于该第二映射关系的确定，可以采用如图4和图5所示的两种可选实现方式实现：

图4为图3所示实施例中步骤302的一种可选实现方式的流程图，如图4所示，包括如下步骤：

步骤401、根据每种支付属性对应的各支付方式的分值，对各支付方式进行排序。

步骤402、确定每种支付属性对应的分值最高的前N种支付方式为与每种支付属性具有第二映射关系的支付方式。

其中，N为小于或等于支付方式总数的正整数。

本实施例中，第二映射关系中具体包含多组支付属性与支付方式间的对应关系，每组对应关系反映了一种支付属性与多个支付方式间的对应关系。从而可知，本实施例中是从单一的一个个支付属性的角度，建立上述第二映射关系的。

具体来说，针对任一支付属性来说，在通过步骤301已经获取其对应的多种支付方式的分值之后，可以对该多种支付方式基于分值多少进行降序排列，从而截取排在前N位的支付方式作为与该支付属性具有第二映射关系的支付方式，即建立该支付属性与排序在前N位的支付方式间的第二映射关系。其中，N的取值可以经验设定，一般小于该支付属性对应的全部支付方式的数量。

图5为图3所示实施例中步骤302的另一种可选实现方式的流程图，如图4所示，包括如下步骤：

步骤501、根据获得的至少一种支付属性分别对应的各支付方式的分值，计算各支付方式分别对应的总分值。

步骤502、根据各支付方式分别对应的总分值，对各支付方式进行排序。

步骤503、根据各支付方式的排序，确定至少一种支付属性构成的支付属性集合与各支付方式间的第二映射关系。

本实施例中是从支付方式的角度建立上述第二映射关系的，亦即从支付属性集合的角度建立上述第二映射关系的。也就是说，本实施例中，第二映射关系反映的是支付属性集合与多种支付方式间的映射关系。

具体来说，当针对每个支付属性通过步骤301获取了其对应的多种支付方式的分值之后，针对同一支付方式，可以计算获得其对应的总分值，该总分值根据该支付方式对应的各个支付属性的分值确定。可选地，该总分值的确定过程中，可以考虑不同支付属性的权重，即该总分值是各支付属性对应的分值的加权和。

进而，按照总分值对全部支付方式进行降序排列，从而构建了支付属性集合与各支付方式间的第二映射关系，该第二映射关系体现了在考虑该支付属性集合中的支付属性的情况下，各支付方式的综合性能排序结果。

可选地，在通过图4和图5所示实施例构建了上述第二映射关系之后，步骤304中根据第二映射关系选择与待付款信息对应的支付方式相应地可以基于图4所示实施例构建的第二映射关系实现，也可以基于图5所示实施例构建的第二映射关系实现。

在基于图5所示实施例构建的第二映射关系实现时：可选地，可以从多种方式中选择排在第一位的支付方式作为与待付款信息对应的支付方式。可选地，还可以综合考虑各种支付方式当前的负载情况和排序情况，从多种支付方式中选择一种排位靠前，且负载量相对较轻的支付方式。其中，支付方式的负载情况可以通过统计短时间内每种支付方式被使用的次数确定。

在基于图4所示实施例构建的第二映射关系实现时，结合图6具体说明步骤304中根据第二映射关系选择与待付款信息对应的支付方式的实现过程。

图6为图3所示实施例中步骤304的一种可选实现方式的流程图，如图6所示，包括如下步骤：

步骤601、根据每种支付属性的优先级，确定第一优先级支付属性。

步骤602、若第一优先级支付属性对应的N种支付方式中不存在分值与第一支付方式的分值相等的第二支付方式，则选择第一支付方式作为与待付款信息对应的支付方式。

步骤603、若第一优先级支付属性对应的N种支付方式中存在分值与第一支付方式的分值相等的第二支付方式，则比较第一支付方式和第二支付方式分别对应的第二优先级支付属性的分值。

步骤604、选择第一支付方式和第二支付方式中第二优先级支付属性的分值较高的支付方式作为与待付款信息对应的支付方式。

值得说明的是，步骤602和步骤603-604是并列的时序关系。

由于基于图4所示实施例构建的第二映射关系反映了多组支付属性与支付方式间的对应关系，每组对应关系之间相互独立。可选地，为了能够基于不同的支付属性进行支付方式的选择，可以为每种支付属性配置不同的优先级。不同支付属性的优先级可以预先人为基于不同支付属性的重要程度而设定。

因此，在基于该第二映射关系进行与待付款信息对应的支付方式的选择的过程中，可以首先根据每种支付属性的优先级，确定第一优先级支付属性，进而可选地，可以从第一优先级支付属性对应的N种支付方式中，选择排在第一位的第一支付方式作为待付款信息对应的支付方式。

实际应用中，有一种可能存在的情况是：针对任一支付属性来说，其对应的N种支付方式中，可能存在分值相等的情况。此时，对于分值相等的支付方式来说，在排序不高于比其分值高，不低于比其分值低的前提下，可以随机确定其排序。那么，对于某支付属性来说，可能会存在排在前几位的支付方式具有相同的分值的情况。

因此，可选地，若第一优先级支付属性对应的N种支付方式中不存在分值与第一支付方式的分值相等的第二支付方式，则可以选择第一支付方式作为与待付款信息对应的支付方式。

另外可选地，若第一优先级支付属性对应的N种支付方式中存在分值与第一支付方式的分值相等的第二支付方式，则比较第一支付方式和第二支付方式分别对应的第二优先级支付属性的分值，选择第一支付方式和第二支付方式中第二优先级支付属性的分值较高的支付方式作为与待付款信息对应的支付方式。

也就是说，当第一优先级支付属性对应的前几种支付方式的分值相同时，可以考虑这几种支付方式对应的第二优先级支付属性的分值，从中选择一个第二优先级支付属性对应的分值较高的支付方式。当然，如果这几种支付方式对应的第二优先级支付属性分值也有相同的，继续比较第三优先级支付属性的分值情况，直到选择出一种支付方式为止。此时，相当于纵向综合考虑了一种支付方式在不同支付属性方面的排名情况。

在某些可选实施例中，上述各支付属性的优先级是可以动态改变的，可以基于各支付属性在一定时间段内的表现情况动态调整其优先级顺序。比如：根据预设时间段内每种支付属性对应的各支付方式的分值，确定每种支付属性的变化情况；根据每种支付属性的变化情况，调整每种支付属性的优先级。

可选地，每种支付属性的变化情况可以体现为对应的多种支付方式的总分值得变化情况，也可以体现为对应的多种支付方式中的每种支付方式的分值的变化情况加权结果，加权可以根据支付方式的排序确定每种支付方式的加权系数。相应地，如果某种支付属性在不同时间段内的变化情况表征该支付属性表现不稳定，则可以调低其优先级顺序。

通过上述实施例，服务平台基于自动分析设置的支付方式和支付属性间映射关系进行与待付款信息对应的支付方式的选择，使得选择出的支付方式具有相对更佳的性能，比如成功率更高、到账及时性更佳、手续费更低等，从而更佳适宜于当前生成的待付款信息。基于该映射关系进行支付方式的选择，使得服务平台能够更佳灵活地选择适合的支付方式，不必局限于一种固定的支付方式。

图7为本发明实施例提供的支付方法实施例四的流程图，在图2-图6所示实施例的基础上，当服务平台中同时存储有第一映射关系和第二映射关系时，如图7所示，该方法包括如下步骤：

步骤701、根据订单生成待付款信息。

步骤702、根据第一映射关系和第二映射关系的优先级配置信息，确定高优先级的映射关系。

本实施例中，当服务平台中同时存储有第一映射关系和第二映射关系时，可以预先配置这两种第二映射关系的优先级。

步骤703、根据高优先级的映射关系选择与待付款信息对应的支付方式。

当高优先级的映射关系为第一映射关系时，可以参照图2所示实施例进行支付方式的选择，当高优先级的映射关系为第二映射关系时，可以参照图3-图6所示实施例进行支付方式的选择，在此不赘述。

值得说明的是，在一些可选实施例中，若采用根据高优先级的映射关系选择出的支付方式进行支付处理失败，则切换至根据低优先级的映射关系选择与所述待付款信息对应的支付方式。

步骤704、采用选择出的支付方式对待付款信息进行支付处理。

步骤705、生成与待付款信息对应的支付记录。

在一些可选实施例中，由于第一映射关系是人为手动设置的，相对固定不变，可能随着时间的推移，该第一映射关系不再适用于作为进行支付方式的选择依据，此时，统计采用第一映射关系进行支付处理的失败次数，在失败次数达到预设阈值时，删除第一映射关系。

本发明实施例中，当服务平台中存储有两种不同的映射关系时，可以基于用户设置的优先级顺序，选择使用哪个映射关系，以满足用户的需求。通过对映射关系失败次数的统计，删除不适宜再用的映射关系，避免了映射关系的冗余对支付方式选择效率的影响。

以下将详细描述本发明的一个或多个实施例的支付装置。这些支付装置可以被实现在服务器的基础架构中，也可以被实现在服务器和客户端的交互系统中。本领域技术人员可以理解，这些支付装置均可使用市售的硬件组件通过本方案所教导的步骤进行配置来构成。

图8为本发明实施例提供的支付装置实施例一的结构示意图，如图8所示，该支付装置包括：第一生成模块11、选择模块12、处理模块13。

第一生成模块11，用于根据订单生成待付款信息。

选择模块12，用于选择与所述待付款信息对应的支付方式。

处理模块13，用于采用选择出的支付方式，对所述待付款信息进行支付处理。

其中，可选地，所述选择模块12具体用于：根据支付属性与支付方式间的映射关系，选择与所述待付款信息对应的支付方式。

图8所示装置可以执行图1所示实施例的方法，本实施例未详细描述的部分，可参考对图1所示实施例的相关说明。该技术方案的执行过程和技术效果参见图1所示实施例中的描述，在此不再赘述。

图9为本发明实施例提供的支付装置实施例二的结构示意图，如图9所示，在图8所示实施例基础上，该支付装置还包括：获取模块21。

获取模块21，用于获取支付方式选择设置信息，所述支付方式选择设置信息中包括支付属性和支付方式间的第一映射关系，所述映射关系包括所述第一映射关系。

相应地，所述选择模块12具体用于：根据所述第一映射关系，选择与所述待付款信息对应的支付方式。

可选地，所述支付属性包括收款账户类型和/或交易金额上限。

图9所示装置可以执行图2所示实施例的方法，本实施例未详细描述的部分，可参考对图2所示实施例的相关说明。该技术方案的执行过程和技术效果参见图2所示实施例中的描述，在此不再赘述。

图10为本发明实施例提供的支付装置实施例三的结构示意图，如图10所示，在图8所示实施例基础上，该支付装置还包括：分析模块31、第一确定模块32。

分析模块31，用于分析历史支付记录，获取至少一种支付属性分别对应的各支付方式的分值。

第一确定模块32，用于根据所述至少一种支付属性分别对应的各支付方式的分值，确定支付属性与支付方式间的第二映射关系，所述映射关系包括所述第二映射关系。

相应地，所述选择模块12具体用于：根据所述第二映射关系，选择与所述待付款信息对应的支付方式。

可选地，所述支付属性包括如下属性中的至少一种：收款账户类型、支付成功率、平均支付完成时间、单笔手续费。

可选地，所述第一确定模块32，包括：第一排序子模321、第一确定子模块322。

第一排序子模块321，用于根据每种支付属性对应的各支付方式的分值，对所述各支付方式进行排序。

第一确定子模块322，用于确定每种支付属性对应的分值最高的前N种支付方式为与所述每种支付属性具有所述第二映射关系的支付方式，其中，N为小于或等于支付方式总数的正整数。

相应地，所述选择模块12包括：第二确定子模块121、第一选择子模块122、比较子模块123、第二选择子模块124。

第二确定子模块121，用于根据每种支付属性的优先级，确定第一优先级支付属性。

第一选择子模块122，用于若所述第一优先级支付属性对应的N种支付方式中不存在分值与第一支付方式的分值相等的第二支付方式，则选择所述第一支付方式作为与所述待付款信息对应的支付方式。

比较子模块123，用于若所述第一优先级支付属性对应的N种支付方式中存在分值与第一支付方式的分值相等的第二支付方式，则比较所述第一支付方式和所述第二支付方式分别对应的第二优先级支付属性的分值。

第二选择子模块124，用于选择所述第一支付方式和所述第二支付方式中第二优先级支付属性的分值较高的支付方式作为与所述待付款信息对应的支付方式。

可选地，该支付装置还包括：第二确定模块33、调整模块34。

第二确定模块33，用于根据预设时间段内每种支付属性对应的各支付方式的分值，确定所述每种支付属性的变化情况。

调整模块34，用于根据所述每种支付属性的变化情况，调整所述每种支付属性的优先级。

可选地，所述第一确定模块32包括：计算子模块323、第二排序子模块324、第三确定子模块325。

计算子模块323，用于根据所述至少一种支付属性分别对应的各支付方式的分值，计算所述各支付方式分别对应的总分值。

第二排序子模块324，用于根据所述各支付方式分别对应的总分值，对所述各支付方式进行排序。

第三确定子模块325，用于根据所述各支付方式的排序，确定所述至少一种支付属性构成的支付属性集合与所述各支付方式间的所述第二映射关系。

图10所示装置可以执行图3至图6所示实施例的方法，本实施例未详细描述的部分，可参考对图3至图6所示实施例的相关说明。该技术方案的执行过程和技术效果参见图3至图6所示实施例中的描述，在此不再赘述。

图11为本发明实施例提供的支付装置实施例四的结构示意图，如图11所示，在前述实施例基础上，若所述映射关系包括所述第一映射关系和所述第二映射关系，所述选择模块12具体用于：根据所述第一映射关系和所述第二映射关系的优先级配置信息，确定高优先级的映射关系；根据高优先级的映射关系，选择与所述待付款信息对应的支付方式。

可选地，所述选择模块12还用于：若采用根据高优先级的映射关系选择出的支付方式进行支付处理失败，则切换至根据低优先级的映射关系，选择与所述待付款信息对应的支付方式。

可选地，该支付装置还包括：统计模块41、删除模块42、第二生成模块43。

统计模块41，用于统计采用所述第一映射关系进行支付处理的失败次数；

删除模块42，用于在所述失败次数达到预设阈值时，删除所述第一映射关系。

第二生成模块43，用于生成与所述待付款信息对应的支付记录。

图11所示装置可以执行图7所示实施例的方法，本实施例未详细描述的部分，可参考对图7所示实施例的相关说明。该技术方案的执行过程和技术效果参见图7所示实施例中的描述，在此不再赘述。

以上描述了支付装置的内部功能和结构，实际中，该支付装置可实现为服务器，包括：输入设备、处理器；

所述输入设备，用于接收订单；

所述处理器，耦合到所述输入设备，用于根据订单生成待付款信息；选择与所述待付款信息对应的支付方式；采用选择出的支付方式对所述待付款信息进行支付处理。

可选地，所述处理器还用于执行上述图1至图7所示方法步骤中的全部或部分步骤。

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

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助加必需的通用硬件平台的方式来实现，当然也可以通过硬件。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以产品的形式体现出来，该计算机产品可以存储在计算机可读存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机装置(可以是个人计算机，服务器，或者网络装置等)执行各个实施例或者实施例的某些部分所述的方法。

最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。