具体实施方式
下面将结合本实施例中的附图,对本实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
本实施例提供了一种在线结算的方法,该方法依托结算应用服务器和结算平台服务器进行实现。其中,结算应用服务器为一个相对独立的网络侧服务器,用于向商户客户端提供结算应用服务,结算平台服务器可以是社交网站(SocialNetworking Services,简称SNS)服务器或者开放平台服务器,用户为结算平台的注册用户。商户客户端与结算应用服务器对接,用户客户端与结算平台服务器对接,通过结算应用服务器、结算平台服务器以及安装在商户手机上的结算应用建立商户与用户之间的信息桥梁,在无需建立相关接口协议的情况下,使商户仅通过手机就能够实现在线结算。具体的,如图1所示,该方法包括:
101、商户客户端向结算应用服务器发送结算请求。
商户在手机上安装结算应用客户端,注册开通结算应用账户并申请结算应用功能。在需要对网购商品进行结算时,商户客户端根据商户触发的结算操作指令向位于网络侧的结算应用服务器发送结算请求。
102、结算应用服务器根据结算请求生成结算信息。
结算信息用于链接待结算商品的结算数据及商户信息,商品的结算数据包括商品标识、商品金额等,商户信息包括商户标识,例如商户身份标识(partnerid)及商户账户标识(app id)。
对于商户标识,结算应用服务器可以在商户注册结算应用账户时进行获取并保存在后台服务器中,对于商品的结算数据则可以在接收到结算请求后向商户客户端获取,或者由商户客户端定期发送给结算应用服务器。
103、结算应用服务器将结算信息发送给商户客户端。
本实施例中,结算应用服务器将链接结算数据信息和商户标识的统一资源定位符(Uniform Resource Locator,简称URL)发送给商户客户端。
104、商户客户端根据结算信息生成结算标识。
商户客户端生成的结算标识包括但不限于是:字符串、条形码或者二维码,商户客户端根据结算应用服务器发送的URL本地生成结算标识。
105、用户客户端在获取结算标识后,将根据结算标识解析出的结算信息发送给结算平台服务器。
用户客户端获取结算标识的方式可以是在当面交易时通过手机对商户手机上显示的结算标识进行扫描,也可以是在远程交易时用户客户端接收商户客户端发送的结算标识,然后通过用户客户端内置的浏览器对接收到的结算标识进行扫描。用户客户端获取结算标识的实现方式因使用场景的不同而存在差异,本实施例对此说不作具体限制。
在获取结算标识后,用户客户端对该结算标识进行解析,解析得到如步骤104中所述的URL,然后将该URL发送给结算平台服务器。
本实施例中,结算应用服务器和结算平台服务器均位于网络侧,但没有必然的位置和逻辑关系。
106、结算平台服务器根据结算信息以及用户客户端的用户信息,关联生成结算单。
结算平台服务器根据用户客户端发送的URL向结算应用服务器请求步骤102中的结算数据和商户标识,然后根据请求的结算数据、商户标识以及获取的用户信息关联生成包含支付方、收款方以及商品信息三方信息的结算单。
对于用户客户端的用户信息,结算平台服务器可以在用户注册账号时进行获取并存储于后台服务器,也可以在进行结算操作时在106之前向用户客户端进行请求。本实施例中的用户信息包括但不限于:用户标识、用户密码以及用户资金账号。
107、结算平台服务器将结算单发送给用户客户端,以使用户客户端对结算单进行确认操作。
在生成结算单后,结算平台服务器将结算单发送给用户客户端,以使用户对支付方、收款方、商品名称、资金等信息进行确认。
108、结算平台服务器根据确认操作将用户客户端关联的资金账户内的资金结算至结算应用服务器。
在用户客户端对结算单进行确认后,结算平台服务器根据用户客户端的确认操作指令,根据结算单中记载的资金,将用户客户端关联的资金账户内的资金结算至结算应用服务器。
109、结算应用服务器将接收的资金划拨到商户客户端关联的资金账户中。
结算应用服务器将结算平台服务器结算的资金划拨到商户客户端关联的资金账户中,由此完成从用户客户端到商户客户端的结算过程。
本实施例提供的在线结算的方法,能够以独立的结算应用服务器以及结算平台服务器作为商户客户端与用户客户端之间的中间媒介,完成在线结算的过程。由于无需商户侧与结算平台服务器之间直接进行信息交互,因此无需商户侧开发原生URL二维码生成接口、信息回传接口等接口协议,相当于以结算应用服务器与结算平台服务器之间建立的接口协议作为广大商户“共享”的接口协议,除了能够降低商户侧参与在线结算的门槛外,还可以大大简化商户的结算操作,商户只需通过客户端向结算应用服务器发送结算请求、输入结算信息即可完成在线结算过程,操作十分简便。
作为对图1所示方法的详细说明及进一步扩展,本实施例还提供了一种在线结算的方法,如图2所示,该方法包括:
201、结算应用服务器接收商户客户端发送的结算请求。
结算应用服务器接收商户客户端网页前端发送的结算请求。
202、结算应用服务器验证商户客户端是否开通了结算应用功能。
如果商户客户端已开通结算应用功能,则直接执行步骤206,如果商户客户端尚未开通结算应用功能,则执行步骤203。
203、结算应用服务器向商户客户端获取商户信息。
所述商户信息包括但不限于是公司名称、法人代表姓名、营业执照副本及银行账户信息,所述银行账户信息用于标识商户客户端接收结算金额所使用的银行账号。
具体的:
203a、结算应用服务器向商户客户端发送功能开通界面的URL链接。
203b、商户客户端根据URL链接获取对应的功能开通页面。
事例性的,该页面可以如图3所示,包括对应至少一项商户信息的输入框,例如公司名称、法人代表姓名等。
203c、商户客户端将商户输入的商户信息发送给结算应用服务器。
事例性的,商户客户端以下述字符串格式发送商户信息:“公司名称=XXXX&法人代表姓名=XXXX&”。
204、结算应用服务器对商户信息进行审核。
本实施例中可以通过计算机自动审核商户的商户信息,例如将银行账户信息发送给银行系统查询其真实性及有效性。由于商户的商户信息是维护网购环境安全性的重要依据,并且事关商户和用户的重大经济利益,因此在本实施例的一个优选的方案中,结算应用服务器通过人机交互界面/窗口向网络管理员显示商户的商户信息,由网络管理员对商户信息进行人工审核。
如果商户信息审核通过,则结算应用服务器向商户客户端发送审核成功的返回值,然后继续执行步骤205;如果商户信息审核未通过,则结算应用服务器向商户客户端发送审核失败的返回值,由商户客户端提示商户重新输入商户信息,结算应用服务器重新顺序执行步骤203和步骤204。
205、结算应用服务器为审核通过的商户客户端开通结算应用功能,并分配商户标识。
本实施例中,商户标识包括商户账户标识(app id)以及商户身份标识(partner id),实际应用中也可以是其他可以对商户身份进行唯一性标识的标志。在分配完账户标识及商户身份标识后,结算应用服务器执行步骤206。
206、结算应用服务器根据结算请求生成结算信息。
结算应用服务器向商户客户端的网页前端发送信息输入界面的URL链接,商户客户端根据该链接获取信息输入界面,并显示给商户,以使商户输入结算数据。事例性的,商户客户端首先向商户显示如图4(a)所示的商品名称和商品描述等信息的输入界面,待接收到商户输入的商品名称后,向商户显示如图4(b)所示的商品金额的输入界面,获取商户输入的商品金额。
本实施例中需要商户输入的结算数据信息包括商品金额,此外还可以但不限于下述信息中的至少一种:商品标识、商品折扣、商品积分、商品描述信息、使用币种、物流费用。在获取到结算数据信息后,商户客户端通过普通的通信交互方式将该结算数据信息发送给结算应用服务器。
在本实施例的另一个优选方案中,结算应用服务器在每次接收到结算数据时,可以对结算数据进行保存,当下次对同样的商品进行结算时,结算应用服务器可以直接从本地存储器中读取对应的结算数据,由此节省与商户客户端之间的信令和数据交互。
在本实施例的另一个优选方案中,结算应用服务器还可以向商户客户端提供信息录入入口,以使商户可以在开通结算应用功能时通过商户客户端一次性将所有商品的结算数据信息都录入到结算应用服务器中,此后进行结算时无需再向结算应用服务器发送结算数据信息。进一步可选的,结算应用服务器还可以允许商户客户端通过信息录入入口定期更新所有或部分商品的结算数据信息,如前所述,所述结算数据信息除商品金额外还包括但不限于下述信息中的至少一种:商品标识、商品折扣、商品积分、商品描述信息、使用币种、物流费用。商户可以通过商户客户端定期更新商品金额、商品折扣、商品积分等信息。结算应用服务器根据接收的结算数据信息定期更新本地存储器中的结算数据信息,并在本次结算时,从本地存储器中读取对应商品的结算数据信息。
如前所述,结算平台服务器生成的结算单包括支付方信息、收款方信息以及商品信息三方信息,其中上述获取结算数据信息的目的即为获取商品信息,而支付方信息(即用户客户端信息)是由结算平台服务器来获取,因此本步骤中还需要获取作为收款方信息的商户标识。
通常在商户开通结算应用功能时,结算应用服务器会为商户客户端分配商户账户标识(app id)以及商户身份标识(partner id)作为商户标识,并将商户标识存储在后台服务器中。在生成结算信息时,结算应用服务器只需从后台服务器中读取该商户标识即可。
在获取到结算数据和商户标识后,结算应用服务器生成链接结算数据和商户标识的URL。事例性的,该URL可以是:
“weixin://wxpay/bizpayurl?sign=XXXX&appid=XXXX&productid=XXXX×tamp=XXXX”
其中,“sign=XXXX”为对结算请求的签名信息,“appid=XXXX”为商户账户的标识号,“productid=XXXX”为待结算商品的标识号,“timestamp=XXXX”为结算请求的时间戳信息。
207、结算应用服务器将结算信息发送给商户客户端。
结算应用服务器将步骤206中生成的URL发送给商户客户端,具体实现方式与图1中步骤103的实现方式相同,此处不再赘述。
208、商户客户端根据结算信息生成计算标识。
本实施例中以二维码作为结算标识为例进行说明,实际应用中结算标识的具体表现形式不限于此。商户客户端根据结算应用服务器发送的URL本地生成二维码。
209、用户客户端在获取结算标识后,将根据结算标识解析出的结算信息发送给结算平台服务器。
本步骤的实现方式与图1中步骤105的实现方式相同,此处不再赘述。
210、结算平台服务器根据结算信息以及用户客户端的用户信息,关联生成结算单。
结算平台服务器根据用户客户端发送的URL向结算应用服务器请求步骤102中的结算数据信息和商户标识,然后根据请求的结算数据信息、商户标识以及获取的用户信息关联生成包含支付方、收款方以及商品信息三方信息的结算单。其中,用户信息为用户客户端在结算平台(例如微信开放平台)中注册账号时提交的个人信息,结算平台服务器可以从后台服务器中调取用户信息。此外,结算平台服务器也可以在步骤209中接收用户客户端发送的用户信息。
事例性的,生成后的结算单如图5所示,其中包括商户名称、商品金额、商品描述、物流费用等必要信息。
在本实施例的另一个优选方案中,为保证数据传递的安全性,结算应用服务器在向结算平台服务器发送结算数据和商户标识前,还可以通过结算平台服务器认证的加密密钥对结算数据和商户标识进行签名加密,然后调用信息回传接口将签名加密后的结算数据和商户标识发送给结算平台服务器。所述加密密钥为结算应用服务器与结算平台服务器事先约定的加密密钥,保存于结算应用服务器的后台。
与现有技术中由商户侧对结算信息进行签名加密相比,加密密钥仅保存在结算应用服务器侧,商户无需配置后台服务器对加密密钥进行保存,可以在保证信息传递安全性的前提下进一步降低商户参与在线结算的门槛。
211、结算平台服务器将结算单发送给用户客户端,以使用户客户端对结算单进行确认操作。
212、结算平台服务器根据确认操作将用户客户端关联的资金账户内的资金结算至结算应用服务器。
结算平台服务器读取用户事先备注的资金账号(例如银行账号)并发送如图6所示的密码输入提示界面,该界面中包含结算单中的信息内容。待用户客户端提交资金账号密码后,结算平台服务器将关联用户客户端的资金账号和密码发送给银行系统。如果银行系统验证密码正确,则结算平台服务器按照结算中的商品金额将相应的资金划拨到结算应用服务器中。
213、结算应用服务器将接收的资金划拨到商户客户端关联的资金账户中。
具体的:
213a、结算应用服务器将接收到的资金划拨到一级公共结算账户中。
该一级公共结算账户为结算应用服务器侧的公共资金账户,任何商户的资金首先都要流向该账户。
213b、结算应用服务器从一级公共结算账户中将资金划拨到二级公共结算账户中。
该二级公共结算账户同样为结算应用服务器侧的公共资金账户,当资金进入一级公共结算账户后,结算应用服务器将该笔资金划拨到二级公共结算账户中。
213c、结算应用服务器将资金从二级公共结算账户中分账到商户的私人结算账户中。
该私人结算账户为结算应用服务器为每一个商户分别设立的、相对用户和商户的第三方账户,该账户虽为商户的私人账户,但是商户客户端无权从该账户中划拨资金。
213d、结算应用服务器在约定的期限内,将资金从商户的私人结算账户中划拨到商户客户端关联的资金账户中。
本步骤为资金从结算应用服务器侧流向商户侧的过程,结算应用服务器根据与商户侧事先协商的期限(例如5个工作日),将资金划拨到商户客户端关联的资金账户中,商户客户端关联的资金账户可以是商户的银行账户或者网上银行账户。
步骤213中设置两级公共结算账户的目的在于避免结算应用服务器级别的公共结算账户直接对接关联商户的资金账户,保证结算应用账户的资金安全。通过增加第二公共结算账户的方式结算应用服务器可以通过服务器侧的财务管理系统对资金流向进行监管,避免随意向商户客户端划拨资金的情况,同时也可以避免例如汇率误差等原因导致的结算错误。
为了减少结算应用服务器与商户银行账户之间的划拨次数,在本实施例的另一个优选方案中,结算应用服务器也可以在预设时间点上对同一商户在一段时间内产生的所有结算资金一并进行划拨。
可选的,在步骤212之后,结算应用服务器还可以接收结算平台服务器发送的结算结果,然后根据获得的结算结果通知商户客户端结算成功或失败。
具体的,结算应用服务器事先开发与结算平台服务器对接的结算通知接口,在用户进行结算操作后,结算平台服务器按照预设时间间隔(例如每30分钟8次)向结算应用服务器重复发送结算结果返回值。事例性的,该结算结果返回值可以通过1比特字节标识结算操作是否成功,例如字节“1”表示结算成功,字节“0”表示结算失败等。与此同时,该结算结果返回值还与对应的结算单进行绑定,结算应用服务器在接收到结算结果返回值后确认对应该结算单的结算结果返回值是否已经处理,如果已经处理则对结算结果返回值进行丢弃,如果尚未处理,则根据结算结果返回值生成结算结果通知界面,并将该界面对应的URL链接发送给商户客户端,结算成功结算结果通知界面可以如图7所示。
进一步可选的,结算应用服务器还可以在结算平台服务器应答超时时,按照预设时间间隔向结算平台服务器请求结算结果返回值。例如,结算平台服务器中可以设置一个最大结算时长,例如15天或2个月。用户从获取到结算标识时刻起可以在上不超过最大结算时长的时间段内进行结算操作。结算应用服务器从向结算平台服务器发送结算单的时刻起,启动一个线程为该次结算过程计时,如果计时时长超过最大结算时长时结算应用服务器仍未收到该次结算对应的结算结果返回值,则判断结算平台服务器应答超时,结算应用服务器向结算平台服务器进行补单请求操作,向结算平台服务器请求结算结果返回值。事例性的,结算应用服务器可以但不限于按照下述时间间隔进行补单请求操作:8s、10s、30s、60s、120s、360s、1000s(s/秒)。
在实际应用中,一种结算平台服务器应答超时的原因之一为:用户没有在最大结算时长规定的时间内进行结算操作。因此考虑到这种情况的存在,本实施例将结算结果返回值升级为2比特字节,“00”表示结算成功、“01”表示结算失败、“10”表示用户未结算,“11”为空省值。当结算应用服务器接收到的结算结果返回值为“10”时,结算应用服务器向商户客户端发送“结算单作废,请重新提交结算请求”的提示。
再进一步的,为了使商户能够主动对结算结果进行查询,结算应用服务器还可以向商户客户端提供通知查询入口,当接收到商户客户端发送的查询指令后,根据该查询指令向结算平台服务器请求结算结果返回值,然后根据获得的结算结果通知商户客户端结算成功或失败。结算应用服务器向结算平台服务器请求结算结果返回值的具体实现方式可以参考前述请求结算结果返回值的实现方式得以实现,此处不再赘述。
为了向商户提供更为多元化的信息服务,在本实施例的最后一个优先方案中,结算应用服务器还可以对每一笔商户客户端的结算单进行记录,根据内置的财务系统模型对商户客户端的历史结算单进行分析,生成财务分析报表,将财务分析报表发送给商户客户端,从而解决中小商户财务分析成本高、专业性差的问题。
本实施例提供的在线结算的方法,除了能够简化商户侧的架构外,还可以对结算金额进行第三方的公共存储和管理,保障商户和用户双方的合法权益。此外,还能够为在商户侧无需开发结算通知接口协议的条件下,为商户提供结算结果通知,使商户能够实时监测结算结果。第三,本实施例提供的在线结算的方法还能够根据商户的历史结算单进行财务分析,为商户提供便捷、专业的财务服务。最后,本实施例提供的在线结算的方法还可以在无需商户保存、使用加密密钥的前提下,对数据传递过程中涉及的结算数据和商户标识进行签名加密,保证商户数据与用户数据的安全性。
参考图1或图2所示方法的实现,本实施例还提供了一种在线结算的装置。该装置位于结算应用服务器内部或者位于结算应用服务器侧,用以对图1或图2所示的方法进行实现。具体的,如图8所示,所述装置包括:输入输出电路81、处理器82以及结算模块83,其中,
输入输出电路81,用于接收商户客户端发送的结算请求;
处理器82,用于根据输入输出电路81接收的结算请求生成结算信息;
输入输出电路81还用于将处理器82生成的结算信息发送给商户客户端;
结算模块83,用于接收结算平台服务器结算的资金;
结算模块83还用于将接收的资金划拨到商户客户端关联的资金账户中。
进一步的,如图9所示,该装置还包括:
功能管理模块91,用于在处理器82根据结算请求生成结算信息之前,验证商户客户端是否开通结算应用功能;
输入输出电路81还用于当功能管理模块91确定商户客户端未开通结算应用功能时,向商户客户端获取商户信息;
功能管理模块91还用于对输入输出电路81获取的商户信息进行审核;
功能管理模块91还用于当审核通过时,为商户客户端开通结算应用功能,并分配商户标识。
进一步的,输入输出电路81还用于在处理器82根据结算请求生成结算信息之前,向商户客户端发送信息输入界面;
输入输出电路81还用于接收商户在信息输入界面中输入的结算数据,结算数据包括商品金额,以及下述数据信息中的至少一种:商品标识、商品折扣、商品积分、商品描述信息、使用币种、物流费用。
进一步的,处理器82用于生成链接结算数据和商户标识的统一资源定位符(URL)。
进一步的,如图10所示,结算模块83包括:
第一划拨子模块101,用于将接收到的资金划拨到一级公共结算账户中;
第一划拨子模块101还用于从一级公共结算账户中将资金划拨到二级公共结算账户中;
分账子模块102,用于将第一划拨子模块101划拨的资金从二级公共结算账户中分账到商户结算账户中;
第二划拨子模块103,用于在约定的期限内,将分账子模块102分账的资金从商户结算账户中划拨到商户客户端关联的资金账户中。
进一步的,如图9所示,该装置还包括:
通知模块92,用于在结算模块83接收结算平台服务器结算的资金之后,接收结算平台服务器发送的结算结果;
通知模块92还用于向商户客户端提供通知查询入口,并根据商户客户端的查询指令向结算平台服务器请求结算结果;
输入输出电路81还用于根据通知模块92获取的结算结果通知商户客户端结算成功或失败。
进一步的,如图9所示,该装置还包括:
数据分析模块93,用于记录商户客户端的结算数据,根据商户客户端的历史结算数据生成财务分析报表;
输入输出电路81还用于将数据分析模块93生成的财务分析报表发送给商户客户端。
本实施例提供的在线结算的装置,能够以独立的结算应用服务器以及结算平台服务器作为商户客户端与用户客户端之间的中间媒介,完成在线结算的过程。由于无需商户侧与结算平台服务器之间直接进行信息交互,因此无需商户侧开发原生URL二维码生成接口、信息回传接口等接口协议,相当于以结算应用服务器与结算平台服务器之间建立的接口协议作为广大商户“共享”的接口协议,除了能够降低商户侧参与在线结算的门槛外,还可以大大简化商户的结算操作,商户只需通过客户端向结算应用服务器发送结算请求、输入结算信息即可完成在线结算过程,操作十分简便。
此外,本实施例提供的在线结算的装置,除了能够简化商户侧的架构外,还可以对结算金额进行第三方的公共存储和管理,保障商户和用户双方的合法权益。另外还能够为在商户侧无需开发结算通知接口协议的条件下,为商户提供结算结果通知,使商户能够实时监测结算结果。第三,本实施例提供的在线结算的装置还能够根据商户的历史结算单进行财务分析,为商户提供便捷、专业的财务服务。最后,本实施例提供的在线结算的装置还可以在无需商户保存、使用加密密钥的前提下,对数据传递过程中涉及的结算数据和商户标识进行签名加密,保证商户数据与用户数据的安全性。
参考图1或图2所示方法的实现,本实施例还提供了一种在线结算的装置。该装置位于结算平台服务器内部或者位于结算平台服务器侧,用以对图1或图2所示的方法进行实现。具体的,如图11所示,所述装置包括:输入输出电路111、处理器112以及结算模块113,其中,
输入输出电路111,用于接收用户客户端发送的结算信息;
处理器112,用于根据输入输出电路111接收的结算信息以及用户客户端的用户信息,关联生成结算单;
输入输出电路111还用于将处理器112生成的结算单发送给用户客户端;
结算模块113,用于根据确认操作将用户客户端关联的资金账户内的资金结算至结算应用服务器。
进一步的,处理器112用于根据输入输出电路111接收的统一资源定位符向结算应用服务器请求结算数据和商户标识,根据结算数据、商户标识以及用户信息生成结算单。
进一步的,处理器112用于接收结算应用服务器签名加密后的结算数据和商户标识。
本实施例提供的在线结算的装置,能够以独立的结算应用服务器以及结算平台服务器作为商户客户端与用户客户端之间的中间媒介,完成在线结算的过程。由于无需商户侧与结算平台服务器之间直接进行信息交互,因此无需商户侧开发原生URL二维码生成接口、信息回传接口等接口协议,相当于以结算应用服务器与结算平台服务器之间建立的接口协议作为广大商户“共享”的接口协议,除了能够降低商户侧参与在线结算的门槛外,还可以大大简化商户的结算操作,商户只需通过客户端向结算应用服务器发送结算请求、输入结算信息即可完成在线结算过程,操作十分简便。
此外,本实施例提供的在线结算的装置,除了能够简化商户侧的架构外,还可以对结算金额进行第三方的公共存储和管理,保障商户和用户双方的合法权益。另外还能够为在商户侧无需开发结算通知接口协议的条件下,为商户提供结算结果通知,使商户能够实时监测结算结果。第三,本实施例提供的在线结算的装置还能够根据商户的历史结算单进行财务分析,为商户提供便捷、专业的财务服务。最后,本实施例提供的在线结算的装置还可以在无需商户保存、使用加密密钥的前提下,对数据传递过程中涉及的结算数据和商户标识进行签名加密,保证商户数据与用户数据的安全性。
参考图8至图10中任意一幅所示的装置以及图11所示的装置,本实施例还提供了一种在线结算的系统,用以实现如图1或图2所示的方法。如图12所示,该系统包括结算应用服务器121、结算平台服务器122、商户客户端123以及用户客户端124。其中结算应用服务器121内包括图8至图10中任一幅所示的装置,或者结算应用服务器121与图8至图10中任一幅所示的装置位于同一侧;结算平台服务器122内包括图11所示的装置,或者结算平台服务器122与图11所示的装置位于同一侧。
商户客户端123,用于向结算应用服务器121发送结算请求;
结算应用服务器121,用于根据结算请求生成结算信息,并将结算信息发送给商户客户端123;
商户客户端123还用于根据结算应用服务器121发送的结算信息生成结算标识;
用户客户端124,用于在获取结算标识后,将根据结算标识解析出的结算信息发送给结算平台服务器122;
结算平台服务器122,用于根据用户客户端124发送的结算信息以及用户客户端124的用户信息,关联生成结算单,并将将结算单发送给用户客户端124,
用户客户端124还用于对结算平台服务器122发送的结算单进行确认操作;
结算平台服务器122还用于根据用户客户端124的确认操作将用户客户端124关联的资金账户内的资金结算至结算应用服务器121;
结算应用服务器121还用于将接收的资金划拨到商户客户端123关联的资金账户中。
本实施例提供的在线结算的系统,能够以独立的结算应用服务器以及结算平台服务器作为商户客户端与用户客户端之间的中间媒介,完成在线结算的过程。由于无需商户侧与结算平台服务器之间直接进行信息交互,因此无需商户侧开发原生URL二维码生成接口、信息回传接口等接口协议,相当于以结算应用服务器与结算平台服务器之间建立的接口协议作为广大商户“共享”的接口协议,除了能够降低商户侧参与在线结算的门槛外,还可以大大简化商户的结算操作,商户只需通过客户端向结算应用服务器发送结算请求、输入结算信息即可完成在线结算过程,操作十分简便。
此外,本实施例提供的在线结算的系统,除了能够简化商户侧的架构外,还可以对结算金额进行第三方的公共存储和管理,保障商户和用户双方的合法权益。另外还能够为在商户侧无需开发结算通知接口协议的条件下,为商户提供结算结果通知,使商户能够实时监测结算结果。第三,本实施例提供的在线结算的系统还能够根据商户的历史结算单进行财务分析,为商户提供便捷、专业的财务服务。最后,本实施例提供的在线结算的系统还可以在无需商户保存、使用加密密钥的前提下,对数据传递过程中涉及的结算数据和商户标识进行签名加密,保证商户数据与用户数据的安全性。
通过以上的实施方式的描述,所属领域的技术人员可以清楚地了解到本发明可借助软件加必需的通用硬件的方式来实现,当然也可以通过硬件,但很多情况下前者是更佳的实施方式。基于这样的理解,本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品存储在可读取的存储介质中,如计算机的软盘,硬盘或光盘等,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本发明各个实施例所述的方法。
以上所述,仅为本发明的具体实施方式,但本发明的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本发明揭露的技术范围内,可轻易想到变化或替换,都应涵盖在本发明的保护范围之内。因此,本发明的保护范围应所述以权利要求的保护范围为准。