CN112465486B - 一种支付状态确定方法、装置以及设备 - Google Patents
一种支付状态确定方法、装置以及设备 Download PDFInfo
- Publication number
- CN112465486B CN112465486B CN202011119416.7A CN202011119416A CN112465486B CN 112465486 B CN112465486 B CN 112465486B CN 202011119416 A CN202011119416 A CN 202011119416A CN 112465486 B CN112465486 B CN 112465486B
- Authority
- CN
- China
- Prior art keywords
- payment
- information
- state
- payment state
- confirmed
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/085—Payment architectures involving remote charge determination or related payment systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
- G06Q20/325—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices using wireless networks
Landscapes
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Engineering & Computer Science (AREA)
- Strategic Management (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Finance (AREA)
- Computer Networks & Wireless Communication (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
本申请提供了一种支付状态确定方法、装置以及设备,用于准确判断UE对于目标服务的确认支付状态,方法包括:UE获取自身上的目标应用的支付状态信息,其中,支付状态信息用于指示UE自身的系统服务器确认目标应用的目标服务的支付状态为确认支付状态,支付状态信息是在UE接收到系统服务器下发的第一支付确认信息后存储得到的;UE向目标应用的应用服务器发送支付状态信息,以使得应用服务器向系统服务器确认UE对于目标服务的支付状态是否为确认支付状态;当UE接收到应用服务器下发的第二支付确认信息后,UE确定自身对目标服务的支付状态为确认支付状态。
Description
技术领域
本申请涉及通信领域,具体涉及一种支付状态确定方法、装置以及设备。
背景技术
在智能手机、平板电脑上,用户可以根据自己的使用需求安装不同的应用进行使用,例如,社交应用、工具应用、购物应用、游戏应用等不同类型的应用。
如今,应用的收费服务往往是内置收费服务类型,相比传统的收费安装服务类型,内置收费服务类型更适用于应用在使用过程中涉及的各类增值服务以及更适用于应用的服务的更新,可提供良性循环,让应用的开发公司为用户提供更为优质的有价值的服务。
而在现有的相关技术的研究过程中,发明人发现,如今的智能手机、平板电脑等用户设备(User Equipment,UE)上,随着系统安全以及系统流畅性的要求,愈加普遍地由设备自身的系统服务器作为主要渠道来进行应用的安装、更新甚至支付,在支付场景中,保证用户支付后可有效地享受应用提供的收费服务,显然,对于应用的正常运营极为重要,若用户支付后享受不到应用提供的收费服务,显然不仅影响了应用的用户体验,还涉及到更为麻烦的金钱纠纷,而在实际中存在一个情况,UE向系统服务器支付成功后,由于存在网络问题等异常情况,应用未能及时通知自身的应用服务器关于用户的支付情况,应用服务器无法获知用户是否支付了收费服务,在该情况下,则未能向用户提供该收费服务,影响了应用的正常运营。
发明内容
本申请提供了一种支付状态确定方法、装置以及设备,用于准确判断UE对于目标服务的确认支付状态,从而,可基于确认支付状态准确地为用户提供目标服务,保证了目标应用的正常运营以及用户体验。
第一方面,本申请提供了一种支付状态确定方法,方法包括:
UE获取自身上的目标应用的支付状态信息,其中,支付状态信息用于指示UE自身的系统服务器确认目标应用的目标服务的支付状态为确认支付状态,支付状态信息是在UE接收到系统服务器下发的第一支付确认信息后存储得到的,第一支付确认信息用于指示支付处理请求的支付状态为确认支付状态,支付处理请求是UE在用户操作的触发下基于目标服务向系统服务器发起的;
UE向目标应用的应用服务器发送支付状态信息,以使得应用服务器向系统服务器确认UE对于目标服务的支付状态是否为确认支付状态;
当UE接收到应用服务器下发的第二支付确认信息后,UE确定自身对目标服务的支付状态为确认支付状态,第二支付确认信息用于指示应用服务器向系统服务器确认的UE对于目标服务的支付状态为确认支付状态。
结合本申请第一方面,在本申请第一方面第一种可能的实现方式中,UE获取自身上的目标应用的支付状态信息之前,方法还包括:
UE在用户操作的触发下基于目标服务,向系统服务器发起支付处理请求;
当UE接收到系统服务器下发的第一支付确认信息后,UE存储支付状态信息。
结合本申请第一方面,在本申请第一方面第二种可能的实现方式中,UE获取自身上的目标应用的支付状态信息包括:
当启动目标应用时,UE触发获取支付状态信息;
或者,当请求启动目标服务时,UE触发获取支付状态信息;
或者,当安装目标应用时,UE触发获取支付状态信息。
结合本申请第一方面,在本申请第一方面第三种可能的实现方式中,当UE为基于IOS系统时,支付状态信息是存储在UE的内存信息、NSUserDefault信息或者keychain信息中的,UE获取自身上的目标应用的支付状态信息包括:
UE从内存信息、NSUserDefault信息或者keychain信息中,调取支付状态信息。
结合本申请第一方面,在本申请第一方面第四种可能的实现方式中,支付状态信息、第一支付确认信息、支付处理请求以及第二支付确认信息四者,是与同一用户账号相对应的;
或者,支付状态信息、第一支付确认信息、支付处理请求以及第二支付确认信息四者,携带同一用户账号的账号标识。
第二方面,本申请提供了又一种支付状态确定方法,方法包括:
应用服务器接收UE发送的支付状态信息,支付状态信息用于指示UE自身的系统服务器确认UE自身上的目标应用的目标服务的支付状态为确认支付状态,支付状态信息是在UE接收到系统服务器下发的第一支付确认信息后存储得到的,第一支付确认信息用于指示支付处理请求的支付状态为确认支付状态,支付处理请求是UE在用户操作的触发下基于目标服务向系统服务器发起的;
应用服务器向系统服务器确认UE对于目标服务的支付状态是否为确认支付状态;
若是,则应用服务器向UE下发第二支付确认信息,以使得UE确认自身对目标服务的支付状态为确认支付状态,第二支付确认信息用于指示应用服务器向系统服务器确认的UE对于目标服务的支付状态为确认支付状态。
第三方面,本申请提供了一种支付状态确定装置,装置包括:
获取单元,用于获取自身上的目标应用的支付状态信息,其中,支付状态信息用于指示UE自身的系统服务器确认目标应用的目标服务的支付状态为确认支付状态,支付状态信息是在UE接收到系统服务器下发的第一支付确认信息后存储得到的,第一支付确认信息用于指示支付处理请求的支付状态为确认支付状态,支付处理请求是UE在用户操作的触发下基于目标服务向系统服务器发起的;
发送单元,用于向目标应用的应用服务器发送支付状态信息,以使得应用服务器向系统服务器确认UE对于目标服务的支付状态是否为确认支付状态;
确定单元,用当UE接收到应用服务器下发的第二支付确认信息后,于确定自身对目标服务的支付状态为确认支付状态,第二支付确认信息用于指示应用服务器向系统服务器确认的UE对于目标服务的支付状态为确认支付状态。
结合本申请第三方面,在本申请第三方面第一种可能的实现方式中,发送单元,还用于:
在用户操作的触发下基于目标服务,向系统服务器发起支付处理请求;
装置还包括存储单元,用于:
当UE接收到系统服务器下发的第一支付确认信息后,存储支付状态信息。
结合本申请第三方面,在本申请第三方面第二种可能的实现方式中,装置还包括触发单元,用于:
当启动目标应用时,触发获取支付状态信息;
或者,当请求启动目标服务时,触发获取支付状态信息;
或者,当安装目标应用时,触发获取支付状态信息。
结合本申请第三方面,在本申请第三方面第三种可能的实现方式中,当UE为基于IOS系统时,支付状态信息是存储在UE的内存信息、NSUserDefault信息或者keychain信息中的,获取单元,具体用于:
从内存信息、NSUserDefault信息或者keychain信息中,调取支付状态信息。
结合本申请第三方面,在本申请第三方面第四种可能的实现方式中,支付状态信息、第一支付确认信息、支付处理请求以及第二支付确认信息四者,是与同一用户账号相对应的;
或者,支付状态信息、第一支付确认信息、支付处理请求以及第二支付确认信息四者,携带同一用户账号的账号标识。
第四方面,本申请提供了又一种支付状态确定装置,装置包括:
接收单元,用于接收UE发送的支付状态信息,支付状态信息用于指示UE自身的系统服务器确认UE自身上的目标应用的目标服务的支付状态为确认支付状态,支付状态信息是在UE接收到系统服务器下发的第一支付确认信息后存储得到的,第一支付确认信息用于指示支付处理请求的支付状态为确认支付状态,支付处理请求是UE在用户操作的触发下基于目标服务向系统服务器发起的;
确定单元,用于向系统服务器确认UE对于目标服务的支付状态是否为确认支付状态,若是,则触发下发单元;
下发单元,用于向UE下发第二支付确认信息,以使得UE确认自身对目标服务的支付状态为确认支付状态,第二支付确认信息用于指示应用服务器向系统服务器确认的UE对于目标服务的支付状态为确认支付状态。
第五方面,本申请提供了一种支付状态确认设备,包括处理器和存储器,存储器中存储有计算机程序,处理器调用存储器中的计算机程序时执行本申请第一方面、本申请第一方面任一种可能的实现方式、本申请第二方面、本申请第二方面任一种可能的实现方式提供的方法。
第六方面,本申请提供了一种计算机可读存储介质,计算机可读存储介质存储有多条指令,指令适于处理器进行加载,以执行本申请第一方面、本申请第一方面任一种可能的实现方式、本申请第二方面、本申请第二方面任一种可能的实现方式提供的方法。
从以上内容可得出,本申请具有以下的有益效果:
对于支付状态确认场景,本申请一方面,通过在UE本地存储支付状态信息,该支付状态信息用于指示UE自身的系统服务器确认目标应用的目标服务的支付状态为确认支付状态,支付状态信息是在UE接收到系统服务器下发的第一支付确认信息后存储得到的,第一支付确认信息用于指示支付处理请求的支付状态为确认支付状态,支付处理请求是UE在用户操作的触发下基于目标服务向系统服务器发起的,从而,可保证UE在受到网络波动等异常情况无法及时向目标应用的应用服务器通知确认支付状态的前提下,后续可将该支付状态信息发送至应用服务器,告知系统服务器确认了确认支付状态,从而可大大保证准确判断UE对于目标服务的确认支付状态;
另一方面,由于应用服务器在接收到UE发送的支付状态信息后,还向UE的系统服务器确认了UE对于目标服务的支付状态是否为确认支付状态,并当确认了确认支付状态后,向UE下发第二支付确认信息进行告知,如此,实现了二次验证机制,再次保证准确判断UE对于目标服务的确认支付状态。
通过这两重验证机制,UE以及应用服务器两侧可准确判断UE对于目标应用的目标服务的支付状态,从而可基于确认支付状态准确地为用户提供目标服务,保证了目标应用的正常运营以及用户体验。
附图说明
为了更清楚地说明本申请实施例中的技术方案,下面将对实施例描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本申请的一些实施例,对于本领域技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1为本申请支付状态确定方法的一种流程示意图;
图2为本申请支付状态确定方法的又一种流程示意图;
图3为本申请支付状态确定方法的一种场景示意图;
图4为本申请支付状态确定装置的一种结构示意图;
图5为本申请支付状态确定装置的又一种结构示意图;
图6为本申请支付状态确定设备的一种结构示意图。
具体实施方式
下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象,而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换,以便这里描述的实施例能够以除了在这里图示或描述的内容以外的顺序实施。此外,术语“包括”和“具有”以及他们的任何变形,意图在于覆盖不排他的包含,例如,包含了一系列步骤或模块的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或模块,而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或模块。在本申请中出现的对步骤进行的命名或者编号,并不意味着必须按照命名或者编号所指示的时间/逻辑先后顺序执行方法流程中的步骤,已经命名或者编号的流程步骤可以根据要实现的技术目的变更执行次序,只要能达到相同或者相类似的技术效果即可。
本申请中所出现的模块的划分,是一种逻辑上的划分,实际应用中实现时可以有另外的划分方式,例如多个模块可以结合成或集成在另一个系统中,或一些特征可以忽略,或不执行,另外,所显示的或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,模块之间的间接耦合或通信连接可以是电性或其他类似的形式,本申请中均不作限定。并且,作为分离部件说明的模块或子模块可以是也可以不是物理上的分离,可以是也可以不是物理模块,或者可以分布到多个电路模块中,可以根据实际的需要选择其中的部分或全部模块来实现本申请方案的目的。
在介绍本申请提供的支付状态确定方法之前,先介绍本申请涉及的应用背景。
在现有的相关技术中,以IOS系统/平台为例,手机上的IOS应用(Application,APP)在处理交易支付时,基本都是通过调用IOS服务器(系统服务器)的支付应用程序接口(Application Programming Interface,API),待手机操作系统通知IOS应用支付成功/失败/取消后,IOS应用再向应用服务器发送支付完毕请求,请求确认支付状态、结束支付流程。
而在该支付场景下,则存下着缺陷:
1、IOS应用向应用服务器发送支付完毕请求的时候,可能网络不好导致请求发送失败;
2、用户支付完后,可能退出IOS应用,这时候IOS应用还来不及向应用服务器发送支付完毕请求;
3、用户支付完后,甚至可能卸载IOS应用,等用户重新安装IOS应用,如何重新获取到之前购买的服务又是一个问题。
基于现有技术存在的上述缺陷,本申请提供了一种支付状态确认方案,用于克服该缺陷。
本申请提供了一种支付状态确定方法、装置以及计算机可读存储介质,可应用于支付状态确认设备上,该支付状态确认设备具体可以为UE或者应用服务器,用于准确判断UE对于目标服务的确认支付状态,从而,可基于确认支付状态准确地为用户提供目标服务,保证了目标AP的正常运营以及用户体验。
本申请提及的支付状态确定方法,其执行主体可以为支付状态确定装置,或者集成了支付状态确定装置的UE或者应用服务器。其中,支付状态确定装置可以采用硬件或者软件的方式实现,UE具体可以为智能手机、平板电脑、智能手环、笔记本电脑、台式电脑或者个人数字助理(Personal Digital Assistant,PDA)等可安装应用的终端设备。
下面,开始介绍本申请提供的支付状态确定方法。
首先,参阅图1,图1从UE侧示出了本申请支付状态确定方法的一种流程示意图,本申请提供的支付状态确定方法,具体可包括如下步骤:
步骤S101,UE获取自身上的目标应用的支付状态信息,其中,支付状态信息用于指示UE自身的系统服务器确认目标应用的目标服务的支付状态为确认支付状态,支付状态信息是在UE接收到系统服务器下发的第一支付确认信息后存储得到的,第一支付确认信息用于指示支付处理请求的支付状态为确认支付状态,支付处理请求是UE在用户操作的触发下基于目标服务向系统服务器发起的;
步骤S102,UE向目标应用的应用服务器发送支付状态信息,以使得应用服务器向系统服务器确认UE对于目标服务的支付状态是否为确认支付状态;
步骤S103,当UE接收到应用服务器下发的第二支付确认信息后,UE确定自身对目标服务的支付状态为确认支付状态,第二支付确认信息用于指示应用服务器向系统服务器确认的UE对于目标服务的支付状态为确认支付状态。
再参阅图2,图2从应用服务器侧示出了本申请支付状态确定方法的又一种流程示意图,本申请提供的支付状态确定方法,具体也可包括如下步骤:
步骤S201,应用服务器接收UE发送的支付状态信息,支付状态信息用于指示UE自身的系统服务器确认UE自身上的目标应用的目标服务的支付状态为确认支付状态,支付状态信息是在UE接收到系统服务器下发的第一支付确认信息后存储得到的,第一支付确认信息用于指示支付处理请求的支付状态为确认支付状态,支付处理请求是UE在用户操作的触发下基于目标服务向系统服务器发起的;
步骤S202,应用服务器向系统服务器确认UE对于目标服务的支付状态是否为确认支付状态,若是,则触发步骤S203;
步骤S203,应用服务器向UE下发第二支付确认信息,以使得UE确认自身对目标服务的支付状态为确认支付状态,第二支付确认信息用于指示应用服务器向系统服务器确认的UE对于目标服务的支付状态为确认支付状态。
结合图1以及图2所示实施例可看出,对于支付状态确认场景,本申请一方面,通过在UE本地存储支付状态信息,该支付状态信息用于指示UE自身的系统服务器确认目标应用的目标服务的支付状态为确认支付状态,支付状态信息是在UE接收到系统服务器下发的第一支付确认信息后存储得到的,第一支付确认信息用于指示支付处理请求的支付状态为确认支付状态,支付处理请求是UE在用户操作的触发下基于目标服务向系统服务器发起的,从而,可保证UE在受到网络波动等异常情况无法及时向目标应用的应用服务器通知确认支付状态的前提下,后续可将该支付状态信息发送至应用服务器,告知系统服务器确认了确认支付状态,从而可大大保证准确判断UE对于目标服务的确认支付状态;
另一方面,由于应用服务器在接收到UE发送的支付状态信息后,还向UE的系统服务器确认了UE对于目标服务的支付状态是否为确认支付状态,并当确认了确认支付状态后,向UE下发第二支付确认信息进行告知,如此,实现了二次验证机制,再次保证准确判断UE对于目标服务的确认支付状态。
通过这两重验证机制,UE以及应用服务器两侧可准确判断UE对于目标应用的目标服务的支付状态,从而可基于确认支付状态准确地为用户提供目标服务,保证了目标应用的正常运营以及用户体验。
以下则对上述图1以及图2所示实施例的各个步骤及其在实际应用中可能的实现方式进行详细阐述。
为便于介绍,下面内容则将应用简称为APP,应用服务器简称为APP服务器,并且由于IOS系统典型的通过APP Sotre(系统服务器)进行APP的安装、更新、支付,因此以IOS系统涉及的手机支付场景为例,介绍本申请提供的支付状态确定方法。
在IOS手机的使用过程中,用户可能会对部分IOS APP所提供的收费服务具有使用需求,因此可进行支付,以享受该收费服务,该IOS APP可调用APP Store的支付API,进行相应数额的确认支付操作,当完成支付时,APP Store会通知IOS APP支付成功,此时IOS APP可将该存储支付状态信息,以记录APP Store确认用户基于该收费服务发起的支付处理请求的支付状态为确认支付状态,在实际应用中,该支付状态信息具体可以包括该收费服务的服务标识(Identification,ID)、订单号以及收据,IOS APP接着可将该支付状态信息发送至APP服务器。
另一侧的APP服务器接收到IOS APP上报的支付状态信息后,则可向APP Store确认对应的订单是否有效完成支付,即确认该收费服务的支付状态是否为确认支付状态,在实际应用中,APP服务器可从APP Store调取对应订单的订单信息,看是否和支付状态信息中的内容相匹配,若匹配,则可确认为确认支付状态,此时IOS APP的支付完毕请求(可以理解为上报的支付状态信息)请求成功,APP服务器可向IOS APP下发响应信息,以通知本次支付状态信息通过验证,用户对于该收费服务成功支付,可向用户正常提供该收费服务。
此时可看出,本申请所提出的支付状态确认方案,核心在于手机预先存储了收费服务对应的支付状态信息,再将该信息发至APP服务器由APP服务器进行二次验证,实现请求支付完毕,即使遇到网络异常、退出APP甚至卸载重装APP的情况,也可基于该存储的支付状态信息,再次向APP服务器发起二次验证,请求支付完毕,准确判断具体支付状态并准确提供收费服务。
如此可看出,IOS APP不仅可以在最开始基于收费服务向APP Store发起支付处理请求并得到APP Store反馈的支付确认信息后,存储支付状态信息并向APP服务器发送该支付状态信息,也可以待后续启动IOS APP、启动收费服务甚至重装IOS AP后,调取支付状态信息并向APP服务器发送该支付状态信息,进行二次验证,如此,在保证可正常请求支付完毕的情况下,防止部分的越狱应用欺骗手机的IOS操作系统通知IOS APP完成支付时,可通过APP服务器的二次验证确认其是否完成真实支付(有效支付),保证APP的正常运营,避免APP开发公司蒙受损失。
其中,IOS APP,具体的,可将支付状态信息存储在手机的内存信息、NSUserDefault信息(一种持久化数据形式的用户配置信息)或者keychain信息(包含APP的密码、序列号、证书等私密信息)中,其中,相比于其他两个存储方式,将支付状态信息存储在内存信息中,可具有读取/存储速度最快的特点。
对应的,IOS APP是从内存信息、NSUserDefault信息或者keychain信息中,调取所存储的支付状态信息的。
需要说明的是,由于keychain信息具有安全效果较高的优点,即使用户卸载了IOSAPP,其在keychain信息中存储的支付状态信息仍然是存在的,因此,当用户重装该IOS APP时,仍可从keychain信息中获取支付状态信息,以对涉及的收费项目进行二次验证或者请求支付完毕,满足支付状态的准确判断以及收费服务的准确提供。
进一步的,对于上述收费服务的支付状态确认,可以理解,在实际应用中,除了可以以手机为单位进行确认的,还可以以手机的登录账户或者IOS APP的登录账户为单位进行确认的,以便针对更小的使用单位提供更为准确的支付状态确认。
对应的,上述的支付状态信息、第一支付确认信息、支付处理请求以及第二支付确认信息四者,是与同一用户账号相对应的;
或者,支付状态信息、第一支付确认信息、支付处理请求以及第二支付确认信息四者,携带同一用户账号的账号标识。
当存在支付异常、支付失败等异常情况时,系统服务器或者APP服务器则可向IOSAPP通知该情况,IOS APP接收到通知后,可重新发起相应的请求,例如支付处理请求或者支付状态信息等。
除了由系统服务器或者APP服务器主动通知支付异常情况,IOS APP也可通过等待时间机制来主动判断支付异常情况。
例如,IOS APP每次发起支付处理请求或者支付状态信息后,若15s内未接收到系统服务器或者APP服务器的反馈,则可确定存在支付异常情况,重新发起支付处理请求或者支付状态信息,又或者向用户输出支付异常提醒。
进一步的,本申请在图3还示出本申请支付状态确定方法的一种场景示意图,在图3所示实际应用场景的基础上,可更为方便地理解上述内容。
以上是本申请提供的支付状态确定方法的介绍,为便于更好的实施本申请提供的支付状态确定方法,本申请还提供了支付状态确定装置。
参阅图4,图4为本申请从UE侧示出了支付状态确定装置的一种结构示意图,在本申请中,支付状态确定装置400具体可包括如下结构:
获取单元401,用于获取自身上的目标应用的支付状态信息,其中,支付状态信息用于指示UE自身的系统服务器确认目标应用的目标服务的支付状态为确认支付状态,支付状态信息是在UE接收到系统服务器下发的第一支付确认信息后存储得到的,第一支付确认信息用于指示支付处理请求的支付状态为确认支付状态,支付处理请求是UE在用户操作的触发下基于目标服务向系统服务器发起的;
发送单元402,用于向目标应用的应用服务器发送支付状态信息,以使得应用服务器向系统服务器确认UE对于目标服务的支付状态是否为确认支付状态;
确定单元403,用于当UE接收到应用服务器下发的第二支付确认信息后,确定自身对目标服务的支付状态为确认支付状态,第二支付确认信息用于指示应用服务器向系统服务器确认的UE对于目标服务的支付状态为确认支付状态。
在一种示例性的实现方式中,发送单元402,还用于:
在用户操作的触发下基于目标服务,向系统服务器发起支付处理请求;
装置还包括存储单元404,用于:
当UE接收到系统服务器下发的第一支付确认信息后,存储支付状态信息。
在又一种示例性的实现方式中,装置还包括触发单元405,用于:
当启动目标应用时,触发获取支付状态信息;
或者,当请求启动目标服务时,触发获取支付状态信息;
或者,当安装目标应用时,触发获取支付状态信息。
在又一种示例性的实现方式中,当UE为基于IOS系统时,支付状态信息是存储在UE的内存信息、NSUserDefault信息或者keychain信息中的,获取单元401,具体用于:
从内存信息、NSUserDefault信息或者keychain信息中,调取支付状态信息。
在又一种示例性的实现方式中,支付状态信息、第一支付确认信息、支付处理请求以及第二支付确认信息四者,是与同一用户账号相对应的;
或者,支付状态信息、第一支付确认信息、支付处理请求以及第二支付确认信息四者,携带同一用户账号的账号标识。
继续参阅图5,图5为本申请从APP服务器侧示出了支付状态确定装置的一种结构示意图,在本申请中,支付状态确定装置500具体还可包括如下结构:
接收单元501,用于接收UE发送的支付状态信息,支付状态信息用于指示UE自身的系统服务器确认UE自身上的目标应用的目标服务的支付状态为确认支付状态,支付状态信息是在UE接收到系统服务器下发的第一支付确认信息后存储得到的,第一支付确认信息用于指示支付处理请求的支付状态为确认支付状态,支付处理请求是UE在用户操作的触发下基于目标服务向系统服务器发起的;
确定单元502,用于向系统服务器确认UE对于目标服务的支付状态是否为确认支付状态,若是,则触发下发单元503;
下发单元503,用于向UE下发第二支付确认信息,以使得UE确认自身对目标服务的支付状态为确认支付状态,第二支付确认信息用于指示应用服务器向系统服务器确认的UE对于目标服务的支付状态为确认支付状态。
本申请还提供了支付状态确定设备,参阅图6,图6示出了本申请支付状态确定设备的一种结构示意图,具体的,支付状态确定设备可以为UE或者APP服务器,本申请支付状态确定设备可包括处理器601、存储器602以及输入输出设备603,处理器601用于执行存储器602中存储的计算机程序时实现如图1至图3对应任意实施例中支付状态确定方法的各步骤;或者,处理器601用于执行存储器602中存储的计算机程序时实现如图3或图4对应实施例中各单元的功能,存储器602用于存储处理器601执行上述图1至图3对应任意实施例中支付状态确定方法所需的计算机程序。
示例性的,计算机程序可以被分割成一个或多个模块/单元,一个或者多个模块/单元被存储在存储器602中,并由处理器601执行,以完成本申请。一个或多个模块/单元可以是能够完成特定功能的一系列计算机程序指令段,该指令段用于描述计算机程序在计算机装置中的执行过程。
支付状态确定设备可包括,但不仅限于处理器601、存储器602、输入输出设备603。本领域技术人员可以理解,示意仅仅是支付状态确定设备的示例,并不构成对支付状态确定设备的限定,可以包括比图示更多或更少的部件,或者组合某些部件,或者不同的部件,例如支付状态确定设备还可以包括网络接入设备、总线等,处理器601、存储器602、输入输出设备603以及网络接入设备等通过总线相连。
处理器601可以是中央处理单元(Central Processing Unit,CPU),还可以是其他通用处理器、数字信号处理器(Digital Signal Processor,DSP)、专用集成电路(Application Specific Integrated Circuit,ASIC)、现成可编程门阵列(Field-Programmable Gate Array,FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等,处理器是支付状态确定设备的控制中心,利用各种接口和线路连接整个设备的各个部分。
存储器602可用于存储计算机程序和/或模块,处理器601通过运行或执行存储在存储器602内的计算机程序和/或模块,以及调用存储在存储器602内的数据,实现计算机装置的各种功能。存储器602可主要包括存储程序区和存储数据区,其中,存储程序区可存储操作系统、至少一个功能所需的应用程序等;存储数据区可存储根据支付状态确定设备的使用所创建的数据等。此外,存储器可以包括高速随机存取存储器,还可以包括非易失性存储器,例如硬盘、内存、插接式硬盘,智能存储卡(Smart Media Card,SMC),安全数字(Secure Digital,SD)卡,闪存卡(Flash Card)、至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。
处理器601用于执行存储器602中存储的计算机程序时,具体可实现以下功能:
获取自身上的目标应用的支付状态信息,其中,支付状态信息用于指示UE自身的系统服务器确认目标应用的目标服务的支付状态为确认支付状态,支付状态信息是在UE接收到系统服务器下发的第一支付确认信息后存储得到的,第一支付确认信息用于指示支付处理请求的支付状态为确认支付状态,支付处理请求是UE在用户操作的触发下基于目标服务向系统服务器发起的;
向目标应用的应用服务器发送支付状态信息,以使得应用服务器向系统服务器确认UE对于目标服务的支付状态是否为确认支付状态;
当UE接收到应用服务器下发的第二支付确认信息后,确定自身对目标服务的支付状态为确认支付状态,第二支付确认信息用于指示应用服务器向系统服务器确认的UE对于目标服务的支付状态为确认支付状态。
或者,处理器601用于执行存储器602中存储的计算机程序时,具体也可实现以下功能:
接收UE发送的支付状态信息,支付状态信息用于指示UE自身的系统服务器确认UE自身上的目标应用的目标服务的支付状态为确认支付状态,支付状态信息是在UE接收到系统服务器下发的第一支付确认信息后存储得到的,第一支付确认信息用于指示支付处理请求的支付状态为确认支付状态,支付处理请求是UE在用户操作的触发下基于目标服务向系统服务器发起的;
向系统服务器确认UE对于目标服务的支付状态是否为确认支付状态;
若是,则向UE下发第二支付确认信息,以使得UE确认自身对目标服务的支付状态为确认支付状态,第二支付确认信息用于指示应用服务器向系统服务器确认的UE对于目标服务的支付状态为确认支付状态。
所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,上述描述的支付状态确定装置、设备及其相应单元的具体工作过程,可以参考如图1及至图3对应任意实施例中支付状态确定方法的说明,具体在此不再赘述。
本领域普通技术人员可以理解,上述实施例的各种方法中的全部或部分步骤可以通过指令来完成,或通过指令控制相关的硬件来完成,该指令可以存储于一计算机可读存储介质中,并由处理器进行加载和执行。
为此,本申请提供一种计算机可读存储介质,其中存储有多条指令,该指令能够被处理器进行加载,以执行本申请如图1至图3对应任意实施例中支付状态确定方法中的步骤,具体操作可参考如图1至图3对应任意实施例中支付状态确定方法的说明,在此不再赘述。
其中,该计算机可读存储介质可以包括:只读存储器(Read Only Memory,ROM)、随机存取记忆体(Random Access Memory,RAM)、磁盘或光盘等。
由于该计算机可读存储介质中所存储的指令,可以执行本申请如图1至图3对应任意实施例中支付状态确定方法中的步骤,因此,可以实现本申请如图1至图3对应任意实施例中支付状态确定方法所能实现的有益效果,详见前面的说明,在此不再赘述。
以上对本申请提供的支付状态确定方法、装置、设备以及计算机可读存储介质进行了详细介绍,本文中应用了具体个例对本申请的原理及实施方式进行了阐述,以上实施例的说明只是用于帮助理解本申请的方法及其核心思想;同时,对于本领域的技术人员,依据本申请的思想,在具体实施方式及应用范围上均会有改变之处,综上所述,本说明书内容不应理解为对本申请的限制。
Claims (8)
1.一种支付状态确定方法,其特征在于,所述方法包括:
用户设备UE获取自身上的目标应用的支付状态信息,其中,所述支付状态信息用于指示所述UE自身的系统服务器确认所述目标应用的目标服务的支付状态为确认支付状态,所述支付状态信息是在所述UE接收到所述系统服务器下发的第一支付确认信息后存储得到的,所述第一支付确认信息用于指示支付处理请求的支付状态为确认支付状态,所述支付处理请求是所述UE在用户操作的触发下基于所述目标服务向所述系统服务器发起的;
所述UE向所述目标应用的应用服务器发送所述支付状态信息,以使得所述应用服务器向所述系统服务器确认所述UE对于所述目标服务的支付状态是否为确认支付状态;
当所述UE接收到所述应用服务器下发的第二支付确认信息后,所述UE确定自身对所述目标服务的支付状态为确认支付状态,所述第二支付确认信息用于指示所述应用服务器向所述系统服务器确认的所述UE对于所述目标服务的支付状态为确认支付状态,从而实现二次验证,准确判断所述UE对于所述目标服务的确认支付状态;
所述UE获取自身上的目标应用的支付状态信息包括:当启动所述目标应用时,所述UE触发获取所述支付状态信息;或者,当请求启动所述目标服务时,所述UE触发获取所述支付状态信息;或者,当安装所述目标应用时,所述UE触发获取所述支付状态信息;
当所述UE为基于IOS系统时,所述支付状态信息是存储在所述UE的内存信息、NSUserDefault信息或者keychain信息中的,所述UE获取自身上的目标应用的支付状态信息包括:所述UE从所述内存信息、所述NSUserDefault信息或者所述keychain信息中,调取所述支付状态信息。
2.根据权利要求1所述的方法,其特征在于,所述UE获取自身上的目标应用的支付状态信息之前,所述方法还包括:
所述UE在所述用户操作的触发下基于所述目标服务,向所述系统服务器发起所述支付处理请求;
当所述UE接收到所述系统服务器下发的所述第一支付确认信息后,所述UE存储所述支付状态信息。
3.根据权利要求1所述的方法,其特征在于,所述支付状态信息、所述第一支付确认信息、所述支付处理请求以及所述第二支付确认信息四者,是与同一用户账号相对应的;
或者,所述支付状态信息、所述第一支付确认信息、所述支付处理请求以及所述第二支付确认信息四者,携带同一用户账号的账号标识。
4.一种支付状态确定方法,其特征在于,所述方法包括:
应用服务器接收用户设备UE发送的支付状态信息,所述支付状态信息用于指示所述UE自身的系统服务器确认UE自身上的目标应用的目标服务的支付状态为确认支付状态,所述支付状态信息是在所述UE接收到所述系统服务器下发的第一支付确认信息后存储得到的,所述第一支付确认信息用于指示支付处理请求的支付状态为确认支付状态,所述支付处理请求是所述UE在用户操作的触发下基于所述目标服务向所述系统服务器发起的;
所述应用服务器向所述系统服务器确认所述UE对于所述目标服务的支付状态是否为确认支付状态;
若是,则所述应用服务器向所述UE下发第二支付确认信息,以使得所述UE确认自身对所述目标服务的支付状态为确认支付状态,所述第二支付确认信息用于指示所述应用服务器向所述系统服务器确认的所述UE对于所述目标服务的支付状态为确认支付状态;从而实现二次验证,准确判断所述UE对于所述目标服务的确认支付状态;
其中,所述UE由自身上的目标应用获取所述支付状态信息,包括:当启动所述目标应用时,所述UE触发获取所述支付状态信息;或者,当请求启动所述目标服务时,所述UE触发获取所述支付状态信息;或者,当安装所述目标应用时,所述UE触发获取所述支付状态信息;
当所述UE为基于IOS系统时,所述支付状态信息是存储在所述UE的内存信息、NSUserDefault信息或者keychain信息中的,所述UE由自身上的目标应用获取所述支付状态信息,包括:所述UE从所述内存信息、所述NSUserDefault信息或者所述keychain信息中,调取所述支付状态信息。
5.一种支付状态确定装置,其特征在于,所述装置包括:
获取单元,用于获取自身上的目标应用的支付状态信息,其中,所述支付状态信息用于指示用户设备UE自身的系统服务器确认所述目标应用的目标服务的支付状态为确认支付状态,所述支付状态信息是在所述UE接收到所述系统服务器下发的第一支付确认信息后存储得到的,所述第一支付确认信息用于指示支付处理请求的支付状态为确认支付状态,所述支付处理请求是所述UE在用户操作的触发下基于所述目标服务向所述系统服务器发起的;
发送单元,用于向所述目标应用的应用服务器发送所述支付状态信息,以使得所述应用服务器向所述系统服务器确认所述UE对于所述目标服务的支付状态是否为确认支付状态;
当所述UE接收到所述应用服务器下发的第二支付确认信息后,确定单元,用于确定自身对所述目标服务的支付状态为确认支付状态,所述第二支付确认信息用于指示所述应用服务器向所述系统服务器确认的所述UE对于所述目标服务的支付状态为确认支付状态;从而实现二次验证,准确判断所述UE对于所述目标服务的确认支付状态;
触发单元,用于当启动所述目标应用时,触发获取所述支付状态信息;或者,当请求启动所述目标服务时,触发获取所述支付状态信息;或者,当安装所述目标应用时,触发获取所述支付状态信息;
当所述UE为基于IOS系统时,所述支付状态信息是存储在UE的内存信息、NSUserDefault信息或者keychain信息中的,所述获取单元,具体用于:从所述内存信息、所述NSUserDefault信息或者所述keychain信息中,调取所述支付状态信息。
6.一种支付状态确定装置,其特征在于,所述装置包括:
接收单元,用于接收用户设备UE发送的支付状态信息,所述支付状态信息用于指示所述UE自身的系统服务器确认UE自身上的目标应用的目标服务的支付状态为确认支付状态,所述支付状态信息是在所述UE接收到所述系统服务器下发的第一支付确认信息后存储得到的,所述第一支付确认信息用于指示支付处理请求的支付状态为确认支付状态,所述支付处理请求是所述UE在用户操作的触发下基于所述目标服务向所述系统服务器发起的;
确定单元,用于向所述系统服务器确认所述UE对于所述目标服务的支付状态是否为确认支付状态,若是,则触发下发单元;
下发单元,用于向所述UE下发第二支付确认信息,以使得所述UE确认自身对所述目标服务的支付状态为确认支付状态,所述第二支付确认信息用于指示所述目标应用的应用服务器向所述系统服务器确认的所述UE对于所述目标服务的支付状态为确认支付状态;从而实现二次验证,准确判断所述UE对于所述目标服务的确认支付状态;
其中,所述UE由自身上的目标应用获取支付状态信息,包括:当启动所述目标应用时,所述UE触发获取所述支付状态信息;或者,当请求启动所述目标服务时,所述UE触发获取所述支付状态信息;或者,当安装所述目标应用时,所述UE触发获取所述支付状态信息;
当所述UE为基于IOS系统时,所述支付状态信息是存储在所述UE的内存信息、NSUserDefault信息或者keychain信息中的,所述UE由自身上的目标应用获取支付状态信息,包括:所述UE从所述内存信息、所述NSUserDefault信息或者所述keychain信息中,调取所述支付状态信息。
7.一种支付状态确定设备,其特征在于,包括处理器和存储器,所述存储器中存储有计算机程序,所述处理器调用所述存储器中的计算机程序时执行如权利要求1至3任一项所述的方法。
8.一种计算机可读存储介质,其特征在于,所述计算机可读存储介质存储有多条指令,所述指令适于处理器进行加载,以执行权利要求1至3任一项所述的方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202011119416.7A CN112465486B (zh) | 2020-10-19 | 2020-10-19 | 一种支付状态确定方法、装置以及设备 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202011119416.7A CN112465486B (zh) | 2020-10-19 | 2020-10-19 | 一种支付状态确定方法、装置以及设备 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN112465486A CN112465486A (zh) | 2021-03-09 |
CN112465486B true CN112465486B (zh) | 2023-01-20 |
Family
ID=74833582
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202011119416.7A Active CN112465486B (zh) | 2020-10-19 | 2020-10-19 | 一种支付状态确定方法、装置以及设备 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN112465486B (zh) |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101901519A (zh) * | 2009-05-26 | 2010-12-01 | 北京易路联动技术有限公司 | 一种移动终端间即时信息交互的方法及系统 |
CN103164792A (zh) * | 2011-12-14 | 2013-06-19 | 阿里巴巴集团控股有限公司 | 无线终端上的支付服务提供方法及相关设备和系统 |
CN107392722A (zh) * | 2017-07-27 | 2017-11-24 | 福建中金在线信息科技有限公司 | 订单处理方法、装置、电子设备及存储介质 |
CN107480981A (zh) * | 2017-07-21 | 2017-12-15 | 深圳市金立通信设备有限公司 | 一种发送通知信息的方法及服务器 |
WO2020080839A1 (en) * | 2018-10-17 | 2020-04-23 | Samsung Electronics Co., Ltd. | Apparatus for payment system and operation method of payment system |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP4914533B2 (ja) * | 2000-06-05 | 2012-04-11 | 株式会社三井住友銀行 | 情報処理装置及び情報処理方法 |
-
2020
- 2020-10-19 CN CN202011119416.7A patent/CN112465486B/zh active Active
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101901519A (zh) * | 2009-05-26 | 2010-12-01 | 北京易路联动技术有限公司 | 一种移动终端间即时信息交互的方法及系统 |
CN103164792A (zh) * | 2011-12-14 | 2013-06-19 | 阿里巴巴集团控股有限公司 | 无线终端上的支付服务提供方法及相关设备和系统 |
CN107480981A (zh) * | 2017-07-21 | 2017-12-15 | 深圳市金立通信设备有限公司 | 一种发送通知信息的方法及服务器 |
CN107392722A (zh) * | 2017-07-27 | 2017-11-24 | 福建中金在线信息科技有限公司 | 订单处理方法、装置、电子设备及存储介质 |
WO2020080839A1 (en) * | 2018-10-17 | 2020-04-23 | Samsung Electronics Co., Ltd. | Apparatus for payment system and operation method of payment system |
Also Published As
Publication number | Publication date |
---|---|
CN112465486A (zh) | 2021-03-09 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20220109974A1 (en) | Esim card change method and related device | |
US10205833B2 (en) | Graphical user interface and method for mobile device activation | |
EP3079326B1 (en) | Network payment method, apparatus and system | |
EP3509270B1 (en) | Data backup method and device, storage medium and electronic apparatus | |
CN109815683B (zh) | 权限验证方法及相关装置 | |
EP1942698A1 (en) | Method and system for mobile device activation | |
JP6074516B2 (ja) | アドレス帳にプラグインを追加する方法、装置、設備、プログラム及び記録媒体 | |
JP2008519353A (ja) | 常駐アプリケーションをアクティブにするための方法、ソフトウェア、および装置 | |
CN105227321A (zh) | 信息处理方法、服务器及客户端 | |
CN109196891B (zh) | 一种签约数据集的管理方法、终端及服务器 | |
CN108650098B (zh) | 用户自定义验证方式的方法及装置 | |
CN112738046B (zh) | 一种一键登录的方法、终端及系统服务器 | |
US20160260103A1 (en) | Method, Apparatus, and Computer Readable Medium for Providing Wireless Device Protection Service | |
CN104951933A (zh) | 一种安全支付方法及移动终端 | |
CN112465486B (zh) | 一种支付状态确定方法、装置以及设备 | |
CN108156206B (zh) | 一种数据转移方法、服务器、客户端以及系统 | |
CN107977564B (zh) | 一种交易认证处理方法、认证服务器、终端及交易设备 | |
CN111178872A (zh) | 一种免手机验证码的手机银行的支付方法及装置 | |
CN110618937A (zh) | 软件测评方法、装置及设备 | |
EP4026357B1 (en) | System, method, and computer program for protecting against unintentional deletion of an esim from a mobile device | |
CN111176678B (zh) | 一种软件受控自动更新方法及装置 | |
US9826402B2 (en) | Mobile device management | |
CN112235784B (zh) | 基于vSIM的码号管理方法、装置及设备 | |
CN105656849B (zh) | 一种数据转移方法和设备 | |
CN115660658A (zh) | 银行卡同时绑定多个第三方支付平台的方法、系统 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |