WO2015101057A1

WO2015101057A1 - Data processing method and related device and system

Info

Publication number: WO2015101057A1
Application number: PCT/CN2014/085657
Authority: WO
Inventors: Wei Liu
Original assignee: Tencent Technology (Shenzhen) Company Limited
Priority date: 2013-12-30
Filing date: 2014-09-01
Publication date: 2015-07-09
Also published as: CN104751326A

Abstract

A method at a computer system includes: receiving, from a first client associated with a first party, a request for a transaction; receiving, from the first client, a first identification information and a second identification information; identifying a first account associated with the first party based on the first identification information and a second account associated with a second party based on the second identification information; sending a request for transaction verification information to a second client associated with the second party and identified based on the second identification information; receiving, from the second client, transaction verification information; determining whether the transaction verification information matches a verification key associated with the second account; if the transaction verification information matches the verification key, completing the transaction using the first account and the second account; and if the transaction verification information does not match the verification key, aborting the transaction.

Description

DATA PROCESSING METHOD AND RELATED DEVICE AND SYSTEM

RELATED APPLICATION

This application claims priority to Chinese Patent Application No. 201310746459.1, entitled “Data Processing Method and Related Device and System, ” filed on December 30, 2013, which is incorporated by reference in its entirety.

TECHNICAL FIELD

The present application relates to the field of Internet technologies, and in particular, to a data processing method and related devices and system.

BACKGROUND

In daily life, a user usually may use a credit card for payment when shopping, and such a credit card payment manner may effectively solve a lot of inconvenience brought about by carrying a large amount of cash. In practical applications, when a user uses a credit card for payment on a transaction terminal, a user account is easily acquired by a transaction terminal through illegal crack, so there is a risk that the credit card is pilfer brushed, resulting in poor payment security.

SUMMARY

In accordance with some embodiments, a method at a computer system comprises: receiving, from a first client, a transaction request for a transaction between a first party and a second party, where the first client is associated with the first party； receiving, from the first client, a first identification information and a second identification information； identifying a first account associated with the first party based on the first identification information and a second account associated with the second party based on the second identification information； sending a request for transaction verification information corresponding to the transaction to a second client associated with the second party, where the second client is identified based on the second identification information； receiving, from the second client, transaction verification information for the transaction； determining whether the transaction verification information matches a verification key associated with the second account； in accordance with a determination that the transaction verification information matches the verification key, completing the transaction using the first account and the second account； and in accordance with a determination that the transaction verification information does not match the verification key, aborting the transaction.

In accordance with some embodiments, a computer system comprises memory, one or more processors, and one or more programs, where the one or more programs are stored in the memory and configured to be executed by the one or more processors. The one or more programs comprise instructions for: receiving, from a first client, a transaction request for a transaction between a first party and a second party, where the first client is associated with the first party； receiving, from the first client, a first identification information and a second identification information； identifying a first account associated with the first party based on the first identification information and a second account associated with the second party based on the second identification information； sending a request for transaction verification information corresponding to the transaction to a second client associated with the second party, where the second client is identified based on the second identification information； receiving, from the second client, transaction verification information for the transaction； determining whether the transaction verification information matches a verification key associated with the second account； in accordance with a determination that the transaction verification information matches the verification key, completing the transaction using the first account and the second account； and in accordance with a determination that the transaction verification information does not match the verification key, aborting the transaction.

In accordance with some embodiments, a non-transitory computer readable storage medium stores one or more programs, the one or more programs comprising instructions, which when executed by a computer system, cause the computer system to: receive, from a first client, a transaction request for a transaction between a first party and a second party, where the first client is associated with the first party； receive, from the first client, a first identification information and a second identification information； identify a first account associated with the first party based on the first identification information and a second account associated with the second party based on the second identification information； send a request for transaction verification information corresponding to the transaction to a second client associated with the second party, where the second client is identified based on the second identification information； receive, from the second client, transaction verification information for the transaction； determine whether the transaction verification information matches a verification key associated with the second account； in accordance with a determination that the transaction verification information matches the verification key, complete the transaction using the first account and the second account； and in accordance with a determination that the transaction verification information does not match the verification key, abort the transaction.

BRIEF DESCRIPTION OF THE DRAWINGS

The aforementioned features and advantages of the present application as well as additional features and advantages thereof will be more clearly understood hereinafter as a result of a detailed description of preferred embodiments when taken in conjunction with the drawings.

To illustrate the technical solutions according to the embodiments of the present application more clearly, the accompanying drawings for describing the embodiments are introduced briefly in the following. Apparently, the accompanying drawings in the following description are only some embodiments of the present application； persons of ordinary skill in the art may obtain other drawings according to the accompanying drawings without paying any creative efforts.

FIG. 1 is a flow chart of one data processing method according to an embodiment of the present application；

FIG. 2 is a flow chart of another data processing method according to an embodiment of the present application；

FIG. 3 is a flow chart of yet another data processing method according to an embodiment of the present application；

FIG. 4 is a schematic view of one interface where a client prompts a user to input payment verification information according to an embodiment of the present application；

FIG. 5 is a schematic view of another interface where a client prompts a user to input payment verification information according to an embodiment of the present application；

FIG. 6 is a flow chart of another data processing method according to an embodiment of the present application；

FIG. 7 is a flow chart of yet another data processing method according to an embodiment of the present application；

FIG. 8 is a schematic structural view of one client according to an embodiment of the present application；

FIG. 9 is a schematic structural view of another client according to an embodiment of the present application；

FIG. 10 is a schematic structural view of one data processing apparatus according to an embodiment of the present application；

FIG. 11 is a schematic structural view of another data processing apparatus according to an embodiment of the present application； and

FIG. 12 is a schematic structural view of a data processing system according to an embodiment of the present application.

FIG. 13 is a block diagram of a client according to some embodiments of the present application.

FIG. 14 is a block diagram of a server system according to some embodiments of the present application.

FIGS. 15A-15B is a flow diagram of a data processing method according to some embodiments of the present application.

Like reference numerals refer to corresponding parts throughout the several views of the drawings.

DESCRIPTION OF EMBODIMENTS

Reference will now be made in detail to embodiments, examples of which are illustrated in the accompanying drawings. In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the subject matter presented herein. But it will be apparent to one skilled in the art that the subject matter may be practiced without these specific details. In other instances, well-known methods, procedures, components, and circuits have not been described in detail so as not to unnecessarily obscure aspects of the embodiments.

The technical solution in the embodiments of the present application will be clearly and fully described below with reference to the accompanying drawings in the embodiments of the present application. It is obvious that the embodiments to be described are only a part rather than all of the embodiments of the present application. All other embodiments derived by persons of ordinary skill in the art based on the embodiments of the present application without carrying out creative activities should fall within the scope of the present application.

The embodiments of the present application disclose a data processing method and related devices and system, which could effectively improve payment security. Detailed description is given below respectively.

Referring to FIG. 1, FIG. 1 is a flow chart of one data processing method according to an embodiment of the present application. The data processing method described in FIG. 1 is mainly described from a first client side. As shown in FIG. 1, the data processing method may include the following steps.

S101. A first client receives a payment value.

In this embodiment of the present application, for instance, the first client may receive an input operation order including a payment value.

In this embodiment of the present application, the first client may include a cashier device, for example, a POS machine or any other terminal device having a payment function, and may also include a smart phone (for example, an Android phone, an iOS phone or the like) , a tablet PC, a handheld computer, a mobile internet device (MID) , a PAD, a PC, a smart device and other terminal devices having an online transaction function.

In this embodiment of the present application, the first client may also include application clients (for example, social application clients) installed to the above terminal devices, which is not limited in this embodiment of the present application.

S102. The first client receives input key payment information, where the key payment information includes at least a part of a first identification or a part of more than two first identifications.

In this embodiment of the present application, the first client may receive the key payment information input in a text manner or a voice manner.

In this embodiment of the present application, the first identification may include a mobile phone number, an ID number, a card number, a social account and a user name. For example, the last four numbers of a mobile phone number (that is, at least a part of a first identification) may be used as key payment information； alternatively, the last four numbers of a mobile phone number and the last four numbers of a social account (that is, a part of more than two first identifications) may be used as key payment information. It should be noted that, a part of more than two first identifications used as key payment information may be flexibly combined, as long as key payment information determined by such flexible combinations could determine a unique third identification, which is not limited in this embodiment of the present application.

As an alternative implementation manner, after the first client executes S101, the first client may prompt input of the key payment information, and then the step S102 is executed, which is not limited in this embodiment of the present application.

S103. The first client sends the payment value and the key payment information to a third party through a payment order, where the payment order further includes a second identification registered by the first client on a platform or an application of the third party, so that after the third party determines a third identification registered on the platform or the application of the third party corresponding to the key payment information according to the key payment information included in the payment order, the third party subtracts a value corresponding to the payment value from an account corresponding to or bound to the third identification, and adds the corresponding value to an account corresponding to or bound to the second identification.

In this embodiment of the present application, the third party refers to a social payment platform, a social payment application or the like except a payer and a payee.

In this embodiment of the present application, the second identification registered by the first client on a platform or an application of the third party refers to identity information for identifying the first client registered by the first client on the platform or the application of the third party. For example, when the first client is a social client, the second identification registered by the first client on the platform or the application of the third party may be a social account.

In this embodiment of the present application, the third identification registered on the platform or the application of the third party refers to identity information for identifying a second client registered by the second client on the platform or the application of the third party. For example, when the second client is a social client, the third identification registered by the second client on the platform or the application of the third party may be a social account.

In this embodiment of the present application, the account corresponding to the third identification may be a payment account registered by the second client on the platform or the application of the third party, and the account bound to the third identification may be a fourth-party payment account registered by the second client in a fourth party. For example, when the third party is a social payment platform, the account corresponding to the third identification may be a payment account registered by the second client in the social payment platform, and the account bound to the third identification may be a payment account registered by the second client in a bank payment system (that is, a fourth party) .

In this embodiment of the present application, the account corresponding to the second identification may be a payment account registered by the first client on the platform or the application of the third party, and the account bound to the second identification may be a fourth-party payment account registered by the first client in a fourth party. For example, when the third party is a social payment platform, the account corresponding to the second identification may be a payment account registered by the first client in the social payment platform, and the account bound to the second identification may be a payment account registered by the first client in a bank payment system (that is, a fourth party) .

As an alternative embodiment, in the method described in FIG. 1, the first terminal may further receive a value processing result (that is, payment operation result) sent by the third party.

As an alternative embodiment, in the method described in FIG. 1, the first terminal may further execute the following operations:

11) . the first client receives payment prompt information sent by the third party, where the payment prompt information is used for prompting sending of payment verification information； and

12) . the first client sends the input payment verification information to the third party, so that the third party compares whether the payment verification information is identical with payment verification information corresponding to the account corresponding to or bound to the third identification stored by the third party.

Correspondingly, after the third party compares that the payment verification information is identical with the payment verification information corresponding to the account corresponding to or bound to the third identification stored by the third party, the third party may subtract a value corresponding to the payment value from the account corresponding to or bound to the third identification, and add the corresponding value to the account corresponding to or bound to the second identification； on the contrary, after the third party compares that the payment verification information is not identical with the payment verification information corresponding to the account corresponding to or bound to the third identification stored by the third party, the third party may refuse to execute the payment operation, that is to say, the third party may refuse to subtract a value corresponding to the payment value from the account corresponding to or bound to the third identification, and refuse to add the corresponding value to the account corresponding to or bound to the second identification, so that the payment security could be further improved.

In this embodiment of the present application, the payment verification information may include payment password and/or user physiological feature information, where the user physiological feature information includes a combination of one or more of user fingerprint information, user facial information and user audio information. Particularly, when the user physiological feature information includes a combination of more of user fingerprint information, user facial information and user audio information, the payment security could be better improved.

In this embodiment of the present application, the third party may pre-store a corresponding relationship between the third identification and the first identification, so that the unique third identification could be determined according to the key payment information.

Thus, through the data processing method described in FIG. 1, a user using a credit card for payment on a transaction terminal may be omitted, and the user account being acquired by a transaction terminal through illegal crack may be prevented, so that a risk that the credit card is pilfer brushed is eliminated and payment security is effectively improved.

Referring to FIG. 2, FIG. 2 is a flow chart of another data processing method according to an embodiment of the present application. The data processing method described in FIG. 2 is mainly described from a third party (for example, a social payment platform) side. As shown in FIG. 2, the data processing method may include the following steps.

S201. A third party receives a payment value and key payment information sent by a first client through a payment order； where the payment order includes a second identification registered by the first client on a platform or an application of the third party； and where the key payment information includes at least a part of a first identification or a part of more than two first identifications.

In this embodiment of the present application, the third party may connect the first client via Internet, so that the third party could receive a payment value and key payment information sent by a first client through a payment order via the Internet.

S202. The third party determines a third identification registered on a platform or an application of the third party corresponding to the key payment information according to the key payment information included in the payment order.

For example, if the key payment information included in the payment order is "7575 (that is, the last four numbers of a mobile phone number) + 8888 (the last four numbers of a social account) , " the third party may determine a third identification, for example, "132456qq, " registered on a platform or an application of the third party corresponding to the key payment information "7575 (that is, the last four numbers of a mobile phone number) + 8888 (the last four numbers of a social account) . "

S203. The third party subtracts a value corresponding to the payment value from an account corresponding to or bound to the third identification, and adds the corresponding value to an account corresponding to or bound to the second identification.

The above example is taken as an example, and the third party may deduct a value corresponding to the payment value from an account "xxxxxxxxxxxx" corresponding to or bound to the third identification "132456qq" registered on the platform or the application of the third party corresponding to the key payment information "7575 (that is, the last four numbers of a mobile phone number) + 8888 (the last four numbers of a social account) , " and add the corresponding value to an account corresponding to or bound to the second identification, so as to complete the payment operation.

In this embodiment of the present application, the account "xxxxxxxxxxxx" corresponding to or bound to the third identification "132456qq" may be a payment account registered by a second client registered on the platform or the application of the third party, and may also be a fourth-party payment account registered by the second client in a bank payment system (that is, a fourth party) .

As an alternative implementation manner, in the method described in FIG. 2, after the third party executes the step S203, the third party may further send a value processing result (that is, payment operation result) to the first client corresponding to the second identification and/or the second client corresponding to the third identification.

In this embodiment of the present application, the second client may include a cashier device, for example, a POS machine or any other terminal device having a payment function, and may also include a smart phone (for example, an Android phone, an iOS phone or the like) , a tablet PC, a handheld computer, an MID, a PAD, a PC, a smart device and other terminal devices having an online transaction function.

In this embodiment of the present application, the second client may also include application clients (for example, social application clients) installed to the above terminal devices, which is not limited in this embodiment of the present application.

As an alternative implementation manner, in the method described in FIG. 2, before completing the step S203, the third party may further execute the following steps:

21) . the third party sends payment prompt information to the first client corresponding to the second identification or the second client corresponding to the third identification, where the payment prompt information is used for prompting sending of payment verification information； and

22) . the third party receives the payment verification information sent by the first client or the second client, and compares whether the payment verification information is identical with payment verification information corresponding to the account corresponding to or bound to the third identification stored by the third party.

Thus, through the data processing method described in FIG. 2, a user using a credit card for payment on a transaction terminal may be omitted, and the user account being acquired by a transaction terminal through illegal crack may be prevented, so that a risk that the credit card is pilfer brushed is eliminated and payment security is effectively improved.

Referring to FIG. 3, FIG. 3 is a flow chart of yet another data processing method according to an embodiment of the present application. The data processing method described in FIG. 3 is still described from a third party (for example, a social payment platform) side. As shown in FIG. 3, the data processing method may include the following steps.

S301. A third party receives a payment value and key payment information sent by a first client through a payment order； where the payment order includes a second identification registered by the first client on a platform or an application of the third party； and where the key payment information includes at least a part of a first identification or a part of more than two first identifications.

In this embodiment of the present application, the third party may connect the first client via Internet, so that the third party could receive a payment value and key payment information sent by a first client through a payment order via the Internet

S302. The third party determines a third identification registered on the platform or the application of the third party corresponding to the key payment information according to the key payment information included in the payment order.

S303. The third party sends payment prompt information to a second client corresponding to the third identification, where the payment prompt information is used for prompting sending of payment verification information.

In this embodiment of the present application, if the third party determines that the third identification registered on a platform or an application of the third party corresponding to the key payment information "7575 (that is, the last four numbers of a mobile phone number) + 8888 (the last four numbers of a social account) " is "132456qq, " the third party may send payment prompt information to a second client corresponding to the third identification "132456qq, " where the payment prompt information is used for prompting sending of payment verification information.

For example, after receiving the payment prompt information sent by the third party, the second client may prompt a user to input payment verification information through a display screen. For example, as shown in FIG. 4, the second client may prompt the user to input payment password in a payment password box, and after receiving that the user has input the payment password in the payment password box, the second client may send the payment password to the third party for verification. For another example, as shown in FIG. 5, the second client may prompt the user to input payment password in a payment password box and input user fingerprint information in a fingerprint input region, and after receiving that the user has input the payment password in the payment password box and has input the user fingerprint information in the fingerprint input region, the second client may send the payment password and the user fingerprint information to the third party for verification.

S304. The third party receives the payment verification information sent by the second client, and compares whether the payment verification information is identical with payment verification information corresponding to the account corresponding to or bound to the third identification stored by the third party, if they are identical, step S305 is executed； and if they are not identical, the process is ended.

In this embodiment of the present application, if the third party sends payment prompt information to the second client corresponding to the third identification "132456qq, " the third party, after receiving the payment verification information sent by the second client, may compare whether the payment verification information is identical with payment verification information corresponding to the account corresponding to or bound to the third identification "132456qq" stored by the third party, if they are identical, step S305 is executed； and if they are not identical, the process is ended.

In this embodiment of the present application, after the third party compares that the payment verification information is not identical with the payment verification information corresponding to the account corresponding to or bound to the third identification "132456qq" stored by the third party, the third party may refuse to execute the payment operation, that is to say, the third party may refuse to subtract a value corresponding to the payment value from the account corresponding to or bound to the third identification "132456qq, " and refuse to add the corresponding value to the account corresponding to or bound to the second identification, so that the payment security could be further improved.

In one embodiment, after the third party compares that the payment verification information sent by the second client is not identical with payment verification information corresponding to the account corresponding to or bound to the third identification "132456qq" stored by the third party, the third party may further send a payment failure notification message to the first client, where the payment failure notification message may include prompt information for prompting failure of identity verification.

S305. The third party subtracts a value corresponding to the payment value from an account corresponding to or bound to the third identification, and adds the corresponding value to an account corresponding to or bound to the second identification.

In this embodiment of the present application, the account "xxxxxxxxxxxx" corresponding to or bound to the third identification "132456qq" may be a payment account registered by the second client registered on the platform or the application of the third party, and may also be a fourth-party payment account registered by the second client in a bank payment system (that is, a fourth party) .

S306. The third party sends a value processing result to the first client corresponding to the second identification.

In this embodiment of the present application, identity verification may be achieved through the steps S303 and S304, and after the identity verification passes, the step S305 is executed to perform the payment operation, so that the payment security could be better improved. Certainly, in some micro-payment environments, identity verification may not be necessary, and after completion of the steps S301-S302, the step S305 may be directly executed to perform the payment operation.

Thus, through the data processing method described in FIG. 3, a user using a credit card for payment on a transaction terminal may be omitted, and the user account being acquired by a transaction terminal through illegal crack may be prevented, so that a risk that the credit card is pilfer brushed is eliminated and payment security is effectively improved.

Referring to FIG. 6, FIG. 6 is a flow chart of another data processing method according to an embodiment of the present application. The data processing method described in FIG. 6 is described from three sides, a first client, a third party and a second client. As shown in FIG. 6, the data processing method may include the following steps.

S601. A first client receives a payment value.

S602. The first client receives input key payment information, where the key payment information includes at least a part of a first identification or a part of more than two first identifications.

As an alternative implementation manner, after the first client executes S601, the first client may prompt input of the key payment information, and then the step S602 is executed, which is not limited in this embodiment of the present application.

S603. The first client sends the payment value and the key payment information to a third party through a payment order, where the payment order further includes a second identification registered by the first client on a platform or an application of the third party.

S604. The third party receives the payment value and the key payment information sent by the first client through the payment order, and determines a third identification registered on the platform or the application of the third party corresponding to the key payment information according to the key payment information included in the payment order.

S605. The third party sends payment prompt information to a second client corresponding to the third identification, where the payment prompt information is used for prompting sending of payment verification information.

S606. The second client prompts a user to input payment verification information after receiving the payment prompt information sent by the third party.

S607. The second client sends the payment verification information input by the user to the third party.

For example, after receiving the payment prompt information sent by the third party, the second client may prompt the user to input payment verification information through a display screen. For example, as shown in FIG. 4, the second client may prompt the user to input payment password in a payment password box, and after receiving that the user has input the payment password in the payment password box, the second client may send the payment password to the third party for verification. For another example, as shown in FIG. 5, the second client may prompt the user to input payment password in a payment password box and input user fingerprint information in a fingerprint input region, and after receiving that the user has input the payment password in the payment password box and has input the user fingerprint information in the fingerprint input region, the second client may send the payment password and the user fingerprint information to the third party for verification.

S608. The third party receives the payment verification information sent by the second client, and compares whether the payment verification information is identical with payment verification information corresponding to the account corresponding to or bound to the third identification stored by the third party, if they are identical, step S609 is executed； and if they are not identical, the process is ended.

In this embodiment of the present application, if the third party sends payment prompt information to the second client corresponding to the third identification "132456qq, " the third party, after receiving the payment verification information sent by the second client, may compare whether the payment verification information is identical with payment verification information corresponding to the account corresponding to or bound to the third identification "132456qq" stored by the third party, if they are identical, step S609 is executed； and if they are not identical, the process is ended.

S609. The third party subtracts a value corresponding to the payment value from an account corresponding to or bound to the third identification, and adds the corresponding value to an account corresponding to or bound to the second identification.

S610. The third party sends a value processing result to the first client corresponding to the second identification.

S611. The third party sends the value processing result to the second client corresponding to the third identification.

Thus, through the data processing method described in FIG. 6, a user using a credit card for payment on a transaction terminal may be omitted, and the user account being acquired by a transaction terminal through illegal crack may be prevented, so that a risk that the credit card is pilfer brushed is eliminated and payment security is effectively improved.

Referring to FIG. 7, FIG. 7 is a flow chart of yet another data processing method according to an embodiment of the present application. The data processing method described in FIG. 7 is described from multiple sides, a user, a business, a first client, a third party and a second client. The first client uses a cashier device as an example, the third party uses a social payment platform as an example, and the second client uses a smart phone as an example. As shown in FIG. 7, the data processing method may include the following steps.

S701. A user pays for shopping, and negotiates with a business about payment.

S702. The business inputs a payment value to a cashier device (that is, a first client) .

S703. The cashier device prompts the business to input key payment information.

S704. The business notifies the user to report the key payment information.

S705. The business receives the key payment information reported by the user.

In this embodiment of the present application, the key payment information may include at least a part of a first identification or a part of more than two first identifications. The first identification may include a mobile phone number, an ID number, a card number, a social account or a user name. Particularly, when the key payment information is a part of more than two first identifications, a unique third identification may be better determined according to the key payment information.

S706. The business input the key payment information to the cashier device.

S707. The cashier device sends the payment value and the key payment information to a social payment platform (that is, a third party) through a payment order,where the payment order further includes a second identification registered by the cashier device in an application of the social payment platform.

For example, the second identification registered by the cashier device in an application of the social payment platform may be a social account.

S708. The social payment platform receives the payment value and the key payment information sent by the cashier device through the payment order, and determines a third identification registered in the application of the social payment platform corresponding to the key payment information according to the key payment information included in the payment order.

For example, if the key payment information included in the payment order is "7575 (that is, the last four numbers of a mobile phone number) + 8888 (the last four numbers of a social account) , " the social payment platform may determine a third identification, for example, "132456qq, " registered in an application of the social payment platform corresponding to the key payment information "7575 (that is, the last four numbers of a mobile phone number) + 8888 (the last four numbers of a social account) . "

S709. The social payment platform sends payment prompt information to a smart phone (that is, a second client) corresponding to the third identification, where the payment prompt information is used for prompting sending of payment verification information.

In this embodiment of the present application, if the social payment platform determines that the third identification registered in an application of the social payment platform corresponding to the key payment information "7575 (that is, the last four numbers of a mobile phone number) + 8888 (the last four numbers of a social account) " is "132456qq, " the social payment platform may send payment prompt information to the smart phone corresponding to the third identification "132456qq, " where the payment prompt information is used for prompting sending of payment verification information.

S710. The smart phone, after receiving the payment prompt information sent by the social payment platform, prompts the user to input payment verification information.

S711. The smart phone sends the payment verification information input by the user to the social payment platform.

S712. The social payment platform receives the payment verification information sent by the smart phone, and compares whether the payment verification information is identical with payment verification information corresponding to an account corresponding to or bound to the third identification stored by the social payment platform, if they are identical, step S713 is executed； and if they are not identical, the process is ended.

In this embodiment of the present application, if the social payment platform sends payment prompt information to the smart phone corresponding to the third identification "132456qq, " the social payment platform, after receiving payment verification information sent by the smart phone, may compare whether the payment verification information is identical with payment verification information corresponding to the account corresponding to or bound to the third identification "132456qq" stored by the social payment platform, if they are identical, step S713 is executed； and if they are not identical, the process is ended.

In this embodiment of the present application, after the social payment platform compares that the payment verification information is not identical with payment verification information corresponding to the account corresponding to or bound to the third identification "132456qq" stored by the social payment platform, the social payment platform may refuse to execute the payment operation, that is to say, the social payment platform may refuse to subtract a value corresponding to the payment value from the account corresponding to or bound to the third identification "132456qq, " and refuse to add the corresponding value to an account corresponding to or bound to the second identification, so that the payment security could be further improved.

S713. The social payment platform subtracts a value corresponding to the payment value from the account corresponding to or bound to the third identification, and adds the corresponding value to an account corresponding to or bound to the second identification.

The above example is taken as an example, and the social payment platform may deduct a value corresponding to the payment value from an account "xxxxxxxxxxxx" corresponding to or bound to the third identification "132456qq" registered in the application of the social payment platform corresponding to the key payment information "7575 (that is, the last four numbers of a mobile phone number) + 8888 (the last four numbers of a social account) , " and add the corresponding value to the account corresponding to or bound to the second identification, so as to complete the payment operation.

In this embodiment of the present application, the account "xxxxxxxxxxxx" corresponding to or bound to the third identification "132456qq" may be a payment account registered by the smart phone registered in the application of the social payment platform, and may also be a fourth-party payment account registered by the smart phone in a bank payment system (that is, a fourth party) .

S714. The social payment platform sends a data processing result (that is, payment operation result) to the cashier device.

S715. The cashier device outputs the data processing result to the business.

S716. The business and the user complete invoicing, delivery and other subsequent procedures.

Thus, through the data processing method described in FIG. 7, a user using a credit card for payment on a transaction terminal may be omitted, and the user account being acquired by a transaction terminal through illegal crack may be prevented, so that a risk that the credit card is pilfer brushed is eliminated and payment security is effectively improved.

The above introduces the data processing methods according to the embodiments of the present application, in the data processing methods according to the embodiments of the present application, when a user pays for shopping, a business may input a payment value that the user needs to pay to a cashier device, and input, for example, key payment information consisting of the last four numbers of a mobile phone number and the last four numbers of a social account provided by the user, to the cashier device, so as to trigger the cashier device to send the payment value and the key payment information to a social payment platform through a payment order, where the payment order further includes a second identification (for example, a social account) registered by the cashier device in an application of the social payment platform, so that the social payment platform may determine a third identification (for example, a social account) registered by a user smart phone in the application of the social payment platform corresponding to the key payment information according to the key payment information consisting of the last four numbers of a mobile phone number and the last four numbers of a social account included in the payment order, and thus the social payment platform may subtract a value corresponding to the payment value from an account corresponding to or bound to the third identification, and add the corresponding value to an account corresponding to or bound to the second identification, thereby completing data processing and achieving the payment operation. The embodiments of the present application may omit that a user uses a credit card for payment on a transaction terminal, and prevent that the user account is acquired by a transaction terminal through illegal crack, so that a risk that the credit card is pilfer brushed is eliminated and payment security is effectively improved.

Referring to FIG. 8, FIG. 8 is a schematic structural view of one client according to an embodiment of the present application. As shown in FIG. 8, the client 800 may include:

a receiving unit 801, for receiving a payment value, and receiving input key payment information； where the key payment information includes at least a part of a first identification or a part of more than two first identifications； and

a sending unit 802, for sending the payment value and the key payment information to a third party through a payment order, where the payment order further includes a second identification registered by the client 800 on a platform or an application of the third party, so that, after the third party determines a third identification registered on the platform or the application of the third party according to the key payment information according to the key payment information included in the payment order, the third party subtracts a value corresponding to the payment value from an account corresponding to or bound to the third identification, and adds the corresponding value to an account corresponding to or bound to the second identification.

In this embodiment of the present application, the account bound to the third identification includes a fourth-party payment account.

In this embodiment of the present application, the receiving unit 801 is further used for receiving a value processing result sent by the third party.

As an alternative implementation manner, in the client shown in FIG. 8, the receiving unit 801 is further used for receiving payment prompt information sent by the third party, where the payment prompt information is used for prompting sending of payment verification information； correspondingly, the sending unit 802 is further used for sending the input payment verification information to the third party, so that the third party compares whether the payment verification information is identical with payment verification information corresponding to the account corresponding to or bound to the third identification stored by the third party.

Thus, through the client described in FIG. 8, a user using a credit card for payment on a transaction terminal may be omitted, and the user account being acquired by a transaction terminal through illegal crack may be prevented, so that a risk that the credit card is pilfer brushed is eliminated and payment security is effectively improved.

Referring to FIG. 9, FIG. 9 is a schematic structural view of another client according to an embodiment of the present application. As shown in FIG. 9, the client 900 may include: at least one processor 901, for example, CPU, at least one network interface 904, a user interface 903, a memory 905 and at least one communication bus 902. The communication bus 902 is used for implementing connections and communications between the components. The user interface 903 may include a Display interface and a Keyboard interface, and alternatively, the user interface 903 may further include a standard loudspeaker interface and a microphone interface. The network interface 904, alternatively, may include standard wired interfaces and wireless interfaces (for example, WI-FI interfaces) . The memory 905 may be a high-speed RAM memory, or may be a non-volatile memory, for example, at least one magnetic disk memory. The memory 905, alternatively, may also be at least one storage device located away from the processor 901. As shown in FIG. 9, as a computer storage medium, the memory 905 may include an operating system, a network communication module, a user interface module and data processing applications.

In the client 900 shown in FIG. 9, the network interface 904 is mainly used for connecting a third party (for example, a social payment platform) ； and the processor 901 may be used for calling the data processing applications stored in the memory 905, and executing the following operations: receiving a payment value through the user interface 903 (for example, Display interface or Keyboard interface) ； receiving input key payment information through the user interface 903 (for example, Display interface or Keyboard interface or microphone interface) ； where the key payment information includes at least a part of a first identification or a part of more than two first identifications； and sending the payment value and the key payment information to the third party by using a payment order through the network interface 904, where the payment order further includes a second identification registered by a first client on a platform or an application of the third party, so that, after the third party determines a third identification registered on the platform or the application of the third party corresponding to the key payment information according to the key payment information included in the payment order, the third party subtracts a value corresponding to the payment value from an account corresponding to or bound to the third identification, and adds the corresponding value to an account corresponding to or bound to the second identification.

In this embodiment of the present application, the processor 901 calls the data processing applications stored in the memory 905, and may further execute the following operation: receiving a value processing result sent by the third party through the user interface 903 (for example, Display interface or Keyboard interface) .

In this embodiment of the present application, the processor 901 calls the data processing applications stored in the memory 905, and may further execute the following operations: receiving payment prompt information sent by the third party through the user interface 903 (for example, Display interface or Keyboard interface) , where the payment prompt information is used for prompting sending of payment verification information； and correspondingly, sending the input payment verification information to the third party through the network interface 904, so that the third party compares whether the payment verification information is identical with payment verification information corresponding to the account corresponding to or bound to the third identification stored by the third party.

Thus, through the client described in FIG. 9, a user using a credit card for payment on a transaction terminal may be omitted, and the user account being acquired by a transaction terminal through illegal crack may be prevented, so that a risk that the credit card is pilfer brushed is eliminated and payment security is effectively improved.

Referring to FIG. 10, FIG. 10 is a schematic structural view of one data processing apparatus according to an embodiment of the present application. As shown in FIG. 10, the data processing apparatus 1000 includes: a receiving unit 1001, for receiving a payment value and key payment information sent by a first client through a payment order； where the payment order further includes a second identification registered by the first client on a platform or an application of the data processing apparatus 1000； and the key payment information includes at least a part of a first identification or a part of more than two first identifications； a determining unit 1002, for determining a third identification registered on the platform or the application of the data processing apparatus 1000 corresponding to the key payment information according to the key payment information included in the payment order； and a processing unit 1003, for decreasing a value corresponding to the payment value from an account corresponding to or bound to the third identification, and increasing the corresponding value to an account corresponding to or bound to the second identification.

As an alternative implementation manner, the apparatus described in FIG. 10 further includes: a first sending unit 1004, for sending a value processing result to the first client corresponding to the second identification and/or a second client corresponding to the third identification after the processing unit 1003 subtracts a value corresponding to the payment value from an account corresponding to or bound to the third identification, and adds the corresponding value to an account corresponding to or bound to the second identification.

As an alternative implementation manner, the apparatus described in FIG. 10 further includes: a second sending unit 1005, for sending payment prompt information to the first client corresponding to the second identification or the second client corresponding to the third identification, where the payment prompt information is used for prompting sending of payment verification information； the receiving unit 1001, further for receiving the payment verification information sent by the first client or the second client； and a comparison unit 1006, for comparing whether the payment verification information is identical with payment verification information corresponding to the account corresponding to or bound to the third identification stored by a third party, and if they are identical, triggering the processing unit 1003 to execute the operations of decreasing a value corresponding to the payment value from an account corresponding to or bound to the third identification, and increasing the corresponding value to an account corresponding to or bound to the second identification.

In this embodiment of the present application, the determining unit 1002 may pre-store a corresponding relationship between the third identification and the first identification, so that the unique third identification could be determined according to the key payment information.

Thus, through the data processing apparatus described in FIG. 10, a user using a credit card for payment on a transaction terminal may be omitted, and the user account being acquired by a transaction terminal through illegal crack may be prevented, so that a risk that the credit card is pilfer brushed is eliminated and payment security is effectively improved.

Referring to FIG. 11, FIG. 11 is a schematic structural view of another data processing apparatus according to an embodiment of the present application. As shown in FIG. 11, the data processing apparatus 1100 includes: at least one processor 1101, for example, CPU, at least one network interface 1104, a user interface 1103, a memory 1105 and at least one communication bus 1102. The communication bus 1102 is used for implementing connections and communications between the components. The user interface 1103 may include standard wired interfaces and wireless interfaces. The network interface 1104, alternatively, may include standard wired interfaces and wireless interfaces (for example, WI-FI interfaces) . The memory 1105 may be a high-speed RAM memory, or may be a non-volatile memory, for example, at least one magnetic disk memory. The memory 1105, alternatively, may also be at least one storage device located away from the processor 1101. As shown in FIG. 11, as a computer storage medium, the memory 1105 may include an operating system, a network communication module, a user interface module and data processing applications.

In the data processing apparatus 1100 shown in FIG. 11, the network interface 1104 is mainly used for connecting a second client, and conducting data communication with the second client； the user interface 1103 is mainly used for connecting a first client, and conducting data communication with the first client； and the processor 1101 may be used for calling the data processing applications stored in the memory 1105, and executing the following operations: receiving a payment value and key payment information sent by a first client through a payment order via the user interface 1103； where the payment order further includes a second identification registered by the first client on a platform or an application of the data processing apparatus 1100； and the key payment information includes at least a part of a first identification or a part of more than two first identifications； determining a third identification registered on the platform or the application of the data processing apparatus 1100 corresponding to the key payment information according to the key payment information included in the payment order； and decreasing a value corresponding to the payment value from an account corresponding to or bound to the third identification, and increasing the corresponding value to an account corresponding to or bound to the second identification.

In this embodiment of the present application, the processor 1101 calls the data processing applications stored in the memory 1105, and may further execute the following operations: after the processor 1101 subtracts a value corresponding to the payment value from an account corresponding to or bound to the third identification, and adds the corresponding value to an account corresponding to or bound to the second identification, sending a value processing result to the first client corresponding to the second identification through the user interface 1103, and/or sending the value processing result to the second client corresponding to the third identification through the network interface 1104.

In this embodiment of the present application, the processor 1101 calls the data processing applications stored in the memory 1105, and may further execute the following operations: before the processor 1101 subtracts a value corresponding to the payment value from an account corresponding to or bound to the third identification, and adds the corresponding value to an account corresponding to or bound to the second identification, sending payment prompt information to the first client corresponding to the first identification through the user interface 1103 or sending payment prompt information to the second client corresponding to the third identification through the network interface 1104, where the payment prompt information is used for prompting sending of payment verification information； and receiving the payment verification information sent by the first client through the user interface 1103 or by the second client through the network interface 1104, and comparing whether the payment verification information is identical with payment verification information corresponding to the account corresponding to or bound to the third identification stored by the data processing apparatus 1100.

Correspondingly, after the processor 1101 compares that the payment verification information is identical with the payment verification information corresponding to the account corresponding to or bound to the third identification stored by the data processing apparatus 1100, the processor 1101 may subtract a value corresponding to the payment value from an account corresponding to or bound to the third identification, and adds the corresponding value to an account corresponding to or bound to the second identification； on the contrary, after the processor 1101 compares that the payment verification information is not identical with the payment verification information corresponding to the account corresponding to or bound to the third identification stored by the data processing apparatus 1100, the processor 1101 may refuse to execute the payment operation, that is to say, the processor 1101 may refuse to subtract a value corresponding to the payment value from the account corresponding to or bound to the third identification, and refuse to add the corresponding value to the account corresponding to or bound to the second identification, so that the payment security could be further improved.

Thus, through the data processing apparatus described in FIG. 11, a user using a credit card for payment on a transaction terminal may be omitted, and the user account being acquired by a transaction terminal through illegal crack may be prevented, so that a risk that the credit card is pilfer brushed is eliminated and payment security is effectively improved.

Referring to FIG. 12, FIG. 12 is a schematic structural view of a data processing system according to an embodiment of the present application. As shown in FIG. 12, the data processing system may include a first client 1201 and a data processing apparatus 1202, where the structure of the first client 1201 is identical with that of the client described in FIG. 8 or FIG. 9, and the structure of the data processing apparatus 1202 is identical with that of the client described in FIG. 10 or FIG. 11, which are not repeated in this embodiment of the present application.

In the data processing system shown in FIG. 12: the first client 1201 is used for receiving a payment value, and receiving input key payment information； where the key payment information includes at least a part of a first identification or a part of more than two first identifications； and sending the payment value and the key payment information to the data processing apparatus 1202 through a payment order； where the payment order further includes a second identification registered by the first client 1201 on a platform or an application of the data processing apparatus 1202； and the data processing apparatus 1202 is used for receiving the payment order sent by the first client 1201, determining a third identification registered on the platform or the application of the data processing apparatus 1202 corresponding to the key payment information according to the key payment information included in the payment order, decreasing a value corresponding to the payment value from an account corresponding to or bound to the third identification, and increasing the corresponding value to an account corresponding to or bound to the second identification.

As an alternative implementation manner, in the system shown in FIG. 12, the system further includes a second client 1203 corresponding to the third identification, correspondingly, the data processing apparatus 1202 is further used for sending a value processing result to the first client 1202 corresponding to the second identification and/or the second client 1203 corresponding to the third identification after decreasing a value corresponding to the payment value from an account corresponding to or bound to the third identification, and increasing the corresponding value to an account corresponding to or bound to the second identification.

As an alternative implementation manner, in the system shown in FIG. 12, the data processing apparatus 1202 is further used for sending payment prompt information to the first client 1202 corresponding to the second identification or the second client 1203 corresponding to the third identification before decreasing a value corresponding to the payment value from an account corresponding to or bound to the third identification, and increasing the corresponding value to an account corresponding to or bound to the second identification, where the payment prompt information is used for prompting sending of payment verification information； the first client 1201 or the second client 1203 is used for receiving the payment prompt information sent by a third party, and sending input payment verification information to the data processing apparatus 1202； and the data processing apparatus 1202 is further used for receiving the payment verification information sent by the first client 1201 or the second client 1203, and comparing whether the payment verification information is identical with payment verification information corresponding to an account corresponding to or bound to the third identification stored by the data processing apparatus 1202.

Correspondingly, after the data processing apparatus 1202 compares that the payment verification information is identical with the payment verification information corresponding to an account corresponding to or bound to the third identification stored by the data processing apparatus 1202, the data processing apparatus 1202 may subtract a value corresponding to the payment value from an account corresponding to or bound to the third identification, and add the corresponding value to an account corresponding to or bound to the second identification； on the contrary, after the data processing apparatus 1202 compares that the payment verification information is not identical with the payment verification information corresponding to an account corresponding to or bound to the third identification stored by the data processing apparatus 1202, the data processing apparatus 1202 may refuse to execute the payment operation, that is to say, the data processing apparatus 1202 may refuse to subtract a value corresponding to the payment value from the account corresponding to or bound to the third identification, and refuse to add the corresponding value to an account corresponding to or bound to the second identification, so that the payment security could be further improved.

In this embodiment of the present application, the data processing apparatus 1202 may pre-store a corresponding relationship between the third identification and the first identification, so that the unique third identification could be determined according to the key payment information.

Thus, through the data processing system described in FIG. 12, a user using a credit card for payment on a transaction terminal may be omitted, and the user account being acquired by a transaction terminal through illegal crack may be prevented, so that a risk that the credit card is pilfer brushed is eliminated and payment security is effectively improved.

FIG. 13 is a block diagram illustrating a client 1300, in accordance with some embodiments. The client 1300 typically includes one or more processing units (CPU’s) 1302, one or more network interfaces 1310, memory 1312, and one or more communication buses 1314 for interconnecting these components. The client 1300 includes a user interface 1304. The user interface 1304 includes an associated display device 1306 and one or more input devices 1308 (e. g. , keyboard, mouse, a touch-sensitive display, other input buttons) . The client 1300 also optionally includes a location device 1309 (e. g. , a Global Positioning System module) for determining a location of the client 1300, and an image capture device 1311 (e. g. , a camera) for capturing images and/or video. Optionally, the client 1300 includes an audio device or other information delivery device. Optionally, the client 1300 includes a microphone and a voice recognition module to supplement or replace the keyboard.

Memory 1312 includes high-speed random access memory, such as DRAM, SRAM, DDR RAM or other random access solid state memory devices； and may include non-volatile memory, such as one or more magnetic disk storage devices, optical disk storage devices, flash memory devices, or other non-volatile solid state storage devices. Memory 1312 may optionally include one or more storage devices remotely located from the CPU (s) 1302. Memory 1312, or alternately the non-volatile memory device (s) within memory 1312, includes a non-transitory computer readable storage medium. In some implementations, memory 1312 or the computer readable storage medium of memory 1312 stores the following programs, modules and data structures, or a subset thereof: an operating system 1316 that includes procedures for handling various basic system services and for performing hardware dependent tasks； a network communication module 1318 that is used for connecting the client 1300 to other computers and devices via the one or more communication network interfaces 1310 (wired or wireless) and one or more communication networks, such as the Internet, other wide area networks, local area networks, metropolitan area networks, ad-hoc wireless networks, and so on； a display module 1320 for enabling display of information on a display 1306 associated with the client 1300； a location module 1322 for determining the location of the client 1300 and optionally other clients 1300 using data from location device 1309, Wi-Fi location information, cell tower triangulation, close-proximity communication (e. g. , near field communication) with other clients 1300, and other suitable methods； an imaging module 1324 for capturing, in conjunction with the image capture device 1322, images and/or videos； one or more client application module (s) 1326 for enabling the client 1300 to perform the functions offered by the client 1300, including but not limited to: an identification information module 1328 for requesting identification information (e. g. , in a scannable barcode) from a service or platform (e. g. , a social networking service) hosted by a server system 1400 (FIG. 14) , requesting provision of identification information from another client 1300, and receiving and sending input of identification information (e. g. , scanning a barcode, keyboard input) ； aservice communication module 1330 for communicating with the server system 1400 (FIG. 14) within the service, including sending transaction requests and receiving information requests in connection with transaction requests； a verification module 1332 for receiving requests for verification from the server system 1400 (FIG. 14) , receiving verification inputs, and sending verification inputs to the server 1400； and identification information 1334 that includes information identifying a user or party with which the client 1300 is associated.

In some embodiments, one or more of the client application modules 1326 are associated with the service/platform hosted by the server system 1400. In some embodiments, these modules are sub-modules of an application associated with the service/platform hosted by the server system 1400.

In some embodiments, the client 1300 includes one or more biometric devices for obtaining user biometrics, such as fingerprint scanners. In some embodiments, the client 1300 includes one or more modules that, in conjunction with any of the devices and modules described above, obtain user biometrics (e. g. , facial scan module that works with the image capture device 1311 and imaging module 1324 to obtain user facial data.

FIG. 14 is a block diagram illustrating a server system 1400, in accordance with some embodiments. The server system 1400 typically includes one or more processing units (CPU’s) 1402, one or more network interfaces 1404, memory 1406, and one or more communication buses 1408 for interconnecting these components.

Memory 1406 includes high-speed random access memory, such as DRAM, SRAM, DDR RAM or other random access solid state memory devices； and may include non-volatile memory, such as one or more magnetic disk storage devices, optical disk storage devices, flash memory devices, or other non-volatile solid state storage devices. Memory 1406 may optionally include one or more storage devices remotely located from the CPU (s) 1402. Memory 1406, or alternately the non-volatile memory device (s) within memory 1406, includes a non-transitory computer readable storage medium. In some implementations, memory 1406 or the computer readable storage medium of memory 1406 stores the following programs, modules and data structures, or a subset thereof: an operating system 1410 that includes procedures for handling various basic system services and for performing hardware dependent tasks； a network communication module 1412 that is used for connecting the server system 1400 to other computers via the one or more communication network interfaces 1404 (wired or wireless) and one or more communication networks, such as the Internet, other wide area networks, local area networks, metropolitan area networks, and so on； one or more server application module (s) 1414 for enabling the server system 1400 to perform the functions offered by the server system 1400, including but not limited to: an identification information module 1416 for requesting and receiving identification information from clients 1300； a service communication module 1418 for communicating with clients 1300 within the service； a transactions module 1420 for processing transaction requests； and a verification module 1422 for requesting and receiving verification information, and comparing received verification information to verification keys； and user profile information 1424 for storing data related to users of the service, including but not limited to: accounts information 1426 that store information on accounts (e. g. , real and virtual currency accounts, such as bank accounts) associated with users； and verification keys 1428 that store information for verifying transactions and authorization to access accounts associated with users.

Referring to FIGS. 15A-15B, FIGS. 15A-15B is a flow chart of another data processing method according to an embodiment of the present application. The data processing method described in FIGS. 15A-15B is described from multiple sides: a first party (e. g. , a user receiving a payment in a transaction) , a second party (e. g. , a user making a payment in the transaction) a first client (e. g. , a client 1300) associated with the first party, a second client (e. g. , another client 1300) associated with the second party, and a third party (e. g. , a service hosted by server system 1400) .

In some embodiments, the first client includes a cashier device (e. g. , a point-of-sale machine or any other terminal device having a payment function) , a smartphone (e. g. , a smartphone running the Android operation system by Google Inc. , a smartphone running the iOS operating system by Apple Inc. ) , a tablet device, a handheld computer, a mobile internet device (MID) , a desktop computer, a notebook computer, a smart device, or other device having an online transaction function. Similarly, the second client, in some embodiments, includes any of these devices.

In some embodiments, the third party is a service or platform (e. g. , a social networking service) that includes a payments platform or some other platform for exchanging value between users. In some embodiments, within the service, a user account or profile is associated with a real currency account (e. g. , a bank account) , or with a virtual currency or credits account that is in turn associated with a real currency account.

In some embodiments, the second party activates a command on the second client to request second identification information (1502) . The second identification information identifies the second party, as opposed to a first identification information (described further below) that identifies the first party. In some embodiments, the second client includes an application associated with the third party and through which the second party is logged into the third party service. The application is configured to, upon command by the second party (e. g. , activation of a corresponding affordance) , to request that the third party generate and provide the second identification information that the second client can provide to identify the second party to other clients 1300. In some embodiments, the identification information is formatted as a barcode (e. g. , a two-dimensional barcode) .

The second client sends a request for the second identification information (e. g. , as a barcode) to the third party (1504) . In accordance with the second party’s command to request the second identification information, the identification information module 1328 in the second client sends a request to the server system 1400. The request is received by the identification information module 1416 in the server system 1400 (1506) .

The third party generates the second identification information and sends the second identification information to the second client (1508) . For example, the identification information module 1416 in the server system 1400, in accordance with the received request, generates a barcode that includes the second identification information. The barcode encodes information that identifies the second party (e. g. , user identifier, email address, etc. associated with a user account, within the service, that corresponds the second party) . The server system 1400 sends the second identification information to the second client.

The second client receives the second identification information (1510) . The second client stores the received second identification information in identification information 1334, which can be displayed by the second client in response to a user command.

In some other embodiments, the second identification information is generated locally at the second client (e. g. , by the identification information module 1328) . Upon receiving the command by the second party, the identification information module 1328 requests and receives, from the server system 1400, information that identifies the second party within the third party service, or alternatively, accesses locally stored information related to the second party’s login with the third party service. The identification information module 1328 generates the barcode from that information at the second client and stores the barcode in the identification information 1334.

The first party and the second party agree to a transaction (1512) . The transaction includes a transfer of value (e. g. , currency, credits) from the second party to the first party. The transfer of value may be associated with, for example, the purchase of goods or services, or for payment of a debt or other obligation.

The first party inputs a transaction request on the first client (1514) . The transaction request is a request to the third party to carry out a transaction between the first party and the second party, specifically a transfer of value (e. g. , from the second party to the first party) . The transaction request includes at least the amount at issue in the transaction, and optionally includes the payer and payee. In some embodiments, the transaction request is sent in the form of a message to the third party. For example, the first party, using the service communication module 1330 on the first client, sends a message to an account associated with the third party. The message includes the transaction request. In some embodiments, the account associated with the third party is an account dedicated to receiving transaction request messages from users of the third party service.

In some embodiments, the format for the transaction request message is a structured expression. The third party may require that transaction requests be formatted as a structured expression so that the requests are recognized as transaction requests when parsed and processed (e. g. , higher priority, processed with heightened security) by the third party (e. g. , server system 1400) . In other words, the structured expression is a predefined way to input a transaction request so that, when a message containing a transaction request is sent to the third party, ambiguity regarding whether the message includes a transaction request and what a transaction being requested includes is minimized.

In some embodiments, the structured expression is a predefined sentence where predefined words (e. g. , keywords that signal the third party that the expression is a transaction request) and transaction-specific parameters are arranged in a predefined sequence. For example, the structured expression message may be “ [payer] pays [payee] [amount] . ” The “ [payer] ” parameter corresponds to the payer in the transaction； an identifier of the payer (the email address, user name, or other information that uniquely identifies the payer within the third party service) is inserted in that position in an actual transaction request. The “ [payee] ” parameter corresponds to the payee in the transaction； an identifier of the payee (the email address, user name, or other information that uniquely identifies the payee within the third party service) is inserted in that position in an actual transaction request. The “ [amount] ” parameter corresponds to the amount being transferred in the transaction； the amount being transferred (e. g. , the amount with a specification of the unit of currency or value (dollar, yen, pounds, bitcoins, credits, etc. ) ) is inserted in that position in an actual transaction request. Thus, for example, for a transaction where John Doe is paying Jane Doe $50, the transaction request may read as “johndoe@doe. com pays janedoe@doe. com $50. ” “johndone@doe. com” and “janedoe@doe. com” are the email addresses associated with John Doe and Jane Doe, respectively, within the third party service, and $50 is the amount being transferred.

In some other embodiments, the transaction request message is a structured expression, as described above, but the parameters for payer and payee can be filled with names that do not uniquely identify the payer and/or the payee within the third party service. For example, the payer and payee parameters can be filled with the payer’s and/or payee’s, respectively, nicknames. Information uniquely identifying the payer and payee within the third party service may be provided in response to a request for identification information, as described below.

In some other embodiments, the transaction request includes the amount, but not the payer and the payee. The payer and payee are identified when a response to a request from the third party for identification information is provided.

The first client sends the transaction request to the third party (1516) . For example, the service communication module 1330 on the first client sends a message that includes the transaction request to the server system 1400.

The transaction request is received by the third party (1518) . For example, the service communication module 1418 receives a message that contains the transaction request from the first client. The message is parsed to determine whether the message contains a transaction request, and, if the message is determined to contain a transaction request, the amount and the parties involved.

The third party sends a request for identification information to the first client (1520) . After receiving the transaction request, the third party requests identification information to confirm the payer and payee as users within the third party service.

The first client prompts the first party to input identification information (1522) . The identification information module 1328, in response to receiving the request for identification information, displays a prompt on the display 1306 prompting for input of identification information.

The first party notifies the second party to provide identification information (1524) . For example, the first party shows the second party the prompt on the first client and instructs the second party to provide the second identification information in response to the prompt.

The second party commands the second client to display the second identification information (e. g. , as a barcode) (1526) . The second party issues a command (e. g. , activate a corresponding affordance) on the identification information module 1328 to display the second identification information that was sent by the server system 1400. In response to the command, the second client displays the second identification information (1528) . For example, the second client displays the second identification information barcode.

The second identification information is input at the first client (1530) . For example, the first client scans the second identification information barcode using the image capture device 1211 and imaging module 1324. The barcode is scanned and decoded to obtain the second identification information.

In some other embodiments, the second identification information is transmitted wirelessly from the second client to the first client. For example, the first client and the second client establish a wireless connection (e. g. , using Bluetooth, Wi-Fi) . The second client sends the second identification information to the first client using the wireless connection instead of displaying a barcode for the first client to scan.

In some other embodiments, the second identification information is input manually at the first client. For example, a prompt for the second identification information, including one or more fields for the identification information, is displayed on the first client. The second party inputs the second identification information into the fields using, for example, a keyboard. Here, the second identification information may include one or more of: all or part of a phone number, all or part of a identity document number, all or part of a credit card number, all or part of the second party’s name, and all or part of a social account number.

The first client sends the first identification information and the second identification information to the third party (1532) . The identification information module 1418 sends the second identification information received from the second party (e. g. , through scanning a barcode displayed on the second client) and the first identification information to the server system 1400. The first identification information uniquely identifies the first party, with which the first client is associated, within the third party service. In some embodiments, the first identification information is obtained from locally stored information related to the first party’s login with the third party service. In some other embodiments, the first identification information is sent to the first client from the server system 1400 in a similar manner as the second identification information is sent to the second client from the server system 1400, as described above.

Continuing in FIG. 15B, the third party receives the first identification information and the second identification information (1534) . The server system 1400 receives the first identification information and the second identification information from the first client.

In some embodiments, if a time period from receiving the transaction request to receiving the second identification information exceeds a predefined time elapsed threshold, the third party aborts the transaction (1536) . If the difference in the times at the server system 1400 at which the transaction request was received and at which the second identification information was received exceed a time elapsed threshold, the server system 1400 aborts the transaction； the second identification information was received too long after the transaction request was received and the transaction request timed out. In some other embodiments, the time period between receiving the transaction request and receiving the second identification information is based on respective timestamps includes with the transaction request message and the second identification information transmission. If the difference between the timestamps exceeds the threshold, the server system 1400 aborts the transaction.

In some embodiments, if a difference between a timestamp of transmission for the first and second identification information and a current time at the server system 1400 as of when the first and second identification information are received exceeds a threshold, the server system 1400 aborts the transaction； the transmission of the first and second identification information timed out.

In some embodiments, if the first client exceeds a predefined proximity from the second client when the first identification information and the second identification information are received, the third party aborts the transaction (1538) . For example, the transmission of the first and second identification information includes location information for the first client (e. g. , data from the location device 1309 on the first client) . The server system 1400 receives the first client location information along with the identification information. The server system 1400 also communicates with the second client to obtain current location information from the second client (e. g. , data from the location device 1309 on the second client) . The server system 1400 determines a distance between the first client and the second client based on the respective location information. If the determined distance between the first client and the second client exceeds a predefined threshold, i. e. , the first client exceeds a predefined proximity from the second client, the server system 1400 aborts the transaction.

In some embodiments, both of the time and distance requirements described above are applicable； the first and second identification information must be received in a timely fashion, and the first and second clients must be within a predefined proximity of each other in order for the server system 1400 to not abort the transaction.

If the server system 1400 has not aborted the transaction, the third party identifies a first account and a second account based on the first identification information and the second identification information, respectively (1540) . The server system 1400 identifies the users of the third party service corresponding to the first party and the second party based the first and second identification information using the user profile information 1424. The server system 1400 identifies a first account corresponding to the first party and a second account corresponding to the second party using the identified user accounts and the accounts information 1426.

The third party sends a request for transaction verification information to the second client (1542) . The verification module 1422 sends a request for the second party to confirm the transaction being requested and authorize the transfer of value from the second account. The transaction verification information being requested includes one or more of: a password, and one or more biometrics (e. g. , fingerprint, voice print, facial scan, retina scan) .

In some embodiments, the third party identifies the second client to send the request to based on the second identification information. The server system 1400 identifies the second party and the corresponding user within the third party service based on the second identification information. The server system 1400, having identified the user corresponding to the second party, sends the request for transaction verification information to the corresponding client, i. e. , the second client.

The second client prompts the second party for transaction verification information (1544) . The second client displays a prompt for transaction verification information, such as those illustrated in FIGS. 4-5described above. For the prompt illustrated in FIG. 4, the transaction verification information includes a password. For the prompt illustrated in FIG. 5, the transaction verification information includes a password and a fingerprint.

The second party inputs transaction verification information (1546) . For example, in response to the prompts illustrated in FIGS. 4-5, the second party inputs a password and/or places a finger on a fingerprint scanner (not shown) on the second client to input the transaction verification information.

The second client sends the transaction verification information to the third party (1548) . For example, the second client sends the transaction verification information (e. g. , password, a fingerprint) input by the second party to the server system 1400.

The third party receives the transaction verification information sent by the second client (1550) . The server system 1400 receives the transaction verification information input by the second party at the second client and sent from the second client.

The third party determines whether the transaction verification information matches a verification key associated with the second account (1552) . The verification module 1422 compares the received transaction verification information to the verification keys 1428 associated with the second account associated with the second party.

If the transaction verification information matches the verification key, the third party completes the transaction using the first account and the second account (1554) . For example, if the verification module 1422 determines that the transaction verification information matches the verification key, the transactions module 1420, in accordance with that determination, completes the transaction (e. g. , transfer the amount in the transaction request from the second account to the first account) .

If the transaction verification information does not match the verification key, the third party aborts the transaction (1554) . For example, if the verification module 1422 determines that the transaction verification information does not match the verification key, the transactions module 1420 aborts the transaction.

In some embodiments, the server system 1400 sends a transaction success message or notification to the first and second clients when the transaction is completed, and a transaction fail message or notification to the first and second clients when the transaction is aborted.

The embodiments of the present application can achieve extremely convenient, safe and efficient payment, the user can input payment verification information in a client, and send the payment verification information to a third party for verification so as to complete the payment. The payment environment in the embodiments of the present application is very convenient, is likely to overturn the existing credit card payment manner, and even replaces the cash payment manner, to become a preferred payment manner.

While particular embodiments are described above, it will be understood it is not intended to limit the present application to these particular embodiments. On the contrary, the present application includes alternatives, modifications and equivalents that are within the spirit and scope of the appended claims. Numerous specific details are set forth in order to provide a thorough understanding of the subject matter presented herein. But it will be apparent to one of ordinary skill in the art that the subject matter may be practiced without these specific details. In other instances, well-known methods, procedures, components, and circuits have not been described in detail so as not to unnecessarily obscure aspects of the embodiments.

The terminology used in the description of the present application herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the present application. As used in the description of the present application and the appended claims, the singular forms "a, " "an, " and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items. It will be further understood that the terms "includes, " "including, " "comprises, " and/or "comprising, " when used in this specification, specify the presence of stated features, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, operations, elements, components, and/or groups thereof.

As used herein, the term "if" may be construed to mean "when" or "upon" or "in response to determining" or "in accordance with a determination" or "in response to detecting, " that a stated condition precedent is true, depending on the context. Similarly, the phrase "if it is determined [that a stated condition precedent is true] " or "if [astated condition precedent is true] " or "when [astated condition precedent is true] " may be construed to mean "upon determining" or "in response to determining" or "in accordance with a determination" or "upon detecting" or "in response to detecting" that the stated condition precedent is true, depending on the context.

Although some of the various drawings illustrate a number of logical stages in a particular order, stages that are not order dependent may be reordered and other stages may be combined or broken out. While some reordering or other groupings are specifically mentioned, others will be obvious to those of ordinary skill in the art and so do not present an exhaustive list of alternatives. Moreover, it should be recognized that the stages could be implemented in hardware, firmware, software or any combination thereof.

The foregoing description, for purpose of explanation, has been described with reference to specific embodiments. However, the illustrative discussions above are not intended to be exhaustive or to limit the present application to the precise forms disclosed. Many modifications and variations are possible in view of the above teachings. The embodiments were chosen and described in order to best explain the principles of the present application and its practical applications, to thereby enable others skilled in the art to best utilize the present application and various embodiments with various modifications as are suited to the particular use contemplated.

Claims

A method, comprising:

at a computer system having one or more processors and memory for storing program modules to be executed by the one or more processors:

receiving, from a first client, a transaction request for a transaction between a first party and a second party, wherein the first client is associated with the first party；

receiving, from the first client, a first identification information and a second identification information；

identifying:

a first account associated with the first party based on the first identification information； and

a second account associated with the second party based on the second identification information；

sending a request for transaction verification information corresponding to the transaction to a second client associated with the second party, wherein the second client is identified based on the second identification information；

receiving, from the second client, transaction verification information for the transaction；

determining whether the transaction verification information matches a verification key associated with the second account；

in accordance with a determination that the transaction verification information matches the verification key, completing the transaction using the first account and the second account； and

in accordance with a determination that the transaction verification information does not match the verification key, aborting the transaction.
The method of claim 1, further comprising:

prior to sending the request for the transaction verification information:

if a time period from receiving the transaction request to receiving the second identification information exceeds a predefined time elapsed threshold, aborting the transaction.
The method of claim 1, further comprising:

prior to sending the request for the transaction verification information:

if the first client exceeds a predefined proximity from the second client when the first identification information and the second identification information are received, aborting the transaction.
The method of claim 1, wherein the second identification information is input at the first client.
The method of claim 4, wherein the second identification information comprises a barcode that is input at the first client by scanning by the first client.
The method of claim 5, wherein the barcode is displayed by the second client for scanning by the first client.
The method of claim 6, further comprising:

before receiving, from the first client, the transaction request:

receiving a request from the second client for the barcode；

generating the barcode； and

sending the barcode to the second client.
The method of claim 1, wherein the transaction request specifies the first party, the second party, and a transaction value.
The method of claim 8, wherein the transaction request is formatted as a structured expression, wherein the structured expression comprises a predefined sequence that includes the first party, the second party, the transaction value, and one or more predefined keywords.
The method of claim 8, wherein completing the transaction using the first account and the second account comprises subtracting the transaction value from the second account and adding the transaction value to the first account.
The method of claim 1, wherein the verification key comprises one or more of: a password, and one or more biometrics.
A computer system, comprising:

memory；

one or more processors； and

one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, the one or more programs comprising instructions for:

receiving, from a first client, a transaction request for a transaction between a first party and a second party, wherein the first client is associated with the first party；

receiving, from the first client, a first identification information and a second identification information；

identifying:

a first account associated with the first party based on the first identification information； and

a second account associated with the second party based on the second identification information；

sending a request for transaction verification information corresponding to the transaction to a second client associated with the second party, wherein the second client is identified based on the second identification information；

receiving, from the second client, transaction verification information for the transaction；

determining whether the transaction verification information matches a verification key associated with the second account；

in accordance with a determination that the transaction verification information matches the verification key, completing the transaction using the first account and the second account； and

in accordance with a determination that the transaction verification information does not match the verification key, aborting the transaction.
The computer system of claim 12, wherein the one or more programs further comprise instructions for:

prior to sending the request for the transaction verification information:

if a time period from receiving the transaction request to receiving the second identification information exceeds a predefined time elapsed threshold, aborting the transaction.
The computer system of claim 12, wherein the one or more programs further comprise instructions for:

prior to sending the request for the transaction verification information:

if the first client exceeds a predefined proximity from the second client when the first identification information and the second identification information are received,aborting the transaction.
The computer system of claim 12, wherein the second identification information is input at the first client.
The computer system of claim 12, wherein the transaction request specifies the first party, the second party, and a transaction value.
The computer system of claim 12, wherein the verification key comprises one or more of: a password, and one or more biometrics.
A non-transitory computer readable storage medium storing one or more programs, the one or more programs comprising instructions, which when executed by a computer system, cause the computer system to:

receive, from a first client, a transaction request for a transaction between a first party and a second party, wherein the first client is associated with the first party；

receive, from the first client, a first identification information and a second identification information；

identify:

a first account associated with the first party based on the first identification information； and

a second account associated with the second party based on the second identification information；

send a request for transaction verification information corresponding to the transaction to a second client associated with the second party, wherein the second client is identified based on the second identification information；

receive, from the second client, transaction verification information for the transaction；

determine whether the transaction verification information matches a verification key associated with the second account；

in accordance with a determination that the transaction verification information matches the verification key, complete the transaction using the first account and the second account； and

in accordance with a determination that the transaction verification information does not match the verification key, abort the transaction.
The non-transitory computer readable storage medium of claim 18, wherein the one or more programs further comprise instructions for:

prior to sending the request for the transaction verification information:

if a time period from receiving the transaction request to receiving the second identification information exceeds a predefined time elapsed threshold, aborting the transaction.
The non-transitory computer readable storage medium of claim 18, wherein the one or more programs further comprise instructions for:

prior to sending the request for the transaction verification information:

if the first client exceeds a predefined proximity from the second client when the first identification information and the second identification information are received, aborting the transaction.