Account pulling method and device, server and storage medium

Abstract

Embodiments of the present application disclose a method and device for account pulling flow, a server and a storage medium, and belong to the technical field of payment. The method comprises: obtaining historical payment information of a user account, the historical payment information being generated based on historical payment behavior of the user account; setting a pulling flow identifier for a target user account meeting a pulling flow condition based on the historical payment information, the pulling flow condition being used to represent that a payment method used at the time of payment is switched from a first payment method to a second payment method; and performing pulling flow processing on the target user account with the pulling flow identifier, the pulling flow processing being used to guide the target user account to reuse the first payment method. In the embodiments of the present application, since the user account with the pulling flow identifier is an account that has historically used the first payment method, the pulling flow processing is performed on such a user account, which can improve the probability of the user account reusing the first payment method, and help to improve the pulling flow effect of the account.

Description

TECHNICAL FIELD

[0001] Embodiments of the present application relate to the payment technical field, and in particular to an account pullback flow method and device, a server and a storage medium. BACKGROUND

[0002] With the continuous development of payment technology, more and more new payment methods have emerged, such as face payment.

[0003] Since the new payment method will change the user's previous payment habits, the user often continues to use the previous payment method after trying the new payment method. This situation is extremely detrimental to the popularization of the new payment method, and causes the use rate of the new payment device supporting the new payment method to be low.

[0004] In related technologies, the new payment method is usually promoted by using the method of advertising delivery. However, this full-amount promotion method lacks pertinence, resulting in poor pullback flow effect (i.e., pulling back the user who has used the new payment method but switches back to the original payment method to use the new payment method). SUMMARY

[0005] Embodiments of the present application provide an account pullback flow method, device, server and storage medium, which helps to improve the pullback flow effect of the account. The technical solution is as follows:

[0006] On the one hand, the present application provides an account pullback flow method, the method comprising:

[0007] obtaining historical payment information of a user account, the historical payment information being generated based on historical payment behavior of the user account;

[0008] based on the historical payment information, setting a pullback flow identifier for a target user account meeting a pullback flow condition, the pullback flow condition being used to represent that the payment method used when paying is switched from a first payment method to a second payment method;

[0009] performing pullback flow processing on the target user account set with the pullback flow identifier, the pullback flow processing being used to guide the target user account to re-use the first payment method.

[0010] On the other hand, the present application provides an account pullback flow device, the device comprising:

[0011] an information obtaining module configured to obtain historical payment information of a user account, the historical payment information being generated based on historical payment behavior of the user account;

[0012] The first identifier setting module is configured to set a pullback flow identifier for a target user account that meets a pullback flow condition based on the historical payment information, the pullback flow condition being used to represent that a payment method used at payment is switched from a first payment method to a second payment method.

[0013] The pullback flow module is configured to perform a pullback flow process on the target user account that is set with the pullback flow identifier, the pullback flow process being used to pull back the target user account to use the first payment method.

[0014] Optionally, the first identifier setting module comprises:

[0015] The payment type obtaining unit is configured to obtain a historical payment type contained in the historical payment information, the historical payment type comprising a payment method used by a user account;

[0016] The payment record obtaining unit is configured to obtain a historical payment record contained in the historical payment information in response to the historical payment type meeting a payment type condition, the historical payment record comprising a payment method used by a user account at the last n times of payment, n being an integer greater than or equal to 2;

[0017] The identifier setting unit is configured to determine that a user account is the target user account in response to the historical payment record meeting a payment record condition, and set the pullback flow identifier for the target user account.

[0018] Optionally, the payment record obtaining unit is configured to:

[0019] obtain the historical payment record contained in the historical payment information in response to the historical payment type containing the first payment method, the historical payment record meeting the payment record condition, and determine that a user account is the target user account.

[0020] The identifier setting unit is configured to:

[0021] obtain the historical payment record contained in the historical payment information in response to the historical payment type containing the first payment method, the historical payment record meeting the payment record condition, and determine that a user account is the target user account.

[0022] Optionally, the identifier setting unit is further configured to:

[0023] obtain a device capability identifier corresponding to a payment device used at each time of payment in the historical payment record in response to the historical payment record not containing the first payment method, the device capability identifier being used to represent a support condition of the payment device for the first payment method;

[0024] In response to the at least one device capability identifier indicating that the payment device supports the first payment method, it is determined that the historical payment record satisfies the payment record condition.

[0025] Optionally, the apparatus further comprises:

[0026] The receiving module is configured to receive payment data corresponding to the user account, the payment data being data reported when the user account generates a payment behavior.

[0027] The updating module is configured to update the historical payment information based on a target payment method indicated by the payment data.

[0028] Optionally, the historical payment information comprises a historical payment type and a historical payment record.

[0029] The updating module comprises:

[0030] The first updating unit is configured to, in response to the target payment method not belonging to the historical payment type, add the target payment method to the historical payment type; or, in response to the target payment method belonging to the historical payment type, not update the historical payment type.

[0031] The second updating unit is configured to add the target payment method to the historical payment record.

[0032] Optionally, the payment data comprises a device identifier of a payment device, and the historical payment record comprises a device capability identifier corresponding to a payment device used in each payment.

[0033] The second updating unit is configured to:

[0034] determine payment method support information of the payment device based on the device identifier comprised in the payment data;

[0035] add the target payment method to the historical payment record, and set the device capability identifier for the target payment method based on the payment method support information.

[0036] Optionally, the pullback flow module comprises:

[0037] The first pullback flow unit is configured to send a payment preferential message to the target user account provided with the pullback flow identifier, the payment preferential message being used to instruct to use the first payment method to make a payment to obtain a payment preferential treatment.

[0038] The second pullback flow unit is configured to receive payment data of the target user account sent by a payment device; and in response to a target payment method indicated by the payment data being the first payment method, issue a payment preferential treatment to the target user account.

[0039] Optionally, the apparatus further comprises:

[0040] a deletion module configured to delete the pullback flow identifier set for the target user account.

[0041] Optionally, the apparatus further comprises:

[0042] a second identifier setting module configured to determine a pullback flow level corresponding to the target user account based on a payment frequency indicated by the historical payment information, and set a pullback flow level identifier for the target user account, wherein different pullback flow level identifiers correspond to different pullback flow processing.

[0043] Optionally, the information obtaining module is configured to:

[0044] obtain the historical payment information of the user account according to a preset frequency;

[0045] or

[0046] obtain the historical payment information of the user account in response to an update of the historical payment information of the user account.

[0047] Optionally, the first payment method is a biometric recognition payment, and the biometric recognition payment includes at least one of face recognition payment, fingerprint recognition payment, gait recognition payment, and iris recognition payment.

[0048] The second payment method includes a graphic code payment, and the graphic code payment includes at least one of graphic code display payment and graphic code scanning payment.

[0049] In another aspect, an embodiment of the present application provides a server, the server comprising a processor and a memory, the memory storing at least one instruction, the at least one instruction being loaded and executed by the processor to implement the account pullback flow method according to the above aspect.

[0050] In another aspect, an embodiment of the present application provides a computer readable storage medium, the storage medium storing at least one instruction, the at least one instruction being loaded and executed by a processor to implement the account pullback flow method according to the above aspect.

[0051] In another aspect, an embodiment of the present application provides a computer program product or a computer program, the computer program product or the computer program comprising computer instructions stored in a computer readable storage medium. A processor of a computer device reads the computer instructions from the computer readable storage medium, and the processor executes the computer instructions to cause the computer device to perform the account pullback flow method provided in various optional implementations of the above aspect.

[0052] The technical solutions provided in the application can include the following beneficial effects:

[0053] In the embodiments of the application, the historical payment information of a user account is acquired, a target user account whose payment method is switched from a first payment method to a second payment method is identified based on the historical payment information, and a pullback flow identifier is set for the target user account, so that subsequent pullback flow processing is performed on the user account with the pullback flow identifier set. Since the user account with the pullback flow identifier set is an account that has used the first payment method historically, the pullback flow processing performed on such an account can improve the probability of the user account using the first payment method again, which is helpful to improve the pullback flow effect of the account compared with the full promotion of the payment method. BRIEF DESCRIPTION OF DRAWINGS

[0054] The accompanying drawings, which are incorporated herein and form part of the specification, illustrate embodiments consistent with the present application and, together with the description, further serve to explain the principles of the application.

[0055] Figure 1 FIG. 1 shows a schematic diagram of an implementation environment provided by an example embodiment of the application;

[0056] Figure 2 FIG. 2 shows a flowchart of an account pullback flow method according to an example embodiment of the application;

[0057] Figure 3 FIG. 3 shows a flowchart of an account pullback flow method according to another example embodiment of the application;

[0058] Figure 4 FIG. 4 is an implementation schematic diagram of a target user account identification process according to an example embodiment of the application;

[0059] Figure 5 FIG. 5 is an implementation schematic diagram of a pullback flow processing process according to an example embodiment of the application;

[0060] Figure 6 FIG. 6 is an implementation schematic diagram of a pullback flow processing process according to another example embodiment of the application;

[0061] Figure 7 FIG. 7 shows a flowchart of an account pullback flow method according to another example embodiment of the application;

[0062] Figure 8 FIG. 8 is an implementation schematic diagram of a target user account identification process according to an example embodiment of the application;

[0063] Figure 9 FIG. 9 is a system architecture diagram of a payment system provided by an example embodiment of the application;

[0064] Figure 10 Fig. 1 shows a structural block diagram of an account pulling flow device according to an example embodiment of the present application;

[0065] Figure 11 Fig. 2 shows a structural block diagram of a server according to an example embodiment of the present application. DETAILED DESCRIPTION

[0066] The example embodiments will be described in detail herein with reference to the drawings. When the description below refers to accompanying drawings, unless otherwise specified, the same numbers in different drawings refer to the same or similar elements. The implementations described in the following example embodiments are not meant to represent all implementations consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with some aspects of the present application as detailed in the appended claims.

[0067] Reference is made to Figure 1 Fig. 1 shows a schematic diagram of an implementation environment according to an example embodiment of the present application, which includes a terminal 110, a payment device 120, and a server 130.

[0068] The terminal 110 is an electronic device with offline payment function, which can be a smartphone, a tablet computer, a wearable device, etc., and the present embodiment is not limited thereto.

[0069] The offline payment function in the terminal 110 can be provided by a third-party application, which can be an instant messaging application with offline payment function, a shopping application with offline payment function, or a financial application with offline payment function, etc.; or the offline payment function can be provided by a native application (provided by the terminal manufacturer in the operating system, and the terminal manufacturer provides payment service), and the present embodiment is not limited thereto.

[0070] Optionally, when the user uses the terminal 110 to make offline payment, the payment can be made by scanning or displaying a graphic code (such as a two-dimensional code). When the payment is made by scanning the graphic code, the graphic code can be displayed by the payment device 120 through the screen, and the terminal 110 scans the graphic code through the camera. When the payment is made by displaying the graphic code, the graphic code is displayed by the terminal 110 through the screen, and the payment device 120 scans the graphic code through the camera.

[0071] Optionally, the user can also pre-enter the biological feature through the application in the terminal 110, and subsequently make offline payment. If the payment device 120 supports biological feature recognition payment, the payment device 120 can collect the biological feature data of the user, and verify the collected biological feature data, so as to complete the payment when the verification is passed, without using the terminal 110.

[0072] The payment device 120 is an electronic device used by a payee to receive offline payment. In one possible implementation, the payment device 120 implements payment by interacting with the terminal 110. In some embodiments, the payment device 120 has a function of displaying a graphic code and a function of scanning a graphic code. A user can use the terminal 110 to scan the graphic code displayed by the payment device 120 to complete payment, or the user can use the terminal 110 to display a graphic code, and the payment device 120 scans the graphic code to complete payment.

[0073] In other possible implementations, the payment device 120 can implement payment without interacting with the terminal 110. In some embodiments, the payment device 120 has a function of collecting biological feature data. Through the function of collecting biological feature data, the payment device 120 can collect biological feature data of a user, and report the biological feature data to the server 130. The server 130 verifies the biological feature data, and completes payment after verification.

[0074] Optionally, when the biological feature is a fingerprint, the payment device 120 collects a fingerprint image through a fingerprint collection component; when the biological feature is a face, the payment device 120 collects a face image through a camera component; when the biological feature is a gait, the payment device 120 collects a gait image through a camera component; and when the biological feature is an iris, the payment device 120 collects an iris image through an iris scanning component.

[0075] The terminal 110 establishes a communication connection with the server 130 through a wireless network, and the payment device 120 establishes a communication connection with the server 130 through a wired or wireless network.

[0076] The server 130 is a server for implementing payment functions. The server 130 can be a background server of an application program with payment functions in the terminal 110. The server 130 can be a single server, a server cluster composed of several servers, or a cloud computing center.

[0077] Optionally, in order to realize decentralization of data and improve the security of data storage, the server 130 can also be a node in a data sharing system. The nodes in the data sharing system can share data. When any node in the data sharing system receives input information, other nodes in the data sharing system obtain the input information according to a consensus algorithm, and store the input information as data in shared data, so that the data stored on all nodes in the data sharing system are consistent.

[0078] Each node in the data sharing system has a node identifier corresponding thereto, and each node in the data sharing system can store node identifiers of other nodes in the data sharing system, so as to subsequently broadcast the generated block to other nodes in the data sharing system according to the node identifiers of the other nodes. Each node in the data sharing system stores a same block chain. The block chain is composed of a plurality of blocks. The genesis block includes a block header and a block body, the block header stores an input information feature value, a version number, a timestamp and a difficulty value, and the block body stores input information; a next block of the genesis block takes the genesis block as a parent block, the next block also includes a block header and a block body, the block header stores an input information feature value of the current block, a block header feature value of the parent block, a version number, a timestamp and a difficulty value, and the like, so that the block data stored in each block in the block chain is associated with the block data stored in the parent block, thereby ensuring the security of the input information in the block.

[0079] In a possible implementation, when the terminal 110 performs payment by scanning a QR code, the terminal 110 sends payment data to the server 130, and the server 130 completes payment based on the payment data; when the terminal 110 performs payment by displaying a QR code, the payment device 120 sends payment data to the server 130, and the server 130 completes payment based on the payment data; when the user performs payment by biometric recognition, the payment device 120 sends collected biometric data and payment data to the server 130, the server 130 verifies the biometric data, and completes payment based on the payment data after verification.

[0080] In the embodiments of the present application, the server 130 has a pullback flow function, can identify a target user account that has used the new payment method historically but has switched back to the original payment method subsequently, and can perform pullback flow on the target user account. Illustratively, as shown in Figure 1 After the terminal 110 and the payment device 120 send payment data to the server 130, the server 130 completes payment according to the payment data, updates historical payment information corresponding to each user account based on the payment data, identifies the target user account that meets the pullback flow condition by identifying the historical payment information, and sets a pullback flow identifier for the target user account. According to the pullback flow identifier, the server 130 can directly perform pullback flow processing on the terminal 110 (for example, issuing a payment discount message to the terminal 110), or can perform pullback flow processing on the payment device 120 (for example, issuing a payment discount when the user uses the new payment method of the payment device 120 to perform payment).

[0081] Compared with full-amount advertisement promotion, the targeted pullback flow can improve the probability of the target user account reusing the new payment method and improve the account pullback flow effect, because the server has the ability to identify the target user account and perform the pullback flow for the target user account.

[0082] Please refer to Figure 2 which shows a flowchart of an account pullback flow method according to an example embodiment of the present application. The example embodiment of the present application applies the method to Figure 1 The method includes the following steps, which are described below by taking the server shown in

[0083] Step 201: Obtain historical payment information of a user account, which is generated based on historical payment behavior of the user account.

[0084] In the example embodiment of the present application, for each user account, the server obtains payment data generated by historical payment behavior of the user account, and generates historical payment information corresponding to the user account based on the payment data. The historical payment information includes information indicating a payment method used in the historical payment behavior.

[0085] Step 202: Based on the historical payment information, set a pullback flow identifier for a target user account that meets a pullback flow condition. The pullback flow condition is used to represent that the payment method used at the time of payment is switched from a first payment method to a second payment method.

[0086] In the example embodiment of the present application, in order to implement targeted pullback flow, the server first needs to identify a target user account that meets the pullback flow condition based on the historical payment information. The target user account that meets the pullback flow condition is a user account that has used a first payment method for payment in the past, but has subsequently switched back to a second payment method for payment. The first payment method is different from the second payment method.

[0087] In some embodiments, the first payment method is a payment method to be popularized or promoted, and the second payment method is an original payment method. For example, the first payment method is a biometric payment, and the biometric payment includes at least one of face recognition payment, fingerprint recognition payment, gait recognition payment, and iris recognition payment; and the second payment method is a graphic code payment, and the graphic code payment includes at least one of graphic code display payment and graphic code scanning payment.

[0088] After determining the target user account, the server further sets a pullback flow identifier for each target user account, that is, indicates that the target user account meets the pullback flow condition through the pullback flow identifier, so that the server subsequently performs targeted pullback flow on the target user account based on the pullback flow identifier.

[0089] In step 203, the target user account provided with the pull-back flow identifier is subjected to the pull-back flow processing, which is used to guide the target user account to reuse the first payment method.

[0090] In a possible implementation, the server actively subjects the target user account provided with the pull-back flow identifier to the pull-back flow processing, i.e., the server subjects the target user account to the pull-back flow processing before the target user account reuses the first payment method, so as to guide the user (using the target user account) to make payment by using the first payment method.

[0091] In another possible implementation, the server passively triggers the pull-back flow processing on the target user account, i.e., the server subjects the target user account to the pull-back flow processing after detecting that the target user account reuses the first payment method, so as to improve the probability that the user continues to make payment by using the first payment method subsequently.

[0092] Optionally, the pull-back flow processing includes, but is not limited to, issuing a pull-back flow message, issuing a pull-back flow reward, and the like.

[0093] In a possible application scenario, when it is necessary to popularize the face recognition payment, the server filters out the target user account that has used the face recognition payment but subsequently switches to use the graphic code display or graphic code scanning payment based on the historical payment information of each user account, and sets a pull-back flow identifier for the target user account, and subsequently subjects the target user account to the pull-back flow processing based on the pull-back flow identifier, so as to improve the probability that the target user account switches to use the face recognition payment.

[0094] To sum up, in the embodiments of the present application, the historical payment information of the user account is acquired, the target user account whose payment method is switched from the first payment method to the second payment method is identified based on the historical payment information, and a pull-back flow identifier is set for the target user account, so as to subsequently subject the user account provided with the pull-back flow identifier to the pull-back flow processing; since the user account provided with the pull-back flow identifier is the account that has used the first payment method historically, the pull-back flow processing on such user account can improve the probability that the user account reuses the first payment method, which is helpful to improve the pull-back flow effect of the account compared with the full promotion of the payment method.

[0095] In a possible implementation, the historical payment information corresponding to the user account includes a historical payment type and a historical payment record, wherein the historical payment type includes the payment method used by the user account, and the historical payment record contains the payment method used by the user account in the last several times of payment. Correspondingly, the server identifies the target user account satisfying the pull-back flow condition based on the historical payment type and the historical payment record. The detailed flow of identifying the target user account is described below by using an illustrative embodiment.

[0096] Referring to Figure 3 , a flowchart of a method of account pulling flow is shown, and the embodiment of the application applies the method to Figure 1 The server shown is taken as an example for illustration, and the method comprises the following steps:

[0097] In step 301, historical payment information of a user account is obtained, and the historical payment information is generated based on historical payment behavior of the user account.

[0098] As to the timing of the server obtaining the historical payment information to identify the target user account, in a possible implementation, the server obtains the historical payment information of the user account at a preset frequency, for example, the preset frequency can be 1 minute / time.

[0099] In another possible implementation, since the user account can perform multiple payment behaviors in a short time, in order to improve the real-time performance of the historical payment information, the server obtains the historical payment information (updated) of the user account in response to the update of the historical payment information of the user account.

[0100] In step 302, historical payment types contained in the historical payment information are obtained, and the historical payment types include payment methods used by the user account.

[0101] In a possible implementation, the historical payment information contains a payment type field, and the historical payment type is contained in the payment type field, wherein the historical payment type can be stored in the form of an array.

[0102] For example, as shown in Figure 4 , the server obtains the payment type field user_pay_chanel corresponding to the user account "Zhang San", and the historical payment types contained in the field are [card, scan, face]; obtains the payment type field user_pay_chanel corresponding to the user account "Li Si", and the historical payment types contained in the field are [card, face]; and obtains the payment type field user_pay_chanel corresponding to the user account "Wang Wu", and the historical payment types contained in the field are [card, scan]. Wherein, card is used to represent graphic code display payment, scan is used to represent graphic code scanning payment, and face is used to represent face recognition payment.

[0103] Since the subsequent pulling flow needs to be performed for the user account using the first payment method, the server first detects whether the user account meets the payment type condition based on the historical payment types. If yes, step 303 is performed, and if not, it is determined that the user account does not meet the pulling flow condition.

[0104] In a possible implementation, the server detects whether the first payment method is included in the historical payment type, and if yes, determines that the historical payment type satisfies the payment type condition, and if not, determines that the historical payment type does not satisfy the payment type condition.

[0105] Illustratively, as shown in Figure 4 When the first payment method is face recognition payment, the server determines that the user account “Zhang San” and “Li Si” satisfy the payment type condition, and the user account “Wang Wu” does not satisfy the payment type condition, because the historical payment types corresponding to the user accounts “Zhang San” and “Li Si” include face, and the historical payment type corresponding to the user account “Wang Wu” does not include face.

[0106] In step 303, in response to the historical payment type satisfying the payment type condition, the server acquires historical payment records included in the historical payment information, and the historical payment records include payment methods used by the user account in the last n times of payment, where n is an integer greater than or equal to 2.

[0107] Further, for the user account satisfying the payment type condition, the server further acquires historical payment records included in the historical payment information, and for the user account not satisfying the payment type condition, the server does not need to acquire the historical payment records.

[0108] In a possible implementation, the historical payment information includes a payment record field, and the payment record field includes the historical payment records, where the historical payment records can be stored in an array form.

[0109] Optionally, the historical payment records store payment methods used in the last n times of payment in a first-in-first-out manner, that is, when n payment methods are stored in the historical payment records, if a new payment method needs to be written, the earliest written payment method is removed from the historical payment records.

[0110] Illustratively, as shown in Figure 4 The server acquires the payment record field last_use_pay_type corresponding to the user account “Zhang San”, and the historical payment records included in the field are [card, scan, scan, card, scan]; and acquires the payment type field last_use_pay_type corresponding to the user account “Li Si”, and the historical payment records included in the field are [scan, scan, face, face, scan].

[0111] Since the subsequent pullback flow needs to be performed for the user account switched from the first payment method to the second payment method, the server first detects whether the user account satisfies the payment record condition based on the historical payment record. If yes, step 304 is performed, and if no, it is determined that the user account does not satisfy the pullback flow condition.

[0112] In a possible implementation, the server detects whether the first payment method is contained in the historical payment record. If no, it is determined that the historical payment record satisfies the payment record condition, and if yes, it is determined that the historical payment type does not satisfy the payment record condition.

[0113] As shown in FIG. 4, when the first payment method is face recognition payment, since the historical payment record corresponding to the user account “Zhang San” does not contain face, and the historical payment record corresponding to the user account “Li Si” contains face, the server determines that the user account “Zhang San” satisfies the payment record condition, and the user account “Li Si” does not satisfy the payment record condition. Figure 4

[0114] In other possible implementations, the server can determine that the historical payment record satisfies the payment record condition when the number of the first payment method in the historical payment record is less than a number threshold (such as 1 or 2), and the present embodiment is not limited in this regard.

[0115] Step 304: In response to the historical payment record satisfying the payment record condition, the user account is determined as a target user account, and the pullback flow identifier is set for the target user account.

[0116] When the historical payment type corresponding to the user account satisfies the payment type condition, and the historical payment record satisfies the payment record condition, the server determines that the user account is the target user account, and sets the pullback flow identifier.

[0117] As shown in FIG. 4, the server determines the user account “Zhang San” satisfying both the payment type condition and the payment record condition as the target user account. Figure 4

[0118] In an illustrative example, the user account information maintained in the server is shown in Table 1.

[0119] Table 1

[0120] User account Pull back stream identification Zhang San 1 Li Si 0 Wang Wu 0 Zhao Liu 1

[0121] In the table, 1 indicates that the user account is set with the pullback flow identifier, and 0 indicates that the user account is not set with the pullback flow identifier.

[0122] ​​In a possible implementation, to further improve the effect of the account pulling flow, after the server sets the pulling flow identifier, the server determines a pulling flow level corresponding to the target user account based on a payment frequency indicated by historical payment information, and sets a pulling flow level identifier for the target user account. Correspondingly, the server performs the pulling flow processing on the target user account based on the pulling flow level. Different pulling flow level identifiers correspond to different pulling flow processing.

[0123] Optionally, the payment frequency and the pulling flow level are in a positive correlation relationship, that is, the higher the payment frequency, the higher the pulling flow level. When the pulling flow processing manner is to issue a payment discount, the pulling flow level and the payment discount are in a positive correlation relationship, that is, the higher the pulling flow level, the greater the payment discount.

[0124] In step 305, a payment discount message is sent to the target user account with the pulling flow identifier, and the payment discount message is used to instruct to use the first payment manner to make payment to obtain the payment discount.

[0125] To guide the user using the target user account to make payment by using the first payment manner, in a possible implementation, the server sends payment discount information to the target user account with the pulling flow identifier, and prompts the user to use the first payment manner to make payment to obtain the payment discount.

[0126] Optionally, the server sends the payment discount information to the target user account at a preset frequency, for example, 1 time / day. Alternatively, the server sends the payment discount message to the target user account after receiving payment data of the target user account, and the payment data indicates that the payment manner used by the target user account this time is not the first payment manner.

[0127] The payment discount can be a payment full-reduction discount, a random fixed-reduction discount, a coupon, or the like, which is not limited in the embodiment.

[0128] As shown in FIG. 5, Figure 5 As shown in FIG. 5, after the server 51 determines that the user account “Zhang San” is the target user account based on the historical payment information 52 of the user account “Zhang San”, when the server 51 receives payment data sent by the terminal 53 (logged in the user account “Zhang San”) again, and the payment data indicates that the payment manner used this time is not the face recognition payment, the server 51 sends a payment discount message to the terminal 53, and the terminal 53 displays the payment discount message on the payment completion interface.

[0129] In step 306, payment data of the target user account sent by a payment device is received.

[0130] In another possible implementation, when the server identifies that the target user account makes payment by the first payment method, the server issues a payment discount to the target user account to increase the probability that the user continues to use the first payment method subsequently.

[0131] Optionally, after the user makes payment by using the payment function provided by the payment device, the payment device reports payment data to the server, and the server completes the payment process based on the payment data. In some embodiments, when the payment function is a biometric feature payment function, the payment device also reports the collected biometric feature data to the server, the server performs identity verification based on the biometric feature data, and after the identity verification is passed, the server completes the payment process based on the payment data.

[0132] Illustratively, as shown in Figure 6 When the user (corresponding to the target user account) uses the payment device 61 to make facial payment, the payment device 61 reports facial payment data to the server 62.

[0133] Step 307, in response to the target payment method indicated by the payment data being the first payment method, issuing a payment discount to the target user account.

[0134] In one possible implementation, after the server receives the payment data, the server detects whether the target payment method indicated by the payment data is the first payment method. If the target payment method is the first payment method, the server issues a payment discount to the target user account, and then completes the payment process based on the payment discount and the payment data. If the target payment method is not the first payment method, the server does not issue a payment discount.

[0135] Optionally, the payment discount is a payment full-reduction discount, a random fixed-reduction discount, a coupon, or the like, which is not limited in the present embodiment.

[0136] Illustratively, as shown in Figure 6 The server 62 identifies that the user uses the facial payment function, and then issues a payment discount to the target user account and automatically uses the payment discount to complete the facial payment process. After the payment is completed, the server 62 feeds back payment completion information to the payment device 61, and informs the user that the facial payment discount has been enjoyed in this payment.

[0137] Step 308, deleting the pull flow identifier set for the target user account.

[0138] After the payment discount is issued to the target user account, the pull flow for the target user account is completed. In order to avoid the target user account from unlimitedly obtaining the payment discount, the server deletes the pull flow identifier set for the target user account after issuing the payment discount.

[0139] According to the data shown in Table 1, when the user account "Zhang San" uses face payment, the server deletes the pullback flow identifier corresponding to "Zhang San".

[0140] In this embodiment, the server performs two-level screening on the target user account based on the historical payment type and the historical payment record in the historical payment information, thereby improving the identification efficiency and accuracy of the target user account. In different scenarios, the server uses different pullback flow processing methods for the target user account, which helps to further improve the pullback flow effect of the account.

[0141] To ensure the effectiveness and accuracy of the historical payment information corresponding to the user account, and further improve the identification and accuracy of the pullback flow of the target user account, in one possible implementation, when receiving the payment data corresponding to the user account, the server updates the historical payment information based on the target payment method indicated by the payment data. The payment data is the data reported by the user account when generating a payment behavior, and the payment data is reported by the terminal or reported by the payment device.

[0142] Optionally, if the historical payment information includes the historical payment type and the historical payment record, the server can include the following steps when updating the historical payment information.

[0143] I. In response to the target payment method not belonging to the historical payment type, the target payment method is added to the historical payment type; or, in response to the target payment method belonging to the historical payment type, the historical payment type is not updated.

[0144] After the server obtains the target payment method, it detects whether the target payment method belongs to the historical payment type corresponding to the user account. If not, the target payment method is added to the historical payment type. If it belongs, the current historical payment type is maintained.

[0145] In one illustrative example, when the historical payment type corresponding to the user account is [card, scan], and the target payment method indicated by the payment data reported by the payment device is face (face recognition payment), the server updates the historical payment type to [card, scan, face]; when the historical payment type corresponding to the user account is [card, face], and the target payment method indicated by the payment data reported by the payment device is card, the server does not update the historical payment type.

[0146] II. The target payment method is added to the historical payment record.

[0147] In a possible implementation, when the payment method used in the last n times of payment is stored in the historical payment record in a first-in-first-out manner, if the number of payment methods recorded in the historical payment record does not reach n, the target payment method is directly added to the historical payment record; if the number of payment methods recorded in the historical payment record reaches n, the server removes the payment method written earliest from the historical payment record and writes the target payment method.

[0148] In an illustrative example, the historical payment record is used to record the payment method used in the last 5 times of payment, if the current historical payment record is [scan, scan, face, face, scan] (payment time from early to late), and the target payment method indicated by the payment data is face, the server updates the historical payment record to [scan, face, face, scan, face].

[0149] In some possible application scenarios, when the payment device does not support the first payment method, the user can only use the second payment method to make payment, that is, the switching of the payment method is not only determined by the subjective will of the user, but also determined by the device function of the payment device. Correspondingly, if only the payment method is recorded in the historical payment record, the target user account identified based on the historical payment record can not be accurate. For example, the payment environment in which the target user account is located can not be set to support the payment device supporting the first payment method, and the effect of the pullback flow process on such target user account is not good.

[0150] In order to further improve the accuracy of the identified target user account, the user who switches the payment method due to subjective will is identified, in a possible implementation, the historical payment record contains not only the payment method, but also the device capability identifier corresponding to the payment device used at the time of payment, and the device capability identifier is used to represent the support of the payment device to the first payment method. On the basis of Figure 3 , as Figure 7 indicated, step 304 can be replaced by steps 3041 and 3042.

[0151] In step 3041, in response to the historical payment record not containing the first payment method, the device capability identifier corresponding to the payment device used at the time of each payment in the historical payment record is obtained.

[0152] When the historical payment record does not contain the first payment method, the server further obtains the device capability identifier corresponding to each payment method, so as to identify whether the first payment method is not used due to the subjective will of the user according to the device capability identifier.

[0153] Illustratively, as Figure 8As shown, after determining that the user accounts "Zhang San" and "Li Si" meet the payment type condition based on the historical payment types included in the user accounts "Zhang San", "Li Si" and "Wang Wu" in the user_pay_chanel, the server further acquires the historical payment record corresponding to "Zhang San" [card(0), scan(1), scan(0), card(1), scan(1)], and the historical payment record corresponding to "Li Si" last_use_pay_type: [scan(0), scan(0), card(0), scan(0), scan(0)]. Wherein, 1 and 0 are device capability identifiers, and 1 indicates that the payment device supports the first payment method, and 0 indicates that the payment device does not support the first payment method.

[0154] In step 3042, in response to the existence of at least one device capability identifier indicating that the payment device supports the first payment method, it is determined that the historical payment record meets the payment record condition.

[0155] Wherein, when the device capability identifier indicates that the payment device supports the first payment method, but the payment method adopted is not the first payment method, it is indicated that the non-adoption of the first payment method is the subjective will of the user, and is irrelevant to the device capability of the payment device, and therefore, the server determines that the historical payment record meets the payment record condition.

[0156] As shown in the table, the server determines that the historical payment record corresponding to the user account "Zhang San" meets the payment record condition, and the historical payment record corresponding to the user account "Li Si" does not meet the payment record condition. Figure 8 As shown, although the historical payment records corresponding to "Zhang San" and "Li Si" do not contain the first payment method face, the payment devices used in each payment of the historical payment record corresponding to "Li Si" do not support the first payment method, that is, "Li Si" switches to use the payment method other than the first payment method due to the limitation of the device capability of the payment device, rather than subjective will, and therefore, the server determines that the historical payment record of the user account "Li Si" does not meet the payment record condition. The historical payment record corresponding to "Zhang San" indicates that the payment device supporting the first payment method has been used, but the payment is still made by using the non-first payment method, that is, "Zhang San" does not adopt the first payment method due to subjective will, and therefore, the server determines that the historical payment record of the user account "Zhang San" meets the payment record condition.

[0157] Correspondingly, regarding the setting manner of the device capability identifier in the historical payment record, in a possible implementation, the payment data reported by the terminal or the payment device to the server further contains the device identifier of the payment device, and the server determines the payment method support information of the payment device based on the device identifier contained in the payment data.

[0158] Wherein, the device identifier can be the serial number (Serial Number, SN) of the payment device, which is used to uniquely identify the payment device.

[0159] Optionally, the server stores a correspondence between the device identifier corresponding to the payment device and the payment method support information, and the server determines whether the payment device supports the first payment method according to the device identifier contained in the payment data, queries the payment method support information corresponding to the payment device in the correspondence, and further determines whether the payment device supports the first payment method. Illustratively, the correspondence between the device identifier and the payment method support information is shown in Table 2.

[0160] Table 2

[0161]

[0162]

[0163] Further, the server adds the target payment method to the historical payment record, and sets the device capability identifier for the target payment method based on the payment method support information. When the first payment method is contained in the payment method support information, the server sets the first device capability identifier for the target payment method, and when the first payment method is not contained in the payment method support information, the server sets the second device capability identifier for the target payment method, wherein the first device capability identifier indicates that the payment device supports the first payment method, and the second device capability identifier indicates that the payment device does not support the first payment method.

[0164] In combination with the data shown in Table 2, when the device identifier contained in the payment data is ID12345678 and the target payment method is scan, the server adds scan(1) to the historical payment record; when the device identifier contained in the payment data is ID23456789 and the target payment method is scan, the server adds scan(0) to the historical payment record.

[0165] In this embodiment, the historical payment record is used to record not only the payment method, but also the device capability identifier indicating whether the payment device supports the first payment method. When identifying the target user account, in addition to detecting whether the first payment method is contained in the historical payment record, it is further necessary to detect whether the environment where the user is located exists a payment device supporting the first payment method according to the device capability identifier, so as to determine the user account switched to use the payment method due to subjective will of the user, thereby improving the identification accuracy of the target user account, and further improving the subsequent pullback flow effect of the target user account.

[0166] In one illustrative example, taking the first payment method as face recognition payment as an example, the overall system structure of the scheme involved in the embodiment of the application is shown in Figure 9 The system includes a terminal 910, a face payment device 920, and a server 930.

[0167] The terminal 910 is installed with a payment APP (application program) having a payment code payment and a scan code payment function. After the payment code payment or the scan code payment is performed, the payment APP reports payment data to the server 930 through a network module, the server 930 completes a payment process through a payment code payment service or a scan code payment service, and sends the payment data to a basic account service, the basic account service determines whether a user account meets a pullback flow condition according to a payment method contained in the payment data, and writes a pullback flow identifier to a user account-basic information library when the pullback flow condition is met.

[0168] The face payment device 920 is provided with a camera for collecting a face image and is installed with a face payment APP. When the face payment is performed, a face collection module obtains the face image collected by the camera and performs face optimization on the face image. The face payment APP uploads the optimized face image to the server 930 through a network module and enters a loading state, waiting for a payment result fed back by the server 930. The server 930 performs identity verification on the received face image through a face payment service based on a preset face image in a face library, and sends payment data to a basic account service, which updates historical payment information of the user account according to the payment method contained in the payment data.

[0169] The server 930 obtains a target user account having the pullback flow identifier set in the user account-basic information library through a timing service at a timing, and sends a face brushing activity preferential treatment notification to the payment APP in the terminal 910 through a push service.

[0170] In addition, when the target user account uses the face payment, the face payment service triggers an activity service to send activity information to an activity module of the face payment APP of the face payment device 920, and informs the user of the activity preferential treatment obtained by the face brushing payment.

[0171] Please refer to Figure 10 which shows a structural block diagram of an account pullback flow device according to an example embodiment of the present application. The device can include:

[0172] An information acquisition module 1001 is configured to acquire historical payment information of a user account, the historical payment information being generated based on historical payment behaviors of the user account;

[0173] A first identifier setting module 1002 is configured to set a pullback flow identifier for a target user account meeting a pullback flow condition based on the historical payment information, the pullback flow condition being used to represent that a payment method used when payment is performed is switched from a first payment method to a second payment method;

[0174] The pulling back flow module 1003 is configured to perform a pulling back flow process on the target user account with the pulling back flow identifier, so as to guide the target user account to reuse the first payment method.

[0175] Optionally, the first identifier setting module 1002 comprises:

[0176] The payment type obtaining unit is configured to obtain a historical payment type included in the historical payment information, the historical payment type comprising a payment method used by the user account;

[0177] The payment record obtaining unit is configured to, in response to the historical payment type satisfying a payment type condition, obtain a historical payment record included in the historical payment information, the historical payment record comprising a payment method used by the user account in the last n times of payment, n being an integer greater than or equal to 2;

[0178] The identifier setting unit is configured to, in response to the historical payment record satisfying a payment record condition, determine that the user account is the target user account, and set the pulling back flow identifier for the target user account.

[0179] Optionally, the payment record obtaining unit is configured to:

[0180] in response to the first payment method being included in the historical payment type, determine that the historical payment type satisfies the payment type condition, and obtain the historical payment record included in the historical payment information;

[0181] The identifier setting unit is configured to:

[0182] in response to the first payment method not being included in the historical payment record, determine that the historical payment record satisfies the payment record condition, determine that the user account is the target user account, and set the pulling back flow identifier for the target user account.

[0183] Optionally, the identifier setting unit is further configured to:

[0184] in response to the first payment method not being included in the historical payment record, obtain a device capability identifier corresponding to a payment device used in each time of payment in the historical payment record, the device capability identifier being used to represent a support condition of the payment device for the first payment method;

[0185] in response to at least one of the device capability identifiers indicating that the payment device supports the first payment method, determine that the historical payment record satisfies the payment record condition.

[0186] Optionally, the apparatus further comprises:

[0187] The receiving module is configured to receive payment data corresponding to a user account, the payment data being data reported by the user account when a payment behavior is generated;

[0188] The updating module is configured to update the historical payment information based on a target payment manner indicated by the payment data.

[0189] Optionally, the historical payment information comprises a historical payment type and a historical payment record.

[0190] The updating module comprises:

[0191] The first updating unit is configured to, in response to the target payment manner not belonging to the historical payment type, add the target payment manner to the historical payment type; or, in response to the target payment manner belonging to the historical payment type, not update the historical payment type.

[0192] The second updating unit is configured to add the target payment manner to the historical payment record.

[0193] Optionally, the payment data comprises a device identifier of a payment device, and the historical payment record comprises a device capability identifier corresponding to a payment device used at each time of payment.

[0194] The second updating unit is configured to:

[0195] determine payment manner support information of the payment device based on the device identifier comprised in the payment data;

[0196] add the target payment manner to the historical payment record, and set the device capability identifier for the target payment manner based on the payment manner support information.

[0197] Optionally, the pullback flow module 1003 comprises:

[0198] The first pullback flow unit is configured to send a payment preferential message to the target user account provided with the pullback flow identifier, the payment preferential message being used to instruct to use the first payment manner to make payment to obtain a payment preferential treatment.

[0199] The second pullback flow unit is configured to receive payment data of the target user account sent by a payment device; and in response to a target payment manner indicated by the payment data being the first payment manner, issue a payment preferential treatment to the target user account.

[0200] Optionally, the apparatus further comprises:

[0201] The deleting module is configured to delete the pullback flow identifier set for the target user account.

[0202] Optionally, the apparatus further comprises:

[0203] a second identity setting module configured to determine a pullback flow level corresponding to the target user account based on a payment frequency indicated by the historical payment information, and set a pullback flow level identity for the target user account, wherein different pullback flow level identities correspond to different pullback flow processing.

[0204] Optionally, the information obtaining module is configured to:

[0205] obtain the historical payment information of the user account according to a preset frequency;

[0206] or,

[0207] obtain the historical payment information of the user account in response to an update of the historical payment information of the user account.

[0208] Optionally, the first payment method is a biometric payment, and the biometric payment includes at least one of face recognition payment, fingerprint recognition payment, gait recognition payment, and iris recognition payment.

[0209] The second payment method includes a graphic code payment, and the graphic code payment includes at least one of graphic code display payment and graphic code scanning payment.

[0210] In summary, in the embodiments of the present application, the historical payment information of the user account is obtained, the target user account whose payment method is switched from the first payment method to the second payment method is identified based on the historical payment information, and a pullback flow identity is set for the target user account, so that subsequent pullback flow processing is performed on the user account with the pullback flow identity. Since the user account with the pullback flow identity is an account that has used the first payment method, the probability of reusing the first payment method by the user account is improved, which helps to improve the pullback flow effect of the account compared with the full promotion of the payment method.

[0211] In the embodiments, the server performs two-level screening on the target user account based on the historical payment type and the historical payment record in the historical payment information, which improves the identification efficiency and accuracy of the target user account. In different scenarios, the server adopts different pullback flow processing methods for the target user account, which helps to further improve the pullback flow effect of the account.

[0212] In this embodiment, the historical payment record is provided with the device capability identifier indicating whether the payment device supports the first payment method in addition to recording the payment method. When identifying the target user account, in addition to detecting whether the historical payment record contains the first payment method, it is further necessary to detect whether the environment where the user is located exists the payment device supporting the first payment method according to the device capability identifier, so as to determine the user account of the user switching the payment method due to subjective will, and improve the identification accuracy of the target user account, and then improve the subsequent pull flow effect of the target user account.

[0213] It should be noted that: the account pull flow device provided in the above embodiments is only exemplified by the division of the above functional modules. In actual application, the above functions can be completed by different functional modules according to needs, that is, the internal structure of the device is divided into different functional modules to complete all or part of the functions described above. In addition, the account pull flow device and the account pull flow method provided in the above embodiments belong to the same concept, and the specific implementation process is detailed in the method embodiments, which will not be repeated here.

[0214] Please refer to Figure 11 which shows the structure block diagram of the server provided in an example embodiment of the present application. Specifically:

[0215] The server 1300 includes a central processing unit (CPU) 1301, a system memory 1304 including a random access memory (RAM) 1302 and a read-only memory (ROM) 1303, and a system bus 1305 connecting the system memory 1304 and the central processing unit 1301. The server 1300 also includes a basic input / output system (Input / Output system, I / O system) 1306 to help transfer information between various devices in the server, and a mass storage device 1307 for storing an operating system 1313, application programs 1314 and other program modules 1315.

[0216] The basic input / output system 1306 includes the display 1308 to display information and input devices 1309 such as a mouse, keyboard, etc. to input information by a user. The display 1308 and the input devices 1309 are connected to the central processing unit 1301 through an input / output controller 1310 connected to the system bus 1305. The basic input / output system 1306 can also include the input / output controller 1310 to receive and process input from a number of other devices, including a keyboard, mouse, or electronic stylus. Similarly, the input / output controller 1310 provides output to a display screen, a printer, or other type of output device.

[0217] The mass storage device 1307 is connected to the central processing unit 1301 through a mass storage controller (not shown) connected to the system bus 1305. The mass storage device 1307 and its associated computer-readable storage media provide non-volatile storage for the server 1300. That is, the mass storage device 1307 can include a computer-readable storage medium (not shown) such as a hard disk or a Compact Disc Read-Only Memory (CD-ROM) drive.

[0218] Without loss of generality, the computer-readable storage media can include computer storage media and communication media. Computer storage media include volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable storage instructions, data structures, program modules or other data. Computer storage media include RAM, ROM, Erasable Programmable Read Only Memory (EPROM), Electrically-Erasable Programmable Read-Only Memory (EEPROM), flash memory or other solid state memory technology, CD-ROM, Digital Versatile Disc (DVD), or other optical storage, magnetic cassettes, magnetic tapes, magnetic disk storage or other magnetic storage devices. Of course, those skilled in the art will recognize that the computer storage media described above can be different from that described above. The system memory 1304 and the mass storage device 1307 described above can be collectively referred to as memory.

[0219] The memory stores one or more programs configured to be executed by the one or more central processing units 1301, and the one or more programs contain instructions for implementing the above-mentioned method embodiments. The central processing unit 1301 executes the one or more programs to implement the method provided by each of the above-mentioned method embodiments.

[0220] According to various embodiments of the present application, the server 1300 can also be operated by connecting to a remote server on a network, such as the Internet. That is, the server 1300 can be connected to a network 1312 through a network interface unit 1311 connected to the system bus 1305, or can be connected to other types of network or remote server systems (not shown) using the network interface unit 1311.

[0221] The memory also includes one or more programs that are stored in the memory and which include instructions for performing the steps executed by the server in the method provided by the embodiments of the present application.

[0222] In the embodiments of the present application, a computer readable storage medium is also provided, in which at least one instruction is stored, and the at least one instruction is loaded and executed by a processor to implement the account pulling flow method according to the above aspect.

[0223] According to an aspect of the present application, a computer program product or computer program is provided, which includes computer instructions stored in a computer readable storage medium. A processor of a computer device reads the computer instructions from the computer readable storage medium, and the processor executes the computer instructions, so that the computer device executes the account pulling flow method provided in various optional implementation manners of the above aspect.

[0224] Other embodiments of the present application will be apparent to those skilled in the art from consideration of the specification and practice of the application disclosed herein. It is intended that the present application cover any and all variations of the application that come within the scope of the claims and a concept of the application. It is intended that the specification and examples be considered exemplary only, with the true scope and spirit of the application being indicated by the following claims.

[0225] It is to be understood that the application is not limited to the precise details of construction and the arrangement of components described above and illustrated in the drawings and that various modifications and changes can be made without departing from the scope thereof. The scope of the application is limited only by the appended claims.

Claims

1. An account pull-through method, characterized by, The method comprises: obtaining historical payment information of a user account, the historical payment information being generated based on historical payment behaviors of the user account; obtaining a historical payment type contained in the historical payment information, the historical payment type comprising a payment method used by the user account; in response to the historical payment type containing a first payment method, determining that the historical payment type satisfies a payment type condition, and obtaining historical payment records contained in the historical payment information, the historical payment records comprising payment methods used by the user account in the last n times of payment, n being an integer greater than or equal to 2; in response to the historical payment records not containing the first payment method, determining that the historical payment records satisfy a payment record condition, and determining that the user account is a target user account satisfying a pullback flow condition, setting a pullback flow identifier for the target user account, and the pullback flow condition is used to represent that the payment method used is switched from the first payment method to a second payment method; performing a pullback flow process on the target user account with the pullback flow identifier, the pullback flow process being used to guide the target user account to reuse the first payment method.

2. The method of claim 1, wherein, The method further comprises: in response to the historical payment records not containing the first payment method, obtaining device capability identifiers corresponding to payment devices used in each time of payment in the historical payment records, the device capability identifiers being used to represent support of the payment devices for the first payment method; in response to at least one of the device capability identifiers indicating that the payment device supports the first payment method, determining that the historical payment records satisfy the payment record condition.

3. The method according to claim 1 or 2, characterized in that, The method further comprises: receiving payment data corresponding to the user account, the payment data being data reported by the user account when generating a payment behavior; updating the historical payment information based on a target payment method indicated by the payment data.

4. The method of claim 3, wherein, The historical payment information contains the historical payment type and the historical payment records; The method further comprises: in response to the target payment method not belonging to the historical payment type, adding the target payment method to the historical payment type; or, in response to the target payment method belonging to the historical payment type, not updating the historical payment type; adding the target payment method to the historical payment records.

5. The method of claim 4, wherein, The payment data contains a device identifier of a payment device, and the historical payment records contain device capability identifiers corresponding to payment devices used in each time of payment; The method further comprises: determining payment method support information of the payment device based on the device identifier contained in the payment data; adding the target payment method to the historical payment records, and setting the device capability identifier for the target payment method based on the payment method support information.

6. The method of claim 1 or 2, wherein, The pullback flow processing on the target user account provided with the pullback flow identifier includes at least one of the following: sending a payment preferential message to the target user account provided with the pullback flow identifier, the payment preferential message being used to instruct to use the first payment method to make payment to obtain payment preferential treatment; and receiving payment data of the target user account sent by a payment device; and in response to the target payment method indicated by the payment data being the first payment method, issuing payment preferential treatment to the target user account.

7. The method of claim 6, wherein, After the payment preferential treatment is issued to the target user account, the method further includes: deleting the pullback flow identifier set for the target user account.

8. The method of claim 1 or 2, wherein, The method further includes: determining a pullback flow level corresponding to the target user account based on the payment frequency indicated by the historical payment information, and setting a pullback flow level identifier for the target user account, wherein different pullback flow level identifiers correspond to different pullback flow processing.

9. The method of claim 1 or 2, wherein, The historical payment information of the user account includes: acquiring the historical payment information of the user account according to a preset frequency; or in response to the historical payment information of the user account being updated, acquiring the historical payment information of the user account.

10. The method of claim 1 or 2, wherein the first payment method is biometric payment, and the biometric payment includes at least one of face recognition payment, fingerprint recognition payment, gait recognition payment, and iris recognition payment; the second payment method includes graphic code payment, and the graphic code payment includes at least one of graphic code display payment and graphic code scanning payment.

11. An account pullback flow device, comprising: The device includes: an information acquisition module configured to acquire historical payment information of a user account, the historical payment information being generated based on historical payment behavior of the user account; a first identifier setting module configured to acquire a historical payment type included in the historical payment information, the historical payment type including a payment method used by the user account; in response to the first payment method being included in the historical payment type, determining that the historical payment type satisfies a payment type condition, and acquiring historical payment records included in the historical payment information, the historical payment records including a payment method used by the user account in the last n times of payment, n being an integer greater than or equal to 2; in response to the first payment method not being included in the historical payment records, determining that the historical payment records satisfy a payment record condition, and determining that the user account is a target user account satisfying a pullback flow condition, setting a pullback flow identifier for the target user account, the pullback flow condition being used to represent that the payment method used when making payment is switched from the first payment method to a second payment method; a pullback flow module configured to perform pullback flow processing on the target user account provided with the pullback flow identifier, the pullback flow processing being used to guide the target user account to use the first payment method again.

12. A server, characterized by The server comprises a processor and a memory, the memory storing at least one instruction, the at least one instruction being loaded and executed by the processor to implement the account pulling flow method as claimed in any one of claims 1 to 10.

13. A computer-readable storage medium, characterized in that, The storage medium stores at least one instruction, the at least one instruction being loaded and executed by the processor to implement the account pulling flow method as claimed in any one of claims 1 to 10.

Images