一种业务订购方法、系统及业务服务器与流程

本发明涉及通信技术领域，尤其涉及一种业务订购方法、系统及业务服务器。

背景技术：

随着各种互联网业务的普及推广，各业务都提供了各种不同周期的套餐供用户选择订购，不同的套餐通常对应的不同的使用时长，相应的费用也会有所区别。比如，一个彩铃包年业务可能定价为100元，而包月则可能定价为10元，而如果只使用一天，则可能只需要支付1元即可。现有技术中通用的订购业务的流程是，用户选择中意的套餐类型并提交申请，扣取相应的费用，如果扣费成功则表示套餐订购成功；在某些场景下，如果用户的余额不足以支付所选择的套餐类型，系统会反馈余额不足，支付失败的提示，必须由用户再自行选择其他套餐。这种情况下所导致的问题是，其一，业务办理效率低下，其二，用户体验差。

技术实现要素：

本发明实施例提供了一种业务订购方法、系统及业务订购服务器，旨在解决现有技术中用户订购业务时效率低下，用户体验度差的问题。

为了解决上述技术问题，本发明实施例提供了一种业务订购方法，包括：

获取终端发起的业务订购请求；

根据所述业务订购请求，确定对应的业务及所需的总费用，并根据所述业务及总费用向计费服务器发送扣费请求；

根据所述计费服务器反馈的扣费结果，执行相应的操作，包括：

当所述计费服务器反馈的扣费结果为扣费失败时，根据与本次扣费请求对应的业务类型相同的、所需总费用更低的业务，向所述计费服务器发送扣费请求；

当所述计费服务器反馈的扣费结果为扣费成功时，订购相应的业务。

本发明实施例还提供了一种业务服务器，包括：

请求获取模块，用于获取终端发起的业务订购请求；

请求解析模块，用于根据所述业务订购请求，确定对应的业务及所需的总费用；

请求发送模块，用于根据所述业务及总费用向计费服务器发送扣费请求；

执行模块，用于根据计费服务器反馈的扣费结果，执行相应的操作，包括：

当所述计费服务器反馈的扣费结果为扣费失败时，根据与本次扣费请求对应的业务类型相同的、所需总费用更低的业务，向所述计费服务器发送扣费请求；

当所述计费服务器反馈的扣费结果为扣费成功时，订购相应的业务。

本发明实施例还提供了一种业务订购系统，包括终端、业务服务器、计费服务器；所述终端根据所述业务服务器上预存的业务信息，发起业务订购请求，业务服务器接收所述业务订购请求，并确定对应的业务及所需的总费用，并根据所述业务及总费用向计费服务器发送扣费请求；计费服务器接收并处理所述扣费请求，向业务服务器反馈扣费结果；所述业务服务器根据所述扣费结果，执行相应的操作，包括：

当所述扣费结果为扣费失败时，根据与本次扣费请求对应的业务类型相同的、所需总费用更低的业务，向所述计费服务器发送扣费请求；

当所述扣费结果为扣费成功时，订购相应的业务。

本发明实施例还提供了一种计算机存储介质，计算机存储介质中存储有计算机可执行指令，计算机可执行指令用于执行上述的业务订购方法。

有益效果

本发明实施例提供了一种业务订购方法、系统及业务服务器，获取终端发起的业务订购请求，根据业务订购请求确定对应的业务及所需的总费用，并根据业务及总费用向计费服务器发送扣费请求，根据计费服务器反馈的扣费结果，执行相应的操作，包括：当扣费结果为扣费失败时，根据与本次扣费请求对应的业务类型相同的、所需总费用更低的业务，向计费服务器发送扣费请求；当扣费结果为扣费成功时，订购相应的业务。通过本发明的实施，无需用户多次手动操作，即可自动的为用户选择可订购的业务，降低的用户操作的复杂度，提升外订购成功率，即保证了用户体验度，又保证了商家的收益。

附图说明

图1是本发明第一实施例提供的一种业务订购方法流程图；

图2是本发明第二实施例提供的一种业务订购方法流程图；

图3是本发明第三实施例提供的一种业务服务器组成示意图；

图4是本发明第四实施例提供的一种业务订购系统组成示意图；

图5是本发明第五实施例提供的一种业务订购方法流程图。

具体实施方式

本发明的构思点在于，在用户订购业务时，通过自动选择业务类型等同而所需总费用更低的业务，为用户提供服务的同时，避免了用户因余额不足等原因导致业务订购失败时，用户需要再继续手动选择总费用较低的业务进行订购，提升了用户业务订购的效率。

下面结合附图对本发明的具体实施作进一步说明。

第一实施例

请参考图1，图1是本发明第一实施例提供的一种业务订购方法流程图，包括：

s101、获取终端发起的业务订购请求；

s102、根据业务订购请求，确定对应的业务及所需的总费用，并根据业务及总费用向计费服务器发送扣费请求；

s103、根据计费服务器反馈的扣费结果，执行相应的操作，包括：

s103a、当计费服务器反馈的扣费结果为扣费失败时，根据与本次扣费请求对应的业务类型相同的、所需总费用更低的业务，向计费服务器发送扣费请求；

s103b、当计费服务器反馈的扣费结果为扣费成功时，订购相应的业务。

根据用户意愿、订购平台、业务类型的不同，业务订购请求也会不同；在本实施例中，业务订购请求所针对的业务，可以是如移动用户所要办理的短信、流量、彩信等各种基础套餐，或者是其他如手机报、音乐包等进阶套餐，而这些业务套餐可以通过相应的运营商的客户端、门户网站进行办理，也可以通过拨打电话、发送短信等方法进行办理；还可以包括一些其他的业务内容，比如视频会员等等。这些办理业务的请求，即业务订购请求会发送给业务服务器，由业务服务器来进行处理。

根据用户发起业务订购请求的对象的不同，业务服务器也会有所区别，有些用户是通过相应的运营商进行业务订购操作的，那么业务服务器则属于运营商；有的用户是通过其他平台进行业务订购操作的，比如支付宝、微信、终端厂商等等，那么业务服务器则属于这些商家。

订购业务时，支付手段也可以根据用户的选择而层出不穷，如可以通过手机话费余额进行支付，可以用网银进行支付，可以用三方应用里面的余额，如支付宝、微信钱包里面的余额进行支付。

s101中，获取终端发起的业务订购请求。终端根据在业务服务器上预存的各个业务信息，选择中意的业务，然后发起与之对应的业务订购请求。在业务服务器上预存的业务信息，至少应该包括业务内容、使用时间及所需总费用等信息，用户可以根据需求或喜好确定一类型的业务内容，如用户想订购流量业务，流量业务包括月包、季包、年包等，且有不同档次的差别，用户根据对比，选择出一个流量包，就这个流量包发起业务订购请求。其中，业务类型相同的业务包括：至少两个业务名称相关，且生效时间一致的业务。业务名称相关，表示两个或以上的业务的名称具有相同或相近的词汇，比如具有两个业务的名称中均含有“流量包”这一词汇；生效时间一致，则表示两个业务或以上业务的使用时间是相同的，比如均是月包，且订购之后的业务的生效的时间点是一致的，比如均是立即生效，或者均是下月生效等等。

s102中，业务订购请求是终端所发起的，业务服务器在接收到该业务订购请求后，会对该业务订购请求进行解析，至少应从中提取出其对应的业务以及所需的总费用。当然，该业务订购请求对应的终端，或者说该业务订购请求对应的用户也是确定的。

业务服务器在确定了该业务订购请求对应的业务及所需的总费用之后，就可以根据该业务和总费用，向计费服务器发送扣费请求。计费服务器和业务服务器的功能虽然有异，但在一些情况下这两者可以是同一个服务器，如当业务服务器归属于运营商，且用户采用的支付方式是话费余额时，此时业务服务器和计费服务器就同属于运营商。业务服务器根据业务及总费用向计费服务器发送扣费请求，扣费请求由计费服务器进行确定，并根据用户的支付手段等情况反馈相应的扣费结果。

s103中，根据计费服务器反馈的扣费结果，执行相应的操作；而计费服务器反馈的扣费结果，无非分为两大类：其一，扣费成功；其二，扣费失败。如果是扣费成功，则说明支付成功了，用户已经成功订购了所请求的业务，之后就可以结束流程；如果是扣费失败，而扣费失败的原因则可以包括：其一，发起业务订购请求的终端对应的用户的余额，小于扣费请求对应的业务所需的总费用，也就是说用户的余额不足以支付所请求的业务；其二，发起业务订购请求的用户没有办理请求的业务的权限，这可能是由于业务冲突，或者说用户的等级不够等等原因。从上述的扣费失败的两种情况来看，当扣费失败是由于用户没有办理请求的业务的权限时，通过办理与请求的业务类型相同的、所需总费用更低的业务可能并不能让用户办理想要的业务，那么，在这种情况下，就没有必要再通过根据与本次扣费请求对应的业务类型相同的、所需总费用更低的业务向计费服务器发送扣费请求。当扣费失败是由于用户的余额不足时，往往通过降低业务的总费用，即选择同类型的更低费用的业务进行办理就可以满足用户的需求，那么，在这种情况下，就可以根据与本次扣费请求对应的业务类型相同的、所需总费用更低的业务，向计费服务器发送扣费请求。

当计费服务器反馈的扣费结果是扣费失败时，根据与本次扣费请求对应的业务类型相同的、所需总费用更低的业务，向计费服务器发送扣费请求。这里所指的与本次扣费请求对应的业务类型相同的、所需总费用更低的业务，具体而言，就是指本次扣费请求对应的业务与下次扣费请求对应的业务的类型是一致的，而下次扣费请求对应的业务的总费用应该小于本次扣费请求对应的应用。举例说明，当用户请求的业务是包月的50元包700m的流量时，而此时用户的话费余额为9元，显然用户不能支付50元700m的流量，那么业务服务器就会选择同类型——流量包、所需总费用更低——10元100m，然后据此向计费服务器发送扣费请求。

计费服务器接收到该扣费请求后，重新进行扣费操作，此时，发现用户的余额——9元，仍然不足以支付，那么，计费服务器会再次反馈扣费失败的扣费结果给业务服务器。业务服务器再根据与本本次扣费请求——10元100m——对应的业务类型相同的——流量包、所需总费用更低的——5元30m，向计费服务器发送扣费请求。计费服务器接收到该扣费请求后，重新进行扣费操作，此时，用户的余额已经足以支付该业务，那么，计费服务器就反馈扣费成功的扣费结果给业务服务器。

可以发现，本实施例中的扣费过程可以是循环进行的，即从用户最开始发起的业务订购请求开始，如果失败了就降低业务所需的总费用，直到支付成功为止。当然，扣费过程也可能一直都不成功，因为用户可能连最低一档的业务所需的余额都没有，也就是说，当计费服务器反馈的扣费结果为扣费失败时，还可以包括：若本次扣费请求对应的业务已经是所需总费用最低的，则向终端反馈业务订购失败。

计费服务器反馈的所有扣费结果中，包括扣费成功和扣费失败；其中，扣费成功，表示用户成功订购了所需类型的业务，这个业务可能是用户最开始选定的档次的业务，也可能是降档之后的业务；扣费失败时，如果是非余额不足所引起的扣费失败，如用户没有办理请求的业务的权限，这可能是由于业务冲突、用户等级不够等原因所造成，这种情况下即使降低业务所需的总费用，往往也不能达到订购该业务的目的，因此，此时可以直接通过业务服务器反馈给终端扣费失败的扣费结果，还可以在该扣费结果中增加相应的原因，比如“因与已办理的**业务冲突”等之类的字眼；扣费失败还可能是由于用户余额不足所引起的，如果选择与该业务同类的、所需总费用更低的业务，那么就可以通过降档申请的方式，重新发起扣费请求。这一过程可以一直持续到存在这么一个同类的业务，用户的余额能够满足需求，此时返回扣费成功的提示；或者不存在任何一个业务，使用户能够支付成功，那么，此时就可以返回扣费失败的提示，同时，可以附上失败的原因，如“您的余额不足”等字眼。

由于很多业务的特点是，总价越高，单价越低，即同样类型的套餐，量大的虽然价格更高，但往往其单价更低，比如以流量包为例，有的运营商有这样的套餐，10元100m流量，以及50元700m流量，显然50元700m流量的总价更高，但是折算下来单价比10元包100m的更便宜，这也是一种吸引用户购买的政策，即用户往往会为了更为优惠的方案而选择购买价格更高的业务套餐。因此，在这种情况下，用户可能并不想订购那些同样类型的，所需总费用更低的业务，那么，在本实施例中，当计费服务器反馈的扣费结果为扣费成功时，订购相应的业务包括：向终端反馈扣费成功时的扣费请求对应的业务及所需的总费用，并根据终端的反馈订购相应的业务。也就是说，业务服务器自动查找终端能够订购的业务之外，在查找到用户能够支付的业务时，除了可以自动为用户订购，还可以接受用户的反馈，根据用户的反馈决定订购与否，这种方式既可以提高用户订购业务的效率，又充满了人性化，进一步的提升了用户体验。

本实施例提供了一种业务订购方法，获取终端发起的业务订购请求，根据业务订购请求，确定对应的业务及所需的总费用，并根据业务及总费用向计费服务器发送扣费请求；根据计费服务器反馈的扣费结果，执行相应的操作。通过本实施例的实施，无需用户多次手动操作，即可自动的为用户选择可订购的业务，降低的用户操作的复杂度，提升外订购成功率，即保证了用户体验度，又保证了商家的收益。

第二实施例

请参考图2，图2为第二实施例提供的一种业务订购方法流程图，包括：

s201、终端根据业务服务器上预存的业务信息，发起业务订购请求。

终端所发起的业务订购请求，是终端的最初的意愿，即用户想要订购的业务所对应的业务订购请求。在本实施例中，以流量包为例，来具体说明本实施例中的业务订购方法：终端发起了50元700m的流量包对应的业务订购请求。

s202、业务服务器接收业务订购请求，确定对应的业务及所需的总费用，并根据业务及总费用向计费服务器发送扣费请求。

业务服务器在接收到该业务订购请求后，会对该业务订购请求进行解析，至少应从中提取出其对应的业务以及所需的总费用。经过解析，业务服务器发现用户所要订购的是50元700m的流量包。

解析完成后，业务服务器就根据解析的结果，向计费服务器发送扣费请求，即申请为50元700m流量包扣费，扣费金额为50元。

s203、计费服务器接收并处理扣费请求，向业务服务器反馈扣费结果。

计费服务器和用户的所选择的支付手段进行交互，包括话费余额、网银、第三方支付平台等方式，而扣费结果则可以包括扣费成功和扣费失败。此时，用户选择通过话费余额支付，而用户的话费余额为15元。显然，用户的话费余额不足以支付用户选定的业务，计费服务器向业务服务器反馈扣费失败的扣费结果。

s204、业务服务器根据扣费结果，执行相应的操作，包括：

s204a、当扣费结果为扣费失败时，根据与本次扣费请求对应的业务类型相同的、所需总费用更低的业务，向计费服务器发送扣费请求，并转到s203；

当扣费失败是由于用户的余额不足时，往往通过降低业务的总费用，即选择同类型的更低总费用的业务进行办理就可以满足用户的需求，那么，在这种情况下，就可以根据与本次扣费请求对应的业务类型相同的、所需总费用更低的业务，向计费服务器发送扣费请求。即：业务服务器根据10元100m的流量包业务，向计费服务器再次发送扣费请求；计费服务器接收并处理扣费请求，此时用户的余额足以支付用户选定的业务，计费服务器向业务服务器反馈扣费成功的扣费结果。其中，业务类型相同的业务包括：两个或以上数量的业务的业务名称相关，以及业务的生效时间一致。

s204b、当所述扣费结果为扣费成功时，订购相应的业务。

如果是扣费成功，则说明支付成功了，用户已经成功订购了所请求的业务，之后就可以结束流程。即：计费服务器根据10元100m的流量包的扣费请求，反馈了扣费成功的扣费结果给业务服务器，业务服务器根据该扣费成功的请求最终为用户订购了10元100m的流量包业务。此时订购成功的流量包业务已经不是用户最初业务订购请求对应的50元700m的流量包业务。

第三实施例

请参考图3，图3为本发明第三实施例提供的一种业务服务器的组成示意图，包括：

请求获取模块101，用于获取终端发起的业务订购请求；

请求解析模块102，所用于根据业务订购请求，确定对应的业务及所需的总费用；

请求发送模块103，用于根据业务及总费用向计费服务器发送扣费请求；

执行模块104，用于根据计费服务器反馈的扣费结果，执行相应的操作，包括：

当计费服务器20反馈的扣费结果为扣费失败时，根据与本次扣费请求对应的业务类型相同的、所需总费用更低的业务，向计费服务器20发送扣费请求；

当计费服务器20反馈的扣费结果为扣费成功时，订购相应的业务。

根据用户意愿、订购平台、业务类型的不同，业务订购请求也会不同；在本实施例中，业务订购请求所针对的业务，可以是如移动用户所要办理的短信、流量、彩信等各种基础套餐，或者是其他如手机报、音乐包等进阶套餐，而这些业务套餐可以通过相应的运营商的客户端、门户网站进行办理，也可以通过拨打电话、发送短信等方法进行办理；还可以包括一些其他的业务内容，比如视频会员等等。这些办理业务的请求，即业务订购请求会发送给业务服务器10，由业务服务器10来进行处理。

根据用户发起业务订购请求的对象的不同，业务服务器10也会有所区别，有些用户是通过相应的运营商进行业务订购操作的，那么业务服务器10则属于运营商；有的用户是通过其他平台进行业务订购操作的，比如支付宝、微信、终端30厂商等等，那么业务服务器10则属于这些商家。

订购业务时，支付手段也可以根据用户的选择而层出不穷，如可以通过手机话费余额进行支付，可以用网银进行支付，可以用三方应用里面的余额，如支付宝、微信钱包里面的余额进行支付。

请求获取模块101用于获取终端30发起的业务订购请求。终端30根据在业务服务器10上预存的各个业务信息，选择中意的业务，然后发起与之对应的业务订购请求。在业务服务器10上预存的业务信息，至少应该包括业务内容、使用时间及所需总费用等信息，用户可以根据需求或喜好确定一类型的业务内容，如用户想订购流量业务，流量业务包括月包、季包、年包等，且有不同档次的差别，用户根据对比，选择出一个流量包，就这个流量包发起业务订购请求。其中，业务类型相同的业务包括：两个或以上数量的业务的业务名称相关，以及业务的生效时间一致。

业务订购请求是终端30所发起的，业务服务器10在接收到该业务订购请求后，会通过请求解析模块102对该业务订购请求进行解析，至少应从中提取出其对应的业务以及所需的总费用。当然，该业务订购请求对应的终端30，或者说该业务订购请求对应的用户也是确定的。

在确定了该业务订购请求对应的业务及所需的总费用之后，就可以根据该业务和总费用，通过请求发送模块103向计费服务器20发送扣费请求。计费服务器20和业务服务器10的功能虽然有异，但在一些情况下这两者可以是同一个服务器，如当业务服务器10归属于运营商，且用户采用的支付方式是话费余额时，此时业务服务器10和计费服务器20就同属于运营商。业务服务器10根据业务及总费用向计费服务器20发送扣费请求，扣费请求由计费服务器20进行确定，并根据用户的支付手段等情况反馈相应的扣费结果。

执行模块104根据计费服务器20反馈的扣费结果，执行相应的操作；而计费服务器20反馈的扣费结果，无非分为两大类：其一，扣费成功；其二，扣费失败。如果是扣费成功，则说明支付成功了，用户已经成功订购了所请求的业务，之后就可以结束流程；如果是扣费失败，而扣费失败的原因则可以包括：其一，发起业务订购请求的终端30对应的用户的余额，小于扣费请求对应的业务所需的总费用，也就是说用户的余额不足以支付所请求的业务；其二，发起业务订购请求的用户没有办理请求的业务的权限，这可能是由于业务冲突，或者说用户的等级不够等等原因。从上述的扣费失败的两种情况来看，当扣费失败是由于用户没有办理请求的业务的权限时，通过办理与请求的业务类型相同的、所需总费用更低的业务可能并不能让用户办理想要的业务，那么，在这种情况下，就没有必要再通过根据与本次扣费请求对应的业务类型相同的、所需总费用更低的业务向计费服务器20发送扣费请求。当扣费失败是由于用户的余额不足时，往往通过降低业务的总费用，即选择同类型的更低总费用的业务进行办理就可以满足用户的需求，那么，在这种情况下，就可以根据与本次扣费请求对应的业务类型相同的、所需总费用更低的业务，向计费服务器20发送扣费请求。

当计费服务器20反馈的扣费结果是扣费失败时，执行模块104根据与本次扣费请求对应的业务类型相同的、所需总费用更低的业务，向计费服务器20发送扣费请求。这里所指的与本次扣费请求对应的业务类型相同的、所需总费用更低的业务，具体而言，就是指本次扣费请求对应的业务与下次扣费请求对应的业务的类型是一致的，而下次扣费请求对应的业务的总费用应该小于本次扣费请求对应的应用。

计费服务器20接收到该扣费请求后，重新进行扣费操作，此时，发现用户的余额仍然不足以支付，那么，计费服务器20会再次反馈扣费失败的扣费结果给业务服务器10。业务服务器10中的执行模块104再根据与本本次扣费请求对应的业务类型相同、所需总费用更低的业务，向计费服务器20发送扣费请求。计费服务器20接收到该扣费请求后，重新进行扣费操作，此时，用户的余额已经足以支付该业务，那么，计费服务器20就反馈扣费成功的扣费结果给业务服务器10。

可以发现，本实施例中的扣费过程可以是循环进行的，即从用户最开始发起的业务订购请求开始，如果失败了就降低业务所需的总费用，直到支付成功为止。当然，扣费过程也可能一直都不成功，因为用户可能连最低一档的业务所需的余额都没有，也就是说，当计费服务器20反馈的扣费结果为扣费失败时，还可以包括：若本次扣费请求对应的业务已经是所需总费用最低的，则向终端30反馈业务订购失败。

计费服务器20反馈的所有扣费结果中，包括扣费成功和扣费失败；其中，扣费成功，表示用户成功订购了所需类型的业务，这个业务可能是用户最开始选定的档次的业务，也可能是降档之后的业务；扣费失败时，如果是非余额不足所引起的扣费失败，如用户没有办理请求的业务的权限，这可能是由于业务冲突、用户等级不够等原因所造成，这种情况下即使降低业务所需的总费用，往往也不能达到订购该业务的目的，因此，此时可以直接通过业务服务器10反馈给终端30扣费失败的扣费结果，还可以在该扣费结果中增加相应的原因，比如“因与已办理的**业务冲突”等之类的字眼；扣费失败还可能是由于用户余额不足所引起的，如果选择与该业务同类的、所需总费用更低的业务，那么就可以通过降档申请的方式，重新发起扣费请求。这一过程可以一直持续到存在这么一个同类的业务，用户的余额能够满足需求，此时返回扣费成功的提示；或者不存在任何一个业务，使用户能够支付成功，那么，此时就可以返回扣费失败的提示，同时，可以附上失败的原因，如“您的余额不足”等字眼。

由于很多业务的特点是，总价越高，单价越低，即同样类型的套餐，量大的虽然价格更高，但往往其单价更低，比如以流量包为例，有的运营商有这样的套餐，10元100m流量，以及50元700m流量，显然50元700m流量的总价更高，但是折算下来单价比10元包100m的更便宜，这也是一种吸引用户购买的政策，即用户往往会为了更为优惠的方案而选择购买价格更高的业务套餐。因此，在这种情况下，用户可能并不想订购那些同样类型的，所需总费用更低的业务，那么，在本实施例中，当计费服务器20反馈的扣费结果为扣费成功时，订购相应的业务包括：向终端30反馈扣费成功时的扣费请求对应的业务及所需的总费用，并根据终端30的反馈订购相应的业务。也就是说，业务服务器10自动查找终端30能够订购的业务之外，在查找到用户能够支付的业务时，除了可以自动为用户订购，还可以接受用户的反馈，根据用户的反馈决定订购与否，这种方式既可以提高用户订购业务的效率，又充满了人性化，进一步的提升了用户体验。

本实施例提供了一种业务服务器，包括请求获取模块、请求解析模块、请求发送模块、执行模块，获取终端发起的业务订购请求，根据业务订购请求，确定对应的业务及所需的总费用，并根据业务及总费用向计费服务器发送扣费请求；根据计费服务器反馈的扣费结果，执行相应的操作。通过本实施例的实施，无需用户多次手动操作，即可自动的为用户选择可订购的业务，降低的用户操作的复杂度，提升外订购成功率，即保证了用户体验度，又保证了商家的收益。

第四实施例

请参考图4，图4为本发明第四实施例提供的一种业务订购系统组成示意图，包括：终端30、业务服务器10、计费服务器20；终端30根据业务服务器10上预存的业务信息，发起业务订购请求，业务服务器10接收业务订购请求，并确定对应的业务及所需的总费用，并根据业务及总费用向计费服务器20发送扣费请求；计费服务器20接收并处理扣费请求，向业务服务器10反馈扣费结果；业务服务器10根据扣费结果，执行相应的操作，包括：

当扣费结果为扣费失败时，根据与本次扣费请求对应的业务类型相同的、所需总费用更低的业务，向计费服务器20发送扣费请求；

当扣费结果为扣费成功时，订购相应的业务。

本实施例中的终端30，可以是如手机、平板电脑等之类的移动终端，还可以是如计算机之类的固定终端，终端30可以以应用程序的方式进行业务订购等操作，也可以通过网页，进入相关的门户网站来进行业务订购等操作。

终端30所发起的业务订购请求，是终端30的最初的意愿，即用户想要订购的业务所对应的业务订购请求。

业务服务器10在接收到该业务订购请求后，会对该业务订购请求进行解析，至少应从中提取出其对应的业务以及所需的总费用；解析完成后，业务服务器10就根据解析的结果，向计费服务器20发送扣费请求。

计费服务器20和用户的所选择的支付手段进行交互，包括话费余额、网银、第三方支付平台等方式，而扣费结果则可以包括扣费成功和扣费失败。

当扣费失败是由于用户的余额不足时，往往通过降低业务的总费用，即选择同类型的更低总费用的业务进行办理就可以满足用户的需求，那么，在这种情况下，就可以根据与本次扣费请求对应的业务类型相同的、所需总费用更低的业务，向计费服务器20发送扣费请求。而如果是扣费成功，则说明支付成功了，用户已经成功订购了所请求的业务，之后就可以结束流程。

第五实施例

请参考图5，图5为本发明第五实施例提供的一种业务订购方法流程图。

本实施例中包括的各个网元及其作用分别为：业务服务器，包含业务逻辑，套餐信息(等级、总费用、使用时长等)和发起扣费的接口。业务逻辑主要有如下几个功能：1、设定各等级套餐对应的等级、总费用、套餐使用时长的信息；2、根据用户的选择的套餐，发起套餐对应总费用的扣费请求到计费服务器扣费；3、如果计费服务器返回扣费成功，为用户订购相应的业务套餐，提示用户业务套餐订购成功；4、如果计费中心返回失败，且不是因为余额不足引起的扣费失败，则提示用户业务套餐订购失败。5、如果计费中心返回是因为余额不足引起的扣费失败，则自动查询低一等级的套餐总费用，并使用该总费用再次发起扣费请求；6、重复步骤3、4、5，直到订购成功或者失败；

计费服务器，接受扣费请求，并根据用户的支付手段和需扣费的金额，返回扣费结果。

s501、业务服务器设置各种业务套餐信息。

s502、业务服务器接收用户发起的业务订购请求，查询业务订购请求对应的业务及总费用，

s503、发起扣费请求到计费服务器，扣取相应的总费用。

s504、业务服务器接收计费服务器返回的扣费结果并进行解析。

s505、如果计费服务器返回扣费成功，为用户订购相应的业务套餐，提示用户业务套餐订购成功，流程结束。

s506、如果计费服务器返回扣费失败，且不是因为余额不足引起的扣费失败，则提示用户业务套餐订购失败。流程结束。

s507、如果计费服务器返回是因为余额不足引起的扣费失败，则自动查询低一等级的业务套餐及总费用，并使用该总费用再次发起扣费请求；如果查询失败，即未查询到低一等级的业务套餐，说明此次以及是最低等级的业务套餐，那么提示用户业务套餐订购失败，流程结束。

重复步骤s504～s507，直到流程结束。

显然，本领域的技术人员应该明白，上述本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储介质(rom/ram、磁碟、光盘)中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。所以，本发明不限制于任何特定的硬件和软件结合。

以上内容是结合具体的实施方式对本发明所作的进一步详细说明，不能认定本发明的具体实施只局限于这些说明。对于本发明所属技术领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干简单推演或替换，都应当视为属于本发明的保护范围。