一种资源处理方法及装置与流程

本申请涉及计算机技术领域，尤其涉及一种资源处理方法及装置。

背景技术：

用户在使用业务提供方(如：网站)所提供的业务时，通常将消耗业务提供方一定数量的资源。对于用户而言，为了能够正常的使用该业务，通常会向业务提供方反馈相应数量的资源代价。

目前，在实际应用中，业务提供方面向用户提供一种线上的预付资源(如：电子券、电子预付卡等，以下简称为：预付资源)，该预付资源可以在用户使用业务提供方的业务时，抵消相应数量的资源代价。

现有技术中，用户可以逐次从业务提供方处获取预付资源，那么，当用户使用了业务提供方所提供的业务时，用户就可以使用已获取的预付资源。具体地，业务提供方后台的服务器(以下简称为：服务器)将针对用户每次获取的预付资源创建资源账户(也即，每个资源账户对应于用户每次所获取的预付资源)，并建立各资源账户与该用户之间的关联。当用户需要使用预付资源时，服务器会确定与该用户具有关联的各资源账户，并依次从各资源账户中扣除相应数量的预付资源，直到所扣除的预付资源的总量与业务所需的资源总量一致为止。

例如：某用户购买业务提供方所提供的多张电子预付卡，相应地，服务器会分别针对每一张电子预付卡在后台建立预付账户，并关联该用户，那么，当该用户就要进行支付时，只需向该业务提供方提供该用户自身的用户信息(如：用户名)，服务器就会根据该用户信息确定出该用户的多个预付账户，并逐一地从该预付账户中扣除相应的额度以便完成支付。

但是，在上述方式中，服务器需要逐一从各资源账户中扣除相应数量的预付资源，这一过程需要耗费一定的时长，尤其在大量用户均使用自身的预付资源的情况下，将增加服务器的处理负荷，使得扣除预付资源过程所需的时间延长，降低了用户正常获得业务的效率。

技术实现要素：

本申请实施例提供一种资源处理方法，用以解决现有技术中业务提供方的服务器扣除用户的预付资源的效率降低的问题。

本申请实施例提供一种资源处理装置，用以解决现有技术中业务提供方的服务器扣除用户的预付资源的效率降低的问题。

本申请实施例采用下述技术方案：

本申请实施例提供的一种资源处理方法，包括：

接收用户发出的业务请求；

确定所述业务请求所对应的资源消耗量；

确定预先创建的该用户的总资源账户；其中，所述总资源账户中包含属于该用户的全部预付资源；

从该总资源账户中获取与所述资源消耗量对应的预付资源，以对所述业务请求进行处理。

本申请实施例另提供的一种资源处理方法，包括：

接收用户的支付请求；

确定所述支付请求所对应的支付金额；

确定预先创建的该用户的总预付卡账户；其中，所述总预付卡账户中包含属于该用户的全部预付卡资金；

从该总预付卡账户中扣除与支付金额相同数额的预付卡资金，以对所述支付请求进行处理。。

本申请实施例提供的一种资源处理装置，包括：

接收模块，接收用户发出的业务请求；

确定模块，确定所述业务请求所对应的资源消耗量；

总账户模块，确定预先创建的该用户的总资源账户；其中，所述总资源账户中包含属于该用户的全部预付资源；

处理模块，从该总资源账户中获取与所述资源消耗量对应的预付资源，以对所述业务请求进行处理。

本申请实施例另提供的一种资源处理装置，包括：

接收模块，接收用户发出的支付请求；

确定模块，确定所述支付请求所对应的支付金额；

总账户模块，确定预先创建的该用户的总预付卡账户；其中，所述总预付卡账户中包含属于该用户的全部预付卡资金；

处理模块，从该总预付卡账户中扣除与支付金额相同数额的预付卡资金，以对所述支付请求进行处理。

本申请实施例采用的上述至少一个技术方案能够达到以下有益效果：

业务提供方的服务器会针对为用户所建立的各子资源账户中的预付资源进行统计，并为用户建立总资源账户，将统计得到的总预付资源量存储在总资源账户中。这样一来，当服务器获取用户的预付资源时，就无需逐一地从每个子资源账户中分别获取预付资源，而是可以直接从总资源账户中一并获取到相应数量的预付资源。显然，这样的方式能够有效减少服务器获取预付资源的时长，进而提升了对业务的处理效率。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1a为本申请实施例提供的资源处理架构示意图；

图1b为本申请实施例提供的资源处理过程示意图；

图2a～2c为本申请实施例提供的创建资源账户的示意图；

图3为本申请实施例提供的在使用预付资源后资源账户的示意图；

图4a～4b为本申请实施例提供的在具有折算系数的情况下预付资源的示意图；

图5a为本申请实施例提供的在商户场景下的资源处理架构示意图；

图5b为基于如图5a所示架构下的资源处理流程示意图；

图6为本申请实施例提供的资源处理装置结构示意图；

图7为本申请实施例提供的在商户场景下的资源处理装置结构示意图。

具体实施方式

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

如前所述，在用户使用预付资源的过程中，服务器通常会逐一地从该用户对应的预付账户中获取相应的预付资源，而该过程将耗费一定的时长，导致业务提供方为用户提供业务的效率较低。

基于此，就需要一种在用户使用预付资源的过程中，可以快速、便捷地获取预付账户内的预付资源的方法。故在本申请实施例中，提供一种资源处理方法，以实现服务器可以快速获取用户的预付资源，提升为用户提供业务的效率。

需要说明的是，本申请实施例中所述的业务提供方可以是能够提供在线业务的业务提供方，诸如：网站、电信运营商等；也可以是能够提供线下业务的业务提供方(该场景下，业务提供方所提供的预付资源仍是线上预付资源)，诸如：商店、餐馆等。基于此，业务提供方的服务器就可以是诸如：网站服务器、电信运营商服务器，或用于处理线上预付资源的服务器等，这里并不构成对本申请的限定。

以下结合附图，详细说明本申请各实施例提供的技术方案。

如图1a所示，示出了本申请实施中的资源处理的架构示意图。基于如图1a所示的架构，本申请实施例中的资源处理方法如图1b所示，具体包括以下步骤：

S101：接收用户发出的业务请求。

在实际应用场景下，用户可以使用由业务提供方所提供的业务服务，此时，用户可以发出相应的业务请求，如：用户使用云计算业务时，发出云计算请求；或者，用户使用网络存储业务，发出存储请求等等。相应地，业务提供方的服务器将接收到由用户发送的业务请求。

当然，作为本申请实施例中的可选方式，用户可以使用终端(可包括：手机、平板电脑、计算机等)，以扫码、在相应页面中点击业务控件等方式，向业务提供方发出业务请求。这里并不构成对本申请的限定。

S102：确定所述业务请求所对应的资源消耗量。

如前所述，业务提供方在处理用户的业务请求时，通常会消耗一定量的资源，如：业务提供方为用户提供云计算业务的过程中，将消耗相应的处理资源；在提供网络存储业务的过程中，将消耗数据库内的存储空间。那么，用户就需要向业务提供方支付相应的资源代价。

故当服务器接收到用户的业务请求后，将首先确定处理该业务请求所需的资源的数量(即，业务消耗量)，以便在后续过程中确定出用户所要支付的资源代价。

S103：确定预先创建的该用户的总资源账户。

其中，所述总资源账户中包含属于该用户的全部预付资源。

在本申请实施例中，用户的总资源账户，是基于该用户的各资源账户(为了区别于总资源账户，将针对用户历次获取预付资源而分别建立的资源账户，称为：子资源账户)所预先建立的，可以认为，总资源账户中所存储的预付资源，是用户各子资源账户内预付资源的总和，也即，总资源账户内包含了属于该用户的预付资源总量。

例如：假设某用户拥有子资源账户A和B，其中，子资源账户A中的预付资源量为100，子资源账户B中包含的预付资源量为200，那么，该用户的总资源账户中所包含的预付资源总量就为300。

需要说明的是，本申请实施例中的总资源账户是由服务器为用户创建的。作为本申请实施例中的一种方式，服务器中存储有用户的标识(如：userID、该用户在服务器中注册的业务账号等)，那么，服务器便可以基于用户的标识，为用户创建总资源账户。例如：某用户在服务器中注册有名为“xiaoming”的业务账户，那么，服务器可基于该业务账户的账户名，为该用户创建总资源账户“xiaoming-general source account”，在创建了总资源账户之后，服务器会将该用户的所有预付资源汇总并存储在该总资源账户中。

当然，上述示例仅是针对总资源账户创建的一种可行方式的说明，并不构成对本申请的限定。

与现有技术不同的是，本申请实施例中，总资源账户将属于某用户的所有预付资源汇总，所以，后续扣除预付资源的过程便无需逐一地从子资源账户中获取。

S104：从该总资源账户中获取与所述资源消耗量对应的预付资源，以对所述业务请求进行处理。

当确定出了业务请求所要消耗的资源量、以及用户总资源账户中所包含的预付资源总量后，便可以从用户的总资源账户中扣除相应数量的资源。

这里需要说明的是，在实际应用场景下，可能出现不同的情况：

一种情况是业务请求所消耗的资源量不大于总资源账户中包含的预付资源总量，那么，服务器便可从总资源账户中扣除业务请求所要消耗的资源量。例如：假设业务请求所消耗的资源量为80，用户的总资源账户中预付资源总量为100，那么，可在总资源账户中扣除80的预付资源量，之后，总资源账户中剩余的预付资源量为20。

另一种情况是业务请求所消耗的资源量大于总资源账户中包含的预付资源总量，那么，服务器可向终端反馈失败通知，以告知用户其拥有的预付资源不足抵扣业务请求的资源消耗量；或者，服务器可将总资源账户内的所有预付资源均扣除，对于不足抵扣的部分，向终端反馈差额补足通知，用户可采用其他方式支付剩余的资源量。例如：假设业务请求所消耗的资源量为200，用户的总资源账户中预付资源总量为100，此时，可将用户的总资源账户内的全部预付资源总量扣除，但业务请求所消耗的资源量还余留100，故用户可选择诸如直接支付资源的方式，以补足余留的资源消耗量。这里并不构成对本申请的限定。

通过上述步骤，业务提供方的服务器预先创建了用户的总资源账户，其中，总资源账户将属于用户的所有预付资源进行汇总，所以，当服务器接收到用户的业务请求后，确定出业务请求所要消耗的资源量，从而可直接在总资源账户中获取相应数量的预付资源，用于抵消业务请求所要消耗的资源，显然，相较于现有技术中逐一从用户的各子资源账户扣除预付资源的方式，本申请实施例中的上述方式能够直接从用户的总资源账户内获取到相应数量的预付资源，有效提升了在获取预付资源过程中的效率，并且，避免了服务器逐一地在用户的多个子资源账户内计算预付资源量的过程，能够减少服务器的工作负荷。

需要说明的是，上述实施例所提供方法的各步骤的执行主体均可以是同一设备，具体而言，执行主体可以是业务提供方的服务器。

下面将对总资源账户的建立过程进行详细说明：

如图2a所示，示出了本申请实施例中服务器创建总资源账户的示意图，结合图2a而言，预先创建该用户的总资源账户，具体包括：确定预先建立的、所述用户的各子资源账户，统计各子资源账户中预付资源的总资源量，根据统计得到的总资源量，为所述用户创建总资源账户，并将所述总资源量对应的预付资源存储在所述总资源账户中。

其中，每个子资源账户中分别存储用户每次所获得的预付资源；

当用户从业务提供方处获得了预付资源后(如：用户购买电子预付卡、电子券)，服务器均会为用户建立相应的账户，用于存储所获得的预付资源。在实际应用中，用户在从业务提供方处获得预付资源的过程中，用户会使用自身的用户标识(如前述的userID、业务账户等)，那么，用户每次获得预付资源时，服务器都可获取到该用户的用户标识，从而，分别建立属于该用户的子资源账户。由于建立子资源账户的过程属于现有技术，故在本申请实施例中不再过多赘述。

属于用户的每个子资源账户中分别存储有该用户各次所获得的预付资源，那么，针对每个子资源账户进行统计，便可以确定出属于该用户的、总共的预付资源的数量。在此基础上，为用户创建总资源账户，并将属于该用户的全部预付资源汇总后存储在总资源账户中。

作为本申请实施例中的一种方式，用户的总资源账户的创建时机，可以是服务器为该用户建立首个子资源账户时，如图2b所示，具体而言，服务器监测为所述用户创建的首个子资源账户(即，图2b中的子资源账户1)，当监测到该子资源账户建立时，统计该子资源账户中的预付资源量，将统计得到的预付资源量作为当前的总资源量，为所述用户创建总资源账户，并将所述预付资源量对应的预付资源存储在所述总资源账户中。从图2b中可见，总资源账户中的总资源量，就是当前子资源账户1中所包含的资源量，即，总资源量为100。

也就是说，在服务器第一次为用户建立子资源账户的同时，服务器将为用户创建总资源账户。此后，如果用户新获得了相应数量的预付资源，服务器将为用户建立新的子资源账户，同时，总资源账户中的预付资源量也将发生变化，即，服务器会将新增的子资源账户中的预付资源实时统计至总资源账户中，使得总资源账户中增加相应数量的预付资源。

例如：如图2c所示，用户新获得了预付资源(假设预付资源的数量为50)，那么，服务器将为用户建立新的子资源账户，也即，子资源账户2(其中，子资源账户2内存储的预付资源量就为50)，此时，服务器会将新增的子资源账户2中的预付资源量累计至总资源账户中，所以，在图2c中，总资源账户中的总资源量变更为150。

总资源账户的建立可以将用户所获得的所有预付资源进行整合，可以理解，通过总资源账户的方式，使得服务器在获取用户的预付资源的过程中，无需再采用逐一从各子资源账户分别获取预付资源的方式，而是可以直接从总资源账户中获取预付资源，显然，相较于现有技术中的方式而言，本申请实施例中采用总资源账户的方式能够有效缩减服务器获取用户预付资源的时间。

在实际应用中，业务提供方所提供的预付资源可能具有不同的折算系数，也就是说，在不同的折算系数的情况下，等量的预付资源能够抵消不同数量的资源代价，具体例如：在折算系数为1时，用户使用数量为100的预付资源，就能够抵消同样数量(即，100)的资源代价。换言之，如果折算系数为1，且假设用户发出的业务请求的资源消耗量为100时，那么，服务器将获取属于该用户的、数量为100的预付资源。

而如果在折算系数为2时，用户使用数量为100的预付资源，就能够抵消数量为200的资源代价。换言之，如果折算系数为2，且假设用户发出的业务请求的资源消耗量为100时，服务器将获取属于该用户的、数量为50的预付资源。

基于此，当服务器在统计各子资源账户中的总资源量时，就需要根据各子资源账户的折算系数进行统计，具体而言，统计各子资源账户中预付资源的总资源量，具体包括：针对任一子资源账户，确定该子资源账户中预付资源的折算系数，根据确定出的每一子资源账户的折算系数，统计各子资源账户中预付资源的总资源量。

故在本申请实施例中，总资源账户中的预付资源的数量，就是经过折算后的各子资源账户中预付资源量的总和。

那么，当用户发出了业务请求后，服务器便可以根据该业务请求所对应的资源消耗量，从总资源账户中获取等量的预付资源。

需要说明的是，子资源账户中的预付资源量和总资源账户的总预付资源量是实时对应的，换言之，当子资源账户中的预付资源量发生变化时，总资源账户中的预付资源量也会发生相应的变化，同样地，总资源账户中的总预付资源量发生了变化，服务器也会调整子资源账户中的预付资源量。所以，当服务器从总资源账户中获取了一定数量的预付资源后，就会从子资源账户中扣除等量的预付资源。

具体而言，在本申请实施例中，上述如图1所示的方法还包括：根据从所述用户的总资源账户中获取的预付资源量，分别从该用户所对应的各子资源账户中扣除相应数量的预付资源。

在本申请实施例中，从各子资源账户中扣除预付资源的方式可以有多种方式。如：考虑到实际应用中，用户可以先后多次获得预付资源，而服务器会对每次用户所获得的预付资源建立子资源账户，那么，用户的各子资源账户就具有了时间上的先后顺序，从而可以根据各子资源账户建立的时间先后顺序，依次扣除预付资源。

基于上述图2c所示的内容为例：基于前述内容可知，在图2c所示的情况下，子资源账户1的创建时间早于子资源账户2的创建时间，那么，假设当服务器从用户的总资源账户中获得数量为120的预付资源后，就需要分别从子资源账户1和子资源账户2中扣除等量的预付资源，由于子资源账户1的创建时间最早，那么，根据各子资源账户建立的时间先后顺序，服务器将首先扣除子资源账户1中的预付资源，如图3所示，当前，子资源账户1中的预付资源量为0。但此时仍需要继续扣除数量为20的预付资源，所以，服务器将在子资源账户2中扣除数量为20的预付资源，从而，在图3中，子资源账户2中当前剩余的预付资源量为30。

又如：不同的子资源账户可能具有不同的折算系数，就可以按照折算系统的大小顺序，依次扣除各子资源账户的预付资源。

具体地，如图4a所示，假设子资源账户1中的预付资源量为100、且折算系数为2；子资源账户2中的预付资源量为30、且折算系数为1。那么，总资源账户中的总资源量就为100*2+30＝230。假设如图4b所示，用户所要使用的业务需要消耗的资源量为100，那么，服务器将直接从总资源账户内获取100的资源量(当前，总资源账户中的总资源量剩余130)，之后，服务器根据折算系数大小的优先级，从子资源账户1中扣除的预付资源量为50。

因此，上述内容中，分别从该用户所对应的各子资源账户中扣除相应数量的预付资源，具体包括：按照各子资源账户与该用户建立关联关系的时间先后顺序，依次从各子资源账户中扣除相应数量的预付资源；或

根据各子资源账户中预付资源的折算系数，确定各子资源账户的优先级顺序，按照确定出的各子资源账户的优先级顺序，依次从各子资源账户中扣除相应数量的预付资源。

当然，在实际应用中，也可以按照用户所设定的子资源账户的顺序，逐一地扣除各子资源账户中的预付资源。又或者，在某些子资源账户具有有效时限的情况下，可按照有效时限的顺序扣除预付资源。这里并不构成对本申请的限定。

需要说明的是，在本申请实施例中，上述扣除子资源账户中预付资源的过程，是在业务提供方提供业务之后，也即，服务器从总资源账户中获取到预付资源后，业务提供方就会为用户提供相应的业务，保证了用户可以及时的获得业务服务，在此前提下，服务器在后续过程中再从各子资源账户中扣除预付资源。显然，这样的方式并不会影响用户及时获得业务服务。

本申请中的上述方法可以适用于实际应用中预付卡的场景。其中，实际应用场景中的架构如图5a所示，在该实际场景下，包含用户、商户以及支付业务提供方，具体而言，用户通过商户获得相应的业务(如：商户可向用户提供商品、餐饮、住宿等业务)，商户可向用户提供电子预付卡(或电子券等，为了便于描述，下文中简称为：预付卡)，可以认为，支付业务提供为商户所提供的预付卡提供在线支付的技术支持，并且，用户在支付业务提供方注册有该用户自身的账户。实际应用时，用户可以使用预付卡从商户处购买相应的商品。这里的预付卡可看作是一种预付资源，不同的预付卡具有不同的金额及折算系数，用户可以多次购买预付卡。在这样的场景下，本申请实施例提供一种资源处理方法，如图5b所示。

具体地，图5b中的方法具体包括如下步骤：

S501：接收用户的支付请求。

用户在获得商户提供的诸如：商品、餐饮、住宿等业务后，用户需要支付相应的金额。在本申请实施例中的一种方式下，支付请求可由用户使用自身的终端发出，具体而言，商户可向用户提供相应的二维码，用户使用终端进行扫码后，发出支付请求。在本申请实施例中的另一种方式下，支付请求可由商户发出，具体而言，商户可通过自身的结算设备(如：POS机、终端等)，向服务器发出业务请求。

当然，无论是用户发出的业务请求还是商户发出的业务请求，均会携带有用户的标识(如：用户在支付业务提供方所注册的账户、手机号、userID等)以及商户标识(如：商户名、商户ID等)。

S502：确定所述支付请求所对应的支付金额。

支付请求中会携带相应的支付金额信息，那么，服务器通过支付金额信息，便可以确定出此次支付请求所要支付的金额。

S503：确定预先创建的该用户的总预付卡账户。

其中，所述总预付卡账户中包含属于该用户的全部预付卡资金。

这里需要说明的是，在本实际应用场景下，预付卡由商户提供，所以，服务器为用户创建预付卡账户(包括：子预付卡账户及总预付卡账户)时，将基于商户标识及用户标识创建预付卡账户。

换言之，服务器将根据业务请求中所携带的用户标识和商户标识，确定出与该商户所对应的预付卡账户，并基于用户标识，确定出属于该用户的预付卡账户。

S504：从该总预付卡账户中扣除与支付金额相同数额的预付卡资金，以对所述支付请求进行处理。

服务器从用户的总预付卡账户中扣除了相应的预付卡资金后，会通知商户，扣款成功，从而使得商户完成对用户的款项结账。并且，服务器也会通知用户：从该用户的预付卡资金中扣款成功，并展示相应的扣款明细。当然，这里并不构成对本申请的限定。

当然，本场景下的资源处理方法中，也包含创建总预付卡账户、根据子预付卡账户中预付卡资金的累计总预付卡资金、扣除预付卡资源的过程，也即：

在该场景下，预先创建的该用户的总预付卡账户，具体包括：确定预先建立的、所述用户的各子预付卡账户(其中，每个子预付卡账户中分别存储用户每次所购买的预付卡资金)，统计各子预付卡账户中预付卡资金的总金额，根据统计得到的总金额，为所述用户创建总预付卡账户，将与所述总金额等额的预付卡资金存储在所述总预付卡账户中。

正如前述，当用户购买了商户的预付卡后，服务器会根据用户标识和该商户标识，为该用户建立子预付卡账户，该子预付卡账户可以表明：预付资源是该商户所提供的、且该子预付卡账户属于该用户。

该过程中，统计各子预付卡账户中预付卡资金的金额，具体包括：针对任一子预付卡账户，确定该子预付卡账户中预付卡资金的折算系数，根据确定出的每一子预付卡账户的折算系数，统计各子预付卡账户中预付卡资金的金额。

扣除预付卡资金的过程：

所述方法还包括：根据从所述用户的总预付卡账户中扣除的预付卡资金，分别从该用户所对应的各子预付卡账户中扣除相应数量的预付卡资金。

进一步地，分别从该用户所对应的各子预付卡账户中扣除相应数量的预付卡资金，具体包括：

按照各子预付卡账户与该用户建立关联关系的时间先后顺序，依次从各子预付卡账户中扣除相应数量的预付卡资金；或

根据各子预付卡账户中预付资源的折算系数，确定各子预付卡账户的优先级顺序，并按照确定出的各子预付卡账户的优先级顺序，依次从各子预付卡账户中扣除相应数量的预付卡资金。

上述内容与前述如图1b所示的方法中所记载的内容相类似，这里并不在过多赘述。

以上为本申请实施例提供的资源处理方法，基于同样的思路，本申请实施例还提供一种资源处理装置。

如图6所示，该装置包括：

接收模块601，接收用户发出的业务请求。

确定模块602，确定所述业务请求所对应的资源消耗量。

总账户模块603，确定预先创建的该用户的总资源账户；其中，所述总资源账户中包含属于该用户的全部预付资源。

处理模块604，从该总资源账户中获取与所述资源消耗量对应的预付资源，以对所述业务请求进行处理。

总账户模块603，确定预先建立的、所述用户的各子资源账户；其中，每个子资源账户中分别存储用户每次所获得的预付资源，统计各子资源账户中预付资源的总资源量，根据统计得到的总资源量，为所述用户创建总资源账户，并将所述总资源量对应的预付资源存储在所述总资源账户中。

进一步地，总账户模块603，针对任一子资源账户，确定该子资源账户中预付资源的折算系数，根据确定出的每一子资源账户的折算系数，统计各子资源账户中预付资源的总资源量。

所述装置还包括：资源结算模块605，根据从所述用户的总资源账户中获取的预付资源量，分别从该用户所对应的各子资源账户中扣除相应数量的预付资源。

所述资源结算模块605，按照各子资源账户与该用户建立关联关系的时间先后顺序，依次从各子资源账户中扣除相应数量的预付资源；或

根据各子资源账户中预付资源的折算系数，确定各子资源账户的优先级顺序，按照确定出的各子资源账户的优先级顺序，依次从各子资源账户中扣除相应数量的预付资源。

基于上述如图6所示的装置，可以应用于用户使用预付卡的场景中，具体而言，在该场景中本申请实施例提供一种资源处理装置，如图7所示：

接收模块701，接收用户的支付请求。

确定模块702，确定所述支付请求所对应的支付金额。

总账户模块703，确定预先创建的该用户的总预付卡账户；其中，所述总预付卡账户中包含属于该用户的全部预付卡资金。

处理模块704，从该总预付卡账户中扣除与支付金额相同数额的预付卡资金，以对所述支付请求进行处理。

总账户模块703，确定预先建立的、所述用户的各子预付卡账户；其中，每个子预付卡账户中分别存储用户每次所购买的预付卡资金；统计各子预付卡账户中预付卡资金的总金额，根据统计得到的总金额，为所述用户创建总预付卡账户，将与所述总金额等额的预付卡资金存储在所述总预付卡账户中。

进一步地，总账户模块703，针对任一子预付卡账户，确定该子预付卡账户中预付卡资金的折算系数，根据确定出的每一子预付卡账户的折算系数，统计各子预付卡账户中预付卡资金的金额。

所述装置还包括：资源结算模块705，根据从所述用户的总预付卡账户中扣除的预付卡资金，分别从该用户所对应的各子预付卡账户中扣除相应数量的预付卡资金。

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

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

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

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

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

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

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

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。