CN109034818B

CN109034818B - Method and device for generating payment mark and method and device for verifying payment mark

Info

Publication number: CN109034818B
Application number: CN201810629985.2A
Authority: CN
Inventors: 王胜
Original assignee: Advanced New Technologies Co Ltd
Current assignee: Advanced New Technologies Co Ltd; Advantageous New Technologies Co Ltd
Priority date: 2018-06-19
Filing date: 2018-06-19
Publication date: 2022-05-13
Anticipated expiration: 2038-06-19
Also published as: CN109034818A

Abstract

The embodiment of the specification provides a method for generating a payment mark and a method for payment verification by using the payment mark. According to the method, when a user requests to bind the bank card, a payment mark is generated for the bank card of the user, and the payment mark at least comprises a first field indicating a time period to which the current time belongs, a second field taking serial numbers sequentially generated in the current time period as field values, and a third field indicating a card issuing organization corresponding to the bank card. In the payment stage, the payment mark can be sent to a card issuing mechanism to carry out payment verification instead of the bank card number, so that the payment safety is improved.

Description

Method and device for generating payment mark and method and device for verifying payment mark

Technical Field

One or more embodiments of the present description relate to the field of electronic payment security, and more particularly, to methods and apparatus for generating payment indicia and using the payment indicia for payment verification.

Background

In a conventional payment process, user and account information is recorded in a recording medium of a bank card, and a payment transaction process is completed by reading the information through a reading terminal, such as a POS machine, and sending the information to a bank for verification. The bank card may be classified into a magnetic stripe card and a chip card according to a recording medium.

Magnetic stripe cards are card-like magnetic recording media that use a magnetic carrier to record characters and digital information for identification or other purposes. The magnetic card is made of high-strength and high-temperature-resistant plastic or paper-coated plastic, can be moisture-proof and wear-resistant, has certain flexibility, and is convenient to carry and relatively stable and reliable to use. However, conventional magnetic stripe cards are easily counterfeited, i.e. we say that they are swiped to be a fake card, and such cards present many risks to both internet and offline transactions. In order to mitigate this risk, a more secure chip card is created.

Chip cards, also known as IC cards, are cards in which the chip serves as a recording and transaction medium. The chip card not only supports multiple financial applications such as credit borrowing, electronic cash, electronic wallet, off-line payment and quick payment, but also can be applied to multiple industry fields such as finance, traffic, communication, commerce, education, medical treatment, social security, travel entertainment and the like, really realizes multiple functions of one card and provides richer value-added services for clients. The chip card has large capacity, the working principle of the chip card is similar to that of a microcomputer, and the chip card can have multiple functions at the same time. Chip cards are divided into pure chip cards and magnetic stripe chip composite cards, and are now becoming a development trend of global bank cards with relatively higher security and multifunctional applications.

With the development of electronic commerce, electronic payment and cardless transactions are gradually popularized. In an electronic payment scene, a third-party payment mechanism acquires the related information of a user bank card, and when a user requests to pay, the third-party payment mechanism sends the related payment information to a bank for verification.

In most of current bank card payment schemes, a merchant or a third-party payment mechanism directly transmits basic element information such as a card number and a name input by a user to a card issuing bank, and in some schemes, the basic element information such as the card number and the name is encrypted in a network transmission process. And after the card issuing mechanism receives the submitted payment information, decrypting or checking the submitted payment information, analyzing the information such as the card number and the like in the submitted payment information, comparing the payment card number, and if the card number is consistent, paying and deducting.

In the process, each card issuing institution may have a signature verification algorithm, the standards are not uniform, and the subsequent upgrading and daily maintenance are troublesome for third-party payment institutions. Moreover, if the encrypted message is intercepted, the risk of stealing sensitive information such as card numbers and the like by using decryption and a reversible algorithm is still high. Therefore, protection of user information, sensitive data, etc. involved in card-less transactions is highly desirable. To this end, payment tokenization techniques have been developed. The payment token may be a substitute for the primary account number (bank card number) in a conventional payment process, referred to as token. The traditional bank card primary account number is replaced by the payment mark, namely token, to carry out transaction verification, so that the risk caused by the leakage of sensitive information such as card numbers and the like is avoided. However, the rule for generating the payment token in the conventional technology is relatively simple, and cannot really meet the requirements of completely replacing the primary account number and ensuring the payment security.

Accordingly, improved schemes for more secure and efficient generation of payment indicia and increased payment security are desired.

Disclosure of Invention

One or more embodiments of the present specification describe a method and apparatus for generating a payment sign, and a method and apparatus for performing payment verification using such a payment sign, thereby more efficiently generating a payment sign satisfying security requirements and improving payment security.

According to a first aspect, there is provided a method of generating a payment token, comprising:

receiving a card binding request of a user, wherein the card binding request comprises a bank card number associated with the user request;

generating a payment mark according to the card binding request, wherein the payment mark at least comprises a first field, a second field and a third field, the first field indicates a current time period to which the current time belongs, the second field is serial numbers sequentially generated in the current time period, and the third field indicates an issuer corresponding to the bank card number;

and sending the payment mark and the bank card number to a corresponding card issuing institution, so that the card issuing institution stores the payment mark and the bank card number in an associated manner.

In one embodiment, the payment token further comprises a fourth field, the fourth field reserving bits for the generation of the payment token; accordingly, generating a payment token includes modifying a field value of the fourth field when the serial number in the second field reaches a maximum value that is allowable for that field.

According to one possible design, the payment token further includes a fifth field indicating a currently valid database for generating the payment token.

In a possible embodiment, the payment token further comprises a sixth field generated based on user information of said user.

Further, in one embodiment, the sixth field of the payment token may be generated by:

acquiring the user information from the card binding request and/or the user registration information;

determining a user number according to the user information;

and determining the field value of the sixth field according to the user number.

In one possible design, the payment token further includes a seventh field generated based on at least a partial number of digits of the bank card number.

In one embodiment, after the payment token is generated, the payment token is stored in association with the bank card indicating information.

According to one possible design, the bank card indication information may take the form of a combination of a user id and a card flag.

According to a second aspect, there is provided a method of payment verification using a payment token, comprising:

receiving a payment request of a user, wherein the payment request comprises bank card indication information which indicates that the user sets an associated bank card in advance through a card binding request;

acquiring a payment mark corresponding to the associated bank card according to the bank card indication information, wherein the payment mark is generated in advance according to the method of the first aspect;

and sending the payment mark to an issuer corresponding to the associated bank card, so that the issuer verifies the payment transaction related to the payment request according to the payment mark.

According to a third aspect, there is provided an apparatus for generating a payment token, comprising:

the system comprises a receiving unit, a processing unit and a processing unit, wherein the receiving unit is configured to receive a card binding request of a user, and the card binding request comprises a bank card number associated with the user request;

the generating unit is configured to generate a payment mark according to the card binding request, wherein the payment mark at least comprises a first field, a second field and a third field, the first field indicates a current time period to which the current time belongs, the second field is an assembly number sequentially generated in the current time period, and the third field indicates an issuing organization corresponding to the bank card number;

and the sending unit is configured to send the payment mark and the bank card number to a corresponding card issuing institution so that the card issuing institution stores the payment mark and the bank card number in an associated manner.

According to a fourth aspect, there is provided an apparatus for payment verification using a payment token, comprising:

the payment processing device comprises a receiving unit, a payment processing unit and a payment processing unit, wherein the receiving unit is configured to receive a payment request of a user, the payment request comprises bank card indicating information, the bank card indicating information indicates that the user previously sets an associated bank card through a card binding request;

an obtaining unit configured to obtain, according to the bank card instruction information, a payment flag corresponding to the associated bank card, where the payment flag is generated in advance by using the apparatus of the third aspect;

and the sending unit is configured to send the payment mark to an issuer corresponding to the associated bank card, so that the issuer verifies the payment transaction related to the payment request according to the payment mark.

According to a fifth aspect, there is provided a computer readable storage medium having stored thereon a computer program which, when executed in a computer, causes the computer to perform the method of the first and second aspects.

According to a fourth aspect, there is provided a computing device comprising a memory and a processor, wherein the memory has stored therein executable code, and wherein the processor, when executing the executable code, implements the methods of the first and second aspects.

By the method and the device provided by the embodiment of the specification, in the binding stage, enough different payment marks can be generated for the same card issuing institution without repetition for the bank card to be bound. In the payment stage, the payment mark can be sent to a card issuing mechanism to carry out payment verification instead of the bank card number, so that the safety risk brought by the transmission of the bank card number is avoided, and the payment safety is improved.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings needed to be used in the description of the embodiments are briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present invention, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without creative efforts.

FIG. 1 illustrates a schematic diagram of an implementation scenario of an embodiment disclosed herein;

FIG. 2 illustrates a flow diagram of a method of generating payment indicia, according to one embodiment;

FIG. 3 illustrates a schematic diagram of a payment token generated in accordance with one embodiment;

FIG. 4 illustrates an example of a payment token generated according to one embodiment;

FIG. 5 illustrates a method for payment verification using payment indicia, in accordance with one embodiment;

FIG. 6 shows a schematic block diagram of an apparatus for generating payment tokens, according to one embodiment;

FIG. 7 shows a schematic block diagram of a payment verification apparatus according to one embodiment.

Detailed Description

The scheme provided by the specification is described in the following with reference to the attached drawings.

Fig. 1 is a schematic view of an implementation scenario of an embodiment disclosed in this specification. In the implementation scenario, a third-party electronic payment platform, such as a pay service platform, may generate a secure payment token, i.e., token, for a bank card of a user, so that when the user performs payment, the payment token is used to replace sensitive information such as a bank card number and the like to perform payment verification on a bank.

Specifically, when the user requests to bind the bank card, the electronic payment platform generates a payment mark for the bank card of the user according to the card binding request of the user. The payment mark at least comprises a first field indicating a time period to which the current time belongs, a second field taking serial numbers sequentially generated in the current time period as field values, and a third field indicating an issuer corresponding to the bank card. In this manner, a maximum allowable number of payment tokens for the second field may be generated for the same card issuer per time period. The lengths of the fields, particularly the length of the second field, are set as required, so that unique corresponding payment marks can be ensured not to be repeatedly generated for different bank cards, and the requirements of related business volumes of banks are met. In a further alternative, the payment sign may also contain more fields to support further functions such as over-warning, database switching, secondary verification, etc. And then, the electronic payment platform sends the generated payment mark and the information of the bank card to a corresponding card issuing organization, so that the electronic payment platform stores the payment mark and the bank card number in an associated manner.

When a user pays through the electronic payment platform, the payment platform acquires a payment mark generated aiming at a bank card appointed by the user in advance according to a payment request, and sends the payment mark to a corresponding card issuing organization. Because the card issuing mechanism stores each payment mark and the corresponding bank card number in association in advance, when the payment mark corresponding to the current payment request is obtained, the corresponding bank card can be determined according to the payment mark, and then operations such as verification, payment deduction and the like are carried out. In the payment verification process, the electronic payment platform requests the card issuing mechanism to perform payment verification through the payment mark, and the payment mark does not contain sensitive information such as a card number and the like. Even if the payment mark is intercepted and leaked in the transmission process, sensitive information such as bank card numbers and the like which threatens the payment security cannot be exposed.

The following describes specific implementation processes for generating a payment token and performing payment verification using the payment token.

FIG. 2 illustrates a flow diagram of a method of generating payment indicia, according to one embodiment. The method can be executed by any device, equipment and system with computing and processing capabilities, and in one embodiment, the execution subject of the method can be a server of a third-party electronic payment platform, such as a Payment treasure server. As shown in fig. 2, the method may include: step 21, receiving a card binding request of a user, wherein the card binding request comprises a bank card number associated with the user request; step 22, generating a payment mark according to the card binding request, wherein the payment mark at least comprises a first field, a second field and a third field so as to respectively indicate a current time period to which the current time belongs, serial numbers sequentially generated in the current time period and a card issuing mechanism corresponding to the bank card number; and step 23, sending the generated payment mark and the bank card number to a corresponding card issuing institution, so that the payment mark and the bank card number are stored in an associated manner. Specific execution modes of the above steps are described below.

First, in step 21, a user's card binding request is received. Generally, a third-party electronic payment system, such as a paypal system, provides a client, such as a web page, App for a smart terminal, and the like, to a user. The user may interact with the server of the electronic payment system through the client, for example, submitting various requests. For the card binding service, a dedicated entry and a corresponding page may be set in the client. The user may fill in information required for binding in the binding request page and then submit the binding request to the payment system server. Typically, the client will also read some user information of the user, such as the user id, included in the card binding request. Therefore, the user information (e.g., user id) and the information required for the binding filled by the user can be included in the binding request. It is understood that the information required for binding the card at least includes the card number of the bank card to which the user is bound, i.e. to be associated. In one embodiment, when the user submits the card binding request, the user is also required to fill in the card owner name, the bank opening bank, the bank reserved mobile phone number and other bank card information. Accordingly, the submitted binding card request also comprises the bank card information filled by the user.

Upon receipt of the above-described card binding request, a payment token is generated in accordance with the card binding request at step 22.

In one embodiment, the user's card bind request is first preliminarily verified before generating the payment token. The preliminary verification may include, for example, whether the user id is legitimate, whether user information involved in bank card information filled by the user for binding the card is identical to information entered in the system at the time of user registration, for example, whether the card owner is the user himself or herself, and the like. In case the preliminary verification passes, a payment sign is generated for the bank card in the card binding request.

In one embodiment, in order to enable the payment token to securely replace bank card number and the like, the generated payment token includes at least the following three fields: a first field indicating a current time period to which a current time belongs; a second field which is a serial number sequentially generated in the current time period; the third field indicates the card issuing organization corresponding to the bank card number. The first field and the second field can be generated according to the current time, and the third field needs to determine the card issuer first and then according to the mapping relationship between the preset card issuer and the field codes. Typically, the first few digits of a bank card number may indicate the card issuing institution. Further, some binding request pages also require the user to fill the card issuer. The card issuing institution may be determined according to the bank card number, optionally, according to the filling information of the user, and then the third field is generated according to the mapping relationship.

FIG. 3 illustrates a schematic diagram of a payment token generated according to one embodiment. As shown in fig. 3, in the example of a generated payment token, the first field includes an 8 digit number indicating the current date in the form of YYYYMMDD, e.g., 20180530 indicating 5 months and 30 days of 2018. That is, in the example of fig. 3, the time period is divided in units of days in the first field, and the date (which day) to which the current time belongs is indicated by 8-bit numbers. The second field includes a 12-bit number, which is a serial number of serial numbers generated sequentially within a day. The third field includes a 3-digit number indicating the issuer to which the bank card number corresponds. For example, 000 indicates an internet merchant bank, 001 indicates an industrial merchant bank, 002 indicates an agricultural bank, and so on.

It is to be understood that fig. 3 is merely an example, and the field lengths of the respective fields may be set or adjusted as desired. For example, the first field length depends on the length of the time period to be divided, and the second field length determines the maximum value N of the running sequence number. And the length of the third field may be determined according to the number of card issuers facing the electronic payment. For example, a 2-bit number can support up to 100 card issuers, and a 3-bit number can support up to 1000 card issuers. The combination of the first field, the second field, and the third field may ensure that N payment tokens may not be repeatedly generated for the same card issuer over the same time period. In particular, by adjusting the field length, in particular the second field length, the number of payment tokens that are not repeatedly generated can be made to meet the needs of the issuer.

For example, in the payment sign illustrated in FIG. 3, the second field is 12 bits and the maximum value N of the running sequence number is on the order of 1 trillion. Thus, the payment token in the example of fig. 3 ensures that 1 trillion non-repeating payment tokens can be generated per day for the same issuer, sufficient to meet the general requirements of the number of bank cards issued by the issuer.

In another example, the first field may also be set to a 10-digit number, indicating in the form of YYYYMMDDHH which hour of which day the current time belongs to, e.g. 2018053011 indicates that the 5 th, 30 th day of 2018 is from 11: 00 begins the time period 12:00 ago. That is, the time period is divided in units of hours, and the time period to which the current time belongs is indicated by 10-digit numbers. Accordingly, the field length of the second field may be shortened, for example, set to 10 bits, corresponding to a maximum number of serial numbers N of billions. Therefore, billions of payment marks can not be generated repeatedly in one hour for the same card issuing institution, and the general requirement of the number of bank cards issued by the card issuing institution can be met.

It is to be understood that the first field, the second field, and the third field are names used for the above-mentioned fields, and are not necessarily arranged in the order of the first, second, and third fields. Also, the payment tag may contain more fields for further functionality.

In one embodiment, in addition to the first, second and third fields described above, the payment token generated in step 22 further includes a fourth field that reserves bits for the generation of the payment token for purposes of over-warning when the number of payment tokens that need to be generated reaches or exceeds the maximum value of the serial number of the second field. Specifically, in one example, the fourth field may be set to a 2-bit reserved bit, with a default value of 00. Accordingly, generating the payment token at step 22 includes modifying the field value of the fourth field when the serial number in the second field reaches the maximum value N allowable for that field. For example, the field value of the fourth field is modified from the default value 00 to 01.

Although the combination of the first field and the second field is sufficient to satisfy the general needs of card issuers and users for card binding, there is still a need to prevent the situation that the bank card to be associated reaches or exceeds the maximum serial number N of the second field during the time period of the burst traffic peak in the individual case. Therefore, the above-described fourth field is set. And once the serial number in the second field reaches the maximum value N allowable by the field, modifying the value of the fourth field, so as to continuously generate the payment mark without repetition and realize service expandability. In some embodiments, the reserved bit can also be used for expansion of other services.

Further, in one embodiment, a fifth field is also included in the payment token, the fifth field indicating the currently active database for generating the payment token. This is considered to be because, for a secure electronic payment platform, in order to prevent disasters such as database downtime, a backup database is provided in addition to the main database. Once a problem occurs in the primary database, a fast switch to the backup database is made. In theory, there is a small probability of repeatedly generating payment tokens during the switchover between the primary and backup databases. To this end, the fifth field described above is provided as a "live-library bit," i.e., a field indicating the currently active database. Once the database is switched, the value of the fifth field is modified to indicate the switched database, thereby avoiding duplicate payment markings during database switching.

In one specific example, the fifth field is a 1-digit number, e.g., a default value of 0, indicating the master database. The value of the fifth field is modified to 1 upon switching to the backup database.

In one embodiment, a sixth field is also included in the payment token, the sixth field being generated based on the user information. The user information may be conventional user information carried when the client sends the request, such as a user id, or information read from user registration information, or information filled by the user for binding.

For example, in one embodiment, the sixth field is generated based on the user number. It is understood that the user number is the number of the user in the server inside the electronic payment platform. To this end, in one embodiment, user information, such as a user id, is first extracted from the card binding request, and then a user number of the user inside the electronic payment platform is determined based on the user information, in step 22. Generally, a mapping relationship exists between the user id and the user number, and the user number corresponding to the user can be determined by reading the mapping relationship. Then, a field value of the sixth field may be generated based on the user number. For example, in one specific example, the sixth field is a 2-digit number showing the second to last and third to last digits, respectively, of the user number.

In another embodiment, the sixth field is generated based on a digital encoding of the user information. In this case, after the user information is extracted, the sixth field may be generated by converting the user information into a digital code according to a preset digital coding rule. For example, the user information includes a user id, and the user id is generally a character string customized by the user. In one example, the individual characters in the user id string may be first converted into corresponding ASCII codes, and then the corresponding numbers of the ASCII codes are summed, and the number within a predetermined range in the summed result is used as the field value of the sixth field. For example, the sixth field is set to 2-bit digits, corresponding to the last 2 bits of the ASCII code sum of user ids.

In another embodiment, the sixth field may also be generated directly based on part of the user information. For example, a registered mobile phone number of the user is acquired as the user information, and a predetermined number of digits of the mobile phone number is used as the sixth field.

It will be appreciated that the sixth field may be generated based on other user information and/or in a greater variety of ways for the purpose of allowing the payment platform to perform a preliminary verification of the user at a later time when the user pays.

In one embodiment, a seventh field is also included in the payment token, the seventh field being generated based on at least a portion of the digits of the bank card number. More specifically, in one example, the seventh field contains a partial number of digits, such as the last 4 digits, of the bank card number. In another example, the seventh field is a number formed by encoding a number of the bank card number. The seventh field may be used for subsequent authentication of the user and his bank card by the bank at the time of payment by the user.

In one embodiment, an eighth field is also included in the payment token, the eighth field indicating the type of service supported. For example, in one example, the eighth field is set to a 3-digit number to indicate the type of business currently supported by the bank card, e.g., 000 for a full scenario, or full business type, 001 for quick payment, 002 for billing inquiry, and so on. The eighth field may be used for performing a preliminary verification on the payment mode or the payment scenario of the user when the user pays.

In one embodiment, a ninth field is also included in the payment token, the ninth field indicating the validity of the payment token. For example, in one example, the ninth field is set to a 1-bit number, 0 indicates no validity period requirement, i.e., long valid, 1 indicates single valid, 2 indicates valid for a limited time, 3 indicates valid for a limited number of times, and so on. The specific validity period time and the number limit may be prescribed in advance by a protocol and stored in a predetermined location. Through the ninth field, the validity of the payment mark can be marked, so that the generation of the payment marks of various validity types can be expanded, and the verification method can be used for verifying the validity of the payment mark subsequently.

FIG. 4 illustrates an example of a payment token generated according to one embodiment. In the example of fig. 4, a 36-digit payment token is generated, which includes:

a first field, taking an 8-digit number, showing the current date in the form of YYYYMMDD;

a second field, which is a serial number generated sequentially within one day by taking 12 digits;

a third field, which takes 3 digits and marks the issuer corresponding to the bank card;

a fourth field, 2 digits are taken as the excess early warning of the second field; the default value of this field is 00;

a fifth field, taking 1 digit number to represent the current valid database; the default value of the field is 0, which represents the main database;

a sixth field, which takes 2 digits and respectively corresponds to the last but one digit and the last but one digit of the user number;

the seventh field, take 4 digits, correspond to the last 4 digits of the bank card number;

an eighth field, which takes 3 digits and represents the service type supported by the current bank card;

the ninth field, taking a 1 digit number, indicates the validity of the payment sign.

It is to be understood that fig. 4 is merely an example. In other examples, the fields in the payment sign may have different lengths, and the arrangement of the fields is not limited to the example of fig. 4.

As described above, at step 22, the electronic payment platform generates a unique payment token for the bank card in the user's card bind request. In one embodiment, the electronic payment platform stores the generated payment token in association with the bank card indicating information in a storage system. In one embodiment, the bank card number is used as the indication information of the bank card, and the payment mark is correspondingly and associatively stored with the bank card number. In another embodiment, the user information is used as the indication information of the bank card, and the payment mark is stored in corresponding association with the user information. It will be appreciated that it is possible for a user to bind multiple bank cards for different payment types or payment scenarios. Thus, in another embodiment, a card flag is further assigned to the currently bound bank card to distinguish between different bank cards of the same user. When storing, the generated payment tag is stored in association with the user information and the card tag of the user. The card mark may be a bank card number, or a part of the bank card number, or may be a card number of a plurality of cards bound by the user, and the bank card bound by the user can be located only by combining with the user information. For example, table 1 below shows the associated storage of payment tokens in an electronic payment platform in one embodiment.

TABLE 1

User id	Card tag	Payment token
			Lily	Business card	1	Token1
Lily	Business card	2					Token2
			Lily	Signboard
1	Token3

In table 1 above, the user information is user id, and the card mark is card issuing bank and card number, so that the combination of user id and card mark is used as the bank card indication information to locate the different bank cards bound.

In addition to storing the generated payment token, at step 23, the generated payment token and the bank card number are sent to the corresponding card issuing institution, so that the payment token and the bank card number are stored in association with each other. Therefore, the card issuing institution acquires the payment mark generated by the electronic payment platform for a certain bank card, and can establish the association between the payment mark and the bank card.

On the basis that the issuer stores the payment tag and the bank card number in an associated manner, the payment tag can be used for verifying the payment request of the user.

Fig. 5 illustrates a method for payment verification using payment indicia, according to one embodiment, which is performed by the same method as illustrated in fig. 2, e.g., both electronic payment platforms. As shown in fig. 5, the method includes: step 51, receiving a payment request of a user, wherein the payment request comprises bank card indication information which indicates that the user sets an associated bank card in advance through a card binding request; step 52, obtaining a payment mark corresponding to the associated bank card according to the bank card indication information; and 53, sending the payment mark to an issuing institution corresponding to the associated bank card, so that the issuing institution verifies the payment transaction related to the payment request according to the payment mark. The specific implementation of the above steps is described below.

First, at step 51, a payment request is received from a user. In one embodiment, the merchant issues a payment request to the electronic payment platform by way of the user presenting the payment code and scanning. Generally, the payment code includes information of the payer, such as user information of the user, and information of the designated bank card. For example, under the common pay-Bay code, the last four digits of the currently used bank card will be displayed to indicate that the bank card is to be used for the current payment. The merchant adds the information of the payee and the information of the payment item in addition to the information of the payer by scanning the payment code, and sends a payment request to the electronic payment platform. Accordingly, the electronic payment platform receives a user's payment request from the merchant, which typically includes payer information, payee information, and payment item information, among others. More specifically, the payer information in the payment request includes at least bank card indication information to indicate which bank card the payer wants to use for payment, the bank card being a bank card that the user has requested to bind in advance by binding, also referred to as an associated bank card. In one embodiment, the bank card indicating information may be the bank card number itself. In another embodiment, the bank card indication information includes user information, and the bank card bound by the user is indicated through the user information. In another embodiment, the bank card indicating information is a combination of user information and card indicia. For example, as shown in table 1, different bank cards of the same user can be located by a combination of user id and card tag.

In step 52, the payment mark corresponding to the associated bank card is obtained according to the bank card indication information. It can be understood that, in the bank card binding stage, the electronic payment platform has generated a payment tag for the bank card according to the method shown in fig. 2, and stores the payment tag and the indication information of the bank card in a corresponding association manner. Accordingly, at step 52, upon extracting the bank card indicating information from the payment request, the corresponding payment sign can be quickly determined based on the bank card indicating information.

The generated payment mark at least comprises a first field, a second field and a third field, wherein the first field indicates the current time period to which the current time belongs, the second field is serial numbers sequentially generated in the current time period, and the third field indicates an issuer corresponding to the bank card number.

In one embodiment, the payment token further comprises a fourth field and/or a fifth field, wherein the fourth field reserves bits for the generation of the payment token and the fifth field indicates the currently active database for generating said payment token. In this way, the non-repeatability and uniqueness of the payment sign is more effectively guaranteed.

In one embodiment, the payment token further comprises a sixth field, the sixth field generated based on the user information. In such a case, after the payment token is obtained at step 52, the payment request may be preliminarily verified based on the sixth field in the payment token.

For example, in one example, the sixth field is generated based on the user number, e.g., showing the second to last and third to last bits of the user number. At this time, the user code of the user corresponding to the payment request is obtained, whether the corresponding digit of the obtained user code is consistent with the sixth field or not is compared, and the verification is passed under the condition of consistency.

In another example, the sixth field is generated based on a numerical encoding of the user information, e.g., the last 2 bits of the ASCII code sum corresponding to the user id. At this time, the user id of the user corresponding to the payment request is obtained, the last 2 bits of the ASCII code summation are calculated, whether the calculation result is consistent with the field value of the sixth field or not is compared, and the verification is passed under the condition of consistency.

And under the condition that the sixth field is generated in other modes, generating a verification field in the same mode based on the user information, comparing the verification field with the field value of the sixth field, and passing the verification if the verification field is consistent with the field value of the sixth field.

In one embodiment, after the preliminary verification passes, the payment token is sent to the issuer corresponding to the associated bank card, so that the issuer can verify the payment transaction related to the payment request according to the payment token in step 53.

In one embodiment, the corresponding card issuer is determined from the field value of the third field in the payment tag. In another embodiment, the corresponding card issuing institution is determined according to the pre-stored bank card information. After the card issuer is determined, the payment token can be sent to the corresponding card issuer so that the payment transaction related to the payment request can be verified according to the payment token.

It will be appreciated that since the payment indicia is generated in accordance with the manner of figure 2, including the aforementioned first, second and third fields, each bank card corresponds to a unique payment indicia in each card issuer, and the card issuer has stored the payment indicia in association with the corresponding bank card. Therefore, the card issuing institution can determine the corresponding bank card through the payment mark, and then carry out operations such as verification and deduction.

Further, in one embodiment, the payment token further includes a seventh field generated based on at least a portion of the digits of the bank card number, such as corresponding to the last 4 digits of the bank card number. At this time, the issuer may further verify the bank card requesting payment based on the seventh field. For example, when a payment request containing a payment tag is received, on one hand, the seventh field in the payment tag is read, on the other hand, the bank card number corresponding to the payment tag is obtained, a verification number is generated according to the same generation method as the seventh field, and then whether the verification number is matched with the seventh field is compared. And in the case that the two are matched, the verification is passed.

As previously described, in one embodiment, the payment token may also include an eighth field to indicate the type of service supported. In such a case, the electronic payment platform and/or the card issuer may verify the current payment request based on the eighth field.

In one embodiment, the payment token further includes a ninth field to indicate validity of the payment token. In such a case, the electronic payment platform and/or the card issuer may verify the validity of the payment sign based on the ninth field.

As described above, the electronic payment platform receives the payment request from the merchant, and then after determining the corresponding payment token, sends the payment token to the corresponding card issuer. In the above process, neither the payment request nor the payment tag itself contains sensitive information such as the complete bank card number. Even if the information is intercepted in the transmission process, sensitive information such as bank card numbers and the like cannot be directly revealed, and meaningful information cannot be obtained through cracking. Therefore, the payment mark replaces the bank card number, and the payment verification is realized more safely.

According to an embodiment of another aspect, there is also provided an apparatus for generating payment indicia. FIG. 6 shows a schematic block diagram of an apparatus to generate payment tokens, according to one embodiment. As shown in fig. 6, the generating means 60 includes: the receiving unit 61 is configured to receive a card binding request of a user, where the card binding request includes a bank card number associated with the user request; the generating unit 62 is configured to generate a payment tag according to the card binding request, where the payment tag includes at least a first field, a second field and a third field, where the first field indicates a current time period to which a current time belongs, the second field is an serial number sequentially generated in the current time period, and the third field indicates an issuer corresponding to the bank card number; and a sending unit 63 configured to send the payment label and the bank card number to a corresponding card issuing institution, so that the card issuing institution stores the payment label and the bank card number in association.

In one embodiment, the payment token further comprises a fourth field that reserves bits for the generation of said payment token. Accordingly, the generating unit 62 is configured to modify the field value of the fourth field when the serial number in the second field reaches the maximum value allowable for this field.

In one embodiment, the payment token further comprises a fifth field indicating a currently valid database for generating said payment token.

According to one embodiment, the payment token further comprises a sixth field, the sixth field being generated based on the user information.

Further, in one embodiment, the generating unit 62 is configured to: acquiring user information from the card binding request and/or the user registration information; determining a user number according to the user information; and determining the field value of the sixth field according to the user number.

In one embodiment, the payment token further includes a seventh field generated based on at least a partial number of digits of the bank card number.

According to one embodiment, the apparatus 60 further comprises a storage unit 64 configured to store said payment token in association with the bank card indication information.

Further, in one embodiment, the bank card indication information may include, a user id and a card flag.

Further, a device for payment verification using the payment sign is also provided. FIG. 7 shows a schematic block diagram of a payment verification apparatus according to one embodiment. As shown in fig. 7, the payment verification apparatus 70 includes: a receiving unit 71, configured to receive a payment request of a user, where the payment request includes bank card indication information indicating that the user previously sets an associated bank card through a card binding request; an obtaining unit 72, configured to obtain, according to the bank card indication information, a payment flag corresponding to the associated bank card, where the payment flag is generated in advance by using the generating device in fig. 6; a sending unit 73 configured to send the payment token to an issuer corresponding to the associated bank card, so that the issuer verifies the payment transaction related to the payment request according to the payment token.

In one embodiment, the payment token further comprises a sixth field, the sixth field generated based on the user information. Accordingly, the apparatus 70 further comprises a verification unit (not shown) configured to perform a preliminary verification of the payment request based on a sixth field in said payment token.

Specifically, in one embodiment, the verification unit is configured to: generating a verification field in the same manner as the sixth field based on the user information; comparing the authentication field with a field value of the sixth field.

In one embodiment, the payment token further comprises a seventh field generated based on at least a partial number of digits of the associated bank card number, such that the issuer validates the associated bank card according to the seventh field.

By utilizing the method and the device, in the binding stage, enough different payment marks can be generated for the same card issuer without repetition for the bank card to be bound. In the payment stage, the payment mark can be sent to a card issuing mechanism to carry out payment verification instead of the bank card number, so that the safety risk brought by the transmission of the bank card number is avoided, and the payment safety is improved.

According to an embodiment of another aspect, there is also provided a computer-readable storage medium having stored thereon a computer program which, when executed in a computer, causes the computer to perform the method described in connection with fig. 2 and 5.

According to an embodiment of yet another aspect, there is also provided a computing device comprising a memory and a processor, the memory having stored therein executable code, the processor, when executing the executable code, implementing the method described in connection with fig. 2 and 5.

Those skilled in the art will recognize that, in one or more of the examples described above, the functions described in this invention may be implemented in hardware, software, firmware, or any combination thereof. When implemented in software, the functions may be stored on or transmitted over as one or more instructions or code on a computer-readable medium.

The above-mentioned embodiments, objects, technical solutions and advantages of the present invention are further described in detail, it should be understood that the above-mentioned embodiments are only exemplary embodiments of the present invention, and are not intended to limit the scope of the present invention, and any modifications, equivalent substitutions, improvements and the like made on the basis of the technical solutions of the present invention should be included in the scope of the present invention.

Claims

1. A method of generating payment indicia, performed by an electronic payment platform, comprising:

sending the payment mark and the bank card number to a corresponding card issuing mechanism, so that the card issuing mechanism stores the payment mark and the bank card number in an associated manner; so that when the user pays, the electronic payment platform uses the payment mark to replace the bank card number to carry out payment verification to the bank.

2. The method of claim 1, wherein the payment token further comprises a fourth field that reserves bits for the generation of the payment token;

said generating a payment token comprises modifying a field value of said fourth field when the serial number in said second field reaches a maximum value allowable for this field.

3. The method of claim 1, wherein the payment token further comprises a fifth field indicating a currently active database for generating the payment token.

4. The method of any of claims 1-3, wherein the payment token further comprises a sixth field generated based on user information of the user.

5. The method of claim 4, wherein the generating payment indicia comprises:

determining a user number according to the user information;

6. The method of any of claims 1-3, wherein the payment token further comprises a seventh field generated based on at least a partial number of digits of the bank card number.

7. The method of any of claims 1-3, further comprising storing the payment indicia in association with bank card indicating information.

8. The method of claim 7, wherein the bank card indicating information comprises a user id and a card flag.

9. A method for payment verification using payment tokens, performed by an electronic payment platform, comprising:

acquiring a payment mark corresponding to the associated bank card according to the bank card indication information, wherein the payment mark is generated in advance according to the method of claim 1;

10. The method of claim 9, the payment token further comprising a sixth field generated based on user information; the method further comprises, after obtaining the payment sign corresponding to the associated bank card:

and performing preliminary verification on the payment request based on a sixth field in the payment mark.

11. The method of claim 10, the preliminary verification of the payment request comprising:

generating a verification field in the same manner as the sixth field based on the user information;

comparing the authentication field with a field value of the sixth field.

12. The method of claim 9, wherein the payment token further comprises a seventh field generated based on at least a partial number of digits of the associated bank card number, such that the issuer validates the associated bank card according to the seventh field.

13. An apparatus for generating payment tokens, implemented by an electronic payment platform, comprising:

the generating unit is configured to generate a payment mark according to the card binding request, wherein the payment mark at least comprises a first field, a second field and a third field, the first field indicates a current time period to which the current time belongs, the second field is an assembly number sequentially generated in the current time period, and the third field indicates an issuing organization corresponding to the bank card number; when the user pays, the electronic payment platform uses the payment mark to replace the bank card number to carry out payment verification to the bank;

14. The apparatus of claim 13, wherein the payment token further comprises a fourth field that reserves bits for generation of the payment token;

the generating unit is configured to modify the field value of the fourth field when the serial number in the second field reaches a maximum value allowable for the field.

15. The apparatus of claim 13, wherein the payment token further comprises a fifth field indicating a currently active database for generating the payment token.

16. The apparatus of any of claims 13-15, wherein the payment token further comprises a sixth field generated based on user information of the user.

17. The apparatus of claim 16, wherein the generating unit is configured to:

determining a user number according to the user information;

18. The apparatus of any of claims 13-15, wherein the payment token further comprises a seventh field generated based on at least a partial number of digits of the bank card number.

19. The apparatus of any of claims 13-15, further comprising a storage unit configured to store the payment token in association with bank card indication information.

20. The apparatus of claim 19, wherein the bank card indicating information comprises a user id and a card flag.

21. An apparatus for payment verification using payment tokens, performed by an electronic payment platform, comprising:

an obtaining unit configured to obtain a payment tag corresponding to the associated bank card according to the bank card indication information, the payment tag being generated in advance by using the apparatus of claim 13;

22. The apparatus of claim 21, the payment token further comprising a sixth field generated based on user information; the device further comprises a verification unit configured to perform a preliminary verification of the payment request based on a sixth field in the payment token.

23. The apparatus of claim 22, the verification unit configured to:

comparing the authentication field with a field value of the sixth field.

24. The apparatus of claim 21, wherein the payment token further comprises a seventh field generated based on at least a partial number of digits of the associated bank card number, such that the issuer validates the associated bank card according to the seventh field.

25. A computer-readable storage medium, on which a computer program is stored which, when executed in a computer, causes the computer to carry out the method of any one of claims 1-12.

26. A computing device comprising a memory and a processor, wherein the memory has stored therein executable code that, when executed by the processor, performs the method of any of claims 1-12.