為克服相關技術中存在的問題，本說明書提供了支付處理方法、裝置、伺服器及設備。
根據本說明書實施例的第一態樣，提供一種支付處理方法，所述方法包括：
確定檢測到攜帶有驗證密碼的連接訊號後，獲取設備姿態參數，所述連接訊號由目標設備發出；
若所述設備姿態參數匹配目標姿態，向伺服端發起支付請求，所述支付請求攜帶有所述驗證密碼，以供所述伺服端根據所述目標設備生成的驗證密碼對所述支付請求攜帶的驗證密碼進行驗證後響應所述支付請求。
可選的，所述連接訊號包括：iBeacon訊號。
可選的，所述方法應用於用戶端，所述用戶端由作業系統喚醒後執行所述支付處理方法，所述用戶端是在所述作業系統檢測到所述連接訊號後被喚醒。
可選的，所述連接訊號還攜帶有目標設備標識，所述支付請求還攜帶有所述目標設備標識。
可選的，所述支付請求還攜帶有支付參數。
根據本說明書實施例的第二態樣，提供一種支付處理方法，所述方法包括：
按照目標時間週期生成驗證密碼；
發出連接訊號，所述連接訊號攜帶有當前生效的驗證密碼；
將攜帶有所述驗證密碼的收款請求發送給伺服端，以供所述伺服端對可攜式設備發起的支付請求中攜帶的驗證密碼進行驗證後響應所述收款請求。
可選的，在所述將所述驗證密碼發送給伺服端之前，所述方法還包括：
接收伺服端發起的驗證密碼發送請求。
可選的，所述收款請求還攜帶有收款參數。
可選的，所述連接訊號包括：iBeacon訊號。
根據本說明書實施例的第三態樣，提供一種支付處理方法，所述方法包括：
接收可攜式設備發起的攜帶有驗證密碼的支付請求，其中，所述驗證密碼是所述可攜式設備檢測目標設備發出的連接訊號中獲取到的；
接收所述目標設備發起的攜帶有驗證密碼的收款請求；
利用所述目標設備生成的驗證密碼對所述支付請求攜帶的驗證密碼進行驗證；
根據驗證結果確定對所述支付請求和所述收款請求的響應結果。
可選的，所述利用所述目標設備生成的驗證密碼對所述支付請求攜帶的驗證密碼進行驗證，包括：
驗證所述目標設備生成的驗證密碼與所述支付請求攜帶的驗證密碼是否匹配。
可選的，所述在接收所述目標設備發起的攜帶有驗證密碼的收款請求前，所述方法包括：
向所述目標設備發起驗證密碼發送請求。
可選的，所述支付請求還攜帶有所述目標設備標識，所述目標設備透過所述目標設備標識查找到。
可選的，所述支付請求還攜帶有支付參數，所述支付參數包括支付方帳戶資訊，所述收款請求還攜帶有收款參數；所述響應結果包括：基於所述收款參數對支付方帳戶進行扣款的扣款結果。
可選的，所述方法還包括：分別向所述可攜式設備和目標設備發送響應結果訊息。
根據本說明書實施例的第四態樣，提供一種支付處理裝置，所述裝置包括：
姿態參數獲取模組，用於：確定檢測到攜帶有驗證密碼的連接訊號後，獲取設備姿態參數，所述連接訊號由目標設備發出；
支付發起模組，用於：若所述設備姿態參數匹配目標姿態，向伺服端發起支付請求，所述支付請求攜帶有所述驗證密碼，以供所述伺服端根據所述目標設備生成的驗證密碼對所述支付請求攜帶的驗證密碼進行驗證後響應所述支付請求。
可選的，所述連接訊號包括：iBeacon訊號。
可選的，所述裝置應用於用戶端，所述用戶端由作業系統喚醒後執行所述支付處理方法，所述用戶端是在所述作業系統檢測到所述連接訊號後被喚醒。
可選的，所述支付請求還攜帶有支付參數。
根據本說明書實施例的第五態樣，提供一種支付處理裝置，所述裝置包括：
密碼生成模組，用於：按照目標時間週期生成驗證密碼；
訊號發出模組，用於：發出連接訊號，所述連接訊號攜帶有當前生效的驗證密碼；
收款發起模組，用於：將攜帶有所述驗證密碼的收款請求發送給伺服端，以供所述伺服端對可攜式設備發起的支付請求中攜帶的驗證密碼進行驗證後響應所述收款請求。
可選的，所述收款發起模組，還用於：在所述將所述驗證密碼發送給伺服端之前，接收伺服端發起的驗證密碼發送請求。
可選的，所述收款請求還攜帶有收款參數。
可選的，所述連接訊號包括：iBeacon訊號。
根據本說明書實施例的第六態樣，提供一種支付處理裝置，所述裝置包括：
支付請求接收模組，用於：接收可攜式設備發起的攜帶有驗證密碼的支付請求，其中，所述驗證密碼是所述可攜式設備檢測目標設備發出的連接訊號中獲取到的；
收款請求接收模組，用於：接收所述目標設備發起的攜帶有驗證密碼的收款請求；
驗證模組，用於：利用所述目標設備生成的驗證密碼對所述支付請求攜帶的驗證密碼進行驗證；
響應模組，用於：根據驗證結果確定對所述支付請求和所述收款請求的響應結果。
可選的，所述驗證模組，還用於：
驗證所述目標設備生成的驗證密碼與所述支付請求攜帶的驗證密碼是否匹配。
可選的，所述支付請求還攜帶有支付參數，所述支付參數包括支付方帳戶資訊，所述收款請求還攜帶有收款參數；所述響應結果包括：基於所述收款參數對支付方帳戶進行扣款的扣款結果。
可選的，所述裝置還包括發送模組，用於：分別向所述可攜式設備和目標設備發送響應結果訊息。
根據本說明書實施例的第七態樣，提供一種可攜式設備，包括儲存器、處理器及儲存在儲存器上並可在處理器上運行的電腦程式，其中，所述處理器執行所述程式時實現如下方法：
確定檢測到攜帶有驗證密碼的連接訊號後，獲取設備姿態參數，所述連接訊號由目標設備發出；
若所述設備姿態參數匹配目標姿態，向伺服端發起支付請求，所述支付請求攜帶有所述驗證密碼，以供所述伺服端根據所述目標設備生成的驗證密碼對所述支付請求攜帶的驗證密碼進行驗證後響應所述支付請求。
根據本說明書實施例的第八態樣，提供一種電子設備，包括儲存器、處理器及儲存在儲存器上並可在處理器上運行的電腦程式，其中，所述處理器執行所述程式時實現如下方法：
按照目標時間週期生成驗證密碼；
發出連接訊號，所述連接訊號攜帶有當前生效的驗證密碼；
將攜帶有所述驗證密碼的收款請求發送給伺服端，以供所述伺服端對可攜式設備發起的支付請求中攜帶的驗證密碼進行驗證後響應所述收款請求。
根據本說明書實施例的第九態樣，提供一種伺服器，包括儲存器、處理器及儲存在儲存器上並可在處理器上運行的電腦程式，其中，所述處理器執行所述程式時實現如下方法：
接收可攜式設備發起的攜帶有驗證密碼的支付請求，其中，所述驗證密碼是所述可攜式設備檢測目標設備發出的連接訊號中獲取到的；
接收所述目標設備發起的攜帶有驗證密碼的收款請求；
利用所述目標設備生成的驗證密碼對所述支付請求攜帶的驗證密碼進行驗證；
根據驗證結果確定對所述支付請求和所述收款請求的響應結果。
本說明書的實施例提供的技術方案可以包括以下有益效果：
本說明書實施例中，可攜式設備可以基於“檢測到連接訊號”和“設備處於目標姿態”確定用戶希望發起一筆支付。因此，若用戶需要支付，可以持可攜式設備靠近目標設備，以使可攜式設備能夠檢測到目標設備發出的連接訊號。由於目標設備發出有攜帶驗證密碼的連接訊號，可攜式設備可檢測到該連接訊號；另外，用戶可令可攜式設備處於目標姿態，基於此，目標設備可認為用戶要進行一筆支付，並發起攜帶有驗證密碼的支付請求。而目標設備也可以發起攜帶有所述驗證密碼的收款請求，伺服端接收到支付請求和收款請求後，可根據目標設備生成的驗證密碼對支付請求中的驗證密碼進行驗證，基於驗證結果響應該支付請求和收款請求。本實施例中，用戶可透過簡單的操作即可進行一筆支付，支付過程方便快捷。
應當理解的是，以上的一般描述和後文的細節描述僅是範例性和解釋性的，並不能限制本說明書。In order to overcome the problems in related technologies, this specification provides payment processing methods, devices, servers, and equipment.
According to a first aspect of the embodiments of the present specification, a payment processing method is provided, and the method includes:
After it is determined that the connection signal carrying the verification password is detected, the posture parameters of the device are obtained, and the connection signal is sent by the target device;
If the posture parameter of the device matches the target posture, a payment request is initiated to the server, and the payment request carries the verification password for the server to carry the payment request according to the verification password generated by the target device After verifying the verification password, respond to the payment request.
Optionally, the connection signal includes: an iBeacon signal.
Optionally, the method is applied to a user terminal that executes the payment processing method after being awakened by an operating system, and the user terminal is awakened after the operating system detects the connection signal.
Optionally, the connection signal also carries a target device identification, and the payment request also carries the target device identification.
Optionally, the payment request also carries payment parameters.
According to a second aspect of the embodiments of the present specification, a payment processing method is provided. The method includes:
Generate a verification password according to the target time period;
Send a connection signal, the connection signal carries the currently valid authentication password;
Sending a payment request carrying the verification password to the server for the server to verify the verification password carried in the payment request initiated by the portable device and respond to the payment request.
Optionally, before sending the verification password to the server, the method further includes:
Receive the authentication password sending request initiated by the server.
Optionally, the collection request also carries collection parameters.
Optionally, the connection signal includes: an iBeacon signal.
According to a third aspect of the embodiments of the present specification, a payment processing method is provided. The method includes:
Receiving a payment request initiated by a portable device and carrying a verification password, wherein the verification password is obtained by the portable device detecting a connection signal sent by a target device;
Receiving a payment request initiated by the target device and carrying a verification password;
Verify the verification password carried in the payment request by using the verification password generated by the target device;
The response result to the payment request and the collection request is determined according to the verification result.
Optionally, using the verification password generated by the target device to verify the verification password carried in the payment request includes:
Verify whether the verification password generated by the target device matches the verification password carried in the payment request.
Optionally, before receiving the payment request initiated by the target device and carrying the verification password, the method includes:
Initiate a verification password sending request to the target device.
Optionally, the payment request also carries the target device identification, and the target device is found through the target device identification.
Optionally, the payment request also carries payment parameters, the payment parameters include payer account information, and the collection request also carries collection parameters; the response result includes: payment based on the collection parameters The deduction result of the deduction in the local account.
Optionally, the method further includes: sending a response result message to the portable device and the target device, respectively.
According to a fourth aspect of the embodiments of the present specification, a payment processing device is provided, and the device includes:
The posture parameter acquisition module is used to: after determining that the connection signal carrying the verification password is detected, obtain the device posture parameter, and the connection signal is sent by the target device;
The payment initiation module is used to: if the device posture parameter matches the target posture, initiate a payment request to the server, the payment request carrying the verification password for the server to perform verification based on the target device The password verifies the verification password carried in the payment request and then responds to the payment request.
Optionally, the connection signal includes: an iBeacon signal.
Optionally, the device is applied to a user terminal, and the user terminal is woken up by an operating system to execute the payment processing method, and the user terminal is woken up after the operating system detects the connection signal.
Optionally, the payment request also carries payment parameters.
According to a fifth aspect of the embodiments of the present specification, a payment processing device is provided, and the device includes:
The password generation module is used to: generate a verification password according to the target time period;
The signal sending module is used to send out a connection signal, and the connection signal carries the currently valid authentication password;
Collection initiation module, used to: send a collection request carrying the verification password to the server for the server to verify the verification password carried in the payment request initiated by the portable device and respond to the verification request Describe the collection request.
Optionally, the collection initiation module is further configured to: before sending the verification password to the server, receive a verification password sending request initiated by the server.
Optionally, the collection request also carries collection parameters.
Optionally, the connection signal includes: an iBeacon signal.
According to a sixth aspect of the embodiments of the present specification, a payment processing device is provided, and the device includes:
The payment request receiving module is used to: receive a payment request initiated by a portable device and carrying a verification password, wherein the verification password is obtained by the portable device from detecting a connection signal sent by a target device;
The payment request receiving module is used to receive a payment 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 used to determine the response result to the payment request and the collection request according to the verification result.
Optionally, the verification module is also used to:
Verify whether the verification password generated by the target device matches the verification password carried in the payment request.
Optionally, the payment request also carries payment parameters, the payment parameters include payer account information, and the collection request also carries collection parameters; the response result includes: payment based on the collection parameters The deduction result of the deduction in the local account.
Optionally, the apparatus further includes a sending module, configured to send a response result message to the portable device and the target device, respectively.
According to a seventh aspect of the embodiments of the present specification, a portable device is provided, including a storage, a processor, and a computer program stored on the storage and executable on the processor, wherein the processor executes the The following methods are implemented in the program:
After it is determined that the connection signal carrying the verification password is detected, the posture parameters of the device are obtained, and the connection signal is sent by the target device;
If the posture parameter of the device matches the target posture, a payment request is initiated to the server, and the payment request carries the verification password for the server to carry the payment request according to the verification password generated by the target device After verifying the verification password, respond to the payment request.
According to an eighth aspect of the embodiments of the present specification, an electronic device is provided, including a storage, a processor, and a computer program stored on the storage and executable on the processor, wherein the processor executes the program Implement the following method:
Generate a verification password according to the target time period;
Send a connection signal, the connection signal carries the currently valid authentication password;
Sending a payment request carrying the verification password to the server for the server to verify the verification password carried in the payment request initiated by the portable device and respond to the payment request.
According to a ninth aspect of the embodiments of the present specification, there is provided a server including a storage, a processor, and a computer program stored on the storage and executable on the processor, wherein the processor executes the program Implement the following method:
Receiving a payment request initiated by a portable device and carrying a verification password, wherein the verification password is obtained by the portable device detecting a connection signal sent by a target device;
Receiving a payment request initiated by the target device and carrying a verification password;
Verify the verification password carried in the payment request by using the verification password generated by the target device;
The response result to the payment request and the collection request is determined according to the verification result.
The technical solutions provided by the embodiments of the present specification may include the following beneficial effects:
In the embodiment of the present specification, the portable device may determine that the user wishes to initiate a payment based on "the connection signal is detected" and "the device is in the target gesture". Therefore, if the user needs to pay, he can hold the portable device close to the target device, so that the portable device can detect the connection signal sent by the target device. Since the target device sends out a connection signal carrying a verification password, the portable device can detect the connection signal; in addition, the user can place the portable device in a target posture, based on which the target device can assume that the user wants to make a payment, and Initiate a payment request with a verification password. The target device can also initiate a payment request carrying the verification password. After receiving the payment request and the payment request, the server can verify the verification password in the payment request based on the verification password generated by the target device, based on the verification result Respond to the payment request and collection request. In this embodiment, the user can make a payment with a simple operation, and the payment process is convenient and fast.
It should be understood that the above general description and the following detailed description are only exemplary and explanatory, and do not limit this specification.
這裡將詳細地對範例性實施例進行說明，其範例表示在圖式中。下面的描述涉及圖式時，除非另有表示，不同圖式中的相同數字表示相同或相似的要素。以下範例性實施例中所描述的實施方式並不代表與本說明書相一致的所有實施方式。相反，它們僅是與如所附申請專利範圍中所詳述的、本說明書的一些態樣相一致的裝置和方法的例子。
在本說明書使用的術語是僅僅出於描述特定實施例的目的，而非意於限制本說明書。在本說明書和所附申請專利範圍中所使用的單數形式的“一種”、“所述”和“該”也意於包括多數形式，除非上下文清楚地表示其他含義。還應當理解，本文中使用的術語“和/或”是指並包含一個或多個相關聯的列出項目的任何或所有可能組合。
應當理解，儘管在本說明書可能採用術語第一、第二、第三等來描述各種資訊，但這些資訊不應限於這些術語。這些術語僅用來將同一類型的資訊彼此區分開。例如，在不脫離本說明書範圍的情況下，第一資訊也可以被稱為第二資訊，類似地，第二資訊也可以被稱為第一資訊。取決於語境，如在此所使用的詞語“如果”可以被解釋成為“在……時”或“當……時”或“響應於確定”。
在大部分行動支付場景中，收款方設備採用攝影鏡頭掃描用戶提供的付款碼，因此對攝影鏡頭的品質有一定的要求，若攝影鏡頭的品質較差、對焦較慢，可能會造成識別付款碼較慢的情況，也可能會出現付款碼與攝影鏡頭沒有對準，需要用戶調整便捷設備以更好地完成支付。
基於此，請參考圖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，用於：根據驗證結果確定對所述支付請求和所述收款請求的響應結果。
可選的，所述驗證模組，還用於：
驗證所述目標設備生成的驗證密碼與所述支付請求攜帶的驗證密碼是否匹配。
可選的，所述收款請求接收模組，還用於：在接收所述目標設備發起的攜帶有驗證密碼的收款請求前，向所述目標設備發起驗證密碼發送請求。
可選的，所述支付請求還攜帶有支付參數，所述支付參數包括支付方帳戶資訊，所述收款請求還攜帶有收款參數；所述響應結果包括：基於所述收款參數對支付方帳戶進行扣款的扣款結果。
可選的，還包括：分別向所述可攜式設備和目標設備發送響應結果訊息。
本說明書實施例還提供一種可攜式設備，包括儲存器、處理器及儲存在儲存器上並可在處理器上運行的電腦程式，其中，所述處理器執行所述程式時實現如下方法：
確定檢測到攜帶有驗證密碼的連接訊號後，獲取設備姿態參數，所述連接訊號由目標設備發出；
若所述設備姿態參數匹配目標姿態，向伺服端發起支付請求，所述支付請求攜帶有所述驗證密碼，以供所述伺服端根據所述目標設備生成的驗證密碼對所述支付請求攜帶的驗證密碼進行驗證後響應所述支付請求。
本說明書實施例還提供一種目標設備，包括儲存器、處理器及儲存在儲存器上並可在處理器上運行的電腦程式，其中，所述處理器執行所述程式時實現如下方法：
按照目標時間週期生成驗證密碼；
發出連接訊號，所述連接訊號攜帶有當前生效的驗證密碼；
將攜帶有所述驗證密碼的收款請求發送給伺服端，以供所述伺服端對可攜式設備發起的支付請求中攜帶的驗證密碼進行驗證。
本說明書實施例還提供一種伺服器，包括儲存器、處理器及儲存在儲存器上並可在處理器上運行的電腦程式，其中，所述處理器執行所述程式時實現如下方法：
接收可攜式設備發起的攜帶有驗證密碼的支付請求，其中，所述驗證密碼是所述可攜式設備檢測電子設備發出的連接訊號中獲取到的；
接收所述電子設備發起的攜帶有驗證密碼的收款請求；
利用所述電子設備生成的驗證密碼對所述支付請求攜帶的驗證密碼進行驗證；
根據驗證結果確定是否響應所述支付請求和所述收款請求。
上述支付處理裝置中各個模組的功能和作用的實現過程具體詳見上述支付處理方法中對應步驟的實現過程，在此不再贅述。
對於支付處理裝置實施例而言，由於其基本對應於支付處理方法實施例，所以相關之處參見方法實施例的部分說明即可。以上所描述的裝置實施例僅僅是示意性的，其中所述作為分離部件說明的模組可以是或者也可以不是實體上分開的，作為模組顯示的部件可以是或者也可以不是實體模組，即可以位於一個地方，或者也可以分佈到多個網路模組上。可以根據實際的需要選擇其中的部分或者全部模組來實現本說明書方案的目的。本領域普通技術人員在不付出創造性勞動的情況下，即可以理解並實施。
上述對本說明書特定實施例進行了描述。其它實施例在所附申請專利範圍的範圍內。在一些情況下，在申請專利範圍中記載的動作或步驟可以按照不同於實施例中的順序來執行並且仍然可以實現期望的結果。另外，在圖式中描繪的過程不一定要求顯示的特定順序或者連續順序才能實現期望的結果。在某些實施方式中，多任務處理和並行處理也是可以的或者可能是有利的。
本領域技術人員在考慮說明書及實踐這裡申請的發明後，將容易想到本說明書的其它實施方案。本說明書意於涵蓋本說明書的任何變型、用途或者適應性變化，這些變型、用途或者適應性變化遵循本說明書的一般性原理並包括本說明書未申請的本技術領域中的眾所皆知常識或慣用技術手段。說明書和實施例僅被視為範例性的，本說明書的真正範圍和精神由下面的申請專利範圍指出。
應當理解的是，本說明書並不局限於上面已經描述並在圖式中顯示的精確結構，並且可以在不脫離其範圍進行各種修改和改變。本說明書的範圍僅由所附的申請專利範圍來限制。
以上所述僅為本說明書的較佳實施例而已，並不用以限制本說明書，凡在本說明書的精神和原則之內，所做的任何修改、等同替換、改進等，均應包含在本說明書保護的範圍之內。Exemplary embodiments will be described in detail here, examples of which are shown in the drawings. When the following description refers to drawings, unless otherwise indicated, the same numerals in different drawings represent the same or similar elements. The implementations described in the following exemplary embodiments do not represent all implementations consistent with this specification. Rather, they are merely examples of devices and methods that are consistent with some aspects of this specification as detailed in the scope of the attached patent applications.
The terminology used in this specification is for the purpose of describing particular embodiments only, and is not intended to limit this specification. The singular forms "a", "said", and "the" used in this specification and the appended patent applications are also intended to include most forms unless the context clearly indicates other meanings. It should also be understood that the term "and/or" as used herein refers to and includes any or all possible combinations of one or more associated listed items.
It should be understood that although the terms 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. For example, without departing from the scope of this specification, the first information may also be referred to as second information, and similarly, the second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when" or "when" or "in response to a determination".
In most mobile payment scenarios, the payee device uses a camera lens to scan the payment code provided by the user, so there are certain requirements for the quality of the camera lens. If the quality of the camera lens is poor and the focus is slow, the payment code may be recognized. In a slower situation, it may happen that the payment code is not aligned with the camera lens, and the user needs to adjust the convenient device to complete the payment better.
Based on this, please refer to FIG. 1, which is a scene diagram of a payment processing method shown in this specification according to an exemplary embodiment. In order to facilitate distinction, this embodiment refers to a device held by a user as a portable device. Taking a smartphone as an example in FIG. 1, the portable device may also be a device such as smart glasses or a smart watch. In the payment scenario, it also involves another type of device that cooperates with a portable device to complete a payment. This embodiment is called a target device. The target device may be owned by various service merchants, and it can be deployed at the entity that provides commercial services. within the area. For example, in the offline store scenario, the target device can be deployed in the commodity settlement area, and in the traffic travel scenario, the target device can be deployed on the bus, subway entrance, and train entrance.
The embodiment of the present specification proposes a payment scheme, 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 “detected connection signal” and “device is in target posture”. Therefore, if the user needs to pay, he can hold the portable device close to the target device, so that the portable device can detect the connection signal sent by the target device. Since the target device sends out a connection signal carrying a verification password, the portable device can detect the connection signal; in addition, the user can place the portable device in the target posture, based on which the target device can assume that the user wants to make a payment, And initiate a payment request carrying a verification password. The target device can also initiate a payment request carrying the verification password. After receiving the payment request and the payment request, the payment server can verify the verification password in the payment request based on the verification password generated by the target device, based on the verification The result responds to the payment request and the collection request. In this embodiment, the user can make a payment with a simple operation, and the payment process is convenient and fast.
As shown in 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 to execute the following processing flow:
In step 202, the target device generates an authentication password according to the target time period.
In step 204, the target device sends a connection signal, and the connection signal carries the currently valid authentication password.
In step 206, the portable device determines that the connection signal carrying the verification password is detected.
In step 208, the portable device acquires device attitude parameters.
In step 210, the portable device determines whether the device posture parameter matches the target posture.
In 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.
In step 214, the server receives the payment request.
In step 216, the target device initiates a payment request with a verification password to the server.
In step 218, the server receives the payment request initiated by the target device.
In step 220, the server uses the verification password generated by the target device to verify the verification password carried in the payment request.
In step 222, a response result to the payment request and the collection request is determined according to the verification result.
In this embodiment, the target device can generate a verification password by configuring a verification password generator or running a verification password generation program, which can be flexibly configured according to actual needs, such as 60 seconds or 120 seconds Wait. On the other hand, the target device can also be equipped with a communication module, which can send out a connection signal carrying a verification password for detection by the portable device. Optionally, the communication module may be a communication module such as Bluetooth, Wi-Fi (Wireless Fidelity, wireless fidelity), near field communication, UWB (Ultra Wideband, a carrier-free communication technology) or HomeRF (Home Radio Frequency) .
In the payment scenario in this embodiment, the payment trigger condition of the portable device is: 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. In other words, the portable device determines that the user wishes to initiate a payment based on the "connection signal detected" and "the device is in the target posture". Therefore, in the payment scenario of 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. Since the target device sends a connection signal carrying a verification password, the portable device can detect the connection signal. Based on this, the target device can assume that the user may be ready to make a payment; on the other hand, the payment scheme of this embodiment may It is agreed with the user in advance that a certain target posture is used as a trigger for payment. The target posture may be "shake-shake", in a flat state, in a vertical state, shake in a vertical state, or shake in a flat state, and so on.
If the user places the portable device in the target posture according to the requirements of the target posture, the portable device may initiate a payment request. Specifically, the process that the portable device detects whether it is in the target posture may be that the portable device detects the posture parameters of the device based on the gyro, posture sensor, angle sensor, or acceleration sensor configured by itself, For example, the orientation parameters, three-axis direction parameters, three-axis acceleration parameters, or three-axis angular velocity parameters of the device. 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. Based on the above judgment, when the portable device detects the connection signal and its own matching 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, due to the detection of the portable device The connection signal sent by the target device can therefore obtain the verification password carried in the connection signal and make the payment request carry the verification password.
From the perspective of the server, the server can receive the payment request with the verification password initiated by the portable device, and after receiving the payment request, the server needs to verify with the target device to determine whether the transaction is in Occurs between the target device and the portable device. Since the server will receive more payment processing between the portable device and the target device, one of the purposes of verification is to prevent payment processing errors. The target device as the payment device in this payment, the target device can issue a payment request with a verification password, and after receiving the server, the verification password in the payment request is used 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. Alternatively, it may be to compare whether the verification password in the payment request is the same as the verification password in the payment request. In other methods, the authentication password carried in the connection signal can also be encrypted authentication password data, the authentication password sent by the target device can also be encrypted, and the server shares the same with the portable device and the target device. The decryption algorithm can improve the security of data interaction between the server and the target device, and the portable device. In the case where the verification password is encrypted, the verification method may be to determine whether the decrypted verification password matches or not.
Among them, the verification password generated by the target device is carried in the payment request and sent to the server to let the server know that there is a payment between the target device and the portable device to be processed. Optional, in actual application, in some In the example, a payment request may be sent after detecting that a portable device is approaching based on signal strength. In other examples, a trigger interface may be implemented on the target device, and a payment request may be sent after receiving a command triggered by the user through the trigger interface. In other examples, 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 the payment request carrying the verification password to the server. Among them, because the server needs to find the target device and initiate the request, 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 The device identification finds the target device.
Optionally, the collection request may carry collection parameters, such as the identification of the target device, the collection amount, collection description information, the collection party identification, the collection party name, or collection time, and so on. Correspondingly, the payment request may also carry payment parameters, and the payment parameters may include payer account information, payment amount, payer name or payment description information, and so on. Using the payment parameters and payment parameters, the server can respond to the payment request and the payment request, and the response method can be to deduct the payer's account based on the payment parameters, thereby realizing the payment processing. After the response, the server can send a response result message to the portable device and the target device respectively. The response result message indicates whether the payment processing is successful or the deduction result after the successful processing, so that the portable device And the target device can obtain the payment processing result.
Among them, the processing flow in this embodiment involves the detection of the connection signal. The detection process needs to be performed by the communication module in the portable device. In some examples, the flow performed on the portable device may be The client installed on the portable device realizes that the operating system is open to the client, so that after the communication module detects the connection signal, it can be provided to the client through the operating system, and the client can obtain the communication module The detection result of the connection signal, and then execute the payment processing method. In some examples, such as Android and other operating systems, the user terminal runs on a portable device, even if the user terminal runs in the background, based on the permissions opened by such operating system, the user terminal can still obtain the communication module when running in the background Test results. In this way, when the user needs to pay, the portable device is close to the target device and the portable device is in the target posture. The user does not need to unlock the portable device and manually start the user terminal, the user operations are very few, payment processing Very fast.
In other operating systems, such as iOS, the user terminal may be restricted by the operating system after running in the background, or may be stopped by the operating system. Therefore, the user may be required to start the user terminal when payment is required, so that the user terminal The front desk runs, and thus can execute the payment processing method of this embodiment. In other examples, in order to reduce user operations, the user terminal may execute the payment processing method after being awakened by the operating system. The user terminal is awakened after the operating system detects the connection signal. In this way, it can be based on the interface provided by the operating system, and the client can apply for the permission from the operating system. As an example, the connection signal may be an iBeacon signal, and the device based on the iOS system may support the detection of the iBeacon signal. Even if the user terminal is not running, the operating system may detect the iBeacon signal requested by the user terminal in the operating system based on the user's pre-application. After that, the operating system will wake up the user terminal, so that the user terminal can be woken up to perform subsequent payment processing. In this way, the user does not need to unlock the portable device and manually start the user terminal, the user operation is very few, and the payment processing is very fast. Taking the iOS system as an example, the user terminal applies for the detection of the iBeacon signal to the operating system. The application process needs to enable the following two location permissions: self.locationManager requestAlwaysAuthorization and NSLocationAlwaysUsageDescription.
Correspondingly, the target device needs to send an iBeacon signal. In some examples, the target device can be configured with an iBeacon signal module. In other examples, if the target device is a device configured with a common Bluetooth module, the target device can be configured through software. The Bluetooth signal is sent according to the format of the iBeacon signal header (the head of the iBeacon signal is 02 01 06 1A FF), so as to simulate the iBeacon signal. When the portable device detects the connection signal, it detects the connection signal sent in the header format of the iBeacon signal, and then determines that the iBeacon signal is detected.
The embodiments of this specification can be applied to a variety of scenarios, and the following uses three application scenarios as examples.
The first, bus scenario (take fixed billing as an example)
The bus scenario of this embodiment is described by taking fixed charging as an example. The target device of this embodiment may be deployed on a bus. As a collection device, the target device can maintain a network connection with the server, and the server can pre-record the relevant information of the target device, such as the device identification or the deduction fee corresponding to the device, and other payment parameters (this embodiment is fixed Billing scenarios, payment parameters such as deduction fees can be recorded in advance by the server). The target device can generate a verification password according to the target time period. The target device can also be equipped with a communication module that can send out a connection signal carrying the verification password and the target device identification for portable device detection.
The user's portable device (such as a smart phone, or a wearable device such as a smart watch) can be installed with a third-party payment APP, which is used to provide subway ride services and other APPs. After the user gets on the bus, 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 places the portable device in the target posture according to the requirements of the target posture (such as "shake" or lay the phone flat, etc.), then the APP installed on the portable device can initiate a payment request, where the payment request can carry Verify the password and target device ID.
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 verification password request to the target device. After the target device receives it, it is determined that the server is currently processing a payment. Since the target device itself is a collection device for the bus, the target device initiates a payment request to the server, and the payment request carries a verification password. After receiving it, the server verifies the verification password carried in the payment request. If the verification is passed, the server will execute the payment process. In the embodiment of the present 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, send a response result message to the portable device and the target device respectively.
Second, the subway scenario (taking segmented charging as an example)
In some subway scenarios, the segmented charging method is used, and this method needs to know the user's inbound and outbound information. In such scenarios, as shown in FIG. 2B, the target device of this embodiment may be configured at the entrance and exit of the site, and the electronic device may be used as a device to control access; the user’s portable device may be installed with a third-party payment APP or Provide apps such as subway ride services. At the entrance, 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, and the user can make the portable device follow the requirements of the target posture (such as "shake", etc.). When the portable device is in the target posture, the APP installed on the portable device may initiate a payment request, where the payment request may carry a verification password and a target device identification.
After receiving the payment request, the server finds the target device according to the target device identifier of the payment request, and initiates a verification password request to the target device. After receiving, the target device initiates a payment request to the server, and the payment request carries a verification password. Among them, the collection request may carry collection parameters, for example, including the inbound information of the target device.
After receiving it, 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.
After the user leaves the station, the user can also use the same method at the exit to make the portable device close to the target device at the exit and place the portable device in the target posture to issue a payment request. Similarly, after receiving the payment request, the server finds the export target device according to the target device identification of the payment request, and initiates a verification password request to the export target device. The exported target device initiates a payment request to the server, and the payment request carries a verification password. Among them, the payment request may carry the payment parameters, for example, including the outbound information of the target device.
Finally, after calculating the deduction fee based on the inbound information and the outbound information, the server side deducts the payer account based on the collection parameter. After successful processing, send a response result message to the portable device and the target device respectively.
Third, offline payment
In this embodiment, the target device may be deployed in the settlement area of the store, and the user's portable device may be installed with a third-party payment APP, an APP for providing subway ride services, and the like. If the user needs to settle the purchase of goods, 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. According to the requirements of the target posture (such as "shake", etc.), the portable device is placed in the target posture, then the APP installed on the portable device can initiate a payment request, where the payment request can carry the verification password and the target Equipment Identity.
At the same time, the store's payee can automatically trigger the target device to the servo through the trigger interface provided by the target device (the trigger interface can specifically be a physical button on the target device, or an option that can be triggered on the device screen, etc.) The terminal initiates a collection request, which may carry collection parameters such as deduction fees.
After receiving the payment request and the payment request, the server verifies the verification password carried in the payment request. If the verification is passed, the server will perform payment processing and deduct the payment account based on the payment parameter. After successful processing, send a response result message to the portable device and the target device respectively.
The embodiments of the payment processing device in this specification can be applied to portable devices/target devices/servers. The device embodiments can be implemented by software, or by hardware or a combination of hardware and software. Taking software implementation as an example, as a logical device, it is formed by reading the corresponding computer program instructions in the nonvolatile memory into the memory through the processor where the data interacts. From the hardware level, as shown in FIG. 3, it is a hardware structure diagram of the portable device/target device/server where the payment processing device of the embodiment of the present specification is located, except for the processor 310 and memory shown in FIG. In addition to the body 330, the network interface 320, and the non-volatile storage 340, the portable device/target device/server where the device 331 is located in the embodiment is generally based on the portable device/target device/server’s The actual function may also include other hardware, which will not be repeated here.
As shown in FIG. 4, FIG. 4 is a payment processing device according to an exemplary embodiment of the present specification. The device includes:
The posture parameter acquisition module 41 is used to: after determining that a connection signal carrying a verification password is detected, obtain a posture parameter of the device, and the connection signal is sent by the target device;
The payment initiation module 42 is configured to: if the device posture parameter matches the target posture, initiate a payment request to the server, the payment request carrying the verification password for the server to generate based on the target device The verification password verifies the verification password carried in the payment request and responds to the payment request.
Optionally, the connection signal includes: an iBeacon signal.
Optionally, the device is applied to a user terminal, and the user terminal is woken up by an operating system to execute the payment processing method, and the user terminal is woken up after the operating system detects the connection signal.
Optionally, the payment request also carries payment parameters.
Optionally, the connection signal also carries a target device identification, and the payment request also carries the target device identification.
As shown in FIG. 5, FIG. 5 is a payment processing device according to an exemplary embodiment of the present specification. The device includes:
The password generation module 51 is used to: generate a verification password according to the target time period;
The signal sending module 52 is used to: send a connection signal, the connection signal carrying the currently validated authentication password;
The payment initiating module 53 is used to: send a payment request carrying the verification password to the server for the server to respond to the verification password carried in the payment request initiated by the portable device after verification The payment request.
Optionally, the collection initiation module is further configured to: before sending the verification password to the server, receive a verification password sending request initiated by the server.
Optionally, the collection request also carries collection parameters.
Optionally, the connection signal includes: an iBeacon signal.
As shown in FIG. 6, 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 initiated by a portable device and carrying a verification password, wherein the verification password is obtained by the portable device from detecting a connection signal sent by a target device;
The payment request receiving module 62 is configured to: receive a payment request initiated by the target device and carrying a verification password;
The verification module 63 is 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 the verification result.
Optionally, the verification module is also used to:
Verify whether the verification password generated by the target device matches the verification password carried in the payment request.
Optionally, 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 verification password sending request to the target device.
Optionally, the payment request also carries payment parameters, the payment parameters include payer account information, and the collection request also carries collection parameters; the response result includes: payment based on the collection parameters The deduction result of the deduction in the local account.
Optionally, the method further includes: sending a response result message to the portable device and the target device respectively.
Embodiments of this specification also provide a portable device, including a storage, a processor, and a computer program stored on the storage and executable on the processor, where the processor implements the following method when the processor executes the program:
After it is determined that the connection signal carrying the verification password is detected, the posture parameters of the device are obtained, and the connection signal is sent by the target device;
If the posture parameter of the device matches the target posture, a payment request is initiated to the server, and the payment request carries the verification password for the server to carry the payment request according to the verification password generated by the target device After verifying the verification password, respond to the payment request.
Embodiments of the present specification also provide a target device, including a storage, a processor, and a computer program stored on the storage and executable on the processor, where the processor implements the following method when executing the program:
Generate a verification password according to the target time period;
Send a connection signal, the connection signal carries the currently valid authentication password;
Sending a payment request carrying the verification password to the server for the server to verify the verification password carried in the payment request initiated by the portable device.
An embodiment of the present specification also provides a server, including a storage, a processor, and a computer program stored on the storage and executable on the processor, where the processor implements the following method when the processor executes the program:
Receiving a payment request initiated by a portable device and carrying a verification password, wherein the verification password is obtained by the portable device from detecting a connection signal sent by an electronic device;
Receiving a payment request initiated by the electronic device and carrying a verification password;
Verify the verification password carried in the payment request by using the verification password generated by the electronic device;
According to the verification result, it is determined whether to respond to the payment request and the collection request.
For the implementation process of the functions and functions of each module in the above payment processing device, please refer to the implementation process of the corresponding steps in the above payment processing method for details, which will not be repeated here.
For the embodiment of the payment processing device, since it basically corresponds to the embodiment of the payment processing method, the relevant part can be referred to the description of the method embodiment. The device embodiments described above are only schematic, wherein 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. It can be located in one place, or it can be distributed on 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 paying creative labor.
The foregoing describes specific embodiments of the present specification. Other embodiments are within the scope of the attached patent application. In some cases, the actions or steps described in the scope of the patent application may be performed in a different order than in the embodiment and still achieve the desired result. In addition, the processes depicted in the drawings do not necessarily require a particular order of display or sequential order to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.
Those skilled in the art will easily think of other embodiments of the specification after considering the specification and practicing the invention filed here. This specification is intended to cover any variations, uses, or adaptations of this specification. These variations, uses, or adaptations follow the general principles of this specification and include common knowledge or common knowledge in the technical field not applied in this specification. Conventional technical means. The description and examples are only to be regarded as exemplary, and the true scope and spirit of this description are indicated by the following patent application.
It should be understood that this specification is not limited to the precise structure that has been described above and shown in the drawings, and that various modifications and changes can be made without departing from its scope. The scope of this specification is limited only by the scope of the attached patent application.
The above are only the preferred embodiments of this specification and are not intended to limit this specification. Any modification, equivalent replacement, improvement, etc. made within the spirit and principles of this specification should be included in this specification Within the scope of protection.
