支付处理方法、装置、服务器及设备与流程

本说明书涉及互联网技术领域，尤其涉及支付处理方法、装置、服务器及设备。

背景技术

随着互联网技术和终端技术的发展，在线下商店或交通出行等多种场景，移动支付已成为人们日常生活中的一种常见支付方式。以公交场景为例，用户可以使用智能手机等便携终端安装具有支付功能的app(application，应用)，若需要付款，app可以展示用于支付车费的乘车码，该乘车码携带有与支付相关的数据。公交车上的收款设备可以通过摄像头或扫描设备识别乘车码，通过获取乘车码中携带的数据，进而完成支付。基于此，需要提供一种更为便利的支付方案。

技术实现要素：

为克服相关技术中存在的问题，本说明书提供了支付处理方法、装置、服务器及设备。

根据本说明书实施例的第一方面，提供一种支付处理方法，所述方法包括：

确定检测到携带有验证口令的连接信号后，获取设备姿态参数，所述连接信号由目标设备发出；

若所述设备姿态参数匹配目标姿态，向服务端发起支付请求，所述支付请求携带有所述验证口令，以供所述服务端根据所述目标设备生成的验证口令对所述支付请求携带的验证口令进行验证后响应所述支付请求。

可选的，所述连接信号包括：ibeacon信号。

可选的，所述方法应用于客户端，所述客户端由操作系统唤醒后执行所述支付处理方法，所述客户端是在所述操作系统检测到所述连接信号后被唤醒。

可选的，所述连接信号还携带有目标设备标识，所述支付请求还携带有所述目标设备标识。

可选的，所述支付请求还携带有支付参数。

根据本说明书实施例的第二方面，提供一种支付处理方法，所述方法包括：

按照目标时间周期生成验证口令；

发出连接信号，所述连接信号携带有当前生效的验证口令；

将携带有所述验证口令的收款请求发送给服务端，以供所述服务端对便携设备发起的支付请求中携带的验证口令进行验证后响应所述收款请求。

可选的，在所述将所述验证口令发送给服务端之前，所述方法还包括：

接收服务端发起的验证口令发送请求。

可选的，所述收款请求还携带有收款参数。

可选的，所述连接信号包括：ibeacon信号。

根据本说明书实施例的第三方面，提供一种支付处理方法，所述方法包括：

接收便携设备发起的携带有验证口令的支付请求，其中，所述验证口令是所述便携设备检测目标设备发出的连接信号中获取到的；

接收所述目标设备发起的携带有验证口令的收款请求；

利用所述目标设备生成的验证口令对所述支付请求携带的验证口令进行验证；

根据验证结果确定对所述支付请求和所述收款请求的响应结果。

可选的，所述利用所述目标设备生成的验证口令对所述支付请求携带的验证口令进行验证，包括：

验证所述目标设备生成的验证口令与所述支付请求携带的验证口令是否匹配。

可选的，所述在接收所述目标设备发起的携带有验证口令的收款请求前，所述方法包括：

向所述目标设备发起验证口令发送请求。

可选的，所述支付请求还携带有所述目标设备标识，所述目标设备通过所述目标设备标识查找到。

可选的，所述支付请求还携带有支付参数，所述支付参数包括支付方账户信息，所述收款请求还携带有收款参数；所述响应结果包括：基于所述收款参数对支付方账户进行扣款的扣款结果。

可选的，所述方法还包括：分别向所述便携设备和目标设备发送响应结果消息。

根据本说明书实施例的第四方面，提供一种支付处理装置，所述装置包括：

姿态参数获取模块，用于：确定检测到携带有验证口令的连接信号后，获取设备姿态参数，所述连接信号由目标设备发出；

支付发起模块，用于：若所述设备姿态参数匹配目标姿态，向服务端发起支付请求，所述支付请求携带有所述验证口令，以供所述服务端根据所述目标设备生成的验证口令对所述支付请求携带的验证口令进行验证后响应所述支付请求。

可选的，所述连接信号包括：ibeacon信号。

可选的，所述装置应用于客户端，所述客户端由操作系统唤醒后执行所述支付处理方法，所述客户端是在所述操作系统检测到所述连接信号后被唤醒。

可选的，所述支付请求还携带有支付参数。

根据本说明书实施例的第五方面，提供一种支付处理装置，所述装置包括：

口令生成模块，用于：按照目标时间周期生成验证口令；

信号发出模块，用于：发出连接信号，所述连接信号携带有当前生效的验证口令；

收款发起模块，用于：将携带有所述验证口令的收款请求发送给服务端，以供所述服务端对便携设备发起的支付请求中携带的验证口令进行验证后响应所述收款请求。

可选的，所述收款发起模块，还用于：在所述将所述验证口令发送给服务端之前，接收服务端发起的验证口令发送请求。

可选的，所述收款请求还携带有收款参数。

可选的，所述连接信号包括：ibeacon信号。

根据本说明书实施例的第六方面，提供一种支付处理装置，所述装置包括：

支付请求接收模块，用于：接收便携设备发起的携带有验证口令的支付请求，其中，所述验证口令是所述便携设备检测目标设备发出的连接信号中获取到的；

收款请求接收模块，用于：接收所述目标设备发起的携带有验证口令的收款请求；

验证模块，用于：利用所述目标设备生成的验证口令对所述支付请求携带的验证口令进行验证；

响应模块，用于：根据验证结果确定对所述支付请求和所述收款请求的响应结果。

可选的，所述验证模块，还用于：

验证所述目标设备生成的验证口令与所述支付请求携带的验证口令是否匹配。

可选的，所述支付请求还携带有支付参数，所述支付参数包括支付方账户信息，所述收款请求还携带有收款参数；所述响应结果包括：基于所述收款参数对支付方账户进行扣款的扣款结果。

可选的，所述装置还包括发送模块，用于：分别向所述便携设备和目标设备发送响应结果消息。

根据本说明书实施例的第七方面，提供一种便携设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，所述处理器执行所述程序时实现如下方法：

确定检测到携带有验证口令的连接信号后，获取设备姿态参数，所述连接信号由目标设备发出；

若所述设备姿态参数匹配目标姿态，向服务端发起支付请求，所述支付请求携带有所述验证口令，以供所述服务端根据所述目标设备生成的验证口令对所述支付请求携带的验证口令进行验证后响应所述支付请求。

根据本说明书实施例的第八方面，提供一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，所述处理器执行所述程序时实现如下方法：

按照目标时间周期生成验证口令；

发出连接信号，所述连接信号携带有当前生效的验证口令；

将携带有所述验证口令的收款请求发送给服务端，以供所述服务端对便携设备发起的支付请求中携带的验证口令进行验证后响应所述收款请求。

根据本说明书实施例的第九方面，提供一种服务器，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，所述处理器执行所述程序时实现如下方法：

接收便携设备发起的携带有验证口令的支付请求，其中，所述验证口令是所述便携设备检测目标设备发出的连接信号中获取到的；

接收所述目标设备发起的携带有验证口令的收款请求；

利用所述目标设备生成的验证口令对所述支付请求携带的验证口令进行验证；

根据验证结果确定对所述支付请求和所述收款请求的响应结果。

本说明书的实施例提供的技术方案可以包括以下有益效果：

本说明书实施例中，便携设备可以基于“检测到连接信号”和“设备处于目标姿态”确定用户希望发起一笔支付。因此，若用户需要支付，可以持便携设备靠近目标设备，以使便携设备能够检测到目标设备发出的连接信号。由于目标设备发出有携带验证口令的连接信号，便携设备可检测到该连接信号；另外，用户可令便携设备处于目标姿态，基于此，目标设备可认为用户要进行一笔支付，并发起携带有验证口令的支付请求。而目标设备也可以发起携带有所述验证口令的收款请求，服务端接收到支付请求和收款请求后，可根据目标设备生成的验证口令对支付请求中的验证口令进行验证，基于验证结果响应该支付请求和收款请求。本实施例中，用户可通过简单的操作即可进行一笔支付，支付过程方便快捷。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本说明书。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本说明书的实施例，并与说明书一起用于解释本说明书的原理。

图1是本说明书根据一示例性实施例示出的一种支付处理方法的场景图。

图2a是本说明书根据一示例性实施例示出的一种支付处理方法的流程图。

图2b是本说明书根据一示例性实施例示出的一种支付场景示意图。

图3是本说明书实施例支付处理装置所在便携设备/电子设备/服务器的一种硬件结构图。

图4是本说明书根据一示例性实施例示出的一种支付处理装置的框图。

图5是本说明书根据一示例性实施例示出的另一种支付处理装置的框图。

图6是本说明书根据一示例性实施例示出的另一种支付处理装置的框图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本说明书相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本说明书的一些方面相一致的装置和方法的例子。

在本说明书使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本说明书。在本说明书和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本说明书可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本说明书范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

在大部分移动支付场景中，收款方设备采用摄像头扫描用户提供的付款码，因此对摄像头的质量有一定的要求，若摄像头的质量较差、对焦较慢，可能会造成识别付款码较慢的情况，也可能会出现付款码与摄像头没有对准，需要用户调整便捷设备以更好地完成支付。

基于此，请参考图1所示，是本说明书根据一示例性实施例示出的一种支付处理方法的场景图，为了便于区分，本实施例将用户所持有的设备称为便携设备，图1中以智能手机为例，便携设备还可以是智能眼镜或智能手表等设备。在支付场景中，还涉及另一类与便携设备配合完成一笔支付的设备，本实施例称为目标设备，该目标设备可能被各类服务商户拥有，其可以部署在商户提供商业服务的物理区域内。例如，在线下商店场景，目标设备可以部署于商品结算区域，在交通出行场景，目标设备可以部署于公交车上、地铁出入口、火车出入口等。

本说明书实施例提出了一种支付方案，该方案可应用于如图1所示场景，便携设备可以基于“检测到连接信号”和“设备处于目标姿态”确定用户希望发起一笔支付。因此，若用户需要支付，可以持便携设备靠近目标设备，以使便携设备能够检测到目标设备发出的连接信号。由于目标设备发出有携带验证口令的连接信号，因此便携设备可检测到该连接信号；另外，用户可令便携设备处于目标姿态，基于此，目标设备可认为用户要进行一笔支付，并发起携带有验证口令的支付请求。而目标设备也可以发起携带有所述验证口令的收款请求，支付服务端接收到支付请求和收款请求后，可根据目标设备生成的验证口令对支付请求中的验证口令进行验证，基于验证结果响应该支付请求和收款请求。本实施例中，用户可通过简单的操作即可进行一笔支付，支付过程方便快捷。

如图2a所示，是本说明书根据一示例性实施例示出的一种支付处理方法的流程图，图2a中的支付服务端、便携设备和目标设备三者相互配合完成执行如下处理流程：

在步骤202中，目标设备按照目标时间周期生成验证口令。

在步骤204中，目标设备发出连接信号，所述连接信号携带有当前生效的验证口令。

在步骤206中，便携设备确定检测到携带有验证口令的连接信号。

在步骤208中，便携设备获取设备姿态参数。

在步骤210中，便携设备判断所述设备姿态参数是否匹配目标姿态。

在步骤212中，便携设备确定姿态参数匹配目标姿态，向服务端发起支付请求，所述支付请求携带有所述验证口令。

在步骤214中，服务端接收所述支付请求。

在步骤216中，目标设备向服务端发起携带有验证口令的收款请求。

在步骤218中，服务端接收目标设备发起的收款请求。

在步骤220中，服务端利用所述目标设备生成的验证口令对所述支付请求携带的验证口令进行验证。

在步骤222中，根据验证结果确定对所述支付请求和所述收款请求的响应结果。

本实施例中，目标设备可通过配置一验证口令生成器或运行一验证口令生成程序，从而可以按照目标时间周期生成验证口令，该目标时间周期可根据实际需要灵活配置，如60秒或120秒等。另一方面，目标设备还可配置有通信模块，该通信模块可发出携带有验证口令的连接信号，以供便携设备检测。可选的，所述通信模块可以是蓝牙、wi-fi(wirelessfidelity，无线保真)、近场通信、uwb(ultrawideband，一种无载波通信技术)或homerf(家庭射频)等通信模块。

本实施例中的支付场景中，便携设备的支付触发条件是：要求用户持有便携设备靠近目标设备以检测到连接信号，并控制便携设备处于目标姿态。也就是说，便携设备基于“检测到连接信号”和“设备处于目标姿态”确定用户希望发起一笔支付。因此，在本实施例在支付场景中，若用户需要支付，用户可以手持便携设备靠近目标设备，以使便携设备能够检测到目标设备发起的连接信号。由于目标设备发出有携带验证口令的连接信号，因此便携设备可检测到该连接信号，基于此，目标设备可以认为用户可能准备要进行一笔支付；另一方面，本实施例的支付方案可以预先与用户约定以某一种目标姿态作为支付的触发条件。该目标姿态可以是“摇一摇”、处于平放状态、处于竖直状态、竖直状态下摇动或平放状态下摇动等等。

若用户按照目标姿态的要求，使便携设备处于该目标姿态，则便携设备可发起支付请求。具体的，便携设备检测自身是否处于目标姿态的过程，可以是便携设备基于自身所配置的陀螺仪、姿态传感器、角度传感器或加速度传感器等检测设备姿态参数，例如设备的朝向参数、三轴方向参数、三轴加速度参数或三轴角速度参数，基于这些设备姿态参数及设备姿态参数的变化，便携设备可判断自身是否处于目标姿态。基于上述判断，便携设备在检测到连接信号和自身匹配目标姿态的情况下，可以认为用户希望进行支付操作，便携设备向服务端发起支付请求，其中，由于便携设备检测得到目标设备发出的连接信号，因此可以获得连接信号中携带的验证口令，并使支付请求携带该验证口令。

从服务端的角度来看，服务端可以接收到便携设备发起的携带有验证口令的支付请求，而服务端接收到该支付请求后，需要与目标设备进行验证，以确定该笔交易是在目标设备与便携设备之间发生。由于服务端会接收到较多的便携设备与目标设备之间的支付处理，验证的目的之一是为了防止支付处理出错。而目标设备作为本次支付中的收款设备，目标设备可以发出携带有验证口令的收款请求，服务端接收后利用收款请求中的验证口令对支付请求中的验证口令进行验证，验证方式可以是验证所述目标设备生成的验证口令与所述支付请求携带的验证口令是否匹配，可选的，可以是对比收款请求中的验证口令与支付请求中的验证口令是否相同。在另一些方式中，连接信号中携带的验证口令还可以是经过加密处理的验证口令数据，目标设备发送的验证口令也可以是经过加密处理，服务器与便携设备和目标设备共享同样加解密算法，可以提高服务器和目标设备、和便携设备之间数据交互的安全性。在验证口令经过加密处理的情况下，验证方式可以是判断解密后的验证口令是否匹配等等。

其中，目标设备生成的验证口令并携带于收款请求中发送给服务器，以使服务器知道目标设备与便携设备之间有一笔支付需要处理，可选的，实际应用中，在一些例子中可以是基于信号强度等方式检测有便携设备靠近后发送收款请求。在另一些例子中，可以是目标设备上实现有触发接口，通过该触发接口接收到用户触发的指令后发送收款请求。在其他例子中，还可以是服务端向目标设备发起验证口令发送请求，目标设备接收到服务端发起的验证口令发送请求后，将携带有所述验证口令的收款请求发送给服务端。其中，由于服务端需要查找到目标设备并发起请求，因此，目标设备发出的连接信号可携带有自身设备标识，而便携设备可以令支付请求携带该设备标识，从而使得服务端可以通过目标设备标识查找到目标设备。

可选的，收款请求中可携带有收款参数，例如目标设备的标识、收款金额、收款说明信息、收款方标识、收款方名称或收款时间等等。对应的，支付请求也可以携带有支付参数，支付参数可包括支付方账户信息、支付金额、支付方名称或支付说明信息等等。利用收款参数和支付参数，服务端可以响应所述支付请求和付款请求，响应方式可以是基于收款参数对支付方账户进行扣款，从而实现本次支付处理。在响应后，服务端可分别向所述便携设备和目标设备发送响应结果消息，该响应结果消息指示本次支付处理是否成功，或者是成功处理后的扣款结果，使得便携设备和目标设备可以获取支付处理结果。

其中，本实施例中的处理流程中涉及对连接信号的检测，检测的过程需要由便携设备中的通信模块执行，在一些例子中，便携设备上所执行的流程可以由便携设备上所安装的客户端实现，操作系统开放有权限给该客户端，以使通信模块在检测到连接信号后，可以通过操作系统提供给客户端，客户端可以获取到通信模块对连接信号的检测结果，进而执行支付处理方法。在一些例子中，例如android等操作系统，客户端运行于便携设备中，即使客户端于后台运行，基于此类操作系统所开放的权限，客户端于后台运行仍可获取到通信模块的检测结果。此种方式中，用户在需要支付时令便携设备靠近目标设备并令便携设备处于目标姿态即可，用户无需解锁便携设备并手动启动客户端，用户操作非常少，支付处理非常快速。

在另一些操作系统如ios等，客户端于后台运行后可能会被操作系统限制一些功能，也有可能被操作系统停止运行，因此，可以要求用户在需要支付的时候启动客户端，使客户端在前台运行，进而可以执行本实施例的支付处理方法。在另一些例子中，为了减少用户操作，客户端可以由操作系统唤醒后执行所述支付处理方法，客户端是在所述操作系统检测到所述连接信号后被唤醒。此种方式中，可以基于操作系统所提供的接口，客户端可以向操作系统申请该权限。作为例子，连接信号可以是ibeacon信号，基于ios系统的设备可以支持ibeacon信号的检测，即使客户端没有运行，操作系统可基于客户端的预先申请，在操作系统检测到客户端申请的ibeacon信号被检测到后，操作系统会唤醒客户端，使客户端可以被唤醒后执行后续的支付处理，此种方式下，用户不需要解锁便携设备并手动启动客户端，用户操作非常少，支付处理非常快速。其中，以ios系统为例，客户端向操作系统申请ibeacon信号的检测，申请过程需开通如下两个定位权限：self.locationmanagerrequestalwaysauthorization以及nslocationalwaysusagedescription。

相应的，目标设备需要发出ibeacon信号，在一些例子中，目标设备可以配置ibeacon信号模块，在另一些例子中，若目标设备是配置普通蓝牙模块的设备，可通过软件配置，令目标设备按照ibeacon信号的头部格式(ibeacon信号的头部是0201061aff)发出蓝牙信号，从而达到模拟ibeacon信号的目的。而便携设备在检测连接信号时，检测到以ibeacon信号的头部格式发出的连接信号，进而确定检测到ibeacon信号。

本说明书实施例可应用于多种场景，接下来通过三个应用场景进行举例说明。

第一种、公交场景(以固定计费为例)

本实施例的公交场景，以固定计费为例进行说明，本实施例的目标设备可部署于公交车上。目标设备作为收款设备，可以与服务端保持网络连接，并且，服务端可预先记录目标设备的相关信息，例如设备标识或该设备对应的扣款费用等收款参数(本实施例是固定计费场景，扣款费用等支付参数可预先由服务端记录)。目标设备可以按照目标时间周期生成验证口令，目标设备还可配置有通信模块，该通信模块可发出携带有验证口令和目标设备标识的连接信号，以供便携设备检测。

用户的便携设备(如智能手机，或者智能手表等可穿戴设备)可安装有第三方支付app、用于提供地铁乘坐服务等app。用户上公交车后，用户可令便携设备靠近目标设备，以使便携设备能够检测到目标设备发起的连接信号。用户按照目标姿态(如“摇一摇”或手机平放等)的要求，使便携设备处于该目标姿态，则便携设备安装的app可发起支付请求，其中，支付请求可携带有验证口令和目标设备标识。

服务端接收到支付请求后，根据支付请求中携带的目标设备标识查找到目标设备，向目标设备发起验证口令请求。目标设备接收后，确定服务端当前正处理一笔支付，由于目标设备本身是作为公交车的收款设备，因此目标设备向服务端发起收款请求，该收款请求携带有验证口令。服务端接收后，对所述支付请求携带的验证口令进行验证，若验证通过，服务端将执行支付处理。本说明书实施例中，服务端可查询到目标设备的收款参数，也可以基于便携设备所发起的支付请求确定支付方账户，进而基于收款参数对支付方账户进行扣款。在成功处理后，分别向所述便携设备和目标设备发送响应结果消息。

第二种、地铁场景(以分段计费为例)

一些地铁场景中采用分段计费的方式，此种方式需要知悉用户的入站信息和出站信息。在此类场景中，如图2b所示，本实施例的目标设备可配置于站点的出入口，电子设备可作为控制出入闸的设备；用户的便携设备可安装有第三方支付app或提供地铁乘坐服务等app。在入口处，用户可令便携设备靠近入口的目标设备，以使便携设备能够检测到目标设备发起的连接信号，用户按照目标姿态(如“摇一摇”等)的要求，使便携设备处于该目标姿态，则便携设备安装的app可发起支付请求，其中，支付请求可携带有验证口令和目标设备标识。

服务端接收到支付请求后，根据支付请求的目标设备标识查找到目标设备，向目标设备发起验证口令请求。目标设备接收后，向服务端发起收款请求，该收款请求携带有验证口令。其中，收款请求可携带收款参数，例如包括目标设备的入站信息等。

服务端接收后，对所述支付请求携带的验证口令进行验证；另一方面，服务端通过收款请求所携带的入站信息，知道用户此时是入站，可暂不进行响应。

待用户出站后，用户可同样于出口处采用相同方式，令便携设备靠近出口的目标设备并使便携设备处于目标姿态后发出支付请求。同样，服务端接收到支付请求后，根据支付请求的目标设备标识查找到出口的目标设备，向出口的目标设备发起验证口令请求。出口的目标设备向服务端发起收款请求，该收款请求携带有验证口令。其中，收款请求可携带收款参数，例如包括目标设备的出站信息等。

最后，服务端基于入站信息和出站信息计算扣款费用后，基于所述收款参数对支付方账户进行扣款。在成功处理后，分别向所述便携设备和目标设备发送响应结果消息。

第三种、线下支付

本实施例中，目标设备可部署于商店的结算区域，用户的便携设备可安装有第三方支付app、用于提供地铁乘坐服务等app。若用户购买商品需要结算，用户可令便携设备靠近目标设备，以使便携设备能够检测到目标设备发起的连接信号。用户按照目标姿态(如“摇一摇”等)的要求，使便携设备处于该目标姿态，则便携设备安装的app可发起支付请求，其中，支付请求可携带有验证口令和目标设备标识。

同时，商店的收款人员可通过目标设备提供的触发接口(该触发接口具体可以是目标设备上的物理按键、或者是设备屏幕上提供的可供触发的选项等等)自动触发目标设备向服务端发起收款请求，该收款请求可携带有扣款费用等收款参数。

服务端接收到支付请求和收款请求后，对所述支付请求携带的验证口令进行验证，若验证通过，服务端将执行支付处理，基于所述收款参数对支付方账户进行扣款。在成功处理后，分别向所述便携设备和目标设备发送响应结果消息。

本说明书支付处理装置的实施例可以应用在便携设备/目标设备/服务器上。装置实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在数据交互的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言，如图3所示，为本说明书实施例支付处理装置所在便携设备/目标设备/服务器的一种硬件结构图，除了图3所示的处理器310、内存330、网络接口320、以及非易失性存储器340之外，实施例中装置331所在的便携设备/目标设备/服务器，通常根据该便携设备/目标设备/服务器的实际功能，还可以包括其他硬件，对此不再赘述。

如图4所示，图4是本说明书根据一示例性实施例示出的一种支付处理装置，所述装置包括：

姿态参数获取模块41，用于：确定检测到携带有验证口令的连接信号后，获取设备姿态参数，所述连接信号由目标设备发出；

支付发起模块42，用于：若所述设备姿态参数匹配目标姿态，向服务端发起支付请求，所述支付请求携带有所述验证口令，以供所述服务端根据所述目标设备生成的验证口令对所述支付请求携带的验证口令进行验证后响应所述支付请求。

可选的，所述连接信号包括：ibeacon信号。

可选的，所述装置应用于客户端，所述客户端由操作系统唤醒后执行所述支付处理方法，所述客户端是在所述操作系统检测到所述连接信号后被唤醒。

可选的，所述支付请求还携带有支付参数。

可选的，所述连接信号还携带有目标设备标识，所述支付请求还携带有所述目标设备标识。

如图5所示，图5是本说明书根据一示例性实施例示出的一种支付处理装置，所述装置包括：

口令生成模块51，用于：按照目标时间周期生成验证口令；

信号发出模块52，用于：发出连接信号，所述连接信号携带有当前生效的验证口令；

收款发起模块53，用于：将携带有所述验证口令的收款请求发送给服务端，以供所述服务端对便携设备发起的支付请求中携带的验证口令进行验证后响应所述收款请求。

可选的，所述收款发起模块，还用于：在所述将所述验证口令发送给服务端之前，接收服务端发起的验证口令发送请求。

可选的，所述收款请求还携带有收款参数。

可选的，所述连接信号包括：ibeacon信号。

如图6所示，图6是本说明书根据一示例性实施例示出的一种支付处理装置，所述装置包括：

支付请求接收模块61，用于：接收便携设备发起的携带有验证口令的支付请求，其中，所述验证口令是所述便携设备检测目标设备发出的连接信号中获取到的；

收款请求接收模块62，用于：接收所述目标设备发起的携带有验证口令的收款请求；

验证模块63，用于：利用所述目标设备生成的验证口令对所述支付请求携带的验证口令进行验证；

响应模块64，用于：根据验证结果确定对所述支付请求和所述收款请求的响应结果。

可选的，所述验证模块，还用于：

验证所述目标设备生成的验证口令与所述支付请求携带的验证口令是否匹配。

可选的，所述收款请求接收模块，还用于：在接收所述目标设备发起的携带有验证口令的收款请求前，向所述目标设备发起验证口令发送请求。

可选的，所述支付请求还携带有支付参数，所述支付参数包括支付方账户信息，所述收款请求还携带有收款参数；所述响应结果包括：基于所述收款参数对支付方账户进行扣款的扣款结果。

可选的，还包括：分别向所述便携设备和目标设备发送响应结果消息。

本说明书实施例还提供一种便携设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，所述处理器执行所述程序时实现如下方法：

确定检测到携带有验证口令的连接信号后，获取设备姿态参数，所述连接信号由目标设备发出；

若所述设备姿态参数匹配目标姿态，向服务端发起支付请求，所述支付请求携带有所述验证口令，以供所述服务端根据所述目标设备生成的验证口令对所述支付请求携带的验证口令进行验证后响应所述支付请求。

本说明书实施例还提供一种目标设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，所述处理器执行所述程序时实现如下方法：

按照目标时间周期生成验证口令；

发出连接信号，所述连接信号携带有当前生效的验证口令；

将携带有所述验证口令的收款请求发送给服务端，以供所述服务端对便携设备发起的支付请求中携带的验证口令进行验证。

本说明书实施例还提供一种服务器，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，所述处理器执行所述程序时实现如下方法：

接收便携设备发起的携带有验证口令的支付请求，其中，所述验证口令是所述便携设备检测电子设备发出的连接信号中获取到的；

接收所述电子设备发起的携带有验证口令的收款请求；

利用所述电子设备生成的验证口令对所述支付请求携带的验证口令进行验证；

根据验证结果确定是否响应所述支付请求和所述收款请求。

上述支付处理装置中各个模块的功能和作用的实现过程具体详见上述支付处理方法中对应步骤的实现过程，在此不再赘述。

对于支付处理装置实施例而言，由于其基本对应于支付处理方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理模块，即可以位于一个地方，或者也可以分布到多个网络模块上。可以根据实际的需要选择其中的部分或者全部模块来实现本说明书方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

本领域技术人员在考虑说明书及实践这里申请的发明后，将容易想到本说明书的其它实施方案。本说明书旨在涵盖本说明书的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本说明书的一般性原理并包括本说明书未申请的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本说明书的真正范围和精神由下面的权利要求指出。

应当理解的是，本说明书并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本说明书的范围仅由所附的权利要求来限制。

以上所述仅为本说明书的较佳实施例而已，并不用以限制本说明书，凡在本说明书的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本说明书保护的范围之内。