CN113762966A - Merchant information verification method, device, equipment and storage medium - Google Patents

Merchant information verification method, device, equipment and storage medium Download PDF

Info

Publication number
CN113762966A
CN113762966A CN202010505193.1A CN202010505193A CN113762966A CN 113762966 A CN113762966 A CN 113762966A CN 202010505193 A CN202010505193 A CN 202010505193A CN 113762966 A CN113762966 A CN 113762966A
Authority
CN
China
Prior art keywords
merchant
transaction
information
target
merchant information
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202010505193.1A
Other languages
Chinese (zh)
Inventor
李智年
黄铮
王斌
朱钦
徐金凯
肖然
陈婉
吕斌
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
NetsUnion Clearing Corp
Original Assignee
NetsUnion Clearing Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by NetsUnion Clearing Corp filed Critical NetsUnion Clearing Corp
Priority to CN202010505193.1A priority Critical patent/CN113762966A/en
Publication of CN113762966A publication Critical patent/CN113762966A/en
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401Transaction verification
    • G06Q20/4016Transaction verification involving fraud or risk level assessment in transaction processing
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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
    • G06Q30/00Commerce
    • G06Q30/06Buying, selling or leasing transactions
    • G06Q30/0601Electronic shopping [e-shopping]
    • G06Q30/0609Buyer or seller confidence or verification

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

The application provides a merchant information verification method, a merchant information verification device, merchant information verification equipment and a storage medium, wherein the method comprises the following steps: receiving a merchant provision request of a target merchant sent by an acceptance mechanism, wherein the merchant provision request carries target merchant information of the target merchant; responding to the merchant preparation request, generating a target merchant code of the target merchant according to a preset generation strategy, and feeding back a preparation completion message carrying the target merchant code to the acceptance mechanism; and verifying the target merchant information according to a preset verification strategy, and generating and storing a transaction risk label corresponding to the merchant code according to a verification result so as to perform risk control on the payment transaction corresponding to the target merchant according to the transaction risk label. Therefore, high-concurrency merchant provision can be realized, and merchant provision processing efficiency is improved.

Description

Merchant information verification method, device, equipment and storage medium
Technical Field
The present application relates to the field of internet technologies, and in particular, to a method, an apparatus, a device, and a storage medium for verifying merchant information.
Background
The clearing institution is responsible for receiving and processing the merchant preparation request, clearing and clearing the transaction funds, and plays roles of transaction intermediate transfer and fund clearing in the network payment service.
At present, the merchant preparation process consumes long time and has low auditing efficiency, and the requirement of high-concurrency merchant preparation cannot be met.
Disclosure of Invention
The present application is directed to solving, at least to some extent, one of the technical problems in the related art.
Therefore, the application provides a merchant information verification method, a merchant information verification device, merchant information verification equipment and a storage medium.
An embodiment of a first aspect of the present application provides a merchant information verification method, including:
receiving a merchant provision request of a target merchant sent by an acceptance mechanism, wherein the merchant provision request carries target merchant information of the target merchant;
responding to the merchant provision request, generating a target merchant code of the target merchant according to a preset generation strategy, and feeding back a provision completion message carrying the target merchant code to the acceptance mechanism;
and verifying the target merchant information according to a preset verification strategy, and generating and storing a transaction risk label corresponding to the merchant code according to a verification result so as to perform risk control on the payment transaction corresponding to the target merchant according to the transaction risk label.
An embodiment of a second aspect of the present application provides a payment processing method, including:
acquiring a transaction request from an acceptance mechanism, wherein the transaction request carries a current merchant code and transaction information of a target merchant;
acquiring a current transaction risk label corresponding to the current merchant code, wherein the transaction risk label is determined after a clearing mechanism verifies merchant information of the target merchant according to a preset verification strategy, and the merchant information is sent to the clearing mechanism by the acceptance mechanism through a merchant preparation request;
determining a transaction condition corresponding to the transaction risk label, and judging whether the transaction information meets the transaction condition;
and when the transaction information does not meet the transaction condition, feeding back transaction failure information to an acceptance mechanism.
An embodiment of a third aspect of the present application provides a merchant information verification device, including:
the system comprises a receiving module, a processing module and a processing module, wherein the receiving module is used for receiving a merchant preparation request of a target merchant sent by an acceptance mechanism, and the merchant preparation request carries target merchant information of the target merchant;
the coding module is used for responding to the merchant preparation request, generating a target merchant code of the target merchant according to a preset generation strategy and feeding back a preparation completion message carrying the target merchant code to the acceptance mechanism;
and the generating module is used for verifying the target merchant information according to a preset verification strategy and generating and storing a transaction risk label corresponding to the merchant code according to a verification result so as to perform risk control on the payment transaction corresponding to the target merchant according to the transaction risk label.
An embodiment of a fourth aspect of the present application provides a payment processing apparatus, including:
the system comprises a request module, a transaction processing module and a processing module, wherein the request module is used for acquiring a transaction request from an acceptance mechanism, and the transaction request carries a current merchant code and transaction information of a target merchant;
the acquisition module is used for acquiring a current transaction risk label corresponding to the current merchant code, wherein the transaction risk label is determined after a clearing mechanism verifies merchant information of the target merchant according to a preset verification strategy, and the merchant information is sent to the clearing mechanism by the acceptance mechanism through a merchant provision request;
the judging module is used for determining the transaction condition corresponding to the transaction risk label and judging whether the transaction information meets the transaction condition;
and the processing module is used for feeding back transaction failure information to an acceptance mechanism when the transaction information does not meet the transaction condition.
An embodiment of a fifth aspect of the present application provides a computer device, including a processor and a memory; the processor executes a program corresponding to the executable program code by reading the executable program code stored in the memory, so as to implement the merchant information verification method according to the embodiment of the first aspect.
An embodiment of a sixth aspect of the present application provides a computer device, comprising a processor and a memory; wherein the processor executes a program corresponding to the executable program code by reading the executable program code stored in the memory, so as to implement the payment processing method according to the embodiment of the second aspect.
An embodiment of a seventh aspect of the present application provides a computer-readable storage medium, on which a computer program is stored, where the computer program, when executed by a processor, implements the merchant information verification method according to the embodiment of the first aspect.
An eighth aspect of the present application provides a computer-readable storage medium, on which a computer program is stored, which when executed by a processor, implements the payment processing method according to the second aspect.
One embodiment in the above application has the following advantages or benefits: the clearing mechanism receives a merchant preparation request of a target merchant sent by the acceptance mechanism, responds to the merchant preparation request, generates a target merchant code of the target merchant according to a preset generation strategy, and feeds back a preparation completion message carrying the target merchant code to the acceptance mechanism; and verifying the target merchant information in the merchant provision request according to a preset verification strategy, and generating and storing a transaction risk label corresponding to the merchant code according to a verification result so as to perform risk control on the payment transaction corresponding to the target merchant according to the transaction risk label. Therefore, the transaction risk label is generated through merchant information verification, and risk control is conveniently performed on the payment transaction corresponding to the target merchant according to the transaction risk label. And the clearing mechanism feeds back the merchant codes to the acceptance mechanism and asynchronously realizes the merchant information verification, thereby realizing high-concurrency merchant provision and improving the merchant provision processing efficiency.
Additional aspects and advantages of the present application will be set forth in part in the description which follows and, in part, will be obvious from the description, or may be learned by practice of the present application.
Drawings
Fig. 1 is a schematic flowchart of a merchant information verification method according to an embodiment of the present disclosure;
fig. 2 is a schematic flow chart of a merchant preparation link in the merchant information verification method according to the embodiment of the present application;
fig. 3 is a schematic flow chart illustrating a step of generating a transaction risk label in the merchant information verification method according to the embodiment of the present application;
fig. 4 is another schematic flow chart illustrating a process of generating a transaction risk label in a merchant information verification method according to an embodiment of the present disclosure;
fig. 5 is a schematic flowchart of a payment processing method according to an embodiment of the present application;
fig. 6 is a schematic structural diagram of a merchant information verification apparatus according to an embodiment of the present application.
Detailed Description
Reference will now be made in detail to embodiments of the present application, examples of which are illustrated in the accompanying drawings, wherein like or similar reference numerals refer to the same or similar elements or elements having the same or similar function throughout. The embodiments described below with reference to the drawings are exemplary and intended to be used for explaining the present application and should not be construed as limiting the present application.
The merchant information verification method, device and equipment according to the embodiments of the present application are described below with reference to the accompanying drawings.
Fig. 1 is a schematic flow chart of a merchant information verification method provided in an embodiment of the present application, and as shown in fig. 1, the method includes:
step 101, receiving a merchant provision request of a target merchant sent by an acceptance mechanism.
The merchant information verification method of the embodiment of the application can be applied to clearing institutions. In this embodiment, the acceptance mechanism obtains target merchant information of the target merchant, and sends a merchant provision request of the target merchant to the clearing mechanism, where the target merchant may be a merchant currently performing provision, and the merchant provision request carries the target merchant information of the target merchant.
Step 103, responding to the merchant provision request, generating a target merchant code of the target merchant according to a preset generation strategy, and feeding back a provision completion message carrying the target merchant code to the acceptance mechanism.
In this embodiment, after receiving the merchant provision request, the clearing mechanism generates a target merchant code corresponding to the target merchant, and returns the target merchant code to the acceptance mechanism, so that the acceptance mechanism can perform subsequent services in time according to the target merchant code. Optionally, the clearing institution feeds back, to the acceptance institution, an offer completion message carrying the target merchant code, where the offer completion message is, for example, "completed".
As a possible implementation manner, the clearing structure verifies the target merchant information, and if the verification is passed, the merchant code corresponding to the target merchant is generated, wherein the manner of verifying the merchant provision information includes verifying whether the request parameter is transmitted according to the interface standard, and the like, and the stability is improved by the verification.
The generating of the target merchant code of the target merchant according to the preset generating strategy comprises the following steps: and acquiring a merchant code rule of the acceptance mechanism for the target merchant, and generating the target merchant code according to the merchant code rule. The merchant code rule is used for determining the code of the target merchant in the acceptance mechanism, and the merchant code comprises the mechanism code of the acceptance mechanism, the code of the target merchant in the acceptance mechanism and a check bit. As an example, the acceptance organization sends the code of the target merchant in the acceptance organization to the clearing organization, the clearing organization queries for the financial institution code of the acceptance organization and generates the check digit, and the clearing organization generates the target merchant code according to the financial institution code of the acceptance organization, the code of the target merchant in the acceptance organization and the check digit.
At present, a clearing institution acquires a national regional code, merchant industry classification information and generates a merchant code scheme, and a business system of an acceptance institution needs to be greatly changed to map or use the merchant code generated by the clearing institution. In the scheme of the application, the merchant code generated by the clearing mechanism comprises the merchant code of the acceptance mechanism, and other service fields are not additionally arranged, so that the merchant code of the acceptance mechanism can be well compatible, and the acceptance mechanism can develop subsequent services according to the merchant code without great change.
And 105, checking the target merchant information according to a preset checking strategy, and generating and storing a transaction risk label corresponding to the merchant code according to a checking result so as to perform risk control on the payment transaction corresponding to the target merchant according to the transaction risk label.
In this embodiment, after receiving the merchant provision request, the clearing institution verifies the target merchant information and generates a transaction risk label according to a verification result, and then stores the transaction risk label. The transaction risk label is used for carrying out risk control on the payment transaction corresponding to the target merchant.
The target merchant information includes, for example, a merchant name, a registered registration certificate number, a legal representative name, a legal representative certificate number, registered capital, an establishment date, an operation range, and the like.
In the related technology, a clearing institution performs a merchant information auditing process in stages aiming at merchant information auditing, performs the next stage after one stage of auditing is completed, and determines that the merchant information auditing is failed if one stage of auditing is failed, and ends the auditing. And when the auditing of all stages is successful, determining that the merchant information auditing is successful, and further generating a merchant code for the merchant. After the acceptance mechanism initiates the merchant provision, the acceptance mechanism needs to wait for the clearing mechanism to return the merchant code, and then follow-up business is carried out according to the merchant code returned by the clearing mechanism.
According to the merchant information verification method, a clearing mechanism receives a merchant provision request of a target merchant sent by an acceptance mechanism, responds to the merchant provision request, generates a target merchant code of the target merchant according to a preset generation strategy, and feeds back a provision completion message carrying the target merchant code to the acceptance mechanism; and verifying the target merchant information in the merchant provision request according to a preset verification strategy, and generating and storing a transaction risk label corresponding to the merchant code according to a verification result so as to perform risk control on the payment transaction corresponding to the target merchant according to the transaction risk label. Therefore, the transaction risk label is generated through merchant information verification, and risk control is conveniently performed on the payment transaction corresponding to the target merchant according to the transaction risk label. And the clearing mechanism feeds back the merchant codes to the acceptance mechanism and asynchronously realizes the merchant information verification, thereby realizing high-concurrency merchant provision and improving the merchant provision processing efficiency.
Based on the above embodiments, the following describes the merchant information verification method according to the embodiments of the present application in combination with an actual application scenario reported by the merchant.
Fig. 2 is a schematic flow chart of a merchant preparation link in the merchant information verification method according to the embodiment of the present application.
Referring to fig. 2, the acceptance agency transmits merchant provision information to the clearing agency. The acceptance mechanism includes member mechanisms for providing services such as acceptance of various payment modes and settlement of funds for merchants, for example, the acceptance mechanism includes: the payment system comprises a banking financial institution engaged in the bill receiving business, a payment institution acquiring the bill receiving business permission, providing account acceptance for entity merchants and completing fund settlement service, a payment institution acquiring the network payment business permission, providing account acceptance for the network merchants and completing the fund settlement service, a payment institution acquiring the prepaid card issuing and acceptance business permission and a payment institution acquiring the prepaid card acceptance business permission.
And the clearing mechanism receives the merchant provision information, synchronously verifies the merchant provision information, generates a merchant code for the merchant if the verification is passed, and synchronously returns the merchant code and the provision result to the acceptance mechanism. Wherein, the merchant code comprises: the financial institution code of the acceptance institution, the code of the merchant in the acceptance institution and the check bit, and the preparation result is, for example, "completed".
And the clearing mechanism checks the merchant provision information and generates different kinds of labels for the merchants according to the checking result. Specifically, 1) the clearing mechanism automatically identifies the image information of the merchant through the system, if the system identification fails, manual identification is carried out, and if the manual identification fails, a marking sub-process of the next stage is entered. If the system/manual identification is successful, comparing the merchant image information obtained by identification with the merchant information reported by the acceptance mechanism, marking the merchant according to the comparison result, and entering a marking sub-process of the next stage. 2) And the clearing institution calls an external authoritative data source to verify the key elements of the commercial tenant, marks the commercial tenant according to the verification result and enters the marking process of the next stage. 3) And the clearing mechanism compares whether the merchant information returned by the authoritative data source is matched with the merchant image information in a manual or system judgment mode, and marks the merchant according to the comparison result. Therefore, different types of transaction risk labels can be generated for the merchants, high-concurrency merchant provision is realized, and merchant provision processing efficiency is improved.
Based on the foregoing embodiment, in the foregoing embodiment, the step 105 verifies the target merchant information according to the preset verification policy, and generates and stores the transaction risk label corresponding to the merchant code according to the verification result, which can be implemented in various ways, and the following describes an implementation manner of generating the transaction risk label in the merchant information verification method with reference to fig. 3 and 4.
Fig. 3 is a schematic flow chart of a link of generating a transaction risk label in the merchant information verification method according to the embodiment of the present application, where the link includes:
step 201, obtaining pre-stored legal merchant information corresponding to each merchant information in the multiple merchant information, and respectively matching each merchant information with the corresponding pre-stored legal merchant information.
In this embodiment, the target merchant information includes a plurality of merchant information, and the plurality of merchant information includes merchant image information, merchant key elements, and merchant business information. The pre-stored legal merchant information is used for matching with the merchant information, the pre-stored legal merchant information can comprise authenticated merchant information, and when the target merchant information is checked, the pre-stored legal merchant information corresponding to the merchant information is respectively obtained for each type of merchant information, for example, the merchant information is a legal representative name A, and the corresponding pre-stored legal merchant information is a legal representative name A'.
As an example, the clearinghouse obtains merchant image information of the target merchant, and the clearinghouse identifies the merchant image information to obtain merchant information, so as to match the merchant information obtained according to the identification with the target merchant information, for example, compare whether the obtained merchant information is consistent with corresponding information in the target merchant information. The merchant image information includes, but is not limited to, a scanning component such as a license, legal certificate, and the like.
As another example, a database is preset, and the preset database stores the corresponding relationship between the merchant and the merchant key element, for example, an external authoritative data source may be invoked to obtain the corresponding relationship between the merchant and the merchant key element. In this example, the clearinghouse queries a preset database, and matches the merchant key elements in the target merchant information with the merchant key elements of each merchant in the database. The key elements of the merchant can comprise the name of the merchant, registration certificate number, legal representative name, legal representative certificate number and the like.
As another example, the preset database further stores business information of each business, and in this example, image recognition may be performed on business image information such as a business license and a legal certificate in the foregoing steps to obtain the first business information. And then, second business operation information of the target business is obtained and returned from the database, and whether the first business operation information is consistent with the second business operation information is compared. The business information of the merchant includes, for example, registered capital, established date, operating range, and the like.
It should be noted that, the above-mentioned manner for verifying the target merchant information according to the preset verification policy is only an example, and is not limited specifically here.
Step 203, determining the first merchant information which is successfully matched and the second merchant information which is unsuccessfully matched according to the matching result, and counting a first quantity of the first merchant information and a second quantity of the second merchant information.
Optionally, if the merchant information matches with the pre-stored legal merchant information in a consistent manner, it is determined that the matching is successful, otherwise, the matching is considered to be failed, and further, a first quantity of the first merchant information that is successfully matched and a second quantity of the second merchant information that is failed to be matched are counted.
Step 205, determining a transaction risk score corresponding to the target merchant according to the first quantity and the second quantity.
In this embodiment, the transaction risk score of the target merchant is determined according to the first quantity and the second quantity, and optionally, the transaction risk score is determined according to a difference between the first quantity and the second quantity, and the lower the first quantity and the higher the second quantity, the lower the transaction risk score.
In one embodiment of the present application, different merchant information may correspond to different weights, for example, merchant name, registered certificate number, business scope, etc. correspond to different weights.
As a possible implementation manner, a first transaction weight of each first merchant information in the first merchant information and a second transaction weight of each second merchant information in the second merchant information are obtained, and the transaction risk score is determined according to the sum of the first transaction weights and the sum of the second transaction weights. Optionally, the transaction risk score is the sum of the first transaction weights-the sum of the second transaction weights.
As an example, the merchant information includes an operating range, a registered and registered certificate number, registered capital, and a merchant name, where the first merchant information includes the operating range and the registered and registered certificate number, and the corresponding first transaction weights are 1 and 5, respectively, and the second merchant information includes the registered capital and the merchant name, and the corresponding second transaction weights are 2 and 2, respectively. The sum of the first trading weights is 6, the sum of the second weights is 4, and the trading risk score is 2.
Step 207, determining a transaction risk label according to the transaction risk score.
In this embodiment, a transaction risk label corresponding to the target merchant is generated according to the transaction risk score of the target merchant, so as to perform risk control on the payment transaction of the target merchant according to the transaction risk label. The corresponding relationship between the transaction risk score and the transaction risk label can be set according to needs, for example, the transaction risk score is 1-10, the corresponding transaction risk label is high, the transaction risk score is 11-20, and the corresponding transaction risk label is low.
Fig. 4 is another schematic flow chart of a link of generating a transaction risk label in a merchant information verification method according to an embodiment of the present application, where the link includes:
step 301, obtaining pre-stored legal merchant information corresponding to each merchant information in the multiple merchant information, respectively matching each merchant information with the corresponding pre-stored legal merchant information, and obtaining a matching result of each merchant information.
Step 303, determining transaction risk labels respectively corresponding to the matching result of each merchant information.
In this embodiment, the target merchant information includes a plurality of merchant information, and the plurality of merchant information includes merchant image information, merchant key elements, and merchant business information. The foregoing description of pre-storing the legal merchant information is also applicable to the present embodiment, and is not repeated herein.
In this embodiment, after the matching result of each merchant information is obtained, the preset relationship may be queried according to the matching result, so as to obtain the transaction risk labels corresponding to the matching result of each merchant information. The preset relationship includes a mapping relationship between a matching result of the merchant information and the transaction risk label, and the preset relationship may be set as required, for example, if the matching result of the merchant information is that the registered and registered certificate numbers are inconsistent, the registered capital is consistent, and the operating range is inconsistent, the transaction risk label includes 1004, 1005, and 1008, and if the matching result of the merchant information is that the registered and registered certificate numbers are consistent, the registered capital is consistent, and the operating range is inconsistent, the transaction risk label includes 1003, 1005, and 1008.
As an example, the clearing mechanism obtains merchant image information of the target merchant, and identifies the merchant image information to obtain merchant information, so as to verify the target merchant information according to the merchant information obtained by identification.
In this example, the merchant image information includes, but is not limited to, a license and a legal certificate. And for each merchant information obtained by identification, comparing whether the identified merchant information is consistent with the target merchant information, and generating a plurality of corresponding transaction risk labels according to the matching result. For example, if the matching result is matched, a mark 1001 is generated, and if the matching result is not matched, a mark 1002 is generated. Optionally, if the identification fails, for example, the merchant image of the target merchant is not identified, the current merchant image marking process is ended.
As another example, a database is preset, and the preset database stores the corresponding relationship between the merchant and the merchant key element, for example, an external authoritative data source may be invoked to obtain the corresponding relationship between the merchant and the merchant key element. In this example, the clearinghouse queries a preset database, and matches the merchant key elements in the target merchant information with the merchant key elements of each merchant in the database, thereby generating a transaction risk label.
The key elements of the merchant comprise a merchant name, a registration certificate number, a legal representative name, a legal representative certificate number and the like.
As still another example, the preset database further stores business information of each merchant, and further, in the case that it is determined that the target merchant exists in the database, the database sends the merchant business information of the target merchant to the clearing institution. In this example, image recognition may be performed on the merchant image information such as the business license and the legal certificate in the foregoing steps, so as to obtain the first merchant business information. And then, second merchant business information of the target merchant returned by the database is obtained, whether the first merchant business information is consistent with the second merchant business information or not is compared, and a transaction risk label is generated according to a matching result.
The business information of the merchant includes, for example, registered capital, established date, operating range, and the like.
According to the merchant information verification method, each type of merchant information is matched with corresponding pre-stored legal merchant information respectively, the matching result of each type of merchant information is obtained, the transaction risk label of the target merchant is generated according to the matching result, different types of transaction risk labels can be generated for the target merchant, and risk control is conducted on payment transaction of the target merchant according to the transaction risk labels. And a plurality of marking processes can be executed in parallel, high-concurrency merchant provision is realized, and merchant provision processing efficiency is improved.
Based on the foregoing embodiment, after verifying the target merchant information according to a preset verification policy and generating and storing the transaction risk label corresponding to the merchant code according to the verification result, the merchant information verification method of this embodiment may further include: and carrying out risk control on the payment transaction corresponding to the target merchant according to the generated transaction risk label.
In this embodiment, performing risk control on the payment transaction corresponding to the target merchant according to the generated transaction risk label may include the following steps:
the method comprises the following steps: the clearing mechanism acquires a transaction request sent by the acceptance mechanism, wherein the transaction request carries the current merchant code and the transaction information.
The transaction request carries a current merchant code and transaction information, the transaction information includes one or more of transaction amount and transaction type, the transaction type includes, for example, transfer, payment and the like, and the current merchant code refers to a merchant code of a merchant currently requesting the transaction. The acceptance mechanism may be a first acceptance mechanism for performing merchant provisioning on the merchant, or may be a second acceptance mechanism that is authorized by the first acceptance mechanism and obtains the current merchant code, which is not limited herein.
Step two: and acquiring a transaction risk label corresponding to the current merchant code, determining a transaction condition corresponding to the transaction risk label, and judging whether the transaction information meets the transaction condition.
In this embodiment, each merchant code corresponds to one merchant, and the transaction risk label of the corresponding merchant may be determined according to the current merchant code. And further, judging whether the transaction information meets the transaction condition according to the transaction condition corresponding to the transaction risk label.
The transaction condition includes, for example, a transaction upper limit amount, such as an amount value of the allowed transaction, a legal transaction type, such as a transaction type of the allowed transaction, and the like. Optionally, different transaction risk tags correspond to different transaction conditions, for example, different transaction risk tags correspond to different transaction upper limit amounts.
Step three: when the transaction information meets the transaction condition, executing the transaction request; and when the transaction information does not meet the transaction conditions, feeding back transaction failure information to the acceptance mechanism.
As an example, taking the case that the transaction information includes the transaction amount, if the transaction amount is less than or equal to the transaction upper limit amount, determining that the transaction condition is met, and executing the transaction request; and if the transaction amount is larger than the transaction upper limit amount, determining that the transaction condition is not met, and feeding back transaction failure information to the acceptance mechanism.
There are various ways to implement the feedback of the transaction failure information, for example, when the transaction information does not satisfy the transaction condition, executing a risk control operation and feeding back the transaction failure information. The risk control operation includes but is not limited to intercepting the transaction, limiting the transaction amount, and the like, and the transaction failure information can be set as required, for example, the transaction failure information includes "transaction condition is not satisfied, transaction failure" and the like.
The merchant information verification method provided by the embodiment of the application can be used for carrying out risk control in payment transaction based on the transaction risk label, and the payment safety is improved.
Based on the above embodiment, further, after receiving the merchant provision request and generating the transaction risk label, the clearing institution may perform risk control on the payment transaction according to the transaction risk label, may also obtain the transaction risk label of the merchant in the payment scenario, directly perform risk control on the payment transaction according to the transaction risk label, and then explain the risk control on the payment transaction directly according to the transaction risk label.
Fig. 5 is a schematic flowchart of a payment processing method according to an embodiment of the present application, and as shown in fig. 5, the method includes:
at step 401, a transaction request from an acceptance institution is obtained.
In this embodiment, when the merchant makes a payment, the merchant initiates a transaction request to the clearinghouse through the acceptance mechanism, and the clearinghouse receives the transaction request from the acceptance mechanism. The accepting mechanism may be a first accepting mechanism for performing merchant provisioning on the merchant, or may be a second accepting mechanism that is authorized by the first accepting mechanism and obtains the current merchant code, which is not limited herein.
The transaction request carries a current merchant code and transaction information, the transaction information comprises one or more of transaction amount and transaction type, and the current merchant code refers to a merchant code corresponding to a merchant requesting transaction currently.
Step 403, obtaining a transaction risk label corresponding to the current merchant code.
The transaction risk label is determined by the clearing mechanism after the merchant information of the target merchant is verified according to the preset verification strategy, the merchant information is sent to the clearing mechanism by the acceptance mechanism through the merchant provision request, and it should be noted that the explanation of determining the transaction risk label after the merchant information of the target merchant is verified according to the preset verification strategy in the foregoing embodiment is also applicable to this embodiment.
In this embodiment, after receiving the transaction request, the clearing institution acquires the transaction risk label corresponding to the current merchant code. Optionally, the transaction risk labels include low, medium, high. Optionally, the transaction risk label may also include 1001, 1002, 1003, 1004, and the like.
Step 405, determining the transaction condition corresponding to the transaction risk label, and judging whether the transaction information meets the transaction condition.
In this embodiment, the transaction condition may include a transaction upper limit amount, such as an amount value of the allowed transaction, a legal transaction type, such as a transaction type of the allowed transaction, and the like. Optionally, different transaction risk tags correspond to different transaction conditions, for example, different transaction risk tags correspond to different transaction upper limit amounts.
As a possible implementation manner, when the transaction information includes the transaction amount, the clearinghouse determines the transaction upper limit amount corresponding to the transaction risk label, and determines whether the transaction amount is less than or equal to the transaction upper limit amount. If the transaction amount is less than or equal to the transaction upper limit amount, determining that the transaction information meets the transaction condition; and if the transaction amount is larger than the transaction upper limit amount, determining that the transaction information does not meet the transaction condition.
As another possible implementation manner, the transaction type includes, for example, transfer, collection, and the like, and when the transaction information includes the transaction type, the clearinghouse determines a legal transaction type corresponding to the transaction risk tag, and determines whether the transaction type belongs to the legal transaction type. If the transaction type belongs to a legal transaction type, determining that the transaction information meets transaction conditions; and if the transaction type does not belong to the legal transaction type, determining that the transaction information does not meet the transaction condition.
As another possible implementation manner, the transaction information includes a transaction amount and a transaction type, a transaction upper limit amount and a legal transaction type corresponding to the transaction risk tag are determined, whether the transaction type belongs to the legal transaction type is judged, if the transaction type belongs to the legal transaction type, whether a difference between the transaction amount and the transaction upper limit amount is smaller than a preset threshold value is judged, and if the transaction type does not belong to the legal transaction type, whether the transaction amount is smaller than the preset transaction threshold value is judged. If the transaction type belongs to a legal transaction type and the difference value between the transaction amount and the transaction upper limit amount is smaller than a preset threshold value, determining that the transaction information meets transaction conditions; or if the transaction type does not belong to the legal transaction type and the transaction amount is smaller than the preset transaction threshold value, determining that the transaction information meets the transaction condition; otherwise, determining that the transaction information does not meet the transaction condition.
And step 407, feeding back transaction failure information when the transaction information does not meet the transaction conditions.
In this embodiment, when the transaction information does not satisfy the transaction condition, the risk control operation is executed, and the transaction failure information is fed back. Wherein the risk control operation includes, but is not limited to, intercepting the transaction, limiting the transaction amount, and the like.
In one embodiment of the application, when the transaction information meets the transaction condition, the transaction is allowed to be carried out, and the transaction request is executed.
The payment processing method of the embodiment of the application realizes risk control in the payment transaction based on the transaction risk label, and improves the payment safety.
In order to implement the above embodiment, the present application further provides a merchant information verification device.
Fig. 6 is a schematic structural diagram of a merchant information verification apparatus according to an embodiment of the present application, and as shown in fig. 6, the apparatus includes: the device comprises a receiving module 10, an encoding module 20 and a generating module 30.
The receiving module 10 is configured to receive a merchant provision request of a target merchant sent by an acceptance mechanism, where the merchant provision request carries target merchant information of the target merchant.
The coding module 20 is configured to respond to the merchant provision request, generate a target merchant code of the target merchant according to a preset generation policy, and feed back a provision completion message carrying the target merchant code to the acceptance mechanism.
The generating module 30 is configured to verify the target merchant information according to a preset verification policy, and generate and store a transaction risk label corresponding to the merchant code according to a verification result, so as to perform risk control on the payment transaction corresponding to the target merchant according to the transaction risk label.
Optionally, the encoding module 20 is specifically configured to: acquiring a merchant coding rule of the acceptance mechanism for the target merchant; and generating the target merchant code according to the merchant code rule.
Optionally, the target merchant information includes a plurality of merchant information, and the generating module 30 includes: the matching unit is used for acquiring prestored legal merchant information corresponding to each merchant information in the multiple merchant information and respectively matching each merchant information with the corresponding prestored legal merchant information; the statistical unit is used for determining first merchant information which is successfully matched and second merchant information which is unsuccessfully matched according to the matching result, and counting a first quantity of the first merchant information and a second quantity of the second merchant information; the calculating unit is used for determining the transaction risk score corresponding to the target merchant according to the first quantity and the second quantity; and the determining unit is used for determining the transaction risk label according to the transaction risk score.
Optionally, the computing unit is specifically configured to: and acquiring a first transaction weight of each first merchant information in the first merchant information and a second transaction weight of each second merchant information in the second merchant information, and determining the transaction risk score according to the sum of the first transaction weights and the sum of the second transaction weights.
Optionally, the target merchant information includes a plurality of merchant information, and the generating module 30 is specifically configured to: obtaining pre-stored legal merchant information corresponding to each merchant information in the multiple merchant information, respectively matching each merchant information with the corresponding pre-stored legal merchant information, and obtaining a matching result of each merchant information; and determining transaction risk labels respectively corresponding to the matching result of each type of merchant information.
Optionally, the apparatus further comprises: the control module is used for acquiring a transaction request sent by the acceptance mechanism, wherein the transaction request carries a current merchant code and transaction information; acquiring a current transaction risk label corresponding to the current merchant code; determining a transaction condition corresponding to the transaction risk label, and judging whether the transaction information meets the transaction condition; and executing the transaction request when the transaction information meets the transaction condition.
Optionally, the apparatus further comprises: and the feedback module is used for feeding back transaction failure information to the acceptance mechanism when the transaction information does not meet the transaction condition.
The explanation of the merchant information verification method in the foregoing embodiment is also applicable to the merchant information verification apparatus in this embodiment, and is not described herein again.
According to the merchant information verification device in the embodiment of the application, a clearing mechanism receives a merchant provision request of a target merchant sent by an acceptance mechanism, responds to the merchant provision request, generates a target merchant code of the target merchant according to a preset generation strategy, and feeds back a provision completion message carrying the target merchant code to the acceptance mechanism; and verifying the target merchant information in the merchant provision request according to a preset verification strategy, and generating and storing a transaction risk label corresponding to the merchant code according to a verification result so as to perform risk control on the payment transaction corresponding to the target merchant according to the transaction risk label. Therefore, the transaction risk label is generated through merchant information verification, and risk control is conveniently performed on the payment transaction corresponding to the target merchant according to the transaction risk label. And the clearing mechanism feeds back the merchant codes to the acceptance mechanism and asynchronously realizes the merchant information verification, thereby realizing high-concurrency merchant provision and improving the merchant provision processing efficiency.
In order to implement the foregoing embodiment, the present application further provides a payment processing apparatus, including: the device comprises a request module, an acquisition module, a judgment module and a processing module.
The request module is used for acquiring a transaction request from an acceptance mechanism, wherein the transaction request carries a current merchant code and transaction information.
And the acquisition module is used for acquiring a current transaction risk label corresponding to the current merchant code, wherein the transaction risk label is determined after a clearing mechanism verifies merchant information of the target merchant according to a preset verification strategy, and the merchant information is sent to the clearing mechanism by the acceptance mechanism through a merchant provision request.
And the judging module is used for determining the transaction condition corresponding to the transaction risk label and judging whether the transaction information meets the transaction condition.
And the processing module is used for feeding back transaction failure information to an acceptance mechanism when the transaction information does not meet the transaction condition.
Optionally, the apparatus further comprises: and the payment module is used for executing the transaction request when the transaction information meets the transaction condition.
Optionally, when the transaction information includes a transaction amount, the determining module is specifically configured to: determining a transaction upper limit amount corresponding to the transaction risk label; and judging whether the transaction amount is less than or equal to the transaction upper limit amount.
Optionally, when the transaction information includes a transaction type, the determining module is specifically configured to: determining a legal transaction type corresponding to the transaction risk label; and judging whether the transaction type belongs to the legal transaction type.
Optionally, when the transaction information includes a transaction type and the transaction amount, the determining module is specifically configured to: determining a transaction upper limit amount and a legal transaction type corresponding to the transaction risk label; judging whether the transaction type belongs to the legal transaction type; if the transaction type belongs to the legal transaction type, judging whether the difference value between the transaction amount and the transaction upper limit amount is smaller than a preset threshold value; and if the transaction type does not belong to the legal transaction type, judging whether the transaction amount is smaller than a preset transaction threshold value.
The explanation of the payment processing method in the foregoing embodiment is also applicable to the payment processing apparatus in this embodiment, and is not described here again.
The payment processing device of the embodiment of the application realizes risk control in payment transaction based on the transaction risk label, and improves payment safety.
In order to implement the above embodiments, the present application also provides a computer device, including a processor and a memory; wherein, the processor runs the program corresponding to the executable program code by reading the executable program code stored in the memory, so as to implement the merchant information verification method according to any one of the foregoing embodiments.
In order to implement the above embodiments, the present application also provides a computer device, including a processor and a memory; wherein the processor executes a program corresponding to the executable program code by reading the executable program code stored in the memory, for implementing the payment processing method as described in any one of the foregoing embodiments.
In order to implement the foregoing embodiments, the present application further proposes a computer-readable storage medium, on which a computer program is stored, which when executed by a processor implements the merchant information verification method according to any one of the foregoing embodiments.
In order to implement the above embodiments, the present application also proposes a computer-readable storage medium having stored thereon a computer program which, when executed by a processor, implements a payment processing method as described in any of the preceding embodiments.
In the description of the present specification, the terms "first", "second" are used for descriptive purposes only and are not to be construed as indicating or implying relative importance or implying any number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one such feature. In the description of the present application, "plurality" means at least two, e.g., two, three, etc., unless specifically limited otherwise.
Although embodiments of the present application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present application, and that variations, modifications, substitutions and alterations may be made to the above embodiments by those of ordinary skill in the art within the scope of the present application.

Claims (18)

1. A merchant information verification method performed by a clearinghouse, comprising:
receiving a merchant provision request of a target merchant sent by an acceptance mechanism, wherein the merchant provision request carries target merchant information of the target merchant;
responding to the merchant preparation request, generating a target merchant code of the target merchant according to a preset generation strategy, and feeding back the target merchant code to the acceptance mechanism;
and verifying the target merchant information according to a preset verification strategy, and determining a transaction risk label corresponding to the target merchant code according to a verification result so as to perform risk control on the payment transaction corresponding to the target merchant according to the transaction risk label.
2. The method of claim 1, wherein the generating the target merchant code of the target merchant according to the preset generation strategy comprises:
acquiring a merchant coding rule of the acceptance mechanism corresponding to the target merchant;
and generating the target merchant code according to the merchant code rule.
3. The method as claimed in claim 1, wherein the target merchant information includes a plurality of merchant information, the verifying the target merchant information according to a preset verifying policy, and generating and storing a transaction risk label corresponding to the merchant code according to a verifying result, includes:
obtaining pre-stored legal merchant information corresponding to each merchant information in the plurality of merchant information;
matching each merchant information with the corresponding pre-stored legal merchant information respectively, and determining first merchant information which is successfully matched and second merchant information which is unsuccessfully matched according to a matching result;
counting a first quantity of the first merchant information and a second quantity of the second merchant information, and determining a transaction risk score corresponding to the target merchant according to the first quantity and the second quantity;
determining the transaction risk label according to the transaction risk score.
4. The method of claim 3, wherein the counting a first amount of the first merchant information and a second amount of the second merchant information, and determining a transaction risk score corresponding to the target merchant based on the first amount and the second amount comprises:
acquiring a first transaction weight of each first merchant information in the first merchant information and a second transaction weight of each second merchant information in the second merchant information, wherein the transaction weights correspond to the types of the merchant information;
determining the transaction risk score according to the sum of the first transaction weights and the sum of the second transaction weights.
5. The method as claimed in claim 1, wherein the target merchant information includes a plurality of merchant information, the verifying the target merchant information according to a preset verifying policy, and generating and storing a transaction risk label corresponding to the merchant code according to a verifying result includes:
obtaining pre-stored legal merchant information corresponding to each merchant information in the plurality of merchant information;
matching each type of merchant information with corresponding pre-stored legal merchant information respectively to obtain a matching result of each type of merchant information;
and determining transaction risk labels respectively corresponding to the matching result of each type of merchant information.
6. The method as claimed in any one of claims 3-5, wherein the plurality of merchant information includes at least two of merchant image information, merchant key elements and merchant business information.
7. The method of claim 1, wherein the risk controlling the payment transaction corresponding to the target merchant according to the transaction risk label comprises:
acquiring a transaction request sent by an acceptance mechanism, wherein the transaction request carries a current merchant code and transaction information;
acquiring a current transaction risk label corresponding to the current merchant code;
determining a transaction condition corresponding to the transaction risk label, and judging whether the transaction information meets the transaction condition;
and executing the transaction request when the transaction information meets the transaction condition.
8. The method of claim 7, further comprising:
and when the transaction information does not meet the transaction condition, feeding back transaction failure information to the acceptance mechanism.
9. A payment processing method, comprising:
acquiring a transaction request from an acceptance mechanism, wherein the transaction request carries a current merchant code and transaction information of a target merchant;
acquiring a current transaction risk label corresponding to the current merchant code, wherein the transaction risk label is determined after a clearing mechanism verifies merchant information of the target merchant according to a preset verification strategy, and the merchant information is sent to the clearing mechanism by the acceptance mechanism through a merchant preparation request;
determining a transaction condition corresponding to the transaction risk label, and judging whether the transaction information meets the transaction condition;
and when the transaction information does not meet the transaction condition, feeding back transaction failure information to an acceptance mechanism.
10. The method of claim 9, wherein after said determining whether the transaction information satisfies the transaction condition, further comprising:
and executing the transaction request when the transaction information meets the transaction condition.
11. The method of claim 9 or 10, wherein when the transaction information includes a transaction amount, the determining a transaction condition corresponding to the transaction risk label, determining whether the transaction information satisfies the transaction condition, comprises:
determining a transaction upper limit amount corresponding to the transaction risk label;
and judging whether the transaction amount is less than or equal to the transaction upper limit amount.
12. The method of claim 9 or 10, wherein when the transaction information includes a transaction type, the determining a transaction condition corresponding to the transaction risk label, determining whether the transaction information satisfies the transaction condition, comprises:
determining a legal transaction type corresponding to the transaction risk label;
and judging whether the transaction type belongs to the legal transaction type.
13. A merchant information verification apparatus, comprising:
the system comprises a receiving module, a processing module and a processing module, wherein the receiving module is used for receiving a merchant preparation request of a target merchant sent by an acceptance mechanism, and the merchant preparation request carries target merchant information of the target merchant;
the coding module is used for responding to the merchant preparation request, generating a target merchant code of the target merchant according to a preset generation strategy and feeding back a preparation completion message carrying the target merchant code to the acceptance mechanism;
and the generating module is used for verifying the target merchant information according to a preset verification strategy and generating and storing a transaction risk label corresponding to the merchant code according to a verification result so as to perform risk control on the payment transaction corresponding to the target merchant according to the transaction risk label.
14. A payment processing apparatus, comprising:
the system comprises a request module, a transaction processing module and a processing module, wherein the request module is used for acquiring a transaction request from an acceptance mechanism, and the transaction request carries a current merchant code and transaction information of a target merchant;
the acquisition module is used for acquiring a current transaction risk label corresponding to the current merchant code, wherein the transaction risk label is determined after a clearing mechanism verifies merchant information of the target merchant according to a preset verification strategy, and the merchant information is sent to the clearing mechanism by the acceptance mechanism through a merchant provision request;
the judging module is used for determining the transaction condition corresponding to the transaction risk label and judging whether the transaction information meets the transaction condition;
and the processing module is used for feeding back transaction failure information to an acceptance mechanism when the transaction information does not meet the transaction condition.
15. A computer device, comprising:
memory, processor and computer program stored on the memory and executable on the processor, characterized in that the processor implements the merchant information verification method as claimed in any one of claims 1 to 8 when executing the program.
16. A computer device, comprising:
memory, processor and computer program stored on the memory and executable on the processor, characterized in that the processor, when executing the program, implements a payment processing method according to any one of claims 9-12.
17. A computer-readable storage medium on which a computer program is stored, wherein the program, when executed by a processor, implements the merchant information verification method as defined in any one of claims 1 to 8.
18. A computer-readable storage medium, on which a computer program is stored, wherein the program, when executed by a processor, implements a payment processing method as claimed in any one of claims 9-12.
CN202010505193.1A 2020-06-05 2020-06-05 Merchant information verification method, device, equipment and storage medium Pending CN113762966A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202010505193.1A CN113762966A (en) 2020-06-05 2020-06-05 Merchant information verification method, device, equipment and storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010505193.1A CN113762966A (en) 2020-06-05 2020-06-05 Merchant information verification method, device, equipment and storage medium

Publications (1)

Publication Number Publication Date
CN113762966A true CN113762966A (en) 2021-12-07

Family

ID=78784955

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010505193.1A Pending CN113762966A (en) 2020-06-05 2020-06-05 Merchant information verification method, device, equipment and storage medium

Country Status (1)

Country Link
CN (1) CN113762966A (en)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109389457A (en) * 2018-08-20 2019-02-26 深圳壹账通智能科技有限公司 Method of network entry, device, equipment and the readable storage medium storing program for executing of application gathering permission
CN109409900A (en) * 2018-01-26 2019-03-01 深圳市买买提信息科技有限公司 A kind of trade company's checking method and server
CN109784934A (en) * 2019-03-14 2019-05-21 浙江鲸腾网络科技有限公司 A kind of transaction risk control method, apparatus and relevant device and medium
CN109829776A (en) * 2018-12-14 2019-05-31 平安科技(深圳)有限公司 Trade company's methods of risk assessment, device, computer equipment and storage medium
CN110148000A (en) * 2019-04-17 2019-08-20 阿里巴巴集团控股有限公司 A kind of security management and control system and method applied to payment platform
CN111062619A (en) * 2019-12-18 2020-04-24 支付宝(杭州)信息技术有限公司 Merchant identification method and device, electronic equipment and storage medium

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109409900A (en) * 2018-01-26 2019-03-01 深圳市买买提信息科技有限公司 A kind of trade company's checking method and server
CN109389457A (en) * 2018-08-20 2019-02-26 深圳壹账通智能科技有限公司 Method of network entry, device, equipment and the readable storage medium storing program for executing of application gathering permission
CN109829776A (en) * 2018-12-14 2019-05-31 平安科技(深圳)有限公司 Trade company's methods of risk assessment, device, computer equipment and storage medium
CN109784934A (en) * 2019-03-14 2019-05-21 浙江鲸腾网络科技有限公司 A kind of transaction risk control method, apparatus and relevant device and medium
CN110148000A (en) * 2019-04-17 2019-08-20 阿里巴巴集团控股有限公司 A kind of security management and control system and method applied to payment platform
CN111062619A (en) * 2019-12-18 2020-04-24 支付宝(杭州)信息技术有限公司 Merchant identification method and device, electronic equipment and storage medium

Similar Documents

Publication Publication Date Title
US7337953B2 (en) Negotiable instrument authentication systems and methods
US6327577B1 (en) Electronic bill payment system with account-number scheming
US7490063B2 (en) Remittance payment processing with account scheming and/or validation
US8271392B2 (en) Methods and systems for managing merchant screening
US20070174208A1 (en) System and Method for Global Automated Address Verification
US20070174164A1 (en) Network/Processor Fraud Scoring for Card Not Present Transactions
CN109034818B (en) Method and device for generating payment mark and method and device for verifying payment mark
CN103714625B (en) A kind of charging intelligent card method and system
CA2583402A1 (en) System and method for authenticating a rf transaction using a radio frequency identification device including a transactions counter
US20240154969A1 (en) Pre-authorization access request screening
CN108133415B (en) Electronic credential reimbursement method, device and system
US20070299775A1 (en) Systems and methods for associating a second source of funds with an electronic check transaction
US20190114633A1 (en) Computer system and computer-implemented method for processing payment card transactions
US11023895B2 (en) Automated review system for transactions
CN113065939A (en) Unattended financial bill reimbursement method, unattended financial bill reimbursement system, electronic equipment and storage medium
US20200195644A1 (en) System for data set translation of accounts
CN109978542B (en) Accounts payable data management method, system, storage medium and electronic device
CN115952220A (en) Bill processing method and device based on block chain, electronic equipment and medium
CN105931035A (en) Payment mark generation method and device
US20050209964A1 (en) Method of Providing Secure Payment and Transaction Reconciliation
US10210512B2 (en) Transaction count synchronization in payment system
CN117196520A (en) Vendor management method, vendor management system, computer device and storage medium
CN113762966A (en) Merchant information verification method, device, equipment and storage medium
CN112613967B (en) Business transaction data processing method and device, computer equipment and storage medium
US20180047019A1 (en) Method of retaining transaction context

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
REG Reference to a national code

Ref country code: HK

Ref legal event code: DE

Ref document number: 40058681

Country of ref document: HK