WO2020019985A1 - 支付处理方法、装置、服务器及设备 - Google Patents

支付处理方法、装置、服务器及设备 Download PDF

Info

Publication number
WO2020019985A1
WO2020019985A1 PCT/CN2019/095521 CN2019095521W WO2020019985A1 WO 2020019985 A1 WO2020019985 A1 WO 2020019985A1 CN 2019095521 W CN2019095521 W CN 2019095521W WO 2020019985 A1 WO2020019985 A1 WO 2020019985A1
Authority
WO
WIPO (PCT)
Prior art keywords
payment
verification password
payment request
request
target device
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.)
Ceased
Application number
PCT/CN2019/095521
Other languages
English (en)
French (fr)
Inventor
黄珠唐
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Alibaba Group Holding Ltd
Original Assignee
Alibaba Group Holding Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Alibaba Group Holding Ltd filed Critical Alibaba Group Holding Ltd
Publication of WO2020019985A1 publication Critical patent/WO2020019985A1/zh
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/327—Short range or proximity payments by means of M-devices
    • G06Q20/3278—RFID or NFC payments by means of M-devices

Definitions

  • This specification relates to the field of Internet technologies, and in particular, to a payment processing method, device, server, and device.
  • a user can use a mobile terminal such as a smart phone to install an APP (application) with a payment function. If payment is required, the APP can display a ride code for paying the fare.
  • the ride code carries the Payment related data.
  • the payment device on the bus can identify the ride code through a camera or scanning device, and complete the payment by obtaining the data carried in the ride code. Based on this, a more convenient payment scheme needs to be provided.
  • this specification provides a payment processing method, device, server, and device.
  • a payment processing method includes:
  • connection signal carrying a verification password After determining that a connection signal carrying a verification password is detected, acquiring a device attitude parameter, the connection signal being sent by a target device;
  • the device posture parameter matches the target posture, a payment request is initiated to the server, and the payment request carries the verification password, so that the server can send the payment request to the The verification password responds to the payment request after verification.
  • connection signal includes an iBeacon signal.
  • the method is applied to a client, and the client executes the payment processing method after being awakened by an operating system, and the client is awakened after the operating system detects the connection signal.
  • connection signal further carries a target device identifier
  • payment request further carries the target device identifier
  • the payment request further carries payment parameters.
  • a payment processing method includes:
  • connection signal carrying a currently valid authentication password
  • the method before the sending the verification password to the server, the method further includes:
  • the collection request further carries a collection parameter.
  • connection signal includes an iBeacon signal.
  • a payment processing method includes:
  • a response result to the payment request and the collection request is determined according to the verification result.
  • the verifying the verification password carried in the payment request by using the verification password generated by the target device includes:
  • the method before the receiving a payment request with an authentication password initiated by the target device, the method includes:
  • the payment request further carries the target device identifier, and the target device is found by using the target device identifier.
  • the payment request further carries payment parameters
  • the payment parameters include payer account information
  • the payment request also carries payment parameters
  • the response result includes: payment based on the payment parameters The debit result of the debit account.
  • the method further includes: sending a response result message to the portable device and the target device, respectively.
  • a payment processing device including:
  • An attitude parameter acquisition module configured to obtain a device attitude parameter after determining that a connection signal carrying a verification password is detected, where the connection signal is sent by a target device;
  • a payment initiation module configured to: if the device posture parameter matches the target posture, initiate a payment request to the server, where the payment request carries the verification password for the server to generate the verification password based on the target device And responding to the payment request after verifying the verification password carried in the payment request.
  • connection signal includes an iBeacon signal.
  • the device is applied to a client, and the client executes the payment processing method after being awakened by an operating system, and the client is awakened after the operating system detects the connection signal.
  • the payment request further carries payment parameters.
  • a payment processing device including:
  • the password generation module is used to: generate a verification password according to a target time period
  • a signal sending module configured to: send a connection signal, where the connection signal carries a currently valid verification password
  • a collection initiation module configured to send a collection request carrying the verification password to a server for the server to respond to the collection after verifying the verification password carried in the payment request initiated by the portable device request.
  • the payment initiation module is further configured to: before sending the verification password to the server, receive a verification password sending request initiated by the server.
  • the collection request further carries a collection parameter.
  • connection signal includes an iBeacon signal.
  • a payment processing device including:
  • a payment request receiving module configured to receive a payment request carried by a portable device and carrying a verification password, wherein the verification password is obtained from a connection signal sent by the portable device to detect a target device;
  • a collection request receiving module configured to receive a collection request initiated by the target device and carrying a verification password
  • a verification module configured to use the verification password generated by the target device to verify the verification password carried in the payment request
  • the response module is configured to determine a response result to the payment request and the collection request according to a verification result.
  • the verification module is further configured to:
  • the payment request further carries payment parameters
  • the payment parameters include payer account information
  • the payment request also carries payment parameters
  • the response result includes: payment based on the payment parameters The debit result of the debit account.
  • the apparatus further includes a sending module, configured to send a response result message to the portable device and the target device, respectively.
  • a sending module configured to send a response result message to the portable device and the target device, respectively.
  • a portable device including a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein the processor implements the program as follows method:
  • connection signal carrying a verification password After determining that a connection signal carrying a verification password is detected, acquiring a device attitude parameter, the connection signal being sent by a target device;
  • the device posture parameter matches the target posture, a payment request is initiated to the server, and the payment request carries the verification password, so that the server can send the payment request to the The verification password responds to the payment request after verification.
  • an electronic device including a memory, a processor, and a computer program stored on the memory and executable on the processor, where the processor implements the program as follows method:
  • connection signal carrying a currently valid authentication password
  • a server including a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein the processor implements the following method when the program is executed. :
  • a response result to the payment request and the collection request is determined according to the verification result.
  • the portable device may determine that the user wishes to initiate a payment based on the “connection signal detected” and “the device is in a target posture”. Therefore, if the user needs to pay, the portable device can be held close to the target device so that the portable device can detect the connection signal sent by the target device. Because the target device sends a connection signal with an authentication password, the portable device can detect the connection signal; in addition, the user can place the portable device in the target posture. Based on this, the target device can think that the user wants to make a payment and initiate the Verify the password payment request. The target device can also initiate a payment request carrying the verification password.
  • the server After receiving the payment request and the payment request, the server can verify the verification password in the payment request according to the verification password generated by the target device, and based on the verification result Respond to the payment request and payment request.
  • the user can make a payment with a simple operation, and the payment process is convenient and fast.
  • Fig. 1 is a scene diagram showing a payment processing method according to an exemplary embodiment of the present specification.
  • Fig. 2A is a flowchart illustrating a payment processing method according to an exemplary embodiment of the present specification.
  • Fig. 2B is a schematic diagram of a payment scenario according to an exemplary embodiment of the present specification.
  • FIG. 3 is a hardware structure diagram of a portable device / electronic device / server where a payment processing device according to an embodiment of the present specification is located.
  • Fig. 4 is a block diagram of a payment processing device according to an exemplary embodiment of the present specification.
  • Fig. 5 is a block diagram of another payment processing device according to an exemplary embodiment of the present specification.
  • Fig. 6 is a block diagram of another payment processing apparatus according to an exemplary embodiment of the present specification.
  • first, second, third, etc. may be used in this specification to describe various information, the information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other.
  • first information may also be referred to as the second information, and similarly, the second information may also be referred to as the first information.
  • word “if” as used herein can be interpreted as “at” or "when” or "in response to determination”.
  • the payee device uses the camera to scan the payment code provided by the user, so there are certain requirements for the quality of the camera. If the quality of the camera is poor and the focus is slow, it may cause the recognition of the payment code to be slow. It may also happen that the payment code is not aligned with the camera, and users need to adjust the convenient device to better complete the payment.
  • FIG. 1 is a scenario diagram of a payment processing method according to an exemplary embodiment of this specification.
  • this embodiment refers to a device held by a user as a portable device.
  • the smart phone in 1 is taken as an example.
  • the portable device may also be a device such as smart glasses or a smart watch.
  • This embodiment is called a target device.
  • This target device may be owned by various service merchants, and it can be deployed on the physical within the area. For example, in an offline store scenario, the target device can be deployed in a commodity settlement area. In a traffic travel scenario, the target device can be deployed on a bus, subway entrance, train entrance, etc.
  • the embodiment of the present specification proposes a payment solution, which can be applied to the scenario shown in FIG. 1, and the portable device can determine that the user wishes to initiate a payment based on the “connection signal detected” and “the device is in a target posture”. Therefore, if the user needs to pay, the portable device can be held close to the target device so that the portable device can detect the connection signal sent by the target device. Because the target device sends a connection signal with an authentication password, the portable device can detect the connection signal; in addition, the user can place the portable device in the target posture. Based on this, the target device can think that the user wants to make a payment and initiate the carrying There is a payment request to verify the password. The target device can also initiate a payment request carrying the verification password.
  • the payment server After receiving the payment request and the payment request, the payment server can verify the verification password in the payment request according to the verification password generated by the target device. The result responds to the payment request and the collection request.
  • the user can make a payment with a simple operation, and the payment process is convenient and fast.
  • FIG. 2A it is a flowchart of a payment processing method shown in this specification according to an exemplary embodiment.
  • the payment server, portable device, and target device in FIG. 2A cooperate with each other to execute the following processing flow:
  • step 202 the target device generates a verification password according to a target time period.
  • step 204 the target device sends a connection signal, where the connection signal carries a currently valid authentication password.
  • step 206 the portable device determines that a connection signal carrying an authentication password is detected.
  • step 208 the portable device acquires a device attitude parameter.
  • step 210 the portable device determines whether the device posture parameter matches the target posture.
  • step 212 the portable device determines that the posture parameter matches the target posture, and initiates a payment request to the server, where the payment request carries the verification password.
  • step 214 the server receives the payment request.
  • step 216 the target device initiates a payment request carrying a verification password to the server.
  • step 218 the server receives a payment request initiated by the target device.
  • step 220 the server uses the verification password generated by the target device to verify the verification password carried in the payment request.
  • step 222 a response result to the payment request and the collection request is determined according to the verification result.
  • the target device can be configured with a verification password generator or run a verification password generation program, so that the verification password can be generated according to a target time period, which can be flexibly configured according to actual needs, such as 60 seconds or 120 seconds. Wait.
  • the target device may also be configured with a communication module, which can send a connection signal carrying an authentication password for detection by the portable device.
  • the communication module may be a communication module such as Bluetooth, Wi-Fi (Wireless Fidelity), near field communication, UWB (Ultra Wideband), or HomeRF (Home Radio Frequency).
  • the payment trigger condition of the portable device is that the user is required to hold the portable device close to the target device to detect the connection signal, and control the portable device to be in the target posture. That is, the portable device determines that the user wishes to initiate a payment based on the "connection signal detected" and "the device is in a target posture". Therefore, in the payment scenario in this embodiment, if the user needs to pay, the user can hold the portable device close to the target device, so that the portable device can detect the connection signal initiated by the target device. Because the target device sends a connection signal with an authentication password, the portable device can detect the connection signal. Based on this, the target device can think that the user may be ready to make a payment.
  • the payment scheme in this embodiment can be pre-empted. It is agreed with the user to use a certain target posture as the trigger condition for payment.
  • the target posture may be "shake-shake", be in a flat state, be in a vertical state, shake in a vertical state or shake in a flat state, and so on.
  • the portable device may initiate a payment request.
  • the process of the portable device detecting whether it is in the target posture may be the portable device's detection of the device's attitude parameters based on its configured gyroscope, attitude sensor, angle sensor, or acceleration sensor, such as the device's orientation parameters and three-axis direction parameters. , Three-axis acceleration parameters or three-axis angular velocity parameters. Based on these device attitude parameters and changes in the device attitude parameters, the portable device can determine whether it is in the target attitude.
  • the portable device when the portable device detects the connection signal and it matches the target posture, it can be considered that the user wants to perform a payment operation, and the portable device initiates a payment request to the server. Among them, the portable device detects the connection signal sent by the target device. , So the authentication password carried in the connection signal can be obtained, and the payment request carries the authentication password.
  • the server can receive a payment request with a verification password initiated by the portable device, and after receiving the payment request, the server needs to verify with the target device to determine that the transaction is on the target device With portable devices. Since the server will receive more payment processing between the portable device and the target device, one of the purposes of the verification is to prevent payment processing errors.
  • the target device is the receiving device in this payment.
  • the target device can send a receiving request with a verification password.
  • the server uses the verification password in the request to verify the verification password in the payment request. It may be to verify whether the verification password generated by the target device matches the verification password carried in the payment request. Optionally, it may be compared whether the verification password in the payment request is the same as the verification password in the payment request.
  • the authentication password carried in the connection signal may also be encrypted authentication password data, and the authentication password sent by the target device may also be encrypted.
  • the server shares the same encryption and decryption algorithm with the portable device and the target device. It can improve the security of data interaction between the server and the target device, and the portable device.
  • the verification method may be to determine whether the decrypted verification password matches or not.
  • the verification password generated by the target device is carried in the collection request and sent to the server, so that the server knows that there is a payment between the target device and the portable device that needs to be processed.
  • it can be Send a payment request after detecting that a portable device is approaching based on signal strength and other methods.
  • a trigger interface may be implemented on the target device, and a payment request is sent after receiving a user-triggered instruction through the trigger interface.
  • the server may also send a verification password sending request to the target device. After receiving the verification password sending request initiated by the server, the target device sends a payment request carrying the verification password to the server.
  • the connection signal sent by the target device can carry its own device identification, and the portable device can make the payment request carry the device identification, so that the server can pass the target device identification Find the target device.
  • the collection request may carry collection parameters, such as the identification of the target device, the collection amount, the description information of the collection, the identification of the collection party, the name of the collection party, or the collection time, and so on.
  • the payment request may also carry payment parameters, and the payment parameters may include the payer account information, the payment amount, the payer name or payment description information, and the like.
  • the server can respond to the payment request and payment request, and the response method can be to debit the payer's account based on the payment parameters, thereby realizing the current payment processing.
  • the server can send a response result message to the portable device and the target device respectively, and the response result message indicates whether the current payment process is successful or the result of the deduction after the successful processing, so that the portable device and the target device can Get payment processing results.
  • the processing flow in this embodiment involves detection of a connection signal.
  • the detection process needs to be performed by a communication module in the portable device.
  • the flow executed on the portable device may be performed by the portable device.
  • Client implementation. The operating system has permission to the client, so that after the communication module detects the connection signal, it can be provided to the client through the operating system.
  • the client can obtain the detection result of the communication module on the connection signal, and then execute Payment processing method.
  • the client runs on a portable device. Even if the client runs in the background, the client can still obtain the detection result of the communication module based on the permissions opened by such operating systems. . In this way, the user can bring the portable device close to the target device and place the portable device in the target posture when the user needs to pay.
  • the user does not need to unlock the portable device and manually start the client.
  • the user has very few operations and payment processing is very fast.
  • the client may execute the payment processing method after being awakened by the operating system, and the client is awakened after the operating system detects the connection signal. In this way, the client can request the permission from the operating system based on the interface provided by the operating system.
  • the connection signal can be an iBeacon signal. IOS-based devices can support the detection of iBeacon signals.
  • the operating system can detect the iBeacon signal applied by the client based on the client's pre-application. After that, the operating system will wake up the client so that the client can perform subsequent payment processing after being awakened. In this way, the user does not need to unlock the portable device and manually start the client. There are very few user operations and payment processing is very fast. Among them, taking the iOS system as an example, the client applies to the operating system for the detection of the iBeacon signal.
  • the application process needs to enable the following two positioning permissions: self.locationManager, requestAlwaysAuthorization, and NSLocationAlwaysUsageDescription.
  • the target device needs to send an iBeacon signal.
  • the target device can be configured with an iBeacon signal module.
  • the signal header format (iBeacon signal's head is 02, 01, 06, 1A, and FF) sends a Bluetooth signal to achieve the purpose of simulating iBeacon signals.
  • the portable device detects the connection signal, it detects the connection signal sent in the format of the iBeacon signal header, and then determines that the iBeacon signal is detected.
  • the first type of bus scenario (take fixed billing as an example)
  • the bus scenario in this embodiment is described by taking a fixed charge as an example.
  • the target device in this embodiment can be deployed on a bus.
  • the target device as the payment device, can maintain a network connection with the server.
  • the server can record the relevant information of the target device in advance, such as the device identification or the charge parameters such as the charge fee corresponding to the device (this embodiment is a fixed meter).
  • Payment parameters such as fee scenarios and deduction fees can be recorded in advance by the server).
  • the target device can generate the authentication password according to the target time period.
  • the target device can also be configured with a communication module, which can send a connection signal carrying the authentication password and the target device identification for portable device detection.
  • a user's portable device (such as a smart phone or a wearable device such as a smart watch) may be installed with a third-party payment APP and an APP for providing subway ride services. After the user gets on the bus, the user can bring the portable device closer to the target device so that the portable device can detect the connection signal initiated by the target device. The user sets the portable device to the target posture according to the requirements of the target posture (such as "shake" or lay the mobile phone flat, etc.), and the APP installed on the portable device can initiate a payment request, wherein the payment request can carry a verification password and a target Equipment Identity.
  • the server After receiving the payment request, the server finds the target device according to the target device identifier carried in the payment request, and initiates a password verification request to the target device. After receiving the target device, it is determined that the server is currently processing a payment. Since the target device itself is a payment device for the bus, the target device initiates a payment request to the server, and the payment request carries a verification password. After receiving, the server verifies the verification password carried in the payment request. If the verification succeeds, the server will perform payment processing. In the embodiment of this specification, the server can query the payment parameters of the target device, or determine the payer account based on the payment request initiated by the portable device, and then deduct the payer account based on the payment parameters. After successful processing, a response result message is sent to the portable device and the target device, respectively.
  • the second type the subway scenario (take segmented billing as an example)
  • the target device of this embodiment can be configured at the entrance of the station, and the electronic device can be used as a device to control entrance and exit; the user's portable device can be installed with a third-party payment app or provide subway ride Services and other apps.
  • the user can bring the portable device close to the target device at the entrance so that the portable device can detect the connection signal initiated by the target device.
  • the user can place the portable device at the target position according to the requirements of the target posture (such as "shake").
  • Target posture the APP installed on the portable device may initiate a payment request, wherein the payment request may carry a verification password and a target device identification.
  • the server After receiving the payment request, the server finds the target device according to the target device identifier of the payment request, and initiates a password verification request to the target device. After receiving, the target device initiates a collection request to the server, and the collection request carries a verification password.
  • the collection request may carry collection parameters, such as the inbound information of the target device.
  • the server After receiving, the server verifies the verification password carried in the payment request. On the other hand, the server knows that the user is inbound at this time through the inbound information carried in the payment request, and may not respond at this time.
  • the user can also use the same method at the exit to make the portable device close to the target device of the exit and place the portable device in the target posture to issue a payment request.
  • the server finds the target device of the exit according to the target device identifier of the payment request, and initiates a password verification request to the target device of the exit.
  • the export target device initiates a collection request to the server, and the collection request carries a verification password.
  • the collection request may carry collection parameters, such as outbound information of the target device.
  • the server calculates the deduction fee based on the inbound and outbound information, it deducts the payer account based on the collection parameters. After successful processing, a response result message is sent to the portable device and the target device, respectively.
  • the target device can be deployed in the settlement area of the store, and the user's portable device can be installed with a third-party payment APP and an APP for providing subway ride services. If the user needs to settle the purchase of the product, the user can bring the portable device close to the target device so that the portable device can detect the connection signal initiated by the target device. The user sets the portable device to the target posture according to the requirements of the target posture (such as "shake a shake", etc.), and the APP installed on the portable device can initiate a payment request, wherein the payment request can carry a verification password and a target device identification.
  • the requirements of the target posture such as "shake a shake", etc.
  • the store's payee can automatically trigger the target device to the service through the trigger interface provided by the target device (the trigger interface can be a physical button on the target device, or an option available on the device screen that can be triggered, etc.)
  • the terminal initiates a collection request, and the collection request may carry collection parameters such as a deduction fee.
  • the server After the server receives the payment request and the payment request, it verifies the verification password carried in the payment request. If the verification succeeds, the server will perform payment processing and charge the payer account based on the payment parameters. After successful processing, a response result message is sent to the portable device and the target device, respectively.
  • the embodiment of the payment processing apparatus of the present specification can be applied to a portable device / target device / server.
  • the device embodiments may be implemented by software, or by hardware or a combination of software and hardware. Taking software implementation as an example, as a device in a logical sense, it is formed by reading the corresponding computer program instructions in the non-volatile memory into the memory and running the processor through the data interaction processor.
  • FIG. 3 this is a hardware structure diagram of the portable device / target device / server where the payment processing device according to the embodiment of the present specification is located, except for the processor 310, the memory 330, and the network interface shown in FIG. 320, and the non-volatile memory 340, the portable device / target device / server where the device 331 is located in the embodiment usually includes other hardware according to the actual function of the portable device / target device / server. More details.
  • FIG. 4 is a payment processing device according to an exemplary embodiment of the present specification.
  • the device includes:
  • An attitude parameter obtaining module 41 is configured to obtain a device attitude parameter after determining that a connection signal carrying an authentication password is detected, where the connection signal is sent by a target device;
  • a payment initiation module 42 is configured to: if the device posture parameter matches the target posture, initiate a payment request to the server, where the payment request carries the verification password for the server to perform verification based on the target device The password responds to the payment request after verifying the verification password carried in the payment request.
  • connection signal includes an iBeacon signal.
  • the device is applied to a client, and the client executes the payment processing method after being awakened by an operating system, and the client is awakened after the operating system detects the connection signal.
  • the payment request further carries payment parameters.
  • connection signal further carries a target device identifier
  • payment request further carries the target device identifier
  • FIG. 5 is a payment processing device according to an exemplary embodiment of the present specification.
  • the device includes:
  • the password generating module 51 is configured to: generate a verification password according to a target time period;
  • the signal sending module 52 is configured to: send a connection signal, where the connection signal carries a currently valid verification password;
  • a collection initiation module 53 is configured to send a collection request carrying the verification password to a server for the server to respond to the collection after verifying the verification password carried in the payment request initiated by the portable device. Money request.
  • the payment initiation module is further configured to: before sending the verification password to the server, receive a verification password sending request initiated by the server.
  • the collection request further carries a collection parameter.
  • connection signal includes an iBeacon signal.
  • FIG. 6 is a payment processing device according to an exemplary embodiment of the present specification.
  • the device includes:
  • the payment request receiving module 61 is configured to receive a payment request with a verification password initiated by a portable device, where the verification password is obtained from a connection signal sent by the portable device to detect a target device;
  • a collection request receiving module 62 configured to: receive a collection request initiated by the target device and carrying a verification password;
  • a verification module 63 configured to use the verification password generated by the target device to verify the verification password carried in the payment request;
  • the response module 64 is configured to determine a response result to the payment request and the collection request according to a verification result.
  • the verification module is further configured to:
  • the payment request receiving module is further configured to: before receiving a payment request initiated by the target device and carrying a verification password, initiate a request for sending a verification password to the target device.
  • the payment request further carries payment parameters
  • the payment parameters include payer account information
  • the payment request also carries payment parameters
  • the response result includes: payment based on the payment parameters The debit result of the debit account.
  • the method further includes: sending a response result message to the portable device and the target device, respectively.
  • An embodiment of the present specification also provides a portable device including a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein the processor implements the following method when the program is executed:
  • connection signal carrying a verification password After determining that a connection signal carrying a verification password is detected, acquiring a device attitude parameter, the connection signal being sent by a target device;
  • the device posture parameter matches the target posture, a payment request is initiated to the server, and the payment request carries the verification password, so that the server can send the payment request to the The verification password responds to the payment request after verification.
  • An embodiment of the present specification further provides a target device, including a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein the processor implements the following method when executing the program:
  • connection signal carrying a currently valid authentication password
  • An embodiment of the present specification also provides a server, including a memory, a processor, and a computer program stored on the memory and executable on the processor.
  • the processor implements the following method when the program is executed:
  • the relevant part may refer to the description of the method embodiment.
  • the device embodiments described above are only schematic, and the modules described as separate components may or may not be physically separated, and the components displayed as modules may or may not be physical modules, which may be located in One place, or can be distributed to multiple network modules. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution in this specification. Those of ordinary skill in the art can understand and implement without creative efforts.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Telephonic Communication Services (AREA)
  • Telephone Function (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

本说明书提供一种支付处理方法、装置、服务器及设备，便携设备基于"检测到连接信号"和"设备处于目标姿态"确定用户希望发起一笔支付。因此，若用户需要支付，可以持便携设备靠近目标设备，以使便携设备能够检测到目标设备发出的连接信号。由于目标设备发出有携带验证口令的连接信号，因此便携设备可检测到该连接信号；另外，用户可令便携设备处于目标姿态，基于此，目标设备可认为用户要进行一笔支付，并发起携带有验证口令的支付请求。而目标设备也可以发起携带有所述验证口令的收款请求，服务端接收到支付请求和收款请求后，可根据目标设备生成的验证口令对支付请求中的验证口令进行验证，基于验证结果响应该支付请求和收款请求。

Description

支付处理方法、装置、服务器及设备 技术领域
本说明书涉及互联网技术领域，尤其涉及支付处理方法、装置、服务器及设备。
背景技术
随着互联网技术和终端技术的发展，在线下商店或交通出行等多种场景，移动支付已成为人们日常生活中的一种常见支付方式。以公交场景为例，用户可以使用智能手机等便携终端安装具有支付功能的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(Wireless Fidelity，无线保真)、近场通信、UWB(Ultra Wideband，一种无载波通信技术)或HomeRF(家庭射频)等通信模块。
本实施例中的支付场景中，便携设备的支付触发条件是：要求用户持有便携设备靠 近目标设备以检测到连接信号，并控制便携设备处于目标姿态。也就是说，便携设备基于“检测到连接信号”和“设备处于目标姿态”确定用户希望发起一笔支付。因此，在本实施例在支付场景中，若用户需要支付，用户可以手持便携设备靠近目标设备，以使便携设备能够检测到目标设备发起的连接信号。由于目标设备发出有携带验证口令的连接信号，因此便携设备可检测到该连接信号，基于此，目标设备可以认为用户可能准备要进行一笔支付；另一方面，本实施例的支付方案可以预先与用户约定以某一种目标姿态作为支付的触发条件。该目标姿态可以是“摇一摇”、处于平放状态、处于竖直状态、竖直状态下摇动或平放状态下摇动等等。
若用户按照目标姿态的要求，使便携设备处于该目标姿态，则便携设备可发起支付请求。具体的，便携设备检测自身是否处于目标姿态的过程，可以是便携设备基于自身所配置的陀螺仪、姿态传感器、角度传感器或加速度传感器等检测设备姿态参数，例如设备的朝向参数、三轴方向参数、三轴加速度参数或三轴角速度参数，基于这些设备姿态参数及设备姿态参数的变化，便携设备可判断自身是否处于目标姿态。基于上述判断，便携设备在检测到连接信号和自身匹配目标姿态的情况下，可以认为用户希望进行支付操作，便携设备向服务端发起支付请求，其中，由于便携设备检测得到目标设备发出的连接信号，因此可以获得连接信号中携带的验证口令，并使支付请求携带该验证口令。
从服务端的角度来看，服务端可以接收到便携设备发起的携带有验证口令的支付请求，而服务端接收到该支付请求后，需要与目标设备进行验证，以确定该笔交易是在目标设备与便携设备之间发生。由于服务端会接收到较多的便携设备与目标设备之间的支付处理，验证的目的之一是为了防止支付处理出错。而目标设备作为本次支付中的收款设备，目标设备可以发出携带有验证口令的收款请求，服务端接收后利用收款请求中的验证口令对支付请求中的验证口令进行验证，验证方式可以是验证所述目标设备生成的验证口令与所述支付请求携带的验证口令是否匹配，可选的，可以是对比收款请求中的验证口令与支付请求中的验证口令是否相同。在另一些方式中，连接信号中携带的验证口令还可以是经过加密处理的验证口令数据，目标设备发送的验证口令也可以是经过加密处理，服务器与便携设备和目标设备共享同样加解密算法，可以提高服务器和目标设备、和便携设备之间数据交互的安全性。在验证口令经过加密处理的情况下，验证方式可以是判断解密后的验证口令是否匹配等等。
其中，目标设备生成的验证口令并携带于收款请求中发送给服务器，以使服务器知道目标设备与便携设备之间有一笔支付需要处理，可选的，实际应用中，在一些例子中 可以是基于信号强度等方式检测有便携设备靠近后发送收款请求。在另一些例子中，可以是目标设备上实现有触发接口，通过该触发接口接收到用户触发的指令后发送收款请求。在其他例子中，还可以是服务端向目标设备发起验证口令发送请求，目标设备接收到服务端发起的验证口令发送请求后，将携带有所述验证口令的收款请求发送给服务端。其中，由于服务端需要查找到目标设备并发起请求，因此，目标设备发出的连接信号可携带有自身设备标识，而便携设备可以令支付请求携带该设备标识，从而使得服务端可以通过目标设备标识查找到目标设备。
可选的，收款请求中可携带有收款参数，例如目标设备的标识、收款金额、收款说明信息、收款方标识、收款方名称或收款时间等等。对应的，支付请求也可以携带有支付参数，支付参数可包括支付方账户信息、支付金额、支付方名称或支付说明信息等等。利用收款参数和支付参数，服务端可以响应所述支付请求和付款请求，响应方式可以是基于收款参数对支付方账户进行扣款，从而实现本次支付处理。在响应后，服务端可分别向所述便携设备和目标设备发送响应结果消息，该响应结果消息指示本次支付处理是否成功，或者是成功处理后的扣款结果，使得便携设备和目标设备可以获取支付处理结果。
其中，本实施例中的处理流程中涉及对连接信号的检测，检测的过程需要由便携设备中的通信模块执行，在一些例子中，便携设备上所执行的流程可以由便携设备上所安装的客户端实现，操作系统开放有权限给该客户端，以使通信模块在检测到连接信号后，可以通过操作系统提供给客户端，客户端可以获取到通信模块对连接信号的检测结果，进而执行支付处理方法。在一些例子中，例如Android等操作系统，客户端运行于便携设备中，即使客户端于后台运行，基于此类操作系统所开放的权限，客户端于后台运行仍可获取到通信模块的检测结果。此种方式中，用户在需要支付时令便携设备靠近目标设备并令便携设备处于目标姿态即可，用户无需解锁便携设备并手动启动客户端，用户操作非常少，支付处理非常快速。
在另一些操作系统如iOS等，客户端于后台运行后可能会被操作系统限制一些功能，也有可能被操作系统停止运行，因此，可以要求用户在需要支付的时候启动客户端，使客户端在前台运行，进而可以执行本实施例的支付处理方法。在另一些例子中，为了减少用户操作，客户端可以由操作系统唤醒后执行所述支付处理方法，客户端是在所述操作系统检测到所述连接信号后被唤醒。此种方式中，可以基于操作系统所提供的接口，客户端可以向操作系统申请该权限。作为例子，连接信号可以是iBeacon信号， 基于iOS系统的设备可以支持iBeacon信号的检测，即使客户端没有运行，操作系统可基于客户端的预先申请，在操作系统检测到客户端申请的iBeacon信号被检测到后，操作系统会唤醒客户端，使客户端可以被唤醒后执行后续的支付处理，此种方式下，用户不需要解锁便携设备并手动启动客户端，用户操作非常少，支付处理非常快速。其中，以iOS系统为例，客户端向操作系统申请iBeacon信号的检测，申请过程需开通如下两个定位权限：self.locationManager requestAlwaysAuthorization以及NSLocationAlwaysUsageDescription。
相应的，目标设备需要发出iBeacon信号，在一些例子中，目标设备可以配置iBeacon信号模块，在另一些例子中，若目标设备是配置普通蓝牙模块的设备，可通过软件配置，令目标设备按照iBeacon信号的头部格式(iBeacon信号的头部是02 01 06 1A FF)发出蓝牙信号，从而达到模拟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，用于：根据验证结果确定对所述支付请求和所述收款请求的响应结果。
可选的，所述验证模块，还用于：
验证所述目标设备生成的验证口令与所述支付请求携带的验证口令是否匹配。
可选的，所述收款请求接收模块，还用于：在接收所述目标设备发起的携带有验证口令的收款请求前，向所述目标设备发起验证口令发送请求。
可选的，所述支付请求还携带有支付参数，所述支付参数包括支付方账户信息，所述收款请求还携带有收款参数；所述响应结果包括：基于所述收款参数对支付方账户进行扣款的扣款结果。
可选的，还包括：分别向所述便携设备和目标设备发送响应结果消息。
本说明书实施例还提供一种便携设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，所述处理器执行所述程序时实现如下方法：
确定检测到携带有验证口令的连接信号后，获取设备姿态参数，所述连接信号由目标设备发出；
若所述设备姿态参数匹配目标姿态，向服务端发起支付请求，所述支付请求携带有所述验证口令，以供所述服务端根据所述目标设备生成的验证口令对所述支付请求携带的验证口令进行验证后响应所述支付请求。
本说明书实施例还提供一种目标设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，所述处理器执行所述程序时实现如下方法：
按照目标时间周期生成验证口令；
发出连接信号，所述连接信号携带有当前生效的验证口令；
将携带有所述验证口令的收款请求发送给服务端，以供所述服务端对便携设备发起的支付请求中携带的验证口令进行验证。
本说明书实施例还提供一种服务器，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，所述处理器执行所述程序时实现如下方法：
接收便携设备发起的携带有验证口令的支付请求，其中，所述验证口令是所述便携设备检测电子设备发出的连接信号中获取到的；
接收所述电子设备发起的携带有验证口令的收款请求；
利用所述电子设备生成的验证口令对所述支付请求携带的验证口令进行验证；
根据验证结果确定是否响应所述支付请求和所述收款请求。
上述支付处理装置中各个模块的功能和作用的实现过程具体详见上述支付处理方法中对应步骤的实现过程，在此不再赘述。
对于支付处理装置实施例而言，由于其基本对应于支付处理方法实施例，所以 相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理模块，即可以位于一个地方，或者也可以分布到多个网络模块上。可以根据实际的需要选择其中的部分或者全部模块来实现本说明书方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。
上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。
本领域技术人员在考虑说明书及实践这里申请的发明后，将容易想到本说明书的其它实施方案。本说明书旨在涵盖本说明书的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本说明书的一般性原理并包括本说明书未申请的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本说明书的真正范围和精神由下面的权利要求指出。
应当理解的是，本说明书并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本说明书的范围仅由所附的权利要求来限制。
以上所述仅为本说明书的较佳实施例而已，并不用以限制本说明书，凡在本说明书的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本说明书保护的范围之内。

Claims (20)

  1. 一种支付处理方法，所述方法包括：
    确定检测到携带有验证口令的连接信号后，获取设备姿态参数，所述连接信号由目标设备发出；
    若所述设备姿态参数匹配目标姿态，向服务端发起支付请求，所述支付请求携带有所述验证口令，以供所述服务端根据所述目标设备生成的验证口令对所述支付请求携带的验证口令进行验证后响应所述支付请求。
  2. 根据权利要求1所述的方法，所述连接信号包括：iBeacon信号。
  3. 根据权利要求2所述的方法应用于客户端，所述客户端由操作系统唤醒后执行所述支付处理方法，所述客户端是在所述操作系统检测到所述连接信号后被唤醒。
  4. 根据权利要求1所述的方法，所述连接信号还携带有目标设备标识，所述支付请求还携带有所述目标设备标识。
  5. 一种支付处理方法，所述方法包括：
    按照目标时间周期生成验证口令；
    发出连接信号，所述连接信号携带有当前生效的验证口令；
    将携带有所述验证口令的收款请求发送给服务端，以供所述服务端对便携设备发起的支付请求中携带的验证口令进行验证后响应所述收款请求。
  6. 根据权利要求5所述的方法，在所述将所述验证口令发送给服务端之前，所述方法还包括：
    接收服务端发起的验证口令发送请求。
  7. 根据权利要求5所述的方法，所述收款请求还携带有收款参数。
  8. 根据权利要求5所述的方法，所述连接信号包括：iBeacon信号。
  9. 一种支付处理方法，所述方法包括：
    接收便携设备发起的携带有验证口令的支付请求，其中，所述验证口令由所述便携设备从目标设备发出的连接信号中获取到；
    接收所述目标设备发起的携带有验证口令的收款请求；
    利用所述目标设备生成的验证口令对所述支付请求携带的验证口令进行验证；
    根据验证结果确定对所述支付请求和所述收款请求的响应结果。
  10. 根据权利要求9所述的方法，所述利用所述目标设备生成的验证口令对所述支付请求携带的验证口令进行验证，包括：
    验证所述目标设备生成的验证口令与所述支付请求携带的验证口令是否匹配。
  11. 根据权利要求9所述的方法，所述在接收所述目标设备发起的携带有验证口令的收款请求前，所述方法包括：
    向所述目标设备发起验证口令发送请求。
  12. 根据权利要求11所述的方法，所述支付请求还携带有所述目标设备标识，所述目标设备通过所述目标设备标识查找到。
  13. 根据权利要求9所述的方法，所述支付请求还携带有支付参数，所述支付参数包括支付方账户信息，所述收款请求还携带有收款参数；所述响应结果包括：基于所述收款参数对支付方账户进行扣款的扣款结果。
  14. 根据权利要求9所述的方法，还包括：分别向所述便携设备和目标设备发送响应结果消息。
  15. 一种支付处理装置，所述装置包括：
    姿态参数获取模块，用于：确定检测到携带有验证口令的连接信号后，获取设备姿态参数，所述连接信号由目标设备发出；
    支付发起模块，用于：若所述设备姿态参数匹配目标姿态，向服务端发起支付请求，所述支付请求携带有所述验证口令，以供所述服务端根据所述目标设备生成的验证口令对所述支付请求携带的验证口令进行验证后响应所述支付请求。
  16. 一种支付处理装置，所述装置包括：
    口令生成模块，用于：按照目标时间周期生成验证口令；
    信号发出模块，用于：发出连接信号，所述连接信号携带有当前生效的验证口令；
    收款发起模块，用于：将携带有所述验证口令的收款请求发送给服务端，以供所述服务端对便携设备发起的支付请求中携带的验证口令进行验证后响应所述收款请求。
  17. 一种支付处理装置，所述装置包括：
    支付请求接收模块，用于：接收便携设备发起的携带有验证口令的支付请求，其中，所述验证口令是所述便携设备检测目标设备发出的连接信号中获取到的；
    收款请求接收模块，用于：接收所述目标设备发起的携带有验证口令的收款请求；
    验证模块，用于：利用所述目标设备生成的验证口令对所述支付请求携带的验证口令进行验证；
    响应模块，用于：根据验证结果确定对所述支付请求和所述收款请求的响应结果。
  18. 一种便携设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，所述处理器执行所述程序时实现如下方法：
    确定检测到携带有验证口令的连接信号后，获取设备姿态参数，所述连接信号由目 标设备发出；
    若所述设备姿态参数匹配目标姿态，向服务端发起支付请求，所述支付请求携带有所述验证口令，以供所述服务端根据所述目标设备生成的验证口令对所述支付请求携带的验证口令进行验证后响应所述支付请求。
  19. 一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，所述处理器执行所述程序时实现如下方法：
    按照目标时间周期生成验证口令；
    发出连接信号，所述连接信号携带有当前生效的验证口令；
    将携带有所述验证口令的收款请求发送给服务端，以供所述服务端对便携设备发起的支付请求中携带的验证口令进行验证后响应所述收款请求。
  20. 一种服务器，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，所述处理器执行所述程序时实现如下方法：
    接收便携设备发起的携带有验证口令的支付请求，其中，所述验证口令是所述便携设备检测目标设备发出的连接信号中获取到的；
    接收所述目标设备发起的携带有验证口令的收款请求；
    利用所述目标设备生成的验证口令对所述支付请求携带的验证口令进行验证；
    根据验证结果确定对所述支付请求和所述收款请求的响应结果。
PCT/CN2019/095521 2018-07-27 2019-07-11 支付处理方法、装置、服务器及设备 Ceased WO2020019985A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201810847143.4A CN109102279A (zh) 2018-07-27 2018-07-27 支付处理方法、装置、服务器及设备
CN201810847143.4 2018-07-27

Publications (1)

Publication Number Publication Date
WO2020019985A1 true WO2020019985A1 (zh) 2020-01-30

Family

ID=64847857

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2019/095521 Ceased WO2020019985A1 (zh) 2018-07-27 2019-07-11 支付处理方法、装置、服务器及设备

Country Status (3)

Country Link
CN (1) CN109102279A (zh)
TW (1) TW202008258A (zh)
WO (1) WO2020019985A1 (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109102279A (zh) * 2018-07-27 2018-12-28 阿里巴巴集团控股有限公司 支付处理方法、装置、服务器及设备

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100078471A1 (en) * 2008-09-30 2010-04-01 Apple Inc. System and method for processing peer-to-peer financial transactions
CN105139194A (zh) * 2015-09-30 2015-12-09 联想(北京)有限公司 一种建立连接的方法、电子设备及建立连接的系统
CN105187937A (zh) * 2015-08-12 2015-12-23 上海众人网络安全技术有限公司 一种基于智能手机的购物系统及方法
CN105894273A (zh) * 2016-04-01 2016-08-24 郁晓东 一种根据动作判断支付行为的方法
CN105931044A (zh) * 2016-04-22 2016-09-07 腾讯科技（深圳）有限公司 移动支付激活方法及装置
CN106096948A (zh) * 2016-06-08 2016-11-09 福建联迪商用设备有限公司 基于蓝牙通信的公交支付方法及系统
CN109102279A (zh) * 2018-07-27 2018-12-28 阿里巴巴集团控股有限公司 支付处理方法、装置、服务器及设备

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104320779B (zh) * 2014-11-13 2018-02-16 熊文俊 基于u/sim卡鉴权响应及限时反馈近场通信认证方法
CN104766206B (zh) * 2015-04-22 2018-03-13 广东欧珀移动通信有限公司 一种基于移动终端的nfc支付方法及装置
CN107194689B (zh) * 2017-06-16 2024-05-03 河南晟宇信息技术有限公司 基于近场磁通信与接近关系检测的手机支付系统与方法

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100078471A1 (en) * 2008-09-30 2010-04-01 Apple Inc. System and method for processing peer-to-peer financial transactions
CN105187937A (zh) * 2015-08-12 2015-12-23 上海众人网络安全技术有限公司 一种基于智能手机的购物系统及方法
CN105139194A (zh) * 2015-09-30 2015-12-09 联想(北京)有限公司 一种建立连接的方法、电子设备及建立连接的系统
CN105894273A (zh) * 2016-04-01 2016-08-24 郁晓东 一种根据动作判断支付行为的方法
CN105931044A (zh) * 2016-04-22 2016-09-07 腾讯科技（深圳）有限公司 移动支付激活方法及装置
CN106096948A (zh) * 2016-06-08 2016-11-09 福建联迪商用设备有限公司 基于蓝牙通信的公交支付方法及系统
CN109102279A (zh) * 2018-07-27 2018-12-28 阿里巴巴集团控股有限公司 支付处理方法、装置、服务器及设备

Also Published As

Publication number Publication date
TW202008258A (zh) 2020-02-16
CN109102279A (zh) 2018-12-28

Similar Documents

Publication Publication Date Title
US11195167B2 (en) Offline payment method and device
US11539522B2 (en) Methods and apparatus for authorizing and providing of services
EP3613229B1 (en) Wireless authentication based on location data
US11250427B2 (en) Credit payment method and apparatus based on mobile terminal peer-to-peer
US11227279B2 (en) Credit payment method and apparatus based on card emulation of mobile terminal
US20190026722A1 (en) Payment processing using a wearable device
US20260067275A1 (en) Methods and apparatus for facilitating nfc transactions
US11411735B2 (en) Methods and apparatus for authorizing and providing of distributed goods or services
KR102511285B1 (ko) 서비스 처리 방법 및 디바이스
US11100473B2 (en) Mobile payment processing
US11562054B2 (en) Authorized gesture control methods and apparatus
WO2020082882A1 (zh) 停车收费系统及方法、装置、电子设备
CN107491966A (zh) 支付方法、装置及系统、存储介质
WO2019149057A1 (zh) 一种支付乘车费的方法、装置及设备
US10387860B2 (en) Transaction processing based on comparing actions recorded on multiple devices
US11539706B2 (en) Authorized off-line access methods and apparatus
US12299670B2 (en) Methods and apparatus for facilitating NFC transactions
CN108898388A (zh) 支付方法及装置
WO2020019985A1 (zh) 支付处理方法、装置、服务器及设备
CN108600238B (zh) 传输卡数据的方法、装置和系统
CN106797386B (zh) 安全验证方法、装置、终端设备及服务器
US20200104824A1 (en) Using an image as a one-time password for authentication during a point-of-sale transaction
HK40002159A (zh) 支付处理方法、装置、服务器及设备
US20210281124A1 (en) Authorized wireless charging methods and apparatus
CN108074094B (zh) 资源补充方法及装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19841009

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19841009

Country of ref document: EP

Kind code of ref document: A1