CN112330323A - Method for generating token seed and two-dimensional code, payment method and payment device - Google Patents

Method for generating token seed and two-dimensional code, payment method and payment device Download PDF

Info

Publication number
CN112330323A
CN112330323A CN202011224727.XA CN202011224727A CN112330323A CN 112330323 A CN112330323 A CN 112330323A CN 202011224727 A CN202011224727 A CN 202011224727A CN 112330323 A CN112330323 A CN 112330323A
Authority
CN
China
Prior art keywords
terminal
payment
risk
customer
risk factor
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202011224727.XA
Other languages
Chinese (zh)
Inventor
唐敏
程浩
邓小茜
杨立兴
干芸芸
何睿
吴紫敏
张海澜
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
CCB Finetech Co Ltd
Original Assignee
CCB Finetech Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by CCB Finetech Co Ltd filed Critical CCB Finetech Co Ltd
Priority to CN202011224727.XA priority Critical patent/CN112330323A/en
Publication of CN112330323A publication Critical patent/CN112330323A/en
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/327—Short range or proximity payments by means of M-devices
    • G06Q20/3274—Short range or proximity payments by means of M-devices using a pictured code, e.g. barcode or QR-code, being displayed on the M-device
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/327—Short range or proximity payments by means of M-devices
    • G06Q20/3276—Short range or proximity payments by means of M-devices using a pictured code, e.g. barcode or QR-code, being read by the M-device
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4016—Transaction verification involving fraud or risk level assessment in transaction processing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange

Abstract

The invention discloses a method for generating a token seed and a two-dimensional code, a payment method and a payment device, and relates to the technical field of communication. One embodiment of the method for generating a token seed includes: generating a token seed when a first client applies for a payment service at a first terminal, the token seed being a set of parameters for generating a two-dimensional code related to the payment service, the token seed comprising at least: a risk factor associated with the first customer, the risk factor being indicative of a probability of the first customer being at risk in the payment transaction; and sending the token seed to the first terminal, generating a two-dimensional code by the first terminal according to the token seed, and completing the payment service through the two-dimensional code. The implementation can realize off-line payment, and can identify the risk of the client in the payment business.

Description

Method for generating token seed and two-dimensional code, payment method and payment device
Technical Field
The invention relates to the technical field of communication, in particular to a method for generating a token seed and a two-dimensional code, a payment method and a payment device.
Background
In recent years, offline payment scenarios have tended to be non-cash payments, non-banking physical card media payments, but payments using third party payment instruments on smart terminals, such as WeChat, Payment Bao and various big Bank APPs. However, when the network information of the merchant server is not good (such as buses, parking lots, navigation, etc.) or the mobile phone of the customer has no network traffic, the online payment can encounter a bottleneck. There is therefore a need to provide a technical solution for offline payment to solve the above technical problem. Moreover, in the off-line payment transaction, the payment success rate needs to be ensured, and the risk of payment failure is reduced.
Disclosure of Invention
In view of this, embodiments of the present invention provide a method, a payment method, and an apparatus for generating a token seed and a two-dimensional code, which can solve the problem that an existing payment method cannot identify a risk of a customer in a payment service.
To achieve the above object, according to an aspect of an embodiment of the present invention, there is provided a method of generating a token seed.
The method for generating the token seed of the embodiment of the invention is applied to a server side, and comprises the following steps:
generating a token seed when a first client applies for a payment service at a first terminal, the token seed being a set of parameters for generating a two-dimensional code related to the payment service, the token seed comprising at least: a risk factor associated with the first customer, the risk factor being indicative of a probability of the first customer being at risk in the payment transaction;
and sending the token seed to the first terminal, generating a two-dimensional code by the first terminal according to the token seed, and completing the payment service through the two-dimensional code.
Optionally, generating the token seed comprises:
compiling identification information, authorization information and risk factors relating to the first client of the first terminal into a sequence bitmap;
and generating a token seed by the sequence bitmap and key information corresponding to the payment scene of the payment service.
Optionally, the risk factors include at least one or more of: a financial default risk factor, a stolen swipe risk factor, and an account risk factor.
To achieve the above object, according to another aspect of the embodiments of the present invention, there is provided a method of generating a two-dimensional code.
The method for generating the two-dimensional code is applied to a first terminal and comprises the following steps:
receiving a token seed related to a payment service sent by a server, where the token seed is a parameter set used for generating a two-dimensional code related to the payment service, and the token seed at least includes: a risk factor associated with a first customer, the risk factor being indicative of a probability of the first customer being at risk in the payment transaction;
identifying the risk factor from the token seed and calculating an offline transaction default risk parameter of the first customer according to the risk factor;
and when the offline transaction default risk parameter is larger than a first critical value, generating a two-dimensional code according to the identification information of the first terminal, the authorization information of the first customer and the risk factor.
Optionally, generating the two-dimensional code according to the identification information of the first terminal, the authorization information of the first client, and the risk factor includes:
and generating a code string of a sequence bitmap by adopting key information corresponding to the payment scene of the payment service according to an encryption algorithm and the identification information of the first terminal, the authorization information of the first client and the risk factor, and compiling the code string into a two-dimensional code.
Optionally, before the step of generating the two-dimensional code, the method further includes:
judging whether the network signal intensity of the first terminal is greater than or equal to a first signal threshold value;
if the network signal strength of the first terminal is greater than or equal to a first signal threshold, requesting a server side to update a token seed, and analyzing the identification information of the first terminal, the authorization information of the first client and a risk factor related to the first client from the updated token seed;
and if the network signal strength of the first terminal is smaller than a first signal threshold, analyzing the identification information of the first terminal, the authorization information of the first client and the risk factor related to the first client from the locally stored token seed.
Optionally, the risk factors include at least one or more of: a financial default risk factor, a stolen swipe risk factor, and an account risk factor.
To achieve the above object, according to still another aspect of an embodiment of the present invention, there is provided a payment method.
The payment method of the embodiment of the invention is applied to a second terminal, and comprises the following steps:
when the fact that the two-dimensional code of the payment service displayed by the first terminal is identified through the code reader of the second terminal is detected, and the network signal intensity of the second terminal is smaller than a second signal threshold value, determining a corrected value of an offline transaction default risk parameter of the first client according to the offline payment times of the first terminal, the authorization information of the first client obtained by analyzing the two-dimensional code and a risk factor related to the first client; wherein the risk factor is used to represent a probability that the first customer is at risk in a payment transaction;
and if the modified value of the offline transaction default risk parameter of the first customer is greater than a second critical value, sending a deduction request to a server of the payment mechanism when the second terminal is online.
Optionally, before the step of determining the offline transaction default risk parameter correction value for the first customer, the method further comprises:
judging whether the offline transaction default risk parameter correction value of the first customer is larger than a second critical value;
if the modified value of the offline transaction default risk parameter of the first customer is smaller than a second critical value, rejecting the payment service;
if the offline transaction default risk parameter correction value of the first customer is larger than a second critical value, judging whether the current time is within the effective transaction time range;
if the transaction time is within the effective transaction time range, executing a step of sending a deduction request to a server of the payment mechanism when the second terminal is online;
and if the transaction time is not within the effective transaction time range, rejecting the payment service.
Optionally, before the step of determining the offline transaction default risk parameter correction value for the first customer, the method further comprises:
judging whether the network signal intensity of the second terminal is greater than or equal to a second signal threshold value;
if yes, sending a deduction request to a server of a payment mechanism to complete the payment service, wherein the deduction request at least comprises: account information and order information corresponding to the two-dimensional code.
To achieve the above object, according to still another aspect of an embodiment of the present invention, a server is provided.
The server of the embodiment of the invention comprises:
a first generating module, configured to generate a token seed when a first customer applies for a payment service at a first terminal, where the token seed is a parameter set used for generating a two-dimensional code related to the payment service, and the token seed at least includes: a risk factor associated with the first customer, the risk factor being indicative of a probability of the first customer being at risk in the payment transaction;
and the first sending module is used for sending the token seed to the first terminal, generating a two-dimensional code according to the token seed through the first terminal, and completing the payment service through the two-dimensional code.
To achieve the above object, according to still another aspect of an embodiment of the present invention, there is provided a first terminal.
The first terminal of the embodiment of the invention comprises:
a receiving module, configured to receive a token seed related to a payment service sent by a server, where the token seed is a parameter set used to generate a two-dimensional code related to the payment service, and the token seed at least includes: a risk factor associated with a first customer, the risk factor being indicative of a probability of the first customer being at risk in the payment transaction;
the calculation module is used for identifying the risk factor from the token seed and calculating an offline transaction default risk parameter of the first customer according to the risk factor; the token seed is a set of parameters for generating a two-dimensional code related to the payment transaction, the token seed including at least: a risk factor associated with a first customer, the risk factor being indicative of a probability of the first customer being at risk in the payment transaction;
and the second generation module is used for generating a two-dimensional code according to the identification information of the first terminal, the authorization information of the first customer and the risk factor when the offline transaction default risk parameter is greater than a first critical value.
To achieve the above object, according to still another aspect of an embodiment of the present invention, there is provided a second terminal.
The second terminal of the embodiment of the invention comprises:
the determining module is used for determining a modified value of an offline transaction default risk parameter of a first client according to the number of offline payments of the first terminal, authorization information of the first client obtained by analyzing the two-dimensional code and a risk factor related to the first client when the fact that the two-dimensional code of the payment service displayed by the first terminal is identified through the code reader of the second terminal is detected, and the network signal intensity of the second terminal is smaller than a second signal threshold; wherein the risk factor is used to represent a probability that the first customer is at risk in a payment transaction;
and the third sending module is used for sending a deduction request to the server of the payment mechanism when the second terminal is online if the modified value of the offline transaction default risk parameter of the first customer is greater than a second critical value.
To achieve the above object, according to still another aspect of an embodiment of the present invention, a terminal is provided.
The terminal of the embodiment of the invention comprises:
one or more processors;
a storage device for storing one or more programs,
when executed by the one or more processors, cause the one or more processors to implement the method as described above.
To achieve the above object, according to still another aspect of an embodiment of the present invention, a server is provided.
The server of the embodiment of the invention comprises:
one or more processors;
a storage device for storing one or more programs,
when executed by the one or more processors, cause the one or more processors to implement the method as described above.
To achieve the above object, according to still another aspect of an embodiment of the present invention, there is provided a computer-readable medium.
A computer-readable medium of an embodiment of the invention has stored thereon a computer program which, when executed by a processor, implements the method as described above.
One embodiment of the above invention has the following advantages or benefits:
in the embodiment of the invention, the method for generating the token seed can realize off-line payment, for example, can ensure that the payment transaction can be carried out under the single off-line or double off-line scene of a customer and a merchant and under the scene that the customer does not carry out pre-recharging, can identify the risk of the customer in the payment service, can reduce the risk of payment failure and shorten the time of the payment transaction.
Further effects of the above-mentioned non-conventional alternatives will be described below in connection with the embodiments.
Drawings
The drawings are included to provide a better understanding of the invention and are not to be construed as unduly limiting the invention. Wherein:
FIG. 1 is a schematic flow chart diagram of a method of generating a token seed according to an embodiment of the invention;
FIG. 2 is a flow chart illustrating a method of generating a token seed according to an embodiment of the invention;
fig. 3 is a flowchart illustrating a method for generating a two-dimensional code according to an embodiment of the present invention;
fig. 4 is a flowchart illustrating a method for generating a two-dimensional code according to an embodiment of the present invention;
FIG. 5 is a schematic flow chart diagram of a payment method of an embodiment of the present invention;
FIG. 6 is a schematic flow chart diagram of a payment method of an embodiment of the present invention;
FIG. 7 is a schematic structural diagram of a server according to an embodiment of the present invention;
fig. 8 is a schematic structural diagram of a first terminal according to an embodiment of the present invention;
fig. 9 is a schematic structural diagram of a second terminal according to an embodiment of the present invention;
FIG. 10 is an exemplary system architecture diagram in which embodiments of the present invention may be employed;
FIG. 11 is a block diagram of a computer system suitable for use with a terminal device or server that implements an embodiment of the invention.
Detailed Description
Exemplary embodiments of the present invention are described below with reference to the accompanying drawings, in which various details of embodiments of the invention are included to assist understanding, and which are to be considered as merely exemplary. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the embodiments described herein can be made without departing from the scope and spirit of the invention. Also, descriptions of well-known functions and constructions are omitted in the following description for clarity and conciseness.
In order to solve the problem that the existing payment mode cannot identify the risk of a client in a payment service, the embodiment of the invention provides a payment system, which comprises: the payment system comprises a first terminal, a second terminal and a server side, wherein payment tools such as a mobile phone, a pad and the like are loaded on the first terminal, and the payment two-dimensional code can be displayed on the first terminal. The payment means APP is generally provided by the payment authority and performs message interaction with the payment authority to transmit information. The second terminal is provided with a money receiving device, the terminal is provided with a code reader (or becomes a code scanner), the terminal can identify and analyze the two-dimensional code, and source strings corresponding to the two-dimensional code or analysis and post-transmission content can be stored locally. And when the payment server is online, the collection server receives the deduction request of the collection terminal and sends the deduction request to the payment server to carry out deduction, and the result is obtained and then transmitted to the collection terminal for display.
The off-line payment can be realized through the following modes:
1) the offline payment method comprises the following steps: the two-dimension code is displayed on the first terminal in an off-line mode, the second terminal is on-line, the contents of the two-dimension code are analyzed to request for deduction from a payment mechanism server, and the deduction result is known in real time so as to ensure the success of deduction. The payment client needs to perform offline verification of a password or a human face under the terminal.
2) And (2) an offline payment method II: and (3) charging the payment voucher (such as an appointed account) by the payment client in advance by using a prepaid card offline payment mode, storing the sum of money into the payment voucher, displaying the two-dimensional code by the client when the payment voucher is double offline, and analyzing the balance of the payment voucher in the two-dimensional code by the collection terminal to perform offline or online deduction.
From the above analysis, the first mode solves the situation that the first terminal has risks, and the financial default risk of the customer is not identified. Therefore, when the risk of the client exists, such as the risk of insufficient balance of the client account, failure of the client account or malicious arbitrage of the client, the system cannot be screened, and the fund loss is caused. The second mode is only suitable for a prepayment mode, and the customer deducts money according to the off-line certificate after prepaying the card. However, for the customer, the prepayment mode may have a capital risk, which is caused by the integrity of the merchant on one hand, and on the other hand, the merchant cannot timely discriminate the customer with the information of the customer stolen.
In an embodiment of the present invention, a processing flow of the payment system may include the following steps:
(1) when network signals exist, a paying client applies for opening the payment service supporting the off-line transaction and binding related contents (accounts, terminals and the like).
(2) When in off-line or on-line transaction, the payment terminal clicks the service entrance to generate a payment two-dimensional code;
(3) the collection terminal scans the two-dimensional code, analyzes the corresponding content, calculates the content and stores the result to the local collection terminal;
(4) when the collection terminal is on line, the stored batch payer information is transmitted to the collection server, and the collection server carries out a deduction request to the payment mechanism server and obtains a message analysis result to store the message analysis result in the server database.
In the embodiment of the invention, the payment system carries out risk identification from the risk of the first terminal on the premise of not revealing the privacy information of the client, carries out risk identification from the financial business risk of the client, and maps the two risks into risk identification factors to be loaded on an offline payment certificate (such as an offline two-dimensional code) of the client so as to ensure the safety of offline payment transaction.
In order to solve the problem that the existing payment mode cannot identify the risk of a client in a payment service, the embodiment of the invention provides a method for generating a token seed, and an execution main body of the method is a server. Wherein the token seed is a specific means for authentication token implementation, and the token is a unique identity identifier in an interactive session. For example: and generating a one-time password by encryption calculation by using the seed and the time. It is to be understood that the token seed is a set of parameters for generating a two-dimensional code associated with a payment transaction, i.e., a transaction in which a first customer pays or collects money from a second customer. Fig. 1 is a flowchart illustrating a method for generating a token seed according to an embodiment of the present invention, and as shown in fig. 1, the method for generating a token seed may include the following steps:
step S101: generating a token seed when a first customer applies for payment traffic at a first terminal, the token seed comprising at least: a risk factor associated with the first customer, the risk factor being indicative of a probability of the first customer being at risk in the payment service.
In step S101, when the server receives a request of a payment service sent by the first terminal, the server generates a token seed related to the payment service and sends the token seed related to the payment service to the first terminal, and the first terminal stores the token seed.
It is understood that the token seed is a set of parameters loaded with risk factors. The risk factors include at least one or more of: a financial default risk factor, a stolen swipe risk factor, and an account risk factor. The financial default risk factor mainly refers to a financial default risk parameter calculated in a payment institution risk system according to the financial transaction behavior data of the first customer. For example: the financial transaction behavior data includes: repayment of credit card, investment and financing, repayment and the like. The financial transaction behavior data may be derived from credit card repayment systems, investment financing systems, house credit systems, and the like. The risk factor of the stolen brush mainly refers to a risk parameter of the stolen brush calculated by terminal behavior data related to the first customer in a risk system of a payment mechanism. For example: the terminal behavior data can be data of terminal replacement, password theft, account theft and the like, and can be derived from an anti-fraud system. The account risk factor mainly refers to a customer account risk parameter calculated in a payment institution risk system according to the account information data related to the first customer. For example: the account information includes: whether the account is insufficient in balance, whether the credit card is unopened, account arrears, account validity period is over, account password is locked, and the like, and the main sources of account information data are a debit card system and a credit card system.
It should be noted that, in addition to the token seed including the risk factor, the token seed further includes: the identification information of the first terminal may be a terminal device number. The authorization information refers to coding information generated when the first client signs on to use the off-line two-dimensional code for transaction. For example: the authorization information may be an authorization protocol number, which may be understood as a special number when the first client signs up for using the offline two-dimensional code, and the client identity information and the corresponding transaction card information of the client during using the offline transaction may be identified by the authorization protocol number.
Further, a token seed may be generated based on the identification information of the first terminal, the authorization information of the first customer, and a risk factor associated with the first customer. Wherein the process of generating the token seed is substantially: the identification information, authorization information, and risk factors associated with the first client of the first terminal are first compiled into a sequence bitmap. And then generating a token seed by the sequence bitmap and key information corresponding to the payment scene of the payment service. When acquiring the risk factor, the identity information of the first client and the identification information of the first terminal may be acquired; and acquiring the risk factor of the client of being stolen according to the identification information of the first terminal, and acquiring the account risk factor of the client according to the identity information of the client.
Step S102: and sending the token seed to the first terminal, generating a two-dimensional code by the first terminal according to the token seed, and completing the payment service through the two-dimensional code.
In step S102, when a first customer applies for a payment service at a first terminal, the server generates the token seed and sends the token seed to the first terminal, and the first terminal generates a two-dimensional code according to the token seed and completes the payment service through the two-dimensional code.
In the embodiment of the invention, the method for generating the token seed can realize off-line payment, for example, can ensure that the payment transaction can be carried out under the single off-line or double off-line scene of a customer and a merchant and under the scene that the customer does not carry out pre-recharging, can identify the risk of the customer in the payment service, can reduce the risk of payment failure and shorten the time of the payment transaction.
Referring to fig. 2, when a first client applies for a payment service on a first terminal, the first terminal is provided with a payment tool, and a server obtains a userid (user ID) of the first client and a device serial number of the first terminal; the method comprises the steps that a server side is linked with a payment mechanism client risk scoring system to obtain client financial default risk factors; the financial default risk factor mainly refers to a financial default risk parameter calculated in a payment institution risk system according to the previous financial transaction behaviors of a client (such as credit card repayment, investment and financing, repayment and the like, and data may be from a credit card repayment system, an investment and financing system, a house loan system and the like). And the server transmits the equipment serial number of the first terminal to a payment mechanism anti-fraud system to inquire and acquire a risk factor of the stolen brushing of the customer, wherein the risk factor of the stolen brushing mainly refers to a risk parameter of the stolen brushing of the customer calculated in the payment mechanism risk system according to the previous related terminal behaviors (such as terminal replacement, password theft, account theft and the like, and data possibly comes from the anti-fraud system) of the customer. And the server side inquires the account information of the customer through the userid of the first customer, and sends the account information to the card issuing system to inquire the information such as the state, balance and the like of the customer account to acquire the account risk factor of the customer. The account risk factor mainly refers to a risk parameter of the account of the customer calculated in the risk system of the payment institution according to the related information of the account related to the customer before (such as whether the account is insufficient in balance, whether a credit card is not opened, account arrears, account validity is over, account password is locked, and the like, and main data sources and a debit card system and a credit card system). In order to generate the token seed, the server compiles the payment authorization protocol number, the financial default risk factor, the stolen swiping factor, the account risk factor and the number of the terminal device applying for opening the service into a sequence bitmap, generates the token seed together with the public key information corresponding to the payment scene, and transmits the token seed to the first terminal for storage.
In order to solve the problem that the existing payment mode cannot identify the risk of a client, the embodiment of the invention provides a method for generating a two-dimensional code. The payment service refers to a service in which a first customer pays or collects money for a second customer. Fig. 3 is a schematic flowchart of a method for generating a two-dimensional code according to an embodiment of the present invention, and as shown in fig. 3, the method for generating a two-dimensional code may include the following steps:
step S301: receiving a token seed related to a payment service sent by a server, where the token seed is a parameter set used for generating a two-dimensional code related to the payment service, and the token seed at least includes: a risk factor associated with the first customer, the risk factor being indicative of a probability of the first customer being at risk in the payment service.
In step S301, the payment service is a service in which the first customer pays or collects money to the second customer. The token seed is a set of parameters loaded with risk factors. The risk factors include at least one or more of: a financial default risk factor, a stolen swipe risk factor, and an account risk factor. The financial default risk factor mainly refers to a financial default risk parameter calculated in a payment institution risk system according to the financial transaction behavior data of the first customer. For example: the financial transaction behavior data includes: repayment of credit card, investment and financing, repayment and the like. The financial transaction behavior data may be derived from credit card repayment systems, investment financing systems, house credit systems, and the like. The risk factor of the stolen brush mainly refers to a risk parameter of the stolen brush calculated by terminal behavior data related to the first customer in a risk system of a payment mechanism. For example: the terminal behavior data can be data of terminal replacement, password theft, account theft and the like, and can be derived from an anti-fraud system. The account risk factor mainly refers to a customer account risk parameter calculated in a payment institution risk system according to the account information data related to the first customer. For example: the account information includes: whether the account is insufficient in balance, whether the credit card is unopened, account arrears, account validity period is over, account password is locked, and the like, and the main sources of account information data are a debit card system and a credit card system.
It should be noted that, in addition to the token seed including the risk factor, the token seed further includes: the identification information of the first terminal may be a terminal device number. The authorization information refers to coding information generated when the first client signs on to use the off-line two-dimensional code for transaction. For example: the authorization information may be an authorization protocol number, which may be understood as a special number when the first client signs up for using the offline two-dimensional code, and the client identity information and the corresponding transaction card information of the client during using the offline transaction may be identified by the authorization protocol number.
Step S302: the risk factor is identified from the token seed and an offline transaction default risk parameter for the first customer is calculated based on the risk factor.
In step S302, the risk factor may be input into a pre-trained risk model to obtain an offline transaction default risk parameter of the first customer. The risk model is a calculation model obtained by analyzing and counting according to big data by a payment institution wind control system, the input parameters of the risk model are a financial default risk factor, a stolen swiping risk factor, an account risk factor and the offline payment times of the first terminal (or called as customer offline code calling times), and the output parameters of the risk model are the offline transaction default risk parameters of customers.
Step S303: and when the offline transaction default risk parameter is larger than a first critical value, generating a two-dimensional code according to the identification information of the first terminal, the authorization information of the first customer and the risk factor.
In step S303, the first critical value may be understood as a risk threshold, and the first critical value may be determined according to actual needs. Before step S303, the identification information of the first terminal, the authorization information of the first client, and the risk factor may be analyzed in the token seed, and then a two-dimensional code may be generated according to parameters analyzed from the token seed.
Referring to fig. 4, further, before step S303, the method further includes: and judging whether the network signal strength of the first terminal is greater than or equal to a first signal threshold value so as to judge whether the first terminal has a good network signal. If the network signal intensity of the first terminal is greater than or equal to a first signal threshold, requesting a server to update a token seed, analyzing parameters, acquiring an equipment serial number of the current terminal, acquiring identification information of the current terminal, and judging whether the identification information of the current terminal is consistent with the identification information of the first terminal; if yes, go to step S303. If the network signal intensity of the first terminal is smaller than a first signal threshold, resolving parameters according to the token seed, collecting the equipment serial number of the APP cache terminal, and then judging whether the equipment serial number of the terminal is consistent with the equipment serial number of the first terminal; if yes, go to step S303. Otherwise, the payment service is refused.
Referring to fig. 4, the first terminal acquires a token seed, identifies a financial default risk factor, a stolen brushing risk factor, an account risk factor, a customer authorization agreement number, an equipment serial number of the first terminal, and a customer offline code calling number from the token seed, and calls a risk model of APP local access, wherein the risk model is a risk calculation model obtained by statistics of a payment authority wind control system according to big data analysis, input parameters of the risk calculation model are three customer factors and the customer offline code calling number, and output parameters of the risk calculation model are offline transaction default risk parameters of customers. And when the risk model result parameter is larger than a critical value, generating a code string with a risk factor sequence bitmap by using the public key through an encryption algorithm, and compiling into an offline payment two-dimensional code.
In the embodiment of the invention, the method for generating the two-dimension code can realize off-line payment, for example, can ensure that the payment transaction can be carried out under the single off-line or double off-line scene of a customer and a merchant and under the scene that the customer does not carry out pre-recharging, can identify the risk of the customer in the payment service, can reduce the risk of payment failure and shorten the time of the payment transaction.
In order to solve the problem that the existing payment mode cannot identify the risk of a client in a payment service, the embodiment of the invention provides a payment method, and an execution main body of the method is a terminal. The payment service refers to a service in which a first customer pays or collects money for a second customer. Fig. 5 is a schematic flow chart of a payment method according to an embodiment of the present invention, and as shown in fig. 5, the payment method may include the following steps:
step S501: when the fact that the two-dimensional code of the payment service displayed by the first terminal is identified through the code reader of the second terminal is detected, and the network signal intensity of the second terminal is smaller than a second signal threshold value, determining a corrected value of an offline transaction default risk parameter of the first client according to the offline payment times of the first terminal, the authorization information of the first client obtained by analyzing the two-dimensional code and a risk factor related to the first client; wherein the risk factor is used to represent a probability that the first customer is at risk in a payment transaction.
In step S501, the risk factors include at least one or more of: a financial default risk factor, a stolen swipe risk factor, and an account risk factor. The financial default risk factor mainly refers to a financial default risk parameter calculated in a payment institution risk system according to the financial transaction behavior data of the first customer. For example: the financial transaction behavior data includes: repayment of credit card, investment and financing, repayment and the like. The financial transaction behavior data may be derived from credit card repayment systems, investment financing systems, house credit systems, and the like. The risk factor of the stolen brush mainly refers to a risk parameter of the stolen brush calculated by terminal behavior data related to the first customer in a risk system of a payment mechanism. For example: the terminal behavior data can be data of terminal replacement, password theft, account theft and the like, and can be derived from an anti-fraud system. The account risk factor mainly refers to a customer account risk parameter calculated in a payment institution risk system according to the account information data related to the first customer. For example: the account information includes: whether the account is insufficient in balance, whether the credit card is unopened, account arrears, account validity period is over, account password is locked, and the like, and the main sources of account information data are a debit card system and a credit card system.
Before step S501, when it is detected that the two-dimensional code of the payment service displayed by the first terminal is identified by the code reader, determining whether the network signal strength of the second terminal is greater than or equal to a second signal threshold, so as to determine whether the second terminal has a good network signal; if yes, sending a deduction request to a server of a payment mechanism to complete the payment service, wherein the deduction request at least comprises: account information and order information corresponding to the two-dimensional code. Otherwise, step S501 is executed.
Step S502: and if the modified value of the offline transaction default risk parameter of the first customer is greater than a second critical value, sending a deduction request to a server of the payment mechanism when the second terminal is online.
In step S502, the second critical value may be understood as a risk threshold, and may be determined according to actual needs.
Before step S502, the method further comprises: judging whether the offline transaction default risk parameter correction value of the first customer is larger than a second critical value; if the modified value of the offline transaction default risk parameter of the first customer is smaller than a second critical value, rejecting the payment service; if the offline transaction default risk parameter correction value of the first customer is larger than a second critical value, judging whether the current time is within the effective transaction time range; if the transaction time is within the effective transaction time range, executing a step of sending a deduction request to a server of the payment mechanism when the second terminal is online; and if the transaction time is not within the effective transaction time range, rejecting the payment service.
In the embodiment of the invention, the payment method can realize off-line payment, for example, the payment transaction can be carried out under the single off-line or double off-line scene of a customer and a merchant and under the scene that the customer does not carry out pre-recharging, the risk of the customer in the payment service can be identified, the risk of payment failure can be reduced, and the time of the payment transaction is shortened.
In order to solve the problem that the existing payment method cannot identify the risk of the client in the payment service, an embodiment of the present invention provides a payment method, and referring to fig. 6, the payment method may include the following steps:
step S601: and the code reader of the second terminal identifies the two-dimensional code displayed by the first terminal.
Step S602: judging whether the network signal intensity of the second terminal is greater than or equal to a second signal threshold value or not so as to judge whether the second terminal has a good network signal or not; if yes, go to step S609. Otherwise, step S603 is performed.
Step S603: and decrypting the client authorization protocol number, the risk factor and the time stamp in the two-dimensional code according to a private key appointed by the payment mechanism.
Step S604: and determining the modified value of the offline transaction default risk parameter of the first customer according to the risk factor and the offline payment times of the first terminal.
In step S604, the calculation result of the offline transaction default risk parameter modification value is obtained by inputting the risk factor and the offline payment times of the first terminal into the risk model.
Step S605: judging whether the offline transaction default risk parameter correction value of the first customer is larger than a second critical value; if yes, go to step S606.
Step S606: judging whether the current time is valid or not through the time slice; if yes, go to step S608. If not, go to step S607.
Step S607: the transaction task is denied.
Step S608: and storing the authorization protocol number and the order information to a server system, accumulating the offline times of the client, and sending a deduction request to a payment structure server when the client is online.
Step S609: sending a deduction request to a server of a payment mechanism to complete the payment service, wherein the deduction request at least comprises: account information and order information corresponding to the two-dimensional code.
In the embodiment of the invention, the second terminal can identify the two-dimension code and analyze the content in the two-dimension code, acquire the corrected payment risk factor model from the payment mechanism server in advance, record the offline payment times of the customer, input the risk factor and the offline payment times of the first terminal into the risk model to obtain a calculation result, and refuse the payment service when the calculation result is greater than the second critical value. When the critical value of the offline transaction default risk parameter is smaller than or equal to the second critical value, the payment information of the client with the two-dimension code terminal is stored, the payment information is sent to the server after online, the server makes a money deduction request to the server of the payment mechanism, and the correct result is obtained and stored in the database.
Fig. 7 is a schematic structural diagram of a server according to an embodiment of the present invention, and referring to fig. 7, an embodiment of the present invention provides a server 700, including:
a first generating module 701, configured to generate a token seed when a first customer applies for a payment service at a first terminal, where the token seed is a parameter set used for generating a two-dimensional code related to the payment service, and the token seed at least includes: a risk factor associated with the first customer, the risk factor being indicative of a probability of the first customer being at risk in the payment transaction;
a first sending module 702, configured to send the token seed to the first terminal, generate a two-dimensional code according to the token seed by the first terminal, and complete the payment service through the two-dimensional code.
Optionally, the first generating module 701 is further configured to:
compiling identification information, authorization information and risk factors relating to the first client of the first terminal into a sequence bitmap;
and generating a token seed by the sequence bitmap and key information corresponding to the payment scene of the payment service.
Optionally, the risk factors include at least one or more of: a financial default risk factor, a stolen swipe risk factor, and an account risk factor.
In the embodiment of the invention, the server can realize off-line payment, for example, the payment transaction can be carried out under the single off-line or double off-line scene of the customer and the merchant and the scene that the customer does not carry out pre-recharging, the risk of the customer in the payment service can be identified, the risk of payment failure can be reduced, and the time of the payment transaction is shortened.
Fig. 8 is a schematic structural diagram of a first terminal according to an embodiment of the present invention, and referring to fig. 8, the first terminal 800 includes:
a receiving module 801, configured to receive a token seed related to a payment service sent by a server, where the token seed is a parameter set used to generate a two-dimensional code related to the payment service, and the token seed at least includes: a risk factor associated with a first customer, the risk factor being indicative of a probability of the first customer being at risk in the payment transaction;
a calculating module 802, configured to identify the risk factor from the token seed, and calculate an offline transaction default risk parameter of the first customer according to the risk factor; the token seed is a set of parameters for generating a two-dimensional code related to the payment transaction, the token seed including at least: a risk factor associated with a first customer, the risk factor being indicative of a probability of the first customer being at risk in the payment transaction;
a second generating module 803, configured to generate a two-dimensional code according to the identification information of the first terminal, the authorization information of the first customer, and the risk factor when the offline transaction default risk parameter is greater than a first critical value.
Optionally, the second generating module 803 is further configured to:
and generating a code string of a sequence bitmap by adopting key information corresponding to the payment scene of the payment service according to an encryption algorithm and the identification information of the first terminal, the authorization information of the first client and the risk factor, and compiling the code string into a two-dimensional code.
Optionally, the first terminal further includes:
the first judging module is used for judging whether the network signal intensity of the first terminal is greater than or equal to a first signal threshold value;
a first parsing module, configured to request a server to update a token seed if the network signal strength of the first terminal is greater than or equal to a first signal threshold, and parse, from the updated token seed, identification information of the first terminal, authorization information of the first client, and a risk factor related to the first client;
and the second analysis module is used for analyzing the identification information of the first terminal, the authorization information of the first client and the risk factor related to the first client from the locally stored token seed if the network signal strength of the first terminal is smaller than a first signal threshold.
Optionally, the risk factors include at least one or more of: a financial default risk factor, a stolen swipe risk factor, and an account risk factor.
In the embodiment of the invention, the first terminal can realize off-line payment, for example, the payment transaction can be carried out under the single off-line or double off-line scene of the customer and the merchant and the scene that the customer does not carry out pre-recharging, the risk of the customer in the payment service can be identified, the risk of payment failure can be reduced, and the time of the payment transaction is shortened.
Fig. 9 is a schematic structural diagram of a second terminal according to an embodiment of the present invention, and referring to fig. 9, the second terminal 900 is provided with a code reader, including:
a determining module 901, configured to determine, when it is detected that a two-dimensional code of a payment service displayed by a first terminal is identified by a code reader of the second terminal and a network signal strength of the second terminal is smaller than a second signal threshold, a modified value of an offline transaction default risk parameter of the first client according to the number of times of offline payment of the first terminal, authorization information of the first client obtained by parsing from the two-dimensional code, and a risk factor related to the first client; wherein the risk factor is used to represent a probability that the first customer is at risk in a payment transaction;
a third sending module 902, configured to send a deduction request to the server of the payment mechanism when the second terminal is online if the modified value of the offline transaction default risk parameter of the first customer is greater than the second critical value.
Optionally, the second terminal further includes:
the second judgment module is used for judging whether the offline transaction default risk parameter correction value of the first customer is larger than a second critical value;
the rejecting module is used for rejecting the payment service if the modified value of the offline transaction default risk parameter of the first customer is smaller than a second critical value; if the transaction time is not within the effective transaction time range, rejecting the payment service;
the third judgment module is used for judging whether the current time is within the effective transaction time range or not if the offline transaction default risk parameter correction value of the first customer is larger than a second critical value; if the transaction time is within the effective transaction time range, executing a step of sending a deduction request to a server of the payment mechanism when the second terminal is online;
optionally, the second terminal further includes:
the fourth judging module is used for judging whether the network signal intensity of the second terminal is equal to or lower than the second signal threshold value;
a fourth sending module, configured to send a deduction request to a server of a payment mechanism to complete the payment service if the payment request at least includes: account information and order information corresponding to the two-dimensional code.
In the embodiment of the invention, the second terminal can realize off-line payment, for example, the payment transaction can be carried out under the single off-line or double off-line scene of the customer and the merchant and the scene that the customer does not carry out pre-recharging, the risk of the customer in the payment service can be identified, the risk of the payment failure can be reduced, and the time of the payment transaction is shortened.
Fig. 10 illustrates an exemplary system architecture 1000 for a method of generating a token seed, a method of generating a two-dimensional code, a payment method, and corresponding devices to which embodiments of the invention may be applied.
As shown in fig. 10, the system architecture 1000 may include terminal devices 1001, 1002, 1003, a network 1004, and a server 1005. The network 1004 is used to provide a medium for communication links between the terminal devices 1001, 1002, 1003 and the server 1005. Network 1004 may include various connection types, such as wired, wireless communication links, or fiber optic cables, to name a few.
The client can use the terminal devices 1001, 1002, 1003 to interact with the server 1005 via the network 1004 to receive or transmit messages or the like. The terminal devices 1001, 1002, 1003 may have installed thereon various messenger client applications such as shopping applications, web browser applications, search applications, instant messenger, mailbox clients, social platform software, etc. (by way of example only).
The terminal devices 1001, 1002, 1003 may be various electronic devices having a display screen and supporting web browsing, including but not limited to smart phones, tablet computers, laptop portable computers, desktop computers, and the like.
The server 1005 may be a server providing various services, such as a background management server (for example only) providing support for shopping websites browsed by customers using the terminal devices 1001, 1002, and 1003.
It should be noted that the method for generating the token seed provided by the embodiment of the present invention is generally executed by the server 1005. The method for generating the two-dimensional code and the payment method provided by the embodiment of the invention are generally executed by the terminal devices 1001, 1002 and 1003.
It should be understood that the number of terminal devices, networks, and servers in fig. 10 is merely illustrative. There may be any number of terminal devices, networks, and servers, as desired for implementation.
Referring now to FIG. 11, shown is a block diagram of a computer system 1100 suitable for use with a terminal device implementing an embodiment of the present invention. The terminal device shown in fig. 11 is only an example, and should not bring any limitation to the functions and the scope of use of the embodiments of the present invention.
As shown in fig. 11, the computer system 1100 includes a Central Processing Unit (CPU)1101, which can perform various appropriate actions and processes in accordance with a program stored in a Read Only Memory (ROM)1102 or a program loaded from a storage section 1108 into a Random Access Memory (RAM) 1103. In the RAM 1103, various programs and data necessary for the operation of the system 1100 are also stored. The CPU 1101, ROM 1102, and RAM 1103 are connected to each other by a bus 1104. An input/output (I/O) interface 1105 is also connected to bus 1104.
The following components are connected to the I/O interface 1105: an input portion 1106 including a keyboard, mouse, and the like; an output portion 1107 including a signal output unit such as a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), and a speaker; a storage section 1108 including a hard disk and the like; and a communication section 1109 including a network interface card such as a LAN card, a modem, or the like. The communication section 1109 performs communication processing via a network such as the internet. A driver 1110 is also connected to the I/O interface 1105 as necessary. A removable medium 1111 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like is mounted on the drive 1110 as necessary, so that a computer program read out therefrom is mounted into the storage section 1108 as necessary.
In particular, according to the embodiments of the present disclosure, the processes described above with reference to the flowcharts may be implemented as computer software programs. For example, embodiments of the present disclosure include a computer program product comprising a computer program embodied on a computer readable medium, the computer program comprising program code for performing the method illustrated in the flow chart. In such an embodiment, the computer program may be downloaded and installed from a network through the communication portion 1109 and/or installed from the removable medium 1111. The above-described functions defined in the system of the present invention are executed when the computer program is executed by a Central Processing Unit (CPU) 1101.
It should be noted that the computer readable medium shown in the present invention can be a computer readable signal medium or a computer readable storage medium or any combination of the two. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples of the computer readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the present invention, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. In the present invention, however, a computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated data signal may take many forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wire, fiber optic cable, RF, etc., or any suitable combination of the foregoing.
The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams or flowchart illustration, and combinations of blocks in the block diagrams or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
As another aspect, the present invention also provides a computer-readable medium that may be contained in the apparatus described in the above embodiments; or may be separate and not incorporated into the device. The computer readable medium carries one or more programs which, when executed by a device, cause the device to comprise: generating a token seed when a first client applies for a payment service at a first terminal, the token seed being a set of parameters for generating a two-dimensional code related to the payment service, the token seed comprising at least: a risk factor associated with the first customer, the risk factor being indicative of a probability of the first customer being at risk in the payment transaction; and sending the token seed to the first terminal, generating a two-dimensional code by the first terminal according to the token seed, and completing the payment service through the two-dimensional code.
In the embodiment of the invention, the method can realize off-line payment, for example, the payment transaction can be carried out under the single off-line or double off-line scene of a customer and a merchant and the scene that the customer does not carry out pre-recharging, the risk of the customer in the payment service can be identified, the risk of payment failure can be reduced, and the time of the payment transaction is shortened.
The above-described embodiments should not be construed as limiting the scope of the invention. Those skilled in the art will appreciate that various modifications, combinations, sub-combinations, and substitutions can occur, depending on design requirements and other factors. Any modification, equivalent replacement, and improvement made within the spirit and principle of the present invention should be included in the protection scope of the present invention.

Claims (16)

1. A method for generating a token seed is applied to a server, and is characterized in that the method comprises the following steps:
generating a token seed when a first client applies for a payment service at a first terminal, the token seed being a set of parameters for generating a two-dimensional code related to the payment service, the token seed comprising at least: a risk factor associated with the first customer, the risk factor being indicative of a probability of the first customer being at risk in the payment transaction;
and sending the token seed to the first terminal, generating a two-dimensional code by the first terminal according to the token seed, and completing the payment service through the two-dimensional code.
2. The method of claim 1, wherein generating a token seed comprises:
compiling identification information, authorization information and risk factors relating to the first client of the first terminal into a sequence bitmap;
and generating a token seed by the sequence bitmap and key information corresponding to the payment scene of the payment service.
3. The method according to any one of claims 1 to 2, wherein the risk factors include at least one or more of: a financial default risk factor, a stolen swipe risk factor, and an account risk factor.
4. A method for generating a two-dimensional code is applied to a first terminal, and is characterized in that the method comprises the following steps:
receiving a token seed related to a payment service sent by a server, where the token seed is a parameter set used for generating a two-dimensional code related to the payment service, and the token seed at least includes: a risk factor associated with a first customer, the risk factor being indicative of a probability of the first customer being at risk in the payment transaction;
identifying the risk factor from the token seed and calculating an offline transaction default risk parameter of the first customer according to the risk factor;
and when the offline transaction default risk parameter is larger than a first critical value, generating a two-dimensional code according to the identification information of the first terminal, the authorization information of the first customer and the risk factor.
5. The method of claim 4, wherein generating the two-dimensional code according to the identification information of the first terminal, the authorization information of the first client, and the risk factor comprises:
and generating a code string of a sequence bitmap by adopting key information corresponding to the payment scene of the payment service according to an encryption algorithm and the identification information of the first terminal, the authorization information of the first client and the risk factor, and compiling the code string into a two-dimensional code.
6. The method of claim 4, wherein prior to the step of generating the two-dimensional code, the method further comprises:
judging whether the network signal intensity of the first terminal is greater than or equal to a first signal threshold value;
if the network signal strength of the first terminal is greater than or equal to a first signal threshold, requesting a server side to update a token seed, and analyzing the identification information of the first terminal, the authorization information of the first client and a risk factor related to the first client from the updated token seed;
and if the network signal strength of the first terminal is smaller than a first signal threshold, analyzing the identification information of the first terminal, the authorization information of the first client and the risk factor related to the first client from the locally stored token seed.
7. The method according to any one of claims 4 to 6, wherein the risk factors include at least one or more of: a financial default risk factor, a stolen swipe risk factor, and an account risk factor.
8. A payment method applied to a second terminal provided with a code reader, the method comprising:
when the fact that the two-dimensional code of the payment service displayed by the first terminal is identified through the code reader of the second terminal is detected, and the network signal intensity of the second terminal is smaller than a second signal threshold value, determining a corrected value of an offline transaction default risk parameter of the first client according to the offline payment times of the first terminal, the authorization information of the first client obtained by analyzing the two-dimensional code and a risk factor related to the first client; wherein the risk factor is used to represent a probability that the first customer is at risk in a payment transaction;
and if the modified value of the offline transaction default risk parameter of the first customer is greater than a second critical value, sending a deduction request to a server of the payment mechanism when the second terminal is online.
9. The method of claim 8, wherein prior to the step of determining the offline transaction default risk parameter correction value for the first customer, the method further comprises:
judging whether the offline transaction default risk parameter correction value of the first customer is larger than a second critical value;
if the modified value of the offline transaction default risk parameter of the first customer is smaller than a second critical value, rejecting the payment service;
if the offline transaction default risk parameter correction value of the first customer is larger than a second critical value, judging whether the current time is within the effective transaction time range;
if the transaction time is within the effective transaction time range, executing a step of sending a deduction request to a server of the payment mechanism when the second terminal is online;
and if the transaction time is not within the effective transaction time range, rejecting the payment service.
10. The method of claim 8, wherein prior to the step of determining the offline transaction default risk parameter correction value for the first customer, the method further comprises:
judging whether the network signal intensity of the second terminal is greater than or equal to a second signal threshold value;
if yes, sending a deduction request to a server of a payment mechanism to complete the payment service, wherein the deduction request at least comprises: account information and order information corresponding to the two-dimensional code.
11. A server, comprising:
a first generating module, configured to generate a token seed when a first customer applies for a payment service at a first terminal, where the token seed is a parameter set used for generating a two-dimensional code related to the payment service, and the token seed at least includes: a risk factor associated with the first customer, the risk factor being indicative of a probability of the first customer being at risk in the payment transaction;
and the first sending module is used for sending the token seed to the first terminal, generating a two-dimensional code according to the token seed through the first terminal, and completing the payment service through the two-dimensional code.
12. A first terminal, comprising:
a receiving module, configured to receive a token seed related to a payment service sent by a server, where the token seed is a parameter set used to generate a two-dimensional code related to the payment service, and the token seed at least includes: a risk factor associated with a first customer, the risk factor being indicative of a probability of the first customer being at risk in the payment transaction;
the calculation module is used for identifying the risk factor from the token seed and calculating an offline transaction default risk parameter of the first customer according to the risk factor; the token seed is a set of parameters for generating a two-dimensional code related to the payment transaction, the token seed including at least: a risk factor associated with a first customer, the risk factor being indicative of a probability of the first customer being at risk in the payment transaction;
and the second generation module is used for generating a two-dimensional code according to the identification information of the first terminal, the authorization information of the first customer and the risk factor when the offline transaction default risk parameter is greater than a first critical value.
13. A second terminal, the second terminal is provided with a code reader, comprising:
the determining module is used for determining a modified value of an offline transaction default risk parameter of a first client according to the number of offline payments of the first terminal, authorization information of the first client obtained by analyzing the two-dimensional code and a risk factor related to the first client when the fact that the two-dimensional code of the payment service displayed by the first terminal is identified through the code reader of the second terminal is detected, and the network signal intensity of the second terminal is smaller than a second signal threshold; wherein the risk factor is used to represent a probability that the first customer is at risk in a payment transaction;
and the third sending module is used for sending a deduction request to the server of the payment mechanism when the second terminal is online if the modified value of the offline transaction default risk parameter of the first customer is greater than a second critical value.
14. A terminal, comprising:
one or more processors;
a storage device for storing one or more programs,
when executed by the one or more processors, cause the one or more processors to implement the method of any one of claims 1-3 or 8-10.
15. A server, comprising:
one or more processors;
a storage device for storing one or more programs,
when executed by the one or more processors, cause the one or more processors to implement the method of any one of claims 4-7.
16. A computer-readable medium, on which a computer program is stored, which, when being executed by a processor, carries out the method according to any one of claims 1-10.
CN202011224727.XA 2020-11-05 2020-11-05 Method for generating token seed and two-dimensional code, payment method and payment device Pending CN112330323A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202011224727.XA CN112330323A (en) 2020-11-05 2020-11-05 Method for generating token seed and two-dimensional code, payment method and payment device

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202011224727.XA CN112330323A (en) 2020-11-05 2020-11-05 Method for generating token seed and two-dimensional code, payment method and payment device

Publications (1)

Publication Number Publication Date
CN112330323A true CN112330323A (en) 2021-02-05

Family

ID=74315372

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202011224727.XA Pending CN112330323A (en) 2020-11-05 2020-11-05 Method for generating token seed and two-dimensional code, payment method and payment device

Country Status (1)

Country Link
CN (1) CN112330323A (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113627931A (en) * 2021-07-14 2021-11-09 荣耀终端有限公司 Payment limiting method and electronic equipment

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104657847A (en) * 2015-02-13 2015-05-27 吴勇 Method for payment with limit code
CN108053205A (en) * 2018-01-25 2018-05-18 苏宁云商集团股份有限公司 A kind of quick paying method and equipment
CN108460593A (en) * 2017-11-01 2018-08-28 福建博思软件股份有限公司 A kind of offline Quick Response Code method of payment and device
US20180268407A1 (en) * 2017-03-19 2018-09-20 TokenID, Inc. Apparatus and method for payment authorization and authentication based tokenization
CN109002958A (en) * 2018-06-06 2018-12-14 阿里巴巴集团控股有限公司 A kind of method of risk identification, system, device and equipment
CN110599156A (en) * 2019-08-08 2019-12-20 威富通科技有限公司 Money collection method, money collection device, terminal equipment and medium
CN110880106A (en) * 2019-10-30 2020-03-13 支付宝(杭州)信息技术有限公司 Method and device for realizing double offline payment
CN111754220A (en) * 2020-06-24 2020-10-09 支付宝(杭州)信息技术有限公司 Terminal device, service processing system and method for transmitting digital resources

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104657847A (en) * 2015-02-13 2015-05-27 吴勇 Method for payment with limit code
US20180268407A1 (en) * 2017-03-19 2018-09-20 TokenID, Inc. Apparatus and method for payment authorization and authentication based tokenization
CN108460593A (en) * 2017-11-01 2018-08-28 福建博思软件股份有限公司 A kind of offline Quick Response Code method of payment and device
CN108053205A (en) * 2018-01-25 2018-05-18 苏宁云商集团股份有限公司 A kind of quick paying method and equipment
CN109002958A (en) * 2018-06-06 2018-12-14 阿里巴巴集团控股有限公司 A kind of method of risk identification, system, device and equipment
CN110599156A (en) * 2019-08-08 2019-12-20 威富通科技有限公司 Money collection method, money collection device, terminal equipment and medium
CN110880106A (en) * 2019-10-30 2020-03-13 支付宝(杭州)信息技术有限公司 Method and device for realizing double offline payment
CN111754220A (en) * 2020-06-24 2020-10-09 支付宝(杭州)信息技术有限公司 Terminal device, service processing system and method for transmitting digital resources

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113627931A (en) * 2021-07-14 2021-11-09 荣耀终端有限公司 Payment limiting method and electronic equipment
CN113627931B (en) * 2021-07-14 2022-12-30 荣耀终端有限公司 Payment limiting method and electronic equipment

Similar Documents

Publication Publication Date Title
US20210042758A1 (en) Systems and methods for blockchain based payment networks
EP3347846B1 (en) Secure permissioning of access to user accounts, including secure deauthorization of access to user accounts
US20230259927A1 (en) Secure account creation
CN105590198B (en) Two-dimensional code payment method and payment system
US20100070405A1 (en) Wireless number risk scores for use with mobile payments
US20140372315A1 (en) Method and system for managing data and enabling payment transactions between multiple entities
US20200265409A1 (en) Systems and methods to split bills and requests for payment from debit or credit account
US20210182850A1 (en) System and method for assessing a digital interaction with a digital third party account service
US10043160B2 (en) Method and apparatus for providing a balance-verified ACH identifier
US20230306411A1 (en) Systems and methods for managing third party tokens and transactions across issuer ecosystems
US20190362348A1 (en) Merchant enrollment for reverse payments
US20240004965A1 (en) Data value routing system and method
JP2018533131A (en) Authentication service customer data management method and system
CN112330323A (en) Method for generating token seed and two-dimensional code, payment method and payment device
CN111105224A (en) Payment feedback information processing method and device, electronic equipment and storage medium
US10303335B2 (en) Multicomputer processing of client device request data with centralized event orchestration
US20190043037A1 (en) System and method for providing secured services
US20210065145A1 (en) Systems and methods for acceptance of payments to a business demand deposit account
US20180165647A1 (en) Multicomputer Processing of Client Device Request Data Using Centralized Event Orchestrator
KR102060976B1 (en) Method for dealing a digital currency with block chain matching QR(or BAR) code
CN114037446A (en) Transaction method, transaction management method, device and system for digital currency
CN111415148A (en) Method and device for non-inductive payment, electronic equipment and storage medium
CN111127006A (en) Transaction processing method and system based on block chain
KR20190124062A (en) Method and server for providing financial service
US20220138803A1 (en) Systems and methods for payment product verification and authorization using a customer identifier

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination