一种支付方法和系统、存储介质与流程

文档序号:15934936发布日期:2018-11-14 02:14阅读:179来源:国知局

本发明实施例涉及互联网应用技术领域,尤其涉及一种支付方法和系统、存储介质。

背景技术

近年,随着信息技术的快速发展,互联网及it系统给传统的零售和餐饮行业带来了巨大的冲击和机遇。传统商家即面临着电商线上行业的冲击,也要研究和应对消费者观念的转型升级,客户对产品和服务的要求与日俱增。不少商家感叹生意不好做,利润率下降。但同时,也有很多商家通过积极拥抱新的技术和营销模式,创造出独特的用户体验和消费体验,从而突围,迅速扩大经营规模,实现了传统商家无法企及的发展速度和规模。典型的技术领域包括点餐,微信支付宝支付,排队,大数据营销,人工智能提高效率等等。商家通过升级自己的管理模式和系统平台,发展线下体验的同时,做好线上营销,在提升效率、降低运营成本、快速建立品牌等方式寻求突破。

软件it经营系统升级换代遇到的难题体现在以下几个方面:

1.基于传统的saas系统和erp系统,升级成本高。

商家升级erp首先需要支付软件费用、服务费用、和硬件成本。这些费用比较高昂,但是更重要的是软件升级更新的学习时间成本,升级时间成本,培训成本等更加高。为了升级一套系统,商家还可能冒着数据迁移和丢失的风险,万一出现升级问题可能会影响正常经营时间。升级系统,商家需要投入在项目周期的精力,可见成本和不可见成本非常高。所以商家很少或尽量减少系统升级的过程,除非必须某些功能。

2.单独的saas软件供应商难以提供全面优质的互联网服务

即便付出了高昂的升级成本后,商家也可能会发现,原有的saas软件或者erp软件提供的新功能并不是自己想要的,或者好用的,甚至根本无用。而自己需要的第三方产品功能,却根本没有。也有可能是费用不合算。举个例子:近两年微信支付宝支付迅速推广,原有的erp软件只有刷卡功能,不满足消费者需求。商家就要求erp厂家进行系统升级提供微信支付功能,当erp软件升级后,商家发现erp厂家提供的微信支付功能没有问题,但是费率很贵,且,通过升级系统的方式并不能很好的解决商家的业务问题。

3.软件系统之间无法对接。

基于前面的问题,商家为了更好的业务功能和服务,往往会选用不同厂家提供的软件系统。由于两个公司没有互联互通,商家的收银员需要手工的进行操作。操作时间加长,容易出错,意味着商家经营效率的下降。

发明人在实现本发明的过程中,发现至少存在如下问题:

1、耗费成本较高;

2、软件之间数据交互不兼容。



技术实现要素:

为解决上述背景技术中的至少一个技术问题,本发明实施例提供了一种支付方法和系统、存储介质。

根据本发明实施例的一个方面,本发明实施例提供了一种支付方法,所述方法包括:

对支付窗口进行监测;

当监测到所述支付窗口被激活时,则对激活所述支付窗口的初始函数进行跳转处理,跳转至替代函数;

通过所述替代函数对与支付金额对应的字符串信息进行获取;

根据所述字符串信息确定金额信息。

通过本实施例提供的:对支付窗口进行监测,如果支付窗口被激活,则对初始函数进行跳转处理,具体为对激活支付窗口的初始函数进行跳转处理,跳转至替代函数,通过替代函数对字符串信息进行获取,具体为对与支付金额对应的字符串信息进行获取,以便根据字符串信息确定金额信息的技术方案,实现了信息之间的转换,从而实现了不同软件之间的数据交互的兼容性,提高了消费者的消费体验,更为不同软件对应的商家节约了成本,节约了资源的技术效果。

根据本发明实施例的另一个方面,本发明实施例提供了一种计算机可读存储介质,包括指令,当其在计算机上运行时,使得计算机执行如上所述的方法。

根据本发明实施例的另一个方面,本发明实施例提供了一种支付系统,所述系统包括:

检测模块:用于对支付窗口进行监测;

跳转模块:用于当监测到所述支付窗口被激活时,则对激活所述支付窗口的初始函数进行跳转处理,跳转至替代函数;

获取模块:用于通过所述替代函数对与支付金额对应的字符串信息进行获取;

确定模块:用于根据所述字符串信息确定金额信息。

附图说明

图1为本发明实施例提供的一种支付方法的流程示意图;

图2为本发明实施例提供的一种支付系统的结构示意图。

具体实施方式

以下描述中,为了说明而不是为了限定,提出了诸如特定系统结构、接口、技术之类的具体细节,以便透切理解本发明。然而,本领域的技术人员应当清楚,在没有这些具体细节的其它实施例中也可以实现本发明。在其它情况中,省略对众所周知的系统以及方法的详细说明,以免不必要的细节妨碍本发明的描述。

本发明实施例提供了一种支付方法和系统、存储介质。

根据本发明实施例的一个方面,本发明实施例提供了一种支付方法。

第一实施例:

请参阅图1,图1为本发明实施例提供的一种支付方法的流程示意图。

如图1所示,该方法包括:

s100:对支付窗口进行监测。

在现有技术中,是直接通过支付窗口进行金额的输入,从而实现金额的支付。

而在本申请中,通过对支付窗口进行监测。具体地,为实时监测。

s200:当监测到支付窗口被激活时,则对激活支付窗口的初始函数进行跳转处理,跳转至替代函数。

当支付窗口被激活时,即当有金额的输入时,则对激活支付窗口的初始函数进行跳转,跳转至替换函数。

s300:通过替代函数对与支付金额对应的字符串信息进行获取。

由替换函数调取字符串信息。字符串信息与支付金额相对应。

即,当支付窗口被激活时,则在支付窗口存在相应的支付金额,通过替换函数对该支付金额对应的字符串信息进行获取。

根据字符串信息确定金额信息。

通过本实施例提供的:对支付窗口进行监测,如果支付窗口被激活,则对初始函数进行跳转处理,具体为对激活支付窗口的初始函数进行跳转处理,跳转至替代函数,通过替代函数对字符串信息进行获取,具体为对与支付金额对应的字符串信息进行获取,以便根据字符串信息确定金额信息的技术方案,实现了信息之间的转换,从而实现了不同软件之间的数据交互的兼容性,提高了消费者的消费体验,更为不同软件对应的商家节约了成本,节约了资源的技术效果。

第二实施例:

本实施例以第一实施例为基础。在本实施例中,该方法还包括:

根据预设的钩子设置跳转指令。

且,此时s200具体为:

当监测到支付窗口被激活时,通过跳转指令对初始函数进行跳转处理,跳转至替代函数。

可以理解的是,windows系统是建立在事件驱动的机制上的,整个系统都是通过消息的传递来实现的。而钩子是windows系统中非常重要的系统接口,用它可以截获并处理送给其他应用程序的消息,来完成普通应用程序难以实现的功能。钩子的种类很多,每种钩子可以截获并处理相应的消息,如键盘钩子可以截获键盘消息,外壳钩子可以截取、启动和关闭应用程序的消息等。本实施例是通过拦截window应用程序绘图钩子来实现的。

应用程序绘图钩子的运行机制,为了实现对drawtext/textout等api的拦截,需要在函数入口放入一条动态生成的"jmp<hook函数>"指令,即跳转指令。

jmp的操作数是我们提供的一个拦截函数的地址(为了适配所有windows系统需要考虑32位系统拦截64位系统的特殊处理)。当该api被调用时,jmp指令首先执行,跳转到替代函数。即,跳转指令将初始函数跳转至替代函数。由替代函数负责从堆栈中获取字符串信息。

第三实施例:

本实施例以第一实施例或第二实施例为基础。在本实施例中,s300具体包括:

通过替代函数获取与支付金额对应的参数信息。

由替代函数从堆栈中获取参数信息,该参数为与支付金额对应的参数信息。

具体地,可以理解的是,支付金额在系统上进行显示时,构成支付金额的最小单位为像素块。

所以,获取参数信息及时对像素块信息进行获取。

可以理解的是,在金额显示时,为二维的显示,即直观效果为平面显示。所以,参数信息包括:像素块x轴上的信息和y轴上的信息。即参数信息包括像素块的x坐标信息和y坐标信息。

对参数信息中的参数进行计算,得到字符串坐标值。

对x坐标信息和y坐标信息进行计算,得到字符串坐标值。

根据字符串坐标值确定字符串信息。

第四实施例:

本实施例以第一实施例至第三实施例中任一实施例为基础。在本实施例中,该方法还包括:

调用支付软件,并基于金额信息完成支付。

其中,基于金额信息完成支付为现有技术,此处不再赘述。

第五实施例:

本实施例以第四实施例为基础。在本实施例中,该方法还包括:

通过替代函数对初始函数进行调用。

由替代函数对原来被拦截的初始函数进行调用。

且将金额信息传输至支付服务器,具体为:

通过初始函数将金额信息传输至支付服务器。

其中,在交互过程中,采用windows消息机制来进行触发。消息能够被分为队列化的和非队列化的。

队列化的消息是由windows放入程序消息队列中的。在程序的消息循环中,重新传回并分配给窗口消息处理程序。即把消息发送给程序的消息队列中,等带消息处理函数取出并处理消息。队列化消息基本上是使用者输入的结果,以击键(如wm_keydown和wm_keyup消息)、击键产生的字符(wm_char)、鼠标移动(wm_mousemove)和鼠标按钮(wm_lbuttondown)的形式给出。队列化消息还包含时钟消息(wm_timer)、更新消息(wm_paint)和退出消息(wm_quit)。

非队列化的消息在windows呼叫窗口时直接送给窗口消息处理程序。直接进行消息处理。非队列化消息则是其它消息.在许多情况下,非队列化消息来自呼叫特定的windows函数.例如,当winmain呼叫createwindow时,windows将建立窗口并在处理中给窗口消息处理程序发送一个wm_create消息。当winmain呼叫showwindow时,windows将给窗口消息处理程序发送wm_size和wm_showwindow消息。当winmain呼叫updatewindow时,windows将给窗口消息处理程序发送wm_paint消息。

注意:键盘或鼠标输入时发出的队列化消息信号,也能在非队列化消息中出现。例如,用键盘或鼠标选择了一个菜单项时,键盘或鼠标消息就是队列化的,而说明菜单项已选中的wm_command消息则可能就是非队列化的。

任何情况下,窗口消息处理程序都将获得窗口所有的消息--包括队列化的和非队列化的。

其中,消息可以由windows系统发送,也可以由应用程序本身;可以向线程内发送,也可以跨线程.主要是看发送函数的调用者。

消息通常包括三个参数:

1、窗口句柄(awindowhandle):窗口句柄用来标识消息将要发送到的窗口对象,系统使用窗口句柄来确定哪一个窗口句柄应该接收该消息。

2、消息标识符(amessageidentifier):消息标识符是用来区分不同消息的命名常量,当窗口过程接收到一个消息时,它使用消息标识符来确定如何处理该消息。例如,消息标识符wm_paint告诉窗口过程“窗口的客户区已经发生变化,窗口必须进行重新绘制”。

3、消息参数(messageparameters):消息参数用来表述窗口过程处理消息时所使用的数据或数据的位置,通常用一对参数表示(即2个长整型的参数:wparam,lparam)。消息参数的意义和取值取决于消息。当不需要使用消息参数时。通常将其设置为null。窗口过程必须通过检查消息标识符来确定如何对消息参数进行解释。

用户在操作程序时对电脑的操作这个事件将会被系统捕获到,然后把这个事件翻译成一个消息并且把消息投递到对应的消息队列中。而程序发现自己的消息队列中具有消息时它便会从自己的消息队列中取出消息并处理消息,直至消息队列为空为止。

为使更清楚透彻的对本发明实施例的技术方案进行理解,现结合现有技术,对本发明实施例的技术方案,以及通过本发明实施例的技术方案实现的技术效果进行详细的阐述。

在现有技术中,餐饮erp系统,当顾客结账买单的时候,且此时顾客并非采用现金结算的方式,而是采用微信或支付宝的方式进行结算。由于餐饮erp系统本身不能直接提供微信或支付宝收款,收银员以另外一家公司提供的二维码收款产品进行收款。但是完成收款后需要手工的把收款结果记录到餐饮erp系统中,以完成完整的结账的业务流程。大致的过程如下:

1.收银员在餐饮erp系统中使用结账功能,由餐饮erp系统计算出应付金额。

2.收银员记录下餐饮erp系统显示的金额,打开另外单独的收款设备(如微信对应的收款设备),输入金额(这时有可能输入产生差错)。

3.单独微信收银成功后,收银员在餐饮erp系统中记录完成收银。并且可能记录收款的流水号,便于下班对账。

这个过程,交互时间长,且容易出错,还增加了夜间对账的工作量。

而通过本发明实施例提供的技术方案,完成完整的结账的业务流程如下:

1.收银员在餐饮erp中选择结账,由餐饮erp系统计算出应付金额。

2.本发明实施例提供的系统自动获取到应付金额,并自动调用了另外的收款设备(如微信对应的收款设备),用户只要出示微信支付码即可完成支付,然后餐饮erp系统中自动完成了该笔交易的记录。

此过程收银员不需要在两个系统中输入任何内容,并且系统自对完成对账过程。

又如:众所周知的是,超市(尤其是大型超市)的日常客流量较多(如1000人/天)。在未采用本发明实施例提供的技术方案之前,由于不能实现做到一体化收银,大部分客户都习惯用手机支付。但是支付方式却各有不同,有时需要针对客户的多样需求进行收银工具的切换,导致收银效率低、客户消费体验差。但是,通过本发明实施例提供的技术方案后,能够轻松实现“支付宝+微信”的聚合收款;自动读取收款金额,大大提高了收银效率,也让客户的消费体验得到提升,促进了客流量的增长。

需要说明的是,上述实施例只是为了更清楚的理解本发明实施例提供的技术方案,而不能理解为对本发明应用场景和保护范围的限定。

根据本发明实施例的另一个方面,本发明实施例提供了一种计算机可读存储介质,包括指令,当其在计算机上运行时,使得计算机执行如上任一实施例所述的方法。

根据本发明实施例的另一个方面,本发明实施例提供了一种支付系统。

请参阅图2,图2为本发明实施例提供的一种支付系统的结构示意图。

如图2所示,该系统包括:

检测模块:用于对支付窗口进行监测;

跳转模块:用于当监测到支付窗口被激活时,则对激活支付窗口的初始函数进行跳转处理,跳转至替代函数;

获取模块:用于通过替代函数对与支付金额对应的字符串信息进行获取;

确定模块:用于根据字符串信息确定金额信息。

在一种可能实现的技术方案中,该系统还包括:设置模块,其中,

设置模块用于:根据预设的钩子设置跳转指令;

则跳转模块具体用于:当监测到支付窗口被激活时,通过跳转指令对初始函数进行跳转处理,跳转至替代函数。

在一种可能实现的技术方案中,获取模块具体用于:

通过替代函数获取与支付金额对应的参数信息;

对参数信息中的参数进行计算,得到字符串坐标值;

根据字符串坐标值确定字符串信息。

在一种可能实现的技术方案中,该系统还包括:

调用模块:用于调用支付软件,并基于金额信息完成支付。

其中,调用模块具体用于:通过替代函数对初始函数进行调用;

且,传输模块具体用于:通过初始函数将金额信息传输至支付服务器。

读者应理解,在本说明书的描述中,参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构或者特点包含于本发明的至少一个实施例或示例中。在本说明书中,对上述术语的示意性表述不必针对的是相同的实施例或示例。而且,描述的具体特征、结构或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外,在不相互矛盾的情况下,本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

所属领域的技术人员可以清楚地了解到,为了描述的方便和简洁,上述描述的装置和单元的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。

在本申请所提供的几个实施例中,应该理解到,所揭露的装置和方法,可以通过其它的方式实现。例如,以上所描述的装置实施例仅仅是示意性的,例如,单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。

作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本发明实施例方案的目的。

另外,在本发明各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以是两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用软件功能单元的形式实现。

集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本发明的技术方案本质上或者说对现有技术做出贡献的部分,或者该技术方案的全部或部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本发明各个实施例方法的全部或部分步骤。而前述的存储介质包括:u盘、移动硬盘、只读存储器(rom,read-onlymemory)、随机存取存储器(ram,randomaccessmemory)、磁碟或者光盘等各种可以存储程序代码的介质。

还应理解,在本发明各实施例中,上述各过程的序号的大小并不意味着执行顺序的先后,各过程的执行顺序应以其功能和内在逻辑确定,而不应对本发明实施例的实施过程构成任何限定。

以上,仅为本发明的具体实施方式,但本发明的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本发明揭露的技术范围内,可轻易想到各种等效的修改或替换,这些修改或替换都应涵盖在本发明的保护范围之内。因此,本发明的保护范围应以权利要求的保护范围为准。

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1