CN114511314A - Payment account management method and device, computer equipment and storage medium - Google Patents
Payment account management method and device, computer equipment and storage medium Download PDFInfo
- Publication number
- CN114511314A CN114511314A CN202210138525.6A CN202210138525A CN114511314A CN 114511314 A CN114511314 A CN 114511314A CN 202210138525 A CN202210138525 A CN 202210138525A CN 114511314 A CN114511314 A CN 114511314A
- Authority
- CN
- China
- Prior art keywords
- account
- version
- payment
- attribute
- time
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/22—Payment schemes or models
- G06Q20/227—Payment schemes or models characterised in that multiple accounts are available, e.g. to the payer
Abstract
The invention discloses a payment account management method, which comprises the following steps: receiving an attribute change instruction, and determining a payment account of an attribute to be changed, attribute change content and attribute change time of the payment account, and an application bound with the payment account; acquiring account versions associated with the application and the payment account, and generating a latest account version of the payment account according to the acquired account versions, the attribute change content and the attribute change time; associating and storing the application, the payment account, and the latest account version of the payment account. The invention also discloses a payment account management device, a computer device and a computer readable storage medium.
Description
Technical Field
The invention relates to the technical field of data processing, in particular to a payment account management method, a payment account management device, computer equipment and a computer-readable storage medium.
Background
The payment account is an important concept for the payment platform, a merchant can complete collection based on the payment account, and finance can complete reconciliation, statement statistics and other operations based on the payment account. In the implementation of the traditional payment platform, the management of payment account data is simple, only the current state is stored, and the change details of the account which have been generated are not effectively recorded, so that the accurate account checking has great difficulty, and the rollback of the account cannot be quickly and effectively implemented.
Aiming at the technical problem that the prior art cannot effectively manage and restrict the change action of a payment account, so that accurate account checking and account rollback cannot be realized, an effective solution does not exist at present.
Disclosure of Invention
The invention aims to provide a payment account management method, a payment account management device, computer equipment and a computer readable storage medium, which can solve the technical problem that in the prior art, the change action of a payment account cannot be effectively managed and restricted, so that accurate account checking and account rollback cannot be realized.
One aspect of the present invention provides a payment account management method, including: receiving an attribute change instruction, and determining a payment account of an attribute to be changed, attribute change content and attribute change time of the payment account, and an application bound with the payment account; acquiring account versions associated with the application and the payment account, and generating a latest account version of the payment account according to the acquired account versions, the attribute change content and the attribute change time; associating and storing the application, the payment account, and the latest account version of the payment account.
Optionally, the obtaining an account version associated with the application and the payment account, and generating a latest account version of the payment account according to the obtained account version, the attribute change content, and the attribute change time includes: obtaining account version identification and account version attributes associated with the application and the payment account; generating the latest account version identification of the payment account according to the acquired account version identification; generating the latest account version attribute of the payment account according to the acquired account version attribute, the attribute change content and the attribute change time; accordingly, the associating and storing the application, the payment account, and the most recent account version of the payment account includes: and associating and storing the application, the payment account and the latest account version identification and account version attribute of the payment account.
Optionally, the generating the latest account version identifier of the payment account according to the acquired account version identifier includes: screening the account version identification with the shortest creation time from the obtained account version identifications; and updating the account version identifier with the shortest creation time according to a preset version creation rule to generate the latest account version identifier of the payment account.
Optionally, the generating the latest account version attribute of the payment account according to the acquired account version attribute, the attribute change content, and the attribute change time includes: screening the account version attribute with the shortest creation time from the acquired account version attributes; attribute contents of the same type as the attribute change contents are removed from the account version attributes with the shortest creation time, and the attribute change contents are added to the account version attributes with the shortest creation time; attribute content used for representing creation time is removed from the account version attribute with the shortest creation time, and the attribute change time is added to the account version with the shortest creation time to generate the latest account version attribute of the payment account; and the attribute change time is used for representing the latest account version identification of the payment account and the creation time of the account version attribute.
Optionally, before the receiving the property change instruction, determining a payment account of the property to be changed, the property change content and the property change time of the payment account, and the application bound to the payment account, the method further includes: receiving an account binding instruction, and binding the application and the payment account; acquiring the binding time of the application and the payment account and the account attribute of the payment account; creating a first account version identification for the payment account, and using the binding time and the account attribute as a first account version attribute of the payment account; associating and storing the application, the payment account, and a first account version identification and a first account version attribute of the payment account; the binding time is used for representing the creation time of the first account version identification and the first account version attribute of the payment account.
Optionally, after the associating and storing the application, the payment account, and the latest account version identification and account version attribute of the payment account, the method further includes: receiving a reconciliation instruction, and determining a target payment flow line belonging to the application; acquiring all payment accounts associated with the application, and screening out a first payment account of which the binding time is less than or equal to the transaction time of the target payment flow and is closest to the transaction time from the acquired payment accounts; determining a first set of account version identifications associated with the application and the first payment account, and retrieving account version attributes associated with each account version identification in the first set of account version identifications; extracting a first account version attribute with the creation time less than or equal to the deal time and the creation time closest to the deal time from the retrieved account version attributes; and generating reconciliation information according to the first account version attribute and the target payment flow.
Optionally, the receiving a reconciliation instruction and determining a target payment streamline attributed to the application includes: receiving a reconciliation instruction, and analyzing a reconciliation time starting point; and screening out target payment running water with the transaction time being more than or equal to the starting point of the reconciliation time from all payment running water belonging to the application.
Optionally, after the associating and storing the application, the payment account, and the latest account version identification and account version attribute of the payment account, the method further includes: receiving an account rollback instruction, and analyzing a time point to which the account rollback is required; acquiring all payment accounts associated with the application, and screening out a second payment account of which the binding time is less than or equal to the time point needing to be rolled back and the binding time is closest to the time point needing to be rolled back from the acquired payment accounts; determining a second set of account versioning associated with the application and the second payment account and querying account versioning attributes associated with each of the second set of account versioning; extracting a second account version attribute with the creation time less than or equal to the time point needing to be rolled back and the creation time closest to the time point needing to be rolled back from the inquired account version attributes; switching the application from a current account version attribute to the second account version attribute.
Another aspect of the present invention provides a payment account management apparatus, the apparatus including: the system comprises a first receiving module, a second receiving module and a third receiving module, wherein the first receiving module is used for receiving an attribute change instruction, determining a payment account of an attribute to be changed, attribute change content and attribute change time of the payment account and an application bound with the payment account; the first acquisition module is used for acquiring the account version associated with the application and the payment account and generating the latest account version of the payment account according to the acquired account version, the attribute change content and the attribute change time; the first association storage module is used for associating and storing the application, the payment account and the latest account version of the payment account.
Yet another aspect of the present invention provides a computer apparatus, comprising: a memory, a processor and a computer program stored on the memory and executable on the processor, the processor implementing the payment account management method of any of the above embodiments when executing the computer program.
Yet another aspect of the present invention provides a computer-readable storage medium having stored thereon a computer program which, when executed by a processor, implements a payment account management method as described in any of the above embodiments.
According to the payment account management method provided by the invention, the concept of the account version is introduced to record each change operation of the payment account, when the payment account is changed for one time, the latest account version of the payment account is determined according to the account version commonly associated with the payment account and the application, then the application, the payment account and the latest account version of the payment account are associated and stored, and when the operations such as rollback, account checking and the like are needed subsequently, the corresponding account version can be found out according to the stored association relation, so that the purpose of accurate account checking and account rollback is realized based on the found account version, and the technical problem that the change action of the payment account cannot be effectively managed and restrained in the prior art, and the accurate account checking and account rollback cannot be realized is solved.
Drawings
Various other advantages and benefits will become apparent to those of ordinary skill in the art upon reading the following detailed description of the preferred embodiments. The drawings are only for purposes of illustrating the preferred embodiments and are not to be construed as limiting the invention. Also, like reference numerals are used to refer to like parts throughout the drawings. In the drawings:
FIG. 1 is a flow diagram illustrating a method for payment account management in one embodiment;
FIG. 2 is a schematic diagram illustrating a payment account management scheme in accordance with one embodiment;
FIG. 3 is a diagram illustrating a prior art static pipelined reconciliation;
FIG. 4 is a diagram illustrating a precision reconciliation based on an account version according to an embodiment;
FIG. 5 is a schematic diagram illustrating an implementation of accurate reconciliation in a first embodiment;
fig. 6 is a block diagram showing a payment account management apparatus in the second embodiment;
fig. 7 shows a block diagram of a computer device suitable for implementing the payment account management method according to the third embodiment.
Detailed Description
In order to make the objects, technical solutions and advantages of the present invention more apparent, the present invention is described in further detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.
It should be noted that, in this document, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.
Application scenarios
For better understanding of the present invention, an application scenario of the present invention is illustrated, but it should be understood that the present invention is not only applicable to this application scenario, and the application scenario illustrated herein should not limit the technical solution of the present invention.
Such as: the invention is suitable for an enterprise-level payment center aggregating third-party payment platforms, the payment account of the payment center is originated from the third-party payment platform, and the payment center needs to realize centralized management of multi-platform payment accounts. In order to better use the service of the payment center, the access party firstly needs to register the application in the payment center, and opens the payment product to be used for the application (selecting the payment account is a necessary link for opening the payment product), and in order to meet the business requirement, the application can also change the payment account.
In the prior art, when attribute information of a payment account needs to be changed, the attribute information can be directly changed in the current account attribute, and the historical account attribute cannot be stored in a system after the change.
In this embodiment, an account version is set for a payment account, and after the payment account is bound with an application for the first time, a first account version of the payment account is created, and the application, the payment account and the first account version of the payment account are associated; when the attributes of the payment account are changed, a second account version of the payment account is created and the application, the payment account, and the second account version of the payment account are associated. Further, if a payment account is newly bound by the application, the process of creating the account version of the new payment account is consistent with the above.
Example one
The method and the device introduce the concept of the account version to record each time of changing operation of the payment account, when the payment account is changed for one time, the latest account version of the payment account is determined according to the account version commonly associated with the payment account and the application, then the application, the payment account and the latest account version of the payment account are associated and stored, and when the operations such as rollback, account checking and the like are needed subsequently, the corresponding account version can be found out according to the stored association relation, so that the purpose of accurate account checking and account rollback can be realized based on the found account version, and the technical problem that the accurate account checking and account rollback cannot be realized due to the fact that the changing action of the payment account cannot be effectively managed and restrained in the prior art is solved. Specifically, fig. 1 shows a flowchart of a payment account management method in the first embodiment, and as shown in fig. 1, the method includes steps S1 to S3, where:
step S1, receiving an attribute change instruction, and determining a payment account of the attribute to be changed, the attribute change content and the attribute change time of the payment account, and the application bound to the payment account.
The attribute changing instruction carries an account identifier of the payment account with the attribute to be changed and an application identifier of the application bound with the payment account, an account identifier and an application identifier can be obtained by analyzing the attribute changing instruction, the analyzed account identifier can be referred to as the payment account with the attribute to be changed, and the analyzed application identifier is referred to as the application bound with the payment account.
The attribute change instruction also carries attribute change content and attribute change time of the payment account, wherein the attribute change content is changed attribute content, and the attribute change time is effective time of the attribute change content.
For example, if the attribute change content is "procedure rate 0.06%", and the attribute change time is "11/3/2021", the payment account procedure rate should be 0.06% after changing the attribute of the payment account, and the effective time is 2021/11/3/11.
Step S2, obtaining an account version associated with the application and the payment account, and generating a latest account version of the payment account according to the obtained account version, the attribute change content, and the attribute change time.
In this embodiment, all account versions of the payment account bound to the application are stored in advance, all account versions associated with the application and the payment account may be acquired, several or one account version closest to the current time may also be acquired, an account version closest to the current time is further screened from the acquired account versions, then the attribute change content and the attribute change time are added to the screened account versions, and the attribute change time is taken as the creation time of the screened account versions, where the creation time is the validation time.
Step S3, associating and storing the application, the payment account, and the latest account version of the payment account.
At this time, a plurality of incidence relations about the application and the payment account are stored, each incidence relation comprises one account version of the payment account bound with the application, and the purposes of rollback and account checking can be effectively and quickly realized based on the account versions.
As an optional embodiment, before changing the property of the payment account, the payment account and the application need to be bound, a first account version of the first bound payment account is generated, and then the application, the payment account, and the first account version of the payment account are associated and stored. Specifically, the account version includes an account version identification and an account version attribute, and before the step S1, the method further includes a step a1 to a step a4, where:
step A1, receiving an account binding instruction, and binding the application and the payment account;
step A2, acquiring the binding time of the application and the payment account and the account attribute of the payment account;
step A3, creating a first account version identification for the payment account, and using the binding time and the account attribute as a first account version attribute of the payment account;
step A4, associating and storing the application, the payment account, and the first account version identification and the first account version attribute of the payment account;
the binding time is used for representing the creation time of the first account version identification and the first account version attribute of the payment account.
The account version attributes include alterable and non-alterable attributes, the alterable attributes including: procedure rates, teller information, etc., and non-modifiable attributes include: the payment platform (such as WeChat, Paibao, Unionpay and the like) to which the payment account belongs, the unique account identifier of the payment platform, the company body description to which the payment account belongs, and the like. In addition, each account version identification is a derivative of an account change action, and is also not alterable.
As an alternative embodiment:
the step S2 includes steps S21 to S23, in which:
step S21, acquiring account version identification and account version attribute associated with the application and the payment account;
step S22, generating the latest account version identification of the payment account according to the acquired account version identification;
step S23, generating the latest account version attribute of the payment account according to the acquired account version attribute, the attribute change content and the attribute change time;
step S4 includes: and associating and storing the application, the payment account and the latest account version identification and account version attribute of the payment account.
When the account version comprises the account version identification and the account version attribute, the latest account version identification can be generated according to the acquired account version identification, the latest account version attribute is generated according to the acquired account version attribute, and correspondingly, the newly generated association relationship is as follows: application-payment account the latest account version identification and account version attributes.
As shown in fig. 2, after an application is bound with a payment account (e.g., an account number), and the binding time is recorded as creation time, an account attribute during initial binding is a first account version attribute, and a second account version (including an account version identifier and an account version attribute) is generated when the attribute is changed. When the account version attributes need to be indexed, all payment accounts can be indexed according to the application, then the required payment accounts are screened out, all account versions are screened out according to the required payment accounts, and then the corresponding account version attributes are screened out according to the account version identification in each account version.
As an alternative embodiment, step S22 includes step S221 and step S222, wherein:
step S221, screening out the account version identification with the shortest creation time from the obtained account version identifications;
step S222, updating the account version identifier with the shortest creation time according to a preset version creation rule, so as to generate the latest account version identifier of the payment account.
For example, the preset version creation rule is: the data structure of the account version identification is V1.x, and the value of x is sequentially increased when one account version identification is added; if the account version id with the shortest creation time is V1.3, the latest account version id may be V1.4.
For another example, the preset version creation rule is: the data structure of the account version identification is n.y.r-V1.x, the value of x is sequentially increased when an account version identification is added, and n, y and r respectively represent the year, month and day of the creation time; if the account version identifier with the shortest creation time is 2021.01.01-V1.3 and the creation time of the latest account version identifier is 2021, 9 and 3 days, the latest account version identifier may be 2021.09.03-V1.4.
As an alternative embodiment, step S23 includes steps S231 to S233, where:
step S231, screening the account version attribute with the shortest creation time from the acquired account version attributes;
step S232, attribute contents of the same type as the attribute change contents are removed from the account version attributes with the shortest creation time, and the attribute change contents are added to the account version attributes with the shortest creation time;
step S233, removing the attribute content used for representing the creation time from the account version attribute with the shortest creation time, and adding the attribute change time to the account version with the shortest creation time to generate the latest account version attribute of the payment account;
and the attribute change time is used for representing the latest account version identification of the payment account and the creation time of the account version attribute.
For example, if the type of the attribute-changed content is a procedure rate, the existing procedure rate in the account version is removed from the attribute of the account version with the shortest creation time, and the attribute-changed content is added to the account version with the shortest creation time, thereby implementing the operation of changing the procedure rate.
And simultaneously, attribute content used for representing the creation time and stored in the account version attribute is removed from the account version attribute with the shortest creation time, and the attribute change time is added to the account version attribute as new creation time, so that the creation time is updated.
As an alternative embodiment, if the attribute change time is earlier than the current time, it indicates that all payment pipelining generated from the attribute change time as the starting point to the present time is wrong, but the bidder may have provided the wrong payment pipelining to the financial audit, for example, if the current time is 2021, 11, 8 days, the attribute change content is "procedure rate 0.06%", the attribute change time is "2021, 11, 3 days, the payment account procedure rate should be 0.06% after changing the attribute of the payment account, and the payment pipelining generated from 2021, 11, 3 days to 2021, 11, 8 days is wrong after having been validated earlier than the current time. Therefore, a financial staff is required to perform reconciliation, as shown in fig. 3, in the prior art, the financial staff needs to generate the reconciliation detail based on the running manual audit of the static payment, as shown in fig. 4, the account can be automatically rolled back to achieve the purpose of calculating the reconciliation detail in real time through the embodiment. Specifically, after the associating the application, the payment account, and the latest account version identification and account version attribute of the payment account, the method further includes steps B1-B5, where:
step B1, receiving a reconciliation instruction, and determining a target payment streamline attributed to the application;
step B2, acquiring all payment accounts associated with the application, and screening out a first payment account of which the binding time is less than or equal to the transaction time of the target payment flow and is closest to the transaction time from the acquired payment accounts;
step B3 of determining a first set of account version identifications associated with the application and the first payment account, and retrieving account version attributes associated with each of the first set of account version identifications;
step B4, extracting a first account version attribute with the creation time less than or equal to the deal time and the creation time closest to the deal time from the retrieved account version attributes;
and step B5, generating reconciliation information according to the first account version attribute and the target payment pipelining.
The first account version identification set comprises one or more account version identifications, and unique account version attributes can be found through each account version identification. In the reconciliation, the payment account of which the effective time contains the transaction time of the target payment flow is inevitably needed to be used, so that the step of screening out the first payment account of which the binding time is less than or equal to the transaction time of the target payment flow and is closest to the transaction time from the acquired payment accounts is executed, and further, the step of extracting the first account version attribute of which the creation time is less than or equal to the transaction time and is closest to the transaction time from the retrieved account version attribute is inevitably needed to be used. If only one account version attribute exists, the creation time is the binding time, and if a plurality of account version attributes exist, the creation time is the attribute changing time.
After filtering out the correct first account version attribute, step B5 may be: and generating a new payment running water according to the first account version attribute, extracting the payment running water with the transaction time consistent with that of the target payment running water from the new payment running water, and then generating reconciliation information according to the extracted payment running water and the target payment running water.
The reason why the accurate account checking can be realized in the embodiment can be seen in fig. 5, each account version has its own effective time (determined by the creation time of each account version and the creation time of the next account version), and the account version corresponding to the payment pipelining can be determined by the transaction time of the payment pipelining and the effective time of each account version, so that the purpose of accurate account checking is realized based on the determined account version attribute of the account version.
As an alternative embodiment, step B1 includes step B11 and step B12, wherein:
step B11, receiving a reconciliation instruction, and analyzing a starting point of reconciliation time;
and step B12, screening out target payment running water with the transaction time being more than or equal to the starting point of the reconciliation time from all payment running water belonging to the application.
And selecting a time point as a starting point of the reconciliation time, and then screening target payment running water with the transaction time being more than or equal to the starting point of the reconciliation time from the generated payment running water so as to reconcile the target payment running water.
As an optional embodiment, the starting point of the reconciliation time is greater than or equal to the attribute change time, so that it is ensured that the reconciliation information can be completed by the target payment flow of the transaction after the attribute change time, so as to ensure the correctness of the payment flow.
As an optional embodiment, if there is a problem in a new account and it is necessary to roll back to an account before change, it is only necessary to query the association relationship between the application and the payment account and determine the attribute of the account version to which the application needs to roll back according to the creation time, so that the application can be switched back to the historical account version. Specifically, after the associating the application, the payment account, and the latest account version identification and account version attribute of the payment account, the method further includes steps C1-C5, where:
step C1, receiving an account rollback instruction, and analyzing a time point to which rollback is required;
step C2, acquiring all payment accounts associated with the application, and screening out a second payment account from the acquired payment accounts, wherein the binding time is less than or equal to the time point needing to be rolled back, and the binding time is closest to the time point needing to be rolled back;
step C3, determining a second set of account version identifications associated with the application and the second payment account, and querying account version attributes associated with each account version identification in the second set of account version identifications;
step C4, extracting a second account version attribute with the creation time less than or equal to the time point needing to be rolled back and the creation time closest to the time point needing to be rolled back from the inquired account version attributes;
step C5, switching the application from the current account version attribute to the second account version attribute.
The second account version identification set comprises two or more account version identifications, and unique account version attributes can be found through each account version identification. And the step of extracting the second account version attribute with the creation time less than or equal to the time point needing to be rolled back and the creation time closest to the time point needing to be rolled back from the inquired account version attribute is further executed. If only one account version attribute exists, the creation time is the binding time, and if a plurality of account version attributes exist, the creation time is the attribute changing time.
The method provided by the invention is used for the account management function of the payment platform, and has the following advantages: 1. strictly controlling the change of the payment account, and recording the change history of the full life cycle of the payment account; 2. the application can flexibly make forward change, reverse rollback and other operations according to the account version; 3. after the payment account is asynchronously changed on the third-party platform, local account checking information can be conveniently reconstructed, account checking information is generated by real-time calculation according to the matching relation between the transaction time of the payment flow and the account version, and the accuracy of account checking is guaranteed.
Example two
The second embodiment of the present invention provides a payment account management apparatus, which corresponds to the method provided in the first embodiment, and corresponding technical features and technical effects are not described in detail in this embodiment, and reference may be made to the first embodiment for relevant points. Specifically, fig. 6 shows a block diagram of the payment account management apparatus in the second embodiment. As shown in fig. 6, the payment account management apparatus 600 may include a first receiving module 601, a first obtaining module 602, and a first associated storage module 603, wherein:
a first receiving module 601, configured to receive an attribute change instruction, and determine a payment account of an attribute to be changed, attribute change content and attribute change time of the payment account, and an application bound to the payment account;
a first obtaining module 602, configured to obtain an account version associated with the application and the payment account, and generate a latest account version of the payment account according to the obtained account version, the attribute change content, and the attribute change time;
a first association storage module 603, configured to associate and store the application, the payment account, and the latest account version of the payment account.
Optionally, the first obtaining module includes: a first obtaining unit, configured to obtain an account version identifier and an account version attribute associated with the application and the payment account; the first generating unit is used for generating the latest account version identification of the payment account according to the acquired account version identification; the second generation unit is used for generating the latest account version attribute of the payment account according to the acquired account version attribute, the attribute change content and the attribute change time; the first associative storage module is specifically configured to: and associating and storing the application, the payment account and the latest account version identification and account version attribute of the payment account.
Optionally, the first generating unit is specifically configured to: screening the account version identification with the shortest creation time from the obtained account version identifications; and updating the account version identifier with the shortest creation time according to a preset version creation rule to generate the latest account version identifier of the payment account.
Optionally, the second generating unit is specifically configured to: screening the account version attribute with the shortest creation time from the acquired account version attributes; attribute contents of the same type as the attribute change contents are removed from the account version attributes with the shortest creation time, and the attribute change contents are added to the account version attributes with the shortest creation time; attribute content used for representing creation time is removed from the account version attribute with the shortest creation time, and the attribute change time is added to the account version with the shortest creation time to generate the latest account version attribute of the payment account; and the attribute change time is used for representing the latest account version identification of the payment account and the creation time of the account version attribute.
Optionally, the apparatus further comprises: a second receiving module, configured to receive an account binding instruction and bind the application and the payment account before receiving the attribute change instruction, determining a payment account of an attribute to be changed, attribute change content and attribute change time of the payment account, and the application bound to the payment account; the second acquisition module is used for acquiring the binding time of the application and the payment account and the account attribute of the payment account; the creating module is used for creating a first account version identification for the payment account and taking the binding time and the account attribute as a first account version attribute of the payment account; the second association storage module is used for associating and storing the application, the payment account and the first account version identification and the first account version attribute of the payment account; the binding time is used for representing the creation time of the first account version identification and the first account version attribute of the payment account.
Optionally, the apparatus further comprises: a third receiving module, configured to receive a reconciliation instruction and determine a target payment flow attributed to the application after associating and storing the application, the payment account, and the latest account version identifier and account version attribute of the payment account; the first screening module is used for acquiring all the payment accounts associated with the application and screening out a first payment account of which the binding time is less than or equal to the transaction time of the target payment flow and is closest to the transaction time from the acquired payment accounts; a retrieval module to determine a first set of account version identifications associated with the application and the first payment account, and retrieve account version attributes associated with each of the first set of account version identifications; the first extraction module is used for extracting a first account version attribute of which the creation time is less than or equal to the deal time and is closest to the deal time from the retrieved account version attributes; and the generating module is used for generating reconciliation information according to the first account version attribute and the target payment flow.
Optionally, the third receiving module includes: the receiving unit is used for receiving the account checking instruction and analyzing the starting point of the account checking time; and the screening unit is used for screening out the target payment running water with the transaction time being more than or equal to the starting point of the reconciliation time from all the payment running water belonging to the application.
Optionally, the apparatus further comprises: a fourth receiving module, configured to receive an account rollback instruction after the application, the payment account, and the latest account version identifier and account version attribute of the payment account are associated and stored, and analyze a time point to which rollback is required; the second screening module is used for acquiring all the payment accounts associated with the application and screening out a second payment account of which the binding time is less than or equal to the time point needing to be rolled back and is closest to the time point needing to be rolled back from the acquired payment accounts; a query module to determine a second set of account version identifications associated with the application and the second payment account, and to query account version attributes associated with each of the second set of account version identifications; the second extraction module is used for extracting a second account version attribute, the creation time of which is less than or equal to the time point needing to be rolled back and the creation time of which is closest to the time point needing to be rolled back, from the inquired account version attributes; a switching module, configured to switch the application from the current account version attribute to the second account version attribute.
EXAMPLE III
Fig. 7 shows a block diagram of a computer device suitable for implementing the payment account management method according to the third embodiment. In this embodiment, the computer device 700 may be a smart phone, a tablet computer, a notebook computer, a desktop computer, a rack server, a blade server, a tower server, or a rack server (including an independent server or a server cluster composed of a plurality of servers), and the like that execute programs. As shown in fig. 7, the computer device 700 of the present embodiment includes at least but is not limited to: a memory 701, a processor 702, and a network interface 703 that may be communicatively coupled to each other via a system bus. It is noted that FIG. 7 only shows computer device 700 having components 701 and 703, but it is to be understood that not all of the shown components are required and that more or fewer components may alternatively be implemented.
In this embodiment, the memory 703 includes at least one type of computer-readable storage medium, which includes flash memory, a hard disk, a multimedia card, a card-type memory (e.g., SD or DX memory, etc.), a Random Access Memory (RAM), a Static Random Access Memory (SRAM), a Read Only Memory (ROM), an Electrically Erasable Programmable Read Only Memory (EEPROM), a Programmable Read Only Memory (PROM), a magnetic memory, a magnetic disk, an optical disk, and the like. In some embodiments, the storage 701 may be an internal storage unit of the computer device 700, such as a hard disk or a memory of the computer device 700. In other embodiments, the memory 701 may also be an external storage device of the computer device 700, such as a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) Card, a Flash memory Card (Flash Card), or the like, provided on the computer device 700. Of course, the memory 701 can also include both internal and external memory units of the computer device 700. In the present embodiment, the memory 701 is generally used for storing an operating system and various types of application software installed in the computer device 700, such as program codes of a payment account management method and the like.
Processor 702 may be a Central Processing Unit (CPU), controller, microcontroller, microprocessor, or other data Processing chip in some embodiments. The processor 702 generally operates to control the overall operation of the computer device 700. Such as performing controls and processes related to data interaction or communication with computer device 700. In this embodiment, the processor 702 is configured to execute the program code of the payment account management method stored in the memory 701.
In this embodiment, the payment account management method stored in the memory 701 may be further divided into one or more program modules and executed by one or more processors (in this embodiment, the processor 702) to complete the present invention.
The network interface 703 may comprise a wireless network interface or a wired network interface, and the network interface 703 is typically used to establish communication links between the computer device 700 and other computer devices. For example, the network interface 703 is used to connect the computer device 700 to an external terminal via a network, establish a data transmission channel and a communication link between the computer device 700 and the external terminal, and the like. The network may be a wireless or wired network such as an Intranet (Intranet), the Internet (Internet), a Global System of Mobile communication (GSM), Wideband Code Division Multiple Access (WCDMA), a 4G network, a 5G network, Bluetooth (Bluetooth), or Wi-Fi.
Example four
The present embodiments also provide a computer-readable storage medium comprising a flash memory, a hard disk, a multimedia card, a card-type memory (e.g., SD or DX memory, etc.), a Random Access Memory (RAM), a Static Random Access Memory (SRAM), a read-only memory (ROM), an electrically erasable programmable read-only memory (EEPROM), a programmable read-only memory (PROM), a magnetic memory, a magnetic disk, an optical disk, a server, an App, etc., having stored thereon a computer program that, when executed by a processor, performs the steps of the payment account management method.
It will be apparent to those skilled in the art that the modules or steps of the embodiments of the invention described above may be implemented by a general purpose computing device, they may be centralized in a single computing device or distributed across a network of multiple computing devices, and alternatively, they may be implemented by program code executable by a computing device, such that it may be stored in a memory device and executed by a computing device, and in some cases, the steps shown or described may be executed out of order, or separately as individual integrated circuit modules, or multiple modules or steps may be implemented as a single integrated circuit module. Thus, embodiments of the invention are not limited to any specific combination of hardware and software.
It should be noted that the numbers of the embodiments of the present invention are merely for description and do not represent the merits of the embodiments.
Through the above description of the embodiments, those skilled in the art will clearly understand that the method of the above embodiments can be implemented by software plus a necessary general hardware platform, and certainly can also be implemented by hardware, but in many cases, the former is a better implementation manner.
The above description is only a preferred embodiment of the present invention, and not intended to limit the scope of the present invention, and all modifications of equivalent structures and equivalent processes, which are made by using the contents of the present specification and the accompanying drawings, or directly or indirectly applied to other related technical fields, are included in the scope of the present invention.
Claims (10)
1. A payment account management method, the method comprising:
receiving an attribute change instruction, and determining a payment account of an attribute to be changed, attribute change content and attribute change time of the payment account, and an application bound with the payment account;
acquiring account versions associated with the application and the payment account, and generating a latest account version of the payment account according to the acquired account versions, the attribute change content and the attribute change time;
associating and storing the application, the payment account, and the latest account version of the payment account.
2. The method of claim 1,
the obtaining an account version associated with the application and the payment account, and generating a latest account version of the payment account according to the obtained account version, the attribute change content, and the attribute change time includes:
obtaining account version identification and account version attributes associated with the application and the payment account;
generating the latest account version identification of the payment account according to the acquired account version identification;
generating the latest account version attribute of the payment account according to the acquired account version attribute, the attribute change content and the attribute change time;
accordingly, the associating and storing the application, the payment account, and the most recent account version of the payment account includes:
and associating and storing the application, the payment account and the latest account version identification and account version attribute of the payment account.
3. The method of claim 2, wherein the generating the latest account version identifier of the payment account according to the obtained account version identifier comprises:
screening the account version identification with the shortest creation time from the obtained account version identifications;
and updating the account version identifier with the shortest creation time according to a preset version creation rule to generate the latest account version identifier of the payment account.
4. The method of claim 2, wherein the generating the latest account version attribute of the payment account according to the obtained account version attribute, the attribute change content and the attribute change time comprises:
screening the account version attribute with the shortest creation time from the acquired account version attributes;
attribute contents of the same type as the attribute change contents are removed from the account version attributes with the shortest creation time, and the attribute change contents are added to the account version attributes with the shortest creation time;
attribute content used for representing creation time is removed from the account version attribute with the shortest creation time, and the attribute change time is added to the account version with the shortest creation time to generate the latest account version attribute of the payment account;
and the attribute change time is used for representing the latest account version identification of the payment account and the creation time of the account version attribute.
5. The method of claim 2, wherein before the receiving the property change instruction, determining the payment account of the property to be changed, the property change content and property change time of the payment account, and the application bound to the payment account, the method further comprises:
receiving an account binding instruction, and binding the application and the payment account;
acquiring the binding time of the application and the payment account and the account attribute of the payment account;
creating a first account version identification for the payment account, and using the binding time and the account attribute as a first account version attribute of the payment account;
associating and storing the application, the payment account, and a first account version identification and a first account version attribute of the payment account;
the binding time is used for representing the creation time of the first account version identification and the first account version attribute of the payment account.
6. The method of claim 5, wherein after associating and storing the application, the payment account, and the most recent account version identification and account version attribute of the payment account, the method further comprises:
receiving a reconciliation instruction, and determining a target payment flow line belonging to the application;
acquiring all payment accounts associated with the application, and screening out a first payment account of which the binding time is less than or equal to the transaction time of the target payment flow and is closest to the transaction time from the acquired payment accounts;
determining a first set of account version identifications associated with the application and the first payment account, and retrieving account version attributes associated with each account version identification in the first set of account version identifications;
extracting a first account version attribute with the creation time less than or equal to the deal time and the creation time closest to the deal time from the retrieved account version attributes;
and generating reconciliation information according to the first account version attribute and the target payment flow.
7. The method of claim 6, wherein receiving a reconciliation instruction to determine a target payment pipeline attributed to the application comprises:
receiving a reconciliation instruction, and analyzing a reconciliation time starting point;
and screening out target payment running water with the transaction time being more than or equal to the starting point of the reconciliation time from all the payment running water belonging to the application.
8. The method of claim 5, wherein after associating and storing the application, the payment account, and the most recent account version identification and account version attribute of the payment account, the method further comprises:
receiving an account rollback instruction, and analyzing a time point to which the account rollback is required;
acquiring all payment accounts associated with the application, and screening out a second payment account of which the binding time is less than or equal to the time point needing to be rolled back and the binding time is closest to the time point needing to be rolled back from the acquired payment accounts;
determining a second set of account versioning associated with the application and the second payment account and querying account versioning attributes associated with each of the second set of account versioning;
extracting a second account version attribute with the creation time less than or equal to the time point needing to be rolled back and the creation time closest to the time point needing to be rolled back from the inquired account version attributes;
switching the application from a current account version attribute to the second account version attribute.
9. A payment account management apparatus, the apparatus comprising:
the system comprises a first receiving module, a second receiving module and a third receiving module, wherein the first receiving module is used for receiving an attribute change instruction, determining a payment account of an attribute to be changed, attribute change content and attribute change time of the payment account and an application bound with the payment account;
the first acquisition module is used for acquiring the account version associated with the application and the payment account and generating the latest account version of the payment account according to the acquired account version, the attribute change content and the attribute change time;
the first association storage module is used for associating and storing the application, the payment account and the latest account version of the payment account.
10. A computer-readable storage medium, on which a computer program is stored, which, when being executed by a processor, carries out the method of any one of claims 1 to 8.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210138525.6A CN114511314A (en) | 2022-02-15 | 2022-02-15 | Payment account management method and device, computer equipment and storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210138525.6A CN114511314A (en) | 2022-02-15 | 2022-02-15 | Payment account management method and device, computer equipment and storage medium |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN114511314A true CN114511314A (en) | 2022-05-17 |
Family
ID=81551324
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202210138525.6A Pending CN114511314A (en) | 2022-02-15 | 2022-02-15 | Payment account management method and device, computer equipment and storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN114511314A (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2024015423A1 (en) * | 2022-07-12 | 2024-01-18 | Akamai Technologies, Inc. | Real-time detection of online new-account creation fraud using graph-based neural network modeling |
-
2022
- 2022-02-15 CN CN202210138525.6A patent/CN114511314A/en active Pending
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2024015423A1 (en) * | 2022-07-12 | 2024-01-18 | Akamai Technologies, Inc. | Real-time detection of online new-account creation fraud using graph-based neural network modeling |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111221726A (en) | Test data generation method and device, storage medium and intelligent equipment | |
| CN110751550B (en) | Account checking method and device, computer equipment and storage medium | |
| CN110209650A (en) | The regular moving method of data, device, computer equipment and storage medium | |
| CN111192144A (en) | Financial data prediction method, device, equipment and storage medium | |
| CN110503564A (en) | Save case processing method, system, equipment and storage medium from damage based on big data | |
| CN112785411A (en) | Credit investigation data processing method, system, equipment and computer readable storage medium | |
| CN107329966B (en) | Machine data storage method and system | |
| KR101737578B1 (en) | Method and device for automatically tuning for sql sentences generated automatically | |
| CN111143434A (en) | Intelligent data checking method, device, equipment and storage medium | |
| CN114511314A (en) | Payment account management method and device, computer equipment and storage medium | |
| CN113626527A (en) | Financial data processing method and system | |
| CN110781235A (en) | Big data based purchase data processing method and device, terminal and storage medium | |
| CN109324963B (en) | Method for automatically testing profit result and terminal equipment | |
| CN116227454A (en) | Universal automatic report generation method and system | |
| CN110175899A (en) | A kind of method, apparatus, computer equipment and readable storage medium storing program for executing for checking invoice | |
| CN112270537B (en) | Multi-channel bill storage method, system and storage medium | |
| CN115168217A (en) | Defect discovery method and device for source code file | |
| CN112632266B (en) | Data writing method and device, computer equipment and readable storage medium | |
| KR101737575B1 (en) | Method and device for verifying data based on sql sentences generated automatically | |
| CN109584061A (en) | Information generating method, device, computer equipment and storage medium | |
| CN112347095B (en) | Data table processing method, device and server | |
| CN111382187B (en) | Data extraction method and device | |
| US11875374B2 (en) | Automated auditing and recommendation systems and methods | |
| CN113095686A (en) | Multi-standard-section cost adjusting method and device for power engineering | |
| CN117472985A (en) | Accounting method, device, equipment and medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |