CN105205666B - Face-to-face payment method and system based on bluetooth - Google Patents

Abstract

The invention discloses a face-to-face payment method based on bluetooth. The method comprises: the payer client receives the payee information broadcast by the payee client through bluetooth, and the payee information includes the payee's user Identification and signature; according to the received payee information, the payer client sends a transaction message to the third-party background, and the transaction message contains the payee's user identification and the signature; the The third-party background verifies the validity of the signature in the transaction message according to the payee's user ID and the pre-stored signature generation time; after the transaction is successful, the third-party background sends all verified The signature is used as a key to encrypt the transaction identifier, and the encrypted transaction identifier is forwarded to the payee client through the payer client; and the payee client decrypts to obtain the transaction identifier And query the transaction result to the third-party background. The invention also discloses a bluetooth-based face-to-face payment system.

Description

Face-to-face payment method and system based on bluetooth

technical field

The invention relates to the field of face-to-face payment, and more specifically, relates to a bluetooth-based face-to-face payment method and system.

Background technique

The existing face-to-face payment methods mainly include sound wave payment and bar code payment. In the sonic payment, the payer obtains the payee’s information through sonic recognition, and then initiates the payment. Since the sonic is susceptible to environmental interference, the mobile phones of both payers need to be placed within a very close range to ensure the payment is successful. In barcode payment, since the payer obtains the payee's information by scanning the QR code, the payee needs to use the mobile phone to generate the QR code, which requires high participation of the payee.

In addition, due to the short distance requirement, when sonic payment is applied to taxi payment or parking lot payment scenarios, the taxi driver or toll collector needs to bring the mobile phone close to the payer's mobile phone, and after the payer obtains the payee's information, , in order to continue their work, which affects the convenience of collection. However, the requirement of the payee's participation in barcode payment affects the convenience of payment, and the applicable scenarios are limited.

Contents of the invention

In order to solve the limitations of short distance and high participation of the payee in the current face-to-face payment solution, the present invention proposes to broadcast the payee information through low-power Bluetooth, and the payer initiates the payment after receiving the information. Since the bluetooth can establish a connection within a range of 50M for communication, the technical solution of the invention can meet the demand for payment in the middle and long distances. However, due to the risk of information leakage and security risks in broadcasting, this proposal considers various mechanisms to improve information and transaction security during the payment process.

According to one aspect of the present invention, a Bluetooth-based face-to-face payment method is provided, the method comprising: the payer client receives the payee information broadcast by the payee client through Bluetooth, and the payee information includes The payee's user ID and signature; according to the received payee information, the payer client sends a transaction message to the third-party background, and the transaction message includes the payee's user ID and the the signature; the third-party background verifies the validity of the signature in the transaction message according to the payee's user ID and the pre-stored signature generation time; after the transaction is successful, the third-party background, Encrypting the transaction identifier with the verified signature as a key, and forwarding the encrypted transaction identifier to the payee client through the payer client; and decrypting the payee client to obtain Generate the transaction identification and query the transaction result from the third-party background.

In the above method, the payee information also includes service effective distance.

The above method may further include: the payer client filtering the received broadcast message according to the effective service distance.

In the above method, the signature in the payee information is determined according to both the payee's user identification and signature generation time.

The above method may further include: the third-party background generates a second signature after the transaction is successful and sends it to the payee client.

The above method may further include: if the signature used in the successful transaction is not the latest signature, the third-party background does not generate the second signature even if the transaction is successful.

According to another aspect of the present invention, a bluetooth-based face-to-face payment system is provided, the system comprising: a payer client, the payer client configured to receive payment received by the payee client via bluetooth broadcast Person information, the payee information includes the payee's user ID and signature; according to the received payee information, send a transaction message to the third party background, the transaction message contains the payee's User ID and the signature; the third-party background, the third-party background is configured to verify the validity of the signature in the transaction message according to the payee's user ID and the pre-stored signature generation time After the transaction is successful, the verified signature is used as a key to encrypt the transaction identifier, and the encrypted transaction identifier is forwarded to the payee client through the payer client; and the The payee client, the payee client is configured to decrypt and obtain the transaction identifier and query the transaction result from the third-party background.

In the above system, the payee information also includes service effective distance.

In the above system, the payer client is further configured to filter the received broadcast message according to the effective service distance.

In the above system, the signature in the payee information is determined based on both the payee's user identification and signature generation time.

In the above system, the third-party background is further configured to generate a second signature and send it to the payee client after the transaction is successful.

In the above system, the third-party background is further configured: if the signature used in the successful transaction is not the latest signature, the second signature will not be generated even if the transaction is successful.

Since the bluetooth has an effective distance of up to 50M when it is broadcasting, the technical solution of the present invention is widely used, including taxi payment, automatic toll collection in parking lots, and AA payment for dinner parties.

Description of drawings

Those skilled in the art will understand various aspects of the present invention more clearly after reading the detailed description of the present invention with reference to the accompanying drawings. Those skilled in the art should understand that: these drawings are only used to describe the technical solutions of the present invention in conjunction with specific implementation methods, and are not intended to limit the protection scope of the present invention.

Fig. 1 and Fig. 2 are schematic flow charts of a Bluetooth-based face-to-face payment method according to an embodiment of the present invention.

Detailed ways

The following introduces some of the possible embodiments of the present invention, which are intended to provide a basic understanding of the present invention, but are not intended to identify key or decisive elements of the present invention or limit the scope of protection. It is easy to understand that, according to the technical solution of the present invention, those skilled in the art may propose other alternative implementation manners without changing the essence and spirit of the present invention. Therefore, the following specific embodiments and drawings are only exemplary descriptions of the technical solution of the present invention, and should not be regarded as the entirety of the present invention or as a limitation or restriction on the technical solution of the present invention.

Fig. 1 is a schematic flowchart of a Bluetooth-based face-to-face payment method according to an embodiment of the present invention. As shown in Figure 1, the payee first needs to register and log in as a user before using it, and broadcast user ID, title, license plate and other information. After receiving the payment information, the payer selects the payment object according to the received information, then enters the amount and initiates the payment. When the payment is successful, the payer's client will receive a successful payment prompt message, and the payee will also receive a successful reminder, and the payee's client will prompt the transaction status, amount, and payer's identification information through voice to ensure payment The payee does not need to participate in the whole process, which is suitable for taxi collection or parking lot payment scenarios.

The technical solution of the present invention will be further introduced below with reference to FIG. 1 .

1.1 User registration

The payee should register as a user before using it. The registration information should include identity information, mobile phone number, title and other information for identification (such as taxi license plate, etc.). In addition, a bank card should be bound for payment or collection. Payers have no hard requirements for registration.

1.2 User login

The payee should log in before using it. After logging in, the server will record the user's login time and return the user ID and payee's signature.

The payee's signature is generated by the background using the user ID and the current time and sent to the payee. When broadcasting later, this signature is sent to the payer together with the payee ID, and the payer carries it to the background when initiating a transaction. The background verifies that the payee information has not been modified according to the payee ID and signature specified in the transaction, and prevents long-term replay attacks through the time information carried in the signature.

1.3 Payee information broadcast

The payee activates the payment collection function and broadcasts the payee information through low-power bluetooth. The broadcast information includes identification information such as user identification, title, the last 4 digits of the taxi license plate or card number, the signature of the payee, the effective distance of the service, and the payment certificate. Among them, the user ID, title, identification information, payee signature, and service effective distance are set as read-only parameters, allowing the payer client to read; the payment certificate is set as writable and subscribeable attributes, allowing the payer client to Notify the payee client after the payment is completed.

The reason for the setting of the service effective distance is that the Bluetooth broadcast distance is relatively long, and there may be multiple broadcast sources within the receiving range of the client. If the effective distance of the broadcast service is set according to the actual needs, the actual receiving range of the service can be narrowed to the specified effective distance range. Although the client outside the effective distance can receive the broadcast information, the judgment of the effective distance will result in the broadcast The message is discarded, thereby greatly reducing the number of broadcast sources that the client can choose.

In order to avoid leakage of user information caused by broadcasting, the broadcasting information is encrypted with a symmetric key, and this key is built into all clients. The payee client decrypts the information after receiving it to obtain the broadcast information.

1.4 Receive the broadcast and select the payment object

The payer opens the client before paying and receives the broadcast information. Filter the received messages according to the effective distance range, and further obtain the user ID, title, identification information, and payee signature for broadcast messages within the effective distance range, and display the title and identification information in the waiting list beneficiary list. When the client searches for multiple effective broadcast services, they are sorted according to the distance, and the payee information to be selected is displayed in this order.

The payer and the payee verbally confirm the identification information such as title and license plate number, and select the corresponding payment object in the list. The payer client establishes a bluetooth connection with the payee's mobile phone, and subscribes to the "payment certificate" information in the broadcast message to maintain the bluetooth connection.

1.5 Fill in the payment information and initiate a transfer transaction

After confirming the payee's information, the payer clicks the "Pay" button.

The payer selects or fills in the bank card number on the payment interface, and the background returns the corresponding payment elements according to the bank card number; the payer fills in the payment elements and clicks the "OK" button to initiate the payment transaction.

In order to protect the security of user information, in the transfer transaction message, the payer, its transfer card number, password, CVN2, validity period and other information are encrypted; for the payee, the message only contains the user ID and signature, and no transfer Card number and other information.

1.6 If the transfer is successful, notify the payee client

After receiving the transfer transaction, the background checks the time when the signature was generated according to the payee ID appearing in the message, so as to verify the validity of the signature. If the verification is passed, the payee ID will be used to query the payee Specify the receiving account number, and initiate a transfer transaction to the bank.

After the transfer transaction is successful, the background inserts the transaction result into the payment result notification table to notify the payee of the transaction status and amount. And save the transaction information including transaction ID, transaction time, payee user ID, payment card number (not logged in) or payer user ID (logged in), and transaction amount in the transaction record table. The background uses the signature of the payee as the key, encrypts the transaction ID and returns it to the payer client.

After receiving the successful response, the payer client will prompt on the interface that the payment is successful, and modify the previously subscribed "payment certificate" information into an encrypted transaction identifier to notify the payer client to confirm the payment result.

1.7 The payee client confirms the payment result and gives a voice prompt

After obtaining the message that the "payment certificate" has been modified, the payee client uses the current signature to decrypt the transaction ID, and initiates a transaction result confirmation request to the background. According to the transaction identifier, query the transaction status in the payment result notification table, and obtain transaction-related information from the transaction record table. The information returned by the background includes transaction time, transaction status, amount, payer’s title (in the case of login), and the last 4 digits of the card number for identification purposes.

After the query result is returned in the background, the transaction status, amount, title of the payer (in the case of login) and identification information will be prompted by voice.

After querying the payment result, the background generates a new signature based on the current time and user ID, and returns it to the payee client together with the query result response message.

Since the payee does not need to do anything during the entire payment process, and the payment result is also prompted by voice, it is very suitable for the application scenario of taxi payment.

The schematic flow diagram of the Bluetooth-based face-to-face payment method is introduced above with reference to FIG. 1 . Considering that Bluetooth technology is weaker than https protocol in terms of security, in the above scheme, it is preferable to only use Bluetooth to complete payer information discovery and transaction result query triggering, while the payment and result query process are encrypted and protected by HTTP protocol and SSL. Since the information broadcast by Bluetooth is easy to leak, in the above solution, it is preferable to only broadcast non-core information such as user identification, title, and identification information through Bluetooth.

In the above solution, the user ID sent through the Bluetooth broadcast is used to indicate the transfer payee, so the key to security lies in how to prevent the payee's user ID from being tampered with. In order to improve security, in the above scheme, the background uses the user ID and time to generate the payee's signature, forwards the signature to the payer during the transaction, and carries the signature in the payment transaction to ensure the payment transaction message. The beneficiary user ID is consistent with the signature. The specific process can be seen in Figure 2 and shown as follows:

1) When logging in, the background generates a signature based on the login user ID and the current time, sends it to the payee client, and records the time when each user ID generates a signature;

2) The payee client broadcasts the signature together with the user ID to the payer;

3) After the payer client selects and confirms the payee, it initiates a payment transaction, and carries the payee's ID and signature in the transaction message;

4) The background verifies the validity of the signature based on the payee’s ID and the recorded signature generation time. If the signatures are inconsistent, it indicates that the user ID or signature has been tampered with, and the transaction is rejected; if the signatures are consistent, but the generation time exceeds the validity period control value (for example, 5 minutes ), it may be a replay attack of the signature information in the previous successful transaction, and the transaction will also be rejected;

5) After the transaction is successful, the background will encrypt the transaction ID with the signature as the key, and forward it to the payee client through the payer client;

6) The payee client uses a valid key to decrypt the transaction identifier and query the transaction result;

7) Generate a new key in the background and send it to the payee client. To prevent too many valid keys in the validity period control value, if the current transaction uses a non-latest key, no new key will be generated.

In the multi-payer payment scenario, multiple payers may initiate a payment transaction at the same time, and the signature information carried in the transaction may be the same, but when the first payment transaction is completed, the signature is updated, and at this time other The signature of the transaction in is not up-to-date, but should be within the validity period. Therefore, in the above steps 4) and 6), when verifying and decrypting the signature, the latest signature generation time is used for calculation first, and when it fails, other signature generation times within the validity period control value are used for calculation.

Some typical security attack scenarios are analyzed below to illustrate that the technical solution of the present invention can ensure transaction security in these scenarios.

Scenario 1: The payee client is tampered with, and the third party payee information is released or the payee ID is tampered with during broadcasting

Since the information of the transfer-in card is queried according to the user ID of the payee in the transfer transaction, if the ID of the payee is tampered with the ID of a third party, the transfer will cause the payer to transfer money to the third party, resulting in financial losses.

If only the payee's ID is tampered with, the backend can find that the user ID has been modified through signature verification in the payment transaction and reject the transaction.

If the payee's ID and signature are tampered with at the same time, the transaction can be completed within the valid period control value; however, when the payer client queries the transaction result, the background can find that the payer's ID does not match according to the login user's SESSION information, and proceed according to the payee's account information chasing money.

Scenario 2: The payer's client is tampered with, and the transfer is initiated using a third-party ID

If the payer's client is tampered with, although the payee information selected by the payer is true, but when the transfer transaction is initiated, as long as the payer's ID is tampered with a third party's ID, the payer will be tricked into paying the third party transfer, resulting in financial loss.

After receiving the result notification, the payee client will continue to use the real user ID to query the transaction status, and after finding that the amount has not been transferred to the payee's account, contact the customer service personnel through the payer for transaction verification and payment recovery.

Scenario 3: The payer client fails to complete the payment, and uses the "payment certificate" of historical successful transactions to send a false success notification to the payee

After receiving the successful notification, the payee client will query the result through the transaction result notification table according to the user ID and transaction ID. For historically successful transactions that have been successfully notified, since the relevant records cannot be queried in the result notification table, the payee client will use the user ID to query historically successful transactions, allowing the payee to manually confirm whether the transaction is successful, and fraud cannot succeed.

In addition, there may be an abnormal situation where the payer makes the payment successfully, but the payee does not respond to querying the transaction status. For this abnormal situation, the present invention proposes following solutions:

1) The transaction result was queried in the background. During the response process, the client did not receive a response due to network communication failure. When querying again, because no relevant records could be queried in the transaction result notification form, there was no response to the client. Afterwards, the client only queries the historical transaction records based on the user ID, and manually confirms whether it is successful;

2) When processing the query request, due to network reasons or other factors, the background has not completed querying the transaction result from the transaction result notification table; when querying again, the background will repeat the normal query operation;

3) If it still times out when trying to query again, the client will retry up to 3 times, and then only query the historical transaction records based on the user ID, and manually confirm whether it is successful.

The technical solution of the present invention is described above with reference to FIG. 1 and FIG. 2 . Compared with the existing face-to-face payment scheme, this technical scheme can realize the payment between the two parties within a larger distance (not less than 20M). In addition, in the payment process of the present invention, only a client such as a mobile phone needs to be used without additional equipment; and the payee does not need additional operations (low participation), which is very suitable for taxi collection and self-parking Field collection and other scenarios. In addition, the technical solution of the present invention is also suitable for the AA payment scenario where multiple payers simultaneously initiate payment by supporting multiple keys.

Hereinbefore, specific embodiments of the present invention have been described with reference to the accompanying drawings. However, those skilled in the art can understand that without departing from the spirit and scope of the present invention, various changes and substitutions can be made to the specific embodiments of the present invention. These changes and substitutions all fall within the scope defined by the claims of the present invention.

Claims (10)

1. A face-to-face payment method based on bluetooth, said method comprising: The third-party background generates a signature according to the user ID and login time of the payee client, sends the signature to the payee client and records the signature generation time of each user ID; The third-party background receives a transaction message from the payer client, and the transaction message includes the payee information that the payee client broadcasts to the payer client via Bluetooth, and the payee information including said user identification and said signature; The third-party background verifies the validity of the signature in the transaction message according to the user ID and the recorded signature generation time; After the transaction is successful, the third-party background uses the verified signature as a key to encrypt the transaction identifier, and forwards the encrypted transaction identifier to the payee client through the payer client, The payee client can decrypt to obtain the transaction identifier and query the transaction result from the third-party background. 2. The method according to claim 1, wherein the payee information further includes service effective distance. 3. The method of claim 2, further comprising: The payer client filters the received broadcast message according to the service effective distance. 4. The method according to claim 1, further comprising: the third-party background generates a second signature after the transaction is successful and sends it to the payee client. 5. The method according to claim 4, further comprising: if the signature used in the successful transaction is not the latest signature, the third-party background does not generate the second signature even if the transaction is successful. 6. A face-to-face payment system based on bluetooth, said system comprising: The payer client, the payer client is configured to receive the payee information broadcast by the payee client via Bluetooth, the payee information includes the user identification and signature of the payee client; according to the received Payee information, sending a transaction message to the third-party background, the transaction message includes the user identification and the signature; The third-party background, the third-party background is configured to generate a signature according to the user ID and login time of the payee client, send the signature to the payee client and record the signature of each user ID Generation time; according to the user identification and the recorded signature generation time, verify the validity of the signature in the transaction message; after the transaction is successful, use the verified signature as a key to perform transaction identification encrypting, and forwarding the encrypted transaction identifier to the payee client through the payer client; and The payee client, the payee client is configured to decrypt and obtain the transaction identifier, and query the transaction result from the third-party background. 7. The system according to claim 6, wherein the payee information further includes service effective distance. 8. The system according to claim 7, wherein the payer client is further configured to filter the received broadcast message according to the effective service distance. 9. The system according to claim 6, wherein the third-party background is further configured to generate a second signature and send it to the payee client after the transaction is successful. 10. The system according to claim 9, wherein the third-party background is further configured to: if the signature used in the successful transaction is not the latest signature, the second signature will not be generated even if the transaction is successful.