CN114723466A

CN114723466A - Account pull-back flow method, device, server and storage medium

Info

Publication number: CN114723466A
Application number: CN202110002071.5A
Authority: CN
Inventors: 郭润增; 王少鸣; 黄家宇; 吴志伟; 陈南瑾
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd
Priority date: 2021-01-04
Filing date: 2021-01-04
Publication date: 2022-07-08

Abstract

The embodiment of the application discloses an account number pull-back flow method, an account number pull-back flow device, a server and a storage medium, and belongs to the technical field of payment. The method comprises the following steps: acquiring historical payment information of a user account, wherein the historical payment information is generated based on historical payment behaviors of the user account; setting a pull-back flow identifier for a target user account meeting a pull-back flow condition based on historical payment information, wherein the pull-back flow condition is used for representing that a payment mode used in payment is switched from a first payment mode to a second payment mode; and performing pull-back flow processing on the target user account with the pull-back flow identifier, wherein the pull-back flow processing is used for guiding the target user account to reuse the first payment mode. In the embodiment of the application, the user account provided with the pull-back flow identifier is an account which uses the first payment mode historically, so that the pull-back flow processing is performed on the user account of the type, the probability that the user account reuses the first payment mode can be improved, and the pull-back flow effect of the account is improved.

Description

Account pull-back flow method, device, server and storage medium

Technical Field

The embodiment of the application relates to the technical field of payment, in particular to an account pull-back flow method, an account pull-back flow device, a server and a storage medium.

Background

With the continuous development of payment technology, more and more novel payment modes, such as face brushing payment, are brought forward.

Because the new payment mode can change the past payment habits of the user, the user often continues to use the past payment mode after trying the new payment mode. This situation is extremely disadvantageous to the popularization of the new payment method, and causes a low usage rate of the new payment device supporting the new payment method.

In the related art, a new payment method is generally popularized by adopting an advertisement putting method, however, the full popularization method lacks pertinence, and the effect of pull-back flow (i.e. a user who uses the new payment method but switches back to the original payment method pulls back to use the new payment method) is poor.

Disclosure of Invention

The embodiment of the application provides an account pull-back flow method, an account pull-back flow device, a server and a storage medium, which are beneficial to improving the pull-back flow effect of an account, and the technical scheme is as follows:

in one aspect, an embodiment of the present application provides a method for pulling and returning an account, where the method includes:

acquiring historical payment information of a user account, wherein the historical payment information is generated based on historical payment behaviors of the user account;

setting a pull-back flow identifier for a target user account meeting a pull-back flow condition based on the historical payment information, wherein the pull-back flow condition is used for representing that a payment mode used in payment is switched from a first payment mode to a second payment mode;

and performing pull-back flow processing on the target user account with the pull-back flow identifier, wherein the pull-back flow processing is used for guiding the target user account to reuse the first payment method.

On the other hand, an embodiment of the present application provides an account number pull-back device, where the device includes:

the information acquisition module is used for acquiring historical payment information of the user account, and the historical payment information is generated based on historical payment behaviors of the user account;

the first identifier setting module is used for setting a pull-back identifier for a target user account meeting a pull-back condition based on the historical payment information, wherein the pull-back condition is used for representing that a payment mode used in payment is switched from a first payment mode to a second payment mode;

and the pull-reflux module is used for carrying out pull-reflux processing on the target user account provided with the pull-reflux identifier, and the pull-reflux processing is used for pulling the target user account back to use the first payment mode.

Optionally, the first identifier setting module includes:

a payment type obtaining unit, configured to obtain a historical payment type included in the historical payment information, where the historical payment type includes a payment method used by a user account;

a payment record obtaining unit, configured to obtain a historical payment record included in the historical payment information in response to that the historical payment type meets a payment type condition, where the historical payment record includes a payment mode used when a user account is paid last n times, and n is an integer greater than or equal to 2;

and the identification setting unit is used for responding to the condition that the historical payment record meets the payment record, determining that the user account is the target user account, and setting the pull-back flow identification for the target user account.

Optionally, the payment record obtaining unit is configured to:

responding to the first payment mode contained in the historical payment type, determining that the historical payment type meets the payment type condition, and acquiring the historical payment record contained in the historical payment information;

the identifier setting unit is configured to:

and responding to the fact that the historical payment record does not contain the first payment mode, determining that the historical payment record meets the payment record condition, determining that the user account is the target user account, and setting the pull-back flow identification for the target user account.

Optionally, the identifier setting unit is further configured to:

responding to the fact that the historical payment record does not contain the first payment mode, and obtaining a device capacity identification corresponding to payment devices used in each payment in the historical payment record, wherein the device capacity identification is used for representing the support condition of the payment devices to the first payment mode;

determining that the historical payment record satisfies the payment record condition in response to the presence of at least one of the device capability identifiers indicating that the payment device supports the first payment method.

Optionally, the apparatus further comprises:

the receiving module is used for receiving payment data corresponding to a user account, wherein the payment data is reported when the user account generates a payment behavior;

and the updating module is used for updating the historical payment information based on the target payment mode indicated by the payment data.

Optionally, the historical payment information includes a historical payment type and a historical payment record;

the update module includes:

a first updating unit, configured to add the target payment method to the historical payment type in response to that the target payment method does not belong to the historical payment type; or, in response to the target payment mode belonging to the historical payment type, not updating the historical payment type;

and the second updating unit is used for adding the target payment mode to the historical payment record.

Optionally, the payment data includes an apparatus identifier of the payment apparatus, and the historical payment record includes an apparatus capability identifier corresponding to the payment apparatus used in each payment;

the second updating unit is configured to:

determining payment mode support information of the payment equipment based on the equipment identification contained in the payment data;

and adding the target payment mode to the historical payment record, and setting the equipment capacity identification for the target payment mode based on the payment mode support information.

Optionally, the pull-back module includes:

the first pull-back flow unit is used for sending a payment discount message to the target user account provided with the pull-back flow identification, wherein the payment discount message is used for indicating that payment is carried out by using the first payment method so as to obtain payment discount;

the second pull-back unit is used for receiving payment data of the target user account sent by the payment equipment; and issuing a payment discount to the target user account in response to the target payment mode indicated by the payment data being the first payment mode.

Optionally, the apparatus further comprises:

and the deleting module is used for deleting the pull-back flow identifier set for the target user account.

Optionally, the apparatus further comprises:

and the second identifier setting module is used for determining the pull-back flow grade corresponding to the target user account based on the payment frequency indicated by the historical payment information, and setting a pull-back flow grade identifier for the target user account, wherein different pull-back flow grade identifiers correspond to different pull-back flow treatments.

Optionally, the information obtaining module is configured to:

acquiring the historical payment information of the user account according to a preset frequency;

or the like, or, alternatively,

and responding to the updating of the historical payment information of the user account, and acquiring the historical payment information of the user account.

Optionally, 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 mode comprises graphic code payment, and the graphic code payment comprises at least one of graphic code display payment and graphic code scanning payment.

In another aspect, an embodiment of the present application provides a server, where the server includes a processor and a memory, where the memory stores at least one instruction, and the at least one instruction is loaded and executed by the processor to implement the account pull-back method according to the above aspect.

In another aspect, an embodiment of the present application provides a computer-readable storage medium, where at least one instruction is stored in the storage medium, and the at least one instruction is loaded and executed by a processor to implement the account pull-back method according to the above aspect.

In another aspect, embodiments of the present application provide a computer program product or a computer program, which includes computer instructions stored in a computer-readable storage medium. The processor of the 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 execute the account pull-back flow method provided in the various alternative implementations of the above aspects.

The technical scheme provided by the application can comprise the following beneficial effects:

in the embodiment of the application, historical payment information of a user account is acquired, a target user account of which the payment mode is switched from a first payment mode to a second payment mode is identified based on the historical payment information, and a pull-back flow identifier is set for the target user account, so that pull-back flow processing is performed on the user account provided with the pull-back flow identifier; because the user account provided with the pull-back flow identifier is the account which uses the first payment mode historically, the pull-back flow processing is carried out on the user account of the type, the probability of reusing the first payment mode by the user account can be improved, and the pull-back flow effect of the account is favorably improved compared with the full-scale popularization of the payment modes.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and together with the description, serve to explain the principles of the application.

FIG. 1 illustrates a schematic diagram of an implementation environment provided by an exemplary embodiment of the present application;

FIG. 2 is a flow chart illustrating a method for account pull-back flow in accordance with an exemplary embodiment of the present application;

FIG. 3 is a flow chart illustrating an account pull-back method according to another exemplary embodiment of the present application;

FIG. 4 is a schematic diagram illustrating an implementation of a target user account identification process according to an exemplary embodiment of the present application;

FIG. 5 is a schematic diagram illustrating an implementation of a pull-back flow process in accordance with an exemplary embodiment of the present application;

FIG. 6 is a schematic diagram illustrating an implementation of a pull-reflow process according to another exemplary embodiment of the present application;

FIG. 7 is a flowchart illustrating an account pull-back method according to another exemplary embodiment of the present application;

FIG. 8 is a diagram illustrating an implementation of a target user account identification process in accordance with an exemplary embodiment of the present application;

FIG. 9 is a system architecture diagram of a payment system provided by an exemplary embodiment of the present application;

FIG. 10 is a block diagram illustrating the structure of an account pull reflow apparatus in accordance with an exemplary embodiment of the present application;

fig. 11 shows a block diagram of a server according to an exemplary embodiment of the present application.

Detailed Description

Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the present application, as detailed in the appended claims.

Referring to fig. 1, a schematic diagram of an implementation environment provided by an exemplary embodiment of the present application is shown, where the implementation environment includes a terminal 110, a payment device 120, and a server 130.

The terminal 110 is an electronic device with an offline payment function, and the electronic device may be a smartphone, a tablet computer, a wearable device, and the like, which is not limited in this embodiment.

The offline payment function in the terminal 110 may be provided by a third party application, which may be an instant messaging application with offline payment function, a shopping-type application with offline payment function, or a financial-type application with offline payment function, etc.; alternatively, the offline payment function may be provided by a native application (the terminal manufacturer is preset in the operating system, and the terminal manufacturer provides the payment service), which is not limited in this embodiment.

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

Optionally, the user may also perform biometric entry in advance through an application program in the terminal 110, and when performing online payment subsequently, if the payment device 120 supports biometric identification payment, the user may be subjected to biometric data acquisition through the payment device 120, and the acquired biometric data is verified, so that payment is completed when verification is passed, without using the terminal 110.

The payment device 120 is an electronic device used by a payee to make offline payments. In one possible implementation, the payment device 120 effects payment through interaction with the terminal 110. In some embodiments, the payment device 120 has a graphic code display function and a graphic code scanning function, and the user may use the terminal 110 to scan the graphic code displayed by the payment device 120 to complete the payment, or the user may use the terminal 110 to display the graphic code and the payment device 120 scans the graphic code to complete the payment.

In other possible implementations, the payment device 120 may effect the payment without interacting with the terminal 110. In some embodiments, the payment device 120 has a biometric collection function, through which the payment device 120 can collect biometric data of the user and report the biometric data to the server 130, and the server 130 verifies the biometric data and completes payment after the verification is passed.

Optionally, when the biometric characteristic is a fingerprint, the payment device 120 collects a fingerprint image through the fingerprint collection component; when the biometric feature is a human face, the payment device 120 collects a human face image through the camera assembly; when the biometric characteristic is gait, the payment device 120 collects gait images through the camera component; when the biometric characteristic is an iris, the payment device 120 acquires an iris image through the iris scanning assembly.

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.

The server 130 is a server implementing a payment function, which may be a background server of an application having a payment function in the terminal 110. The server 130 may be a server, a server cluster formed by several servers, or a cloud computing center.

Optionally, in order to achieve decentralization of data and improve security of data storage, the server 130 may also be a node in the data sharing system, and data sharing can be performed between nodes in the data sharing system. When any node in the data sharing system receives the input information, other nodes in the data sharing system acquire the input information according to a consensus algorithm, and the input information is stored as data in shared data, so that the data stored on all the nodes in the data sharing system are consistent.

Each node in the data sharing system has a node identifier corresponding thereto, and each node in the data sharing system may store a node identifier of another node in the data sharing system, so that the generated block is broadcast to the other node in the data sharing system according to the node identifier of the other node in the following. Each node in the data sharing system stores one identical blockchain. The block chain is composed of a plurality of blocks. The starting block comprises a block head and a block main body, wherein the block head stores an input information characteristic value, a version number, a timestamp and a difficulty value, and the block main body stores input information; the next block of the starting block takes the starting block as a parent block, the next block also comprises a block head and a block main body, the block head stores the input information characteristic value of the current block, the block head characteristic value of the parent block, the version number, the timestamp and the 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, and the safety of the input information in the block is ensured.

In one possible embodiment, when the terminal 110 performs the payment by scanning the graphic code, the terminal 110 sends payment data to the server 130, and the server 130 completes the payment based on the payment data; when the terminal 110 performs payment by displaying the graphic 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 pays in a biometric identification mode, the payment device 120 sends the collected biometric data and payment data to the server 130, the server 130 verifies the biometric data, and payment is completed based on the payment data after the verification is passed.

In the embodiment of the present application, the server 130 has a pull-back flow function, and can identify a new payment method used in history, but subsequently switch back to a target user account of an original payment method, and can pull back flow the target user account. Illustratively, as shown in fig. 1, after the terminal 110 and the payment device 120 send the payment data to the server 130, the server 130 updates historical payment information corresponding to each user account based on the payment data while completing payment according to the payment data, identifies the historical payment information, and determines a target user account satisfying a pull-back flow condition, thereby setting a pull-back flow identifier for the target user account. According to the pull back flow identifier, the server 130 can directly perform pull back flow processing through the terminal 110 (for example, issue a payment offer message to the terminal 110), and also perform pull back flow processing through the payment device 120 (for example, issue a payment offer after the user uses a novel payment method of the payment device 120 to perform payment).

Compared with full-scale advertisement promotion, the server has the capabilities of identifying the target user account and performing pull-back flow aiming at the target user account, so that the targeted pull-back flow can improve the probability of reusing a novel payment mode by the target user account, and the account pull-back flow effect is improved.

Referring to fig. 2, a flowchart of an account pull-back flow method according to an exemplary embodiment of the present application is shown, where the embodiment of the present application takes the application of the method to the server shown in fig. 1 as an example to explain, the method includes:

step 201, obtaining historical payment information of a user account, wherein the historical payment information is generated based on historical payment behaviors of the user account.

In the embodiment of the application, for each user account, the server acquires payment data generated by historical payment behaviors under the user account, so that historical payment information corresponding to the user account is generated based on the payment data, wherein the historical payment information comprises information used for indicating a payment mode adopted by the historical payment behaviors.

Step 202, setting a pull-back flow identifier for a target user account meeting a pull-back flow condition based on historical payment information, wherein the pull-back flow condition is used for representing that a payment mode used in payment is switched from a first payment mode to a second payment mode.

In the embodiment of the application, in order to implement targeted pull-back, the server first needs to identify a target user account satisfying a pull-back condition based on historical payment information. The target user account satisfying the pull-back flow condition is a user account which is historically paid by adopting a first payment mode, but is subsequently switched back to a second payment mode for payment, and the first payment mode is different from the second payment mode.

In some embodiments, the payment method is divided according to the purpose of the pull-back flow, 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 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 mode is graphic code payment, and the graphic code payment comprises at least one of graphic code display payment and graphic code scanning payment.

After the target user account is determined, the server further sets a pull-back flow identifier for each target user account, that is, the target user account is indicated to meet a pull-back flow condition through the pull-back flow identifier, so that the server performs targeted pull-back flow on the target user account based on the pull-back flow identifier.

And 203, performing pull-back flow processing on the target user account with the pull-back flow identifier, wherein the pull-back flow processing is used for guiding the target user account to reuse the first payment mode.

In a possible implementation manner, the server actively performs a pull-back flow process on the target user account provided with the pull-back flow identifier, that is, the server performs the pull-back flow process on the target user account before the target user account does not reuse the first payment method, so as to guide the user (using the target user account) to perform payment in the first payment method.

In another possible implementation manner, the server passively triggers the pull-back flow processing on the target user account, that is, after detecting that the target user account reuses the first payment method, the server performs the pull-back flow processing on the target user account, so as to improve the probability that the reflow user continues to pay by using the first payment method subsequently.

Optionally, the manner of performing the pull-back processing includes, but is not limited to, sending a pull-back message, sending a pull-back reward, and the like.

In a possible application scenario, when a payment mode of face recognition payment needs to be popularized, a server screens out a target user account which has been historically used for face recognition payment and is displayed by using a graphic code or scanned by using the graphic code in subsequent switching based on historical payment information of each user account, and sets a pull-back flow identifier for the target user account, wherein the pull-back flow identifier is used for carrying out pull-back flow processing on the target user account subsequently, so that the probability of face recognition payment in target user account switching is improved.

To sum up, in the embodiment of the present application, historical payment information of a user account is acquired, a target user account whose payment mode is switched from a first payment mode to a second payment mode is identified based on the historical payment information, and a pull-back flow identifier is set for the target user account, so that a pull-back flow process is performed on the user account with the pull-back flow identifier; because the user account provided with the pull-back flow identifier is the account which uses the first payment mode historically, the pull-back flow processing is carried out on the user account of the type, the probability of reusing the first payment mode by the user account can be improved, and the pull-back flow effect of the account is favorably improved compared with the full-scale popularization of the payment modes.

In a possible implementation manner, 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 a payment method used by the user account, and the historical payment record includes a payment method adopted when the user account has paid for the last several times. 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 following describes a detailed process for identifying a target user account with an exemplary embodiment.

Referring to fig. 3, a flowchart of an account pull-back flow method according to another exemplary embodiment of the present application is shown, where in the embodiment of the present application, taking an example that the method is applied to the server shown in fig. 1 as an example, the method includes:

step 301, obtaining historical payment information of the user account, wherein the historical payment information is generated based on historical payment behaviors of the user account.

Regarding the timing of the server acquiring the historical payment information to identify the target user account, in one possible embodiment, the server acquires the historical payment information of the user account according to a preset frequency, for example, the preset frequency may be 1 minute/time.

In another possible embodiment, since the user account may perform multiple payment actions in a short time, in order to improve the real-time performance of the historical payment information, the server obtains (updated) historical payment information of the user account in response to the historical payment information update of the user account.

Step 302, obtaining the historical payment type contained in the historical payment information, wherein the historical payment type comprises the payment mode used by the user account.

In one possible implementation, the historical payment information includes a payment type field, and the payment type field includes a historical payment type, wherein the historical payment type may be stored in an array form.

Illustratively, as shown in fig. 4, the server obtains a payment type field user _ pay _ channel corresponding to "zhang san" of the user account, where a historical payment type included in the field is [ card, scan, face ]; acquiring a payment type field user _ pay _ chanel corresponding to a user account "Liquan", wherein the historical payment type contained in the field is [ card, face ]; and acquiring a payment type field user _ pay _ channel corresponding to the user account number 'wang five', wherein the historical payment type contained in the field is [ card, scan ]. The card is used for representing graphic code display payment, the scan is used for representing graphic code scanning payment, and the face is used for representing face recognition payment.

Since the pull-back flow is subsequently required 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 type. If yes, executing step 303, and if not, determining that the user account does not satisfy the pull-back flow condition.

In a possible implementation manner, the server detects whether the historical payment type includes the first payment method, if yes, the historical payment type is determined to meet the payment type condition, and if not, the historical payment type is determined not to meet the payment type condition.

Illustratively, as shown in fig. 4, when the first payment method is face recognition payment, since the historical payment types corresponding to the user account "zhang san" and "lie si" include a face, but the historical payment types corresponding to the user account "wang wu" do not include a face, the server determines that the user account "zhang san" and "lie si" satisfy the payment type condition, but the user account "wang wu" does not satisfy the payment type condition.

Step 303, in response to that the historical payment type meets the payment type condition, obtaining a historical payment record contained in the historical payment information, where the historical payment record contains a payment mode adopted by the user account in the last n times of payment, and n is an integer greater than or equal to 2.

Further, for the user account satisfying the payment type condition, the server further acquires the historical payment record contained 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 record.

In one possible embodiment, the historical payment information includes a payment record field, and the payment record field includes a historical payment record, wherein the historical payment record may be stored in an array form.

Optionally, the historical payment record stores the payment method used in the last n-time payment in a first-in first-out manner, that is, when n payment methods are stored in the historical payment record, if a new payment method needs to be written in, the earliest written payment method is moved out of the historical payment record.

Illustratively, as shown in fig. 4, the server obtains a payment record field last _ use _ pay _ type corresponding to "zhang san" of the user account, where the historical payment record contained in the field is [ card, scan, scan, card, scan ]; and acquiring a payment type field last _ use _ pay _ type corresponding to the user account number 'Liquan', wherein the historical payment record contained in the field is [ scan, scan, face, face, scan ].

Since the flow of the user account switched from the first payment mode to the second payment mode needs to be performed subsequently, the server first detects whether the user account meets the payment record condition based on the historical payment record. If yes, go to step 304, if not, determine that the user account does not satisfy the pull-back flow condition.

In a possible implementation manner, the server detects whether the historical payment record contains the first payment mode, if not, the server determines that the historical payment record meets the payment record condition, and if so, the server determines that the historical payment type does not meet the payment record condition.

Illustratively, as shown in fig. 4, when the first payment method is face recognition payment, since the historical payment record corresponding to the user account "zhangsan" does not include a face, and the historical payment record corresponding to the user account "lie si" includes a face, the server determines that the user account "zhangsan" satisfies the payment record condition, and the user account "lie si" does not satisfy the payment record condition.

In other possible embodiments, the server may determine that the historical payment record satisfies the payment record condition when the number of the first payment means in the historical payment record is smaller than a number threshold (for example, 1 time or 2 times), which is not limited in this embodiment.

And step 304, responding to the condition that the historical payment record meets the payment record, determining that the user account is a target user account, and setting a pull-back flow identifier for the target user account.

And when the historical payment type corresponding to the user account meets the payment type condition and the historical payment record meets the payment record condition, the server determines that the user account is the target user account and sets the pull-back flow identification.

Illustratively, as shown in fig. 4, the server determines that the user account "zhang san" satisfying both the payment type condition and the payment record condition is the target user account.

In one illustrative example, the user account information maintained in the server is shown in Table one.

Watch 1

User account number	Pull-back flow identifier
		Zhang San	1
Li Si	0
		Wang Wu	0
Zhao liu xi	1

Wherein, 1 indicates that the user account is provided with the pull-back flow identifier, and 0 indicates that the user account is not provided with the pull-back flow identifier.

In a possible implementation manner, in order to further improve the account pull-back flow effect, after the server sets the pull-back flow identifier, based on the payment frequency indicated by the historical payment information, the pull-back flow level corresponding to the target user account is determined, and a pull-back flow level identifier is set for the target user account.

Optionally, the payment frequency and the pull-back flow grade have a positive correlation, that is, the higher the payment frequency is, the higher the pull-back flow grade is. When the pull-back flow processing mode is to issue the payment discount, the pull-back flow grade and the payment discount are in positive correlation, namely the higher the pull-back flow grade is, the greater the payment discount strength is.

And 305, sending a payment preference message to the target user account with the pull-back flow identification, wherein the payment preference message is used for indicating that the payment is carried out by using the first payment method to obtain the payment preference.

In order to guide the user using the target user account to pay in the first payment mode, in a possible implementation manner, the server sends payment preference information to the target user account provided with the pull-back flow identifier, and prompts the user to pay in the first payment mode to obtain the payment preference.

Optionally, the server sends the payment discount information to the target user account according to a preset frequency, for example, 1 day/time, or when the server receives the payment data of the target user account and the payment data indicates that the payment method used by the target user account this time does not belong to the first payment method, the server sends the payment discount information to the target user account after the payment is completed this time.

The payment offer may be a full discount offer, a random discount offer, a voucher, etc., which is not limited in this embodiment.

Illustratively, as shown in fig. 5, after determining that "zhang san" is a target user account based on historical payment information 52 of the user account "zhang san", when receiving payment data sent by the terminal 53 (login user account "zhang san") again and the payment data indicates that the payment method adopted by the current payment is not face recognition payment, the server 51 sends a payment preference message to the terminal 53, and the terminal 53 displays the payment preference message on a payment completion interface.

And step 306, receiving the payment data of the target user account sent by the payment device.

In another possible implementation manner, when the server identifies that the target user account is paid through the first payment manner, the server issues a payment discount to the target user account so as to improve the probability of the user to continue using the first payment manner subsequently.

Optionally, after the user uses the payment function provided by the payment device to pay, 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 payment function, the payment device may also report the collected biometric data to the server, and the server performs authentication based on the biometric data and completes a payment process based on the payment data after the authentication is passed.

Illustratively, as shown in fig. 6, when a user (corresponding to a target user account) uses a payment device 61 to perform face payment, the payment device 61 reports face payment data to a server 62.

And 307, in response to that the target payment mode indicated by the payment data is the first payment mode, issuing a payment discount to the target user account.

In a possible implementation mode, after receiving the payment data, the server detects whether a target payment mode indicated by the payment data is a first payment mode, if the target payment mode is the first payment mode, the server issues payment discount to a target user account, and therefore a payment process is completed according to the payment discount and the payment data; and if the target payment mode is not the first payment mode, not issuing the payment discount.

Optionally, the payment offer is a full discount offer, a random discount offer, a voucher, or the like, which is not limited in this embodiment.

Illustratively, as shown in fig. 6, the server 62 recognizes that the user uses the face payment function, so as to issue a payment discount to the target user account, and automatically uses the payment discount to complete the face 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 payment has enjoyed face payment preference.

In step 308, the pull stream id set for the target user account is deleted.

And after the server issues the payment discount, deleting the pull-back flow identification set for the target user account.

And combining the data shown in the table I, and after the user account number Zhang III uses the face payment, deleting the pull-back flow identifier corresponding to Zhang III by the server.

In the embodiment, the server performs two-stage screening of the target user account based on the historical payment type and the historical payment record in the historical payment information, so that the identification efficiency and the identification accuracy of the target user account are improved; in addition, under different scenes, the server adopts different pull-back flow processing modes for the target user account, which is beneficial to further improving the pull-back flow effect of the account.

In order to ensure the effectiveness and accuracy of the historical payment information corresponding to the user account and further improve the identification of the target user account and the accuracy of the pull-back flow, in one possible implementation, when the payment data corresponding to the user account is received, the server updates the historical payment information based on the target payment mode indicated by the payment data. The payment data is reported by a terminal when a user account generates payment behavior, or reported by payment equipment.

Optionally, if the historical payment information includes the historical payment type and the historical payment record, the server may include the following steps when updating the historical payment information.

Responding to the fact that the target payment mode does not belong to the historical payment type, and adding the target payment mode 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.

After the server acquires the target payment mode, whether the target payment mode belongs to the historical payment type corresponding to the user account is detected, if not, the target payment mode is added to the historical payment type, and if yes, the current historical payment type is kept.

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

And secondly, adding the target payment mode to the historical payment record.

In a possible implementation mode, when the historical payment record stores the payment mode adopted in the last n times of payment in a first-in first-out mode, if the number of the payment modes recorded in the historical payment record does not reach n, the target payment mode is directly added to the historical payment record; and if the number of the payment modes recorded in the historical payment record reaches n, the server moves the payment mode written at the earliest out of the historical payment record and writes the payment mode into a target payment mode.

In an illustrative example, the historical payment record is used to record the payment method used in the last 5 payments, and if the current historical payment record is [ scan, scan, face, face, scan ] (payment time is 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 ].

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 for payment, that is, the switching of the payment methods is not only determined by the user subjectively, but also may be determined by the device function of the payment device. Accordingly, if only the payment method is recorded in the historical payment record, the target user account identified based on the historical payment record may not be accurate. For example, the payment environment in which the identified target user account is located may not be provided with a payment device supporting the first payment method, and the effect of performing the pull-back flow processing on such target user account is not good.

In order to further improve the accuracy of the identified target user account and identify the user who switches the payment mode according to the subjective intention, in a possible implementation manner, the historical payment record includes not only the payment mode but also an equipment capability identifier corresponding to the payment equipment used in payment, and the equipment capability identifier is used for representing the support condition of the payment equipment on the first payment mode. On the basis of fig. 3, as shown in fig. 7, step 304 may be replaced with

steps

3041 and 3042.

Step 3041, in response to that the historical payment record does not include the first payment method, obtaining the device capability identifier corresponding to the payment device used in each payment in the historical payment record.

And when the historical payment record does not contain the first payment mode, the server further acquires the equipment capability identification corresponding to each payment mode, so that whether the first payment mode is not used due to the subjective intention of the user is identified according to the equipment capability identification.

Illustratively, as shown in fig. 8, after determining the user account "zhangsan" and "zhangsi" meeting the payment type condition based on the historical payment types contained in the user account "zhangsan", "lisi" and "wangwu" user _ pay _ chanel, the server further obtains the historical payment record [ card (0), scan (1), scan (0), card (1), scan (1) ] corresponding to "zhangsan", and the historical payment record last _ use _ pay _ type corresponding to "lisi": [ scan (0), scan (0), card (0), scan (0), scan (0) ]. Wherein, 1 and 0 are device capability identifiers, and 1 represents that the payment device supports the first payment mode, and 0 identifies that the payment device does not support the first payment mode.

Step 3042, in response to the presence of the at least one device capability identifier indicating that the payment device supports the first payment method, determining that the historical payment record satisfies the payment record condition.

When the device capability identifier indicates that the payment device supports the first payment mode but the adopted payment mode is not the first payment mode, the fact that the first payment mode is not adopted is the subjective intention 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.

Illustratively, as shown in fig. 8, although the historical payment records corresponding to "zhangsan" and "lie si" do not include the first payment method face, the payment device used in each payment in the historical payment record corresponding to "lie si" does not support the first payment method, that is, the switching of the "lie si" to the payment method other than the first payment method is that the payment device capability limit is received, instead of the subjective intention, so the server determines that the historical payment record of the user account "lie si" does not satisfy the payment record condition. And the historical payment record corresponding to Zhang III indicates that the payment equipment supporting the first payment mode is used, but the payment is still carried out by using a non-first payment mode, namely the first payment mode is not adopted by Zhang III due to subjective intention, so that the server determines that the historical payment record of the Zhang III in the user account number meets the payment record condition.

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

The device identifier may be a Serial Number (SN) of the payment device, and is used to uniquely identify the payment device.

Optionally, the server stores a corresponding relationship between the device identifier corresponding to the payment device and the payment method support information, and the server queries, according to the device identifier included in the payment data, the payment method support information corresponding to the payment device in the corresponding relationship, and further determines whether the payment device supports the first payment method. Illustratively, the correspondence between the device identifier and the payment means support information is shown in table two.

Watch two

Further, the server adds the target payment mode to the historical payment record, and sets the device capability identifier for the target payment mode based on the payment mode support information. When the payment mode support information contains a first payment mode, the server sets a first device capacity identification for the target payment mode, and when the payment mode support information does not contain the first payment mode, the server sets a second device capacity identification for the target payment mode, wherein the first device capacity identification indicates that the payment device supports the first payment mode, and the second device capacity identification indicates that the payment device does not support the first payment mode.

Combining the data shown in the table two, when the device identifier contained in the obtained payment data is ID12345678 and the target payment mode is scan, adding scan (1) to the historical payment record by the server; when the device identification contained in the acquired payment data is ID23456789 and the target payment mode is scan, the server adds scan (0) to the historical payment record.

In this embodiment, the historical payment record is used for recording the payment mode, and is further provided with a device capability identifier indicating whether the payment device supports the first payment mode, and when subsequently identifying the target user account, whether the historical payment record contains the first payment mode needs to be detected, and whether the payment device supporting the first payment mode exists in the environment where the user is located needs to be further detected according to the device capability identifier, so that the user account using the payment mode is determined to be switched due to the subjective intention of the user, the identification accuracy of the target user account is improved, and the subsequent pull-back flow effect on the target user account is further improved.

In an illustrative example, taking the first payment method as an example for face recognition payment, the overall system structure of the solution according to the embodiment of the present application is shown in fig. 9. The system comprises a terminal 910, a face payment device 920 and a server 930.

The terminal 910 has installed therein a payment APP (application), which has payment code payment and code scanning payment functions. After payment code payment or code scanning payment is carried out, the payment APP reports payment data to the server 930 through the network module, the server 930 completes a payment process through payment code payment service or code scanning payment service and sends the payment data to basic account number service, the basic account number service determines whether a user account number meets a pull-back flow condition according to a payment mode contained in the payment data, and when the pull-back flow condition is met, a pull-back flow identifier is written into a user account number-basic information base.

The face payment device 920 is provided with a camera for collecting face images and is provided with a face payment APP. When the face payment is carried out, the face acquisition module acquires the face image acquired by the camera and carries out face optimization on the face image. The face payment APP uploads the preferred face image to the server 930 through the network module, enters a loading state, and waits for a payment result fed back by the server 930. The server 930 performs authentication on the received face image through the face payment service based on the preset face image in the face library, and sends the payment data to the basic account service, which updates the historical payment information of the user account according to the payment mode contained in the payment data.

The server 930 acquires a target user account with a pull-back flow identifier in the user account-basic information base at regular time through a timing service, and sends a face-brushing activity preference notification to the payment APP in the terminal 910 through a push service.

In addition, when the target user account adopts face payment, the face payment service triggers the activity service, and sends activity information to the activity module of the face payment APP of the face payment device 920 to inform the user of the activity preference obtained by face-brushing payment.

Referring to fig. 10, a block diagram of an account pull-back device according to an exemplary embodiment of the present application is shown. The apparatus may include:

an information obtaining module 1001, configured to obtain historical payment information of a user account, where the historical payment information is generated based on historical payment behavior of the user account;

a first identifier setting module 1002, configured to set a pull-back identifier for a target user account that meets a pull-back condition based on the historical payment information, where the pull-back condition is used to represent that a payment method used in payment is switched from a first payment method to a second payment method;

and a pull-back flow module 1003, configured to perform a pull-back flow process on the target user account with the pull-back flow identifier, where the pull-back flow process is used to guide the target user account to reuse the first payment method.

Optionally, the first identifier setting module 1002 includes:

Optionally, the payment record obtaining unit is configured to:

the identifier setting unit is configured to:

Optionally, the identifier setting unit is further configured to:

responding to the fact that the historical payment record does not contain the first payment mode, and obtaining a device capacity identification corresponding to payment devices used in each payment in the historical payment record, wherein the device capacity identification is used for representing the support condition of the payment devices on the first payment mode;

Optionally, the apparatus further comprises:

the update module includes:

a first updating unit, configured to add the target payment method to the historical payment type in response to that the target payment method does not belong to the historical payment type; or, in response to the target payment means belonging to the historical payment type, not updating the historical payment type;

the second updating unit is configured to:

Optionally, the pull-reflow module 1003 includes:

Optionally, the apparatus further comprises:

Optionally, the information obtaining module is configured to:

or the like, or, alternatively,

and responding to the update of the historical payment information of the user account, and acquiring the historical payment information of the user account.

It should be noted that: the account pull-reflow apparatus provided in the above embodiment is only illustrated by the division of the above functional modules, and in practical applications, the above functions may be distributed by different functional modules according to needs, that is, the internal structure of the apparatus is divided into different functional modules to complete all or part of the above described functions. In addition, the account pull-back device and the account pull-back method provided by the above embodiments belong to the same concept, and specific implementation processes thereof are detailed in the method embodiments and are not described herein again.

Referring to fig. 11, a block diagram of a server according to an exemplary embodiment of the present application is shown. Specifically, the method comprises the following steps:

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 CPU 1301. The server 1300 also includes a basic Input/Output system (I/O system) 1306, which facilitates transfer of information between devices within the server, and a mass storage device 1307 for storing an operating system 1313, application programs 1314, and other program modules 1315.

The basic input/output system 1306 includes a display 1308 for displaying information and an input device 1309, such as a mouse, keyboard, etc., for a user to input information. Wherein the display 1308 and input device 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 may also include an input/output controller 1310 for receiving and processing input from a number of other devices, such as a keyboard, mouse, or electronic stylus. Similarly, input-output controller 1310 also provides output to a display screen, a printer, or other type of output device.

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 may include a computer-readable storage medium (not shown) such as a hard disk or Compact Disc-Only Memory (CD-ROM) drive.

Without loss of generality, the computer-readable storage media may include computer storage media and communication media. Computer storage media includes volatile and nonvolatile, 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 includes 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 Disks (DVD), or other optical, magnetic, or other magnetic storage devices. Of course, those skilled in the art will appreciate that the computer storage media is not limited to the foregoing. The system memory 1304 and mass storage device 1307 described above may be collectively referred to as memory.

The memory stores one or more programs configured to be executed by the one or more central processing units 1301, the one or more programs containing instructions for implementing the method embodiments described above, and the central processing unit 1301 executes the one or more programs to implement the methods provided by the various method embodiments described above.

The server 1300 may also operate as a remote server connected to a network via a network, such as the internet, according to various embodiments of the present application. That is, the server 1300 may be connected to the network 1312 through the network interface unit 1311, which is connected to the system bus 1305, or may be connected to other types of networks or remote server systems (not shown) using the network interface unit 1311.

The memory also includes one or more programs, which are stored in the memory, and the one or more programs include steps for performing the steps performed by the server in the method provided by the embodiment of the present application.

In an embodiment of the present application, a computer-readable storage medium is further provided, where at least one instruction is stored in the storage medium, and the at least one instruction is loaded and executed by a processor to implement the account pull-back method according to the above aspect.

According to an aspect of the application, a computer program product or computer program is provided, comprising computer instructions, the computer instructions being stored in a computer readable storage medium. The processor of the 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 execute the account pull-back flow method provided in the various alternative implementations of the above aspects.

Other embodiments of the present application will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of the invention following, in general, the principles of the application and including such departures from the present disclosure as come within known or customary practice within the art to which the invention pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the application being indicated by the following claims.

It will be understood that the present application is not limited to the precise arrangements described above and shown in the drawings and that various modifications and changes may 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-back method, the method comprising:

2. The method of claim 1, wherein setting a pull flow identifier for a target user account satisfying a pull flow condition based on the historical payment information comprises:

obtaining a historical payment type contained in the historical payment information, wherein the historical payment type comprises a payment mode used by a user account;

responding to the fact that the historical payment type meets a payment type condition, and acquiring a historical payment record contained in the historical payment information, wherein the historical payment record contains a payment mode adopted by a user account in the last n times of payment, and n is an integer greater than or equal to 2;

and responding to the condition that the historical payment record meets the payment record, determining that the user account is the target user account, and setting the pull-back flow identification for the target user account.

3. The method according to claim 2, wherein the obtaining the historical payment record contained in the historical payment information in response to the historical payment type satisfying the payment type condition comprises:

the responding to the historical payment record meeting the payment record condition, determining that the user account is the target user account, and setting the pull-back flow identifier for the target user account includes:

4. The method of claim 3, wherein the determining that the historical payment record satisfies the payment record condition in response to the historical payment record not including the first payment method comprises:

5. The method of any of claims 1 to 4, further comprising:

receiving payment data corresponding to a user account, wherein the payment data is reported when the user account generates a payment behavior;

updating the historical payment information based on the target payment mode indicated by the payment data.

6. The method according to claim 5, wherein the historical payment information comprises a historical payment type and a historical payment record;

the updating the historical payment information based on the target payment mode indicated by the payment data comprises:

in response to the target payment means not belonging to the historical payment type, adding the target payment means to the historical payment type; or, in response to the target payment mode belonging to the historical payment type, not updating the historical payment type;

adding the target payment means to the historical payment record.

7. The method according to claim 6, wherein the payment data includes device identification of the payment device, and the historical payment record includes device capability identification corresponding to the payment device used in each payment;

the adding the target payment method to the historical payment record comprises:

8. The method according to any one of claims 1 to 4, wherein the performing the pull flow processing on the target user account provided with the pull flow identifier includes at least one of:

sending a payment discount message to the target user account provided with the pull-back flow identification, wherein the payment discount message is used for indicating that payment is carried out by using the first payment method so as to obtain payment discount; and the combination of (a) and (b),

receiving payment data of the target user account sent by payment equipment; and issuing a payment discount to the target user account in response to the target payment mode indicated by the payment data being the first payment mode.

9. The method of claim 8, wherein after issuing a payment offer to the target user account, the method further comprises:

and deleting the pull-back flow identification set for the target user account.

10. The method according to any one of claims 1 to 4, wherein after setting a pull-back flow identifier for a target user account satisfying a pull-back flow condition based on the historical payment information, the method further comprises:

and determining a pull-back flow grade corresponding to the target user account based on the payment frequency indicated by the historical payment information, and setting a pull-back flow grade identifier for the target user account, wherein different pull-back flow grade identifiers correspond to different pull-back flow treatments.

11. The method according to any one of claims 1 to 4, wherein the acquiring historical payment information of the user account comprises:

or the like, or, alternatively,

12. The method according to any one of claims 1 to 4,

the first payment method is biometric identification payment, and the biometric identification payment comprises at least one of face identification payment, fingerprint identification payment, gait identification payment and iris identification payment;

13. An account number pull-back flow device, the device comprising:

and the pull-back flow module is used for carrying out pull-back flow processing on the target user account with the pull-back flow identifier, and the pull-back flow processing is used for guiding the target user account to reuse the first payment mode.

14. A server, comprising a processor and a memory, wherein the memory stores at least one instruction, and the at least one instruction is loaded and executed by the processor to implement the account pull-back method according to any one of claims 1 to 12.

15. A computer-readable storage medium having stored thereon at least one instruction, which is loaded and executed by a processor, to implement the account pull-back method according to any one of claims 1 to 12.