A secure payment control method, device and equipment of an enterprise

Abstract

This application provides a secure payment control method, apparatus, and equipment for enterprises, relating to the field of enterprise secure payment technology. The method includes: acquiring historical consumption sequences of enterprise employees and target consumption requests sent by enterprise employees that have passed business approval; determining a target payment strategy based on the historical consumption sequences and target consumption requests; generating a target virtual payment tool according to the target payment strategy and target consumption requests; wherein the target virtual payment tool includes fund control rules bound to the target consumption request; responding to a payment request initiated by an enterprise employee based on the target virtual payment tool, performing payment verification on the payment request and the target virtual payment tool according to the fund control rules and the target consumption request; and controlling the target virtual payment tool to complete the payment when the payment request passes the payment verification. This application achieves a secure payment closed loop in scenarios involving sporadic enterprise expenditures, eliminating the need for advance funding, enabling automatic reconciliation, and providing real-time risk control.

Description

Technical Field

[0001] This application relates to the field of enterprise secure payment technology, and more specifically, to an enterprise secure payment control method, device, and equipment. Background Technology

[0002] In existing corporate payment systems, for non-procurement-related miscellaneous expenditures (such as SaaS subscriptions, cloud resource top-ups, and travel expenses), traditional physical credit cards, general corporate cards, or employee reserve funds are typically relied upon. These traditional methods suffer from significant lag and rigidity: physical cards have long application and issuance cycles, failing to meet the immediate payment needs of sudden business emergencies; while reserve funds result in large amounts of corporate funds being tied up, accompanied by the pain point of employees having to advance funds. More importantly, existing payment tools are often disconnected from specific business scenarios, making it difficult for finance departments to accurately intervene in fund flows before payments, leading to persistent risks of misappropriation and overspending. Summary of the Invention

[0003] The purpose of this application is to provide a secure payment control method, device, and equipment for enterprises, which solves the above-mentioned problems existing in the prior art and realizes a secure payment closed loop that does not require advance payment, automatically reconciles accounts, and conducts real-time risk control in the case of sporadic expenditures of enterprises.

[0004] Firstly, a secure payment control method for enterprises is provided, which may include: Obtain the historical consumption sequence of enterprise employees and the target consumption requests sent by the enterprise employees that have passed business approval; Based on the historical consumption sequence and the target consumption request, a target payment strategy is determined; A target virtual payment tool is generated based on the target payment strategy and the target consumption request; wherein, the target virtual payment tool includes fund control rules bound to the target consumption request; In response to a payment request initiated by an employee based on the target virtual payment tool, the payment request and the target virtual payment tool are verified according to the fund control rules and the target consumption request; When the payment request passes the payment verification, the target virtual payment tool is controlled to complete the payment.

[0005] In an optional implementation, the target consumption request includes: consumption scenario, expected consumption amount, expected consumption time, budget allocation, and business information; The target virtual payment tool also includes: payment credentials and audit metadata.

[0006] In an optional implementation, determining the target payment strategy based on the historical consumption sequence and the target consumption request includes: From the comparison table of different consumption scenarios and different candidate payment strategies, match multiple target candidate payment strategies corresponding to the consumption scenario; The historical consumption sequence is input into a pre-trained compliance probability prediction model to obtain the predicted compliance probability and predicted anomaly index of the enterprise's employees. If the predicted compliance probability is greater than the configured compliance probability threshold, then obtain the configuration parameters of each target candidate payment strategy and historical payment data within the past preset time period. Based on the expected consumption time, the predicted anomaly index, the configuration parameters, and the historical payment data, the target weight of each target candidate payment strategy is determined. Based on the target weights of each target candidate payment strategy, a target payment strategy is selected from multiple target candidate payment strategies.

[0007] In an optional implementation, the configuration parameters include: policy priority, constraint coefficient, and effective time period; Based on the expected consumption time, the predicted anomaly index, the configuration parameters, and the historical payment data, the target weights of each target candidate payment strategy are determined, including: For any target candidate payment strategy, the timeliness factor of the target candidate payment strategy is determined based on the expected consumption time and the effective time period; Based on the historical payment data, the success rate of the target candidate payment strategy within a preset time period is calculated to obtain the success rate factor of the target candidate payment strategy. Based on the predicted anomaly index and the constraint coefficient, the behavioral factors of the target candidate payment strategy are determined; The target weight of the target candidate payment strategy is determined based on the strategy priority, the timeliness factor, the success rate factor, and the behavior factor.

[0008] In an optional implementation, a target virtual payment tool is generated based on the target payment strategy and the target consumption request, including: Based on the configuration parameters of the target payment strategy, the expected consumption amount, and the expected consumption time, generate a fund management rule instance; Control the API to generate payment credentials for the target virtual payment tool; Based on the budget allocation and business information, generate audit metadata; By associating the fund control rule instance, the audit metadata, and the payment voucher, a target virtual payment tool is obtained.

[0009] In an optional implementation, the payment request includes payment request time, payment amount, payee information, and merchant type; Based on the fund control rules and the target consumption request, payment verification is performed on the payment request and the target virtual payment tool, including: Verify whether the payment request time falls within the effective period of the target virtual payment tool; Verify whether the request status of the target consumption request is "approved" at the time of the payment request; Verify whether the payee information and merchant type meet the consumption scenario and the business information; Verify that the payment amount is not greater than the sum of the expected consumption amount and the configured tolerance amount; Verify whether the payment request time, payment amount, payee information, and merchant type meet the fund control rule instance.

[0010] In an optional implementation, after controlling the target virtual payment tool to complete the payment, the method further includes: Upon receiving payment information, the company sends an invoice upload notification to its employees. The system receives invoices uploaded by the company's employees and verifies the payment information, the invoices, and the target consumption request.

[0011] Secondly, a secure payment control device for an enterprise is provided, the device including: The acquisition unit is used to acquire the historical consumption sequence of enterprise employees and the target consumption requests sent by the enterprise employees that have passed business approval; The determining unit is configured to determine a target payment strategy based on the historical consumption sequence and the target consumption request; A generation unit is configured to generate a target virtual payment tool based on the target payment strategy and the target consumption request; wherein the target virtual payment tool includes fund control rules bound to the target consumption request; The verification unit is used to respond to a payment request initiated by an enterprise employee based on the target virtual payment tool, and to perform payment verification on the payment request and the target virtual payment tool according to the fund control rules and the target consumption request; The control unit is used to control the target virtual payment tool to complete the payment when the payment request passes the payment verification.

[0012] Thirdly, an electronic device is provided, which includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; When a processor executes a program stored in memory, it implements any of the steps described in the first aspect above.

[0013] Fourthly, a computer-readable storage medium is provided, wherein a computer program is stored therein, and when executed by a processor, the computer program implements the steps of any of the methods described in the first aspect above.

[0014] This application dynamically determines the target payment strategy bound to specific consumption scenarios by integrating employees' historical consumption sequences with real-time approved consumption requests, and generates a target virtual payment tool with attached fund control rules. This allows each small corporate expenditure to complete personalized and automated compliance and risk control constraints before payment. During the payment process, the payment request and the virtual payment tool itself are double-verified based on the bound fund control rules and the original consumption request, effectively preventing risks such as exceeding limits, theft, and cross-scenario violations. At the same time, the entire process does not require employees to advance funds or manual reconciliation, significantly shortening the payment cycle, reducing financial audit costs, and achieving a secure closed loop from approval to payment to automatic accounting. Attached Figure Description

[0015] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 An architecture diagram of a secure payment control system for an enterprise provided in this application embodiment; Figure 2 A flowchart illustrating a secure payment control method for an enterprise, provided as an embodiment of this application; Figure 3 A schematic diagram of a secure payment control device for an enterprise provided in this application embodiment; Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0017] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application. Unless otherwise defined, the technical or scientific terms used in this application should have the ordinary meaning understood by those skilled in the art. The words "first," "second," and similar terms used in this application do not indicate any order, quantity, or importance, but are only used to distinguish different components. The words "comprising" or "including," etc., mean that the element or object preceding the word covers the element or object listed after the word and its equivalents, but do not exclude other elements or objects. The words "connected," "coupled," or "connected," etc., are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect. "Up," "down," "left," "right," etc., are only used to indicate relative positional relationships. When the absolute position of the described object changes, the relative positional relationship may also change accordingly.

[0018] The secure payment control method for enterprises provided in this application embodiment can be applied to... Figure 1 In the system architecture shown, such as Figure 1 As shown, the system may include: a server in the enterprise's backend and terminals for enterprise employees. The server can be a physical server, a server cluster composed of multiple physical servers, or a distributed system. It can also be a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms. The terminal may be a user equipment (UE) such as a mobile phone, smartphone, laptop, digital radio receiver, personal digital assistant (PDA), tablet computer (PAD), handheld device, in-vehicle device, wearable device, computing device, or other processing device connected to a wireless modem, mobile station (MS), mobile terminal, etc. The terminal and server can be directly or indirectly connected via wired or wireless communication methods; this application does not limit the connection.

[0019] The preferred embodiments of this application are described below with reference to the accompanying drawings. It should be understood that the preferred embodiments described herein are for illustration and explanation only and are not intended to limit this application. Furthermore, the embodiments and features in the embodiments of this application can be combined with each other without conflict.

[0020] Figure 2 This is a flowchart illustrating a secure payment control method for an enterprise, as provided in an embodiment of this application. Figure 2 As shown, the method may include: Step S210: Obtain the historical consumption sequence of enterprise employees and the target consumption requests sent by enterprise employees that have passed business approval.

[0021] The target consumption request includes: consumption scenario, expected consumption amount, expected consumption time, budget allocation, and business information. Consumption scenarios may include: business travel, business entertainment, office supplies procurement, marketing promotion, employee benefits, software / SaaS subscriptions, service fees, production material procurement, transportation, and meetings and training. Budget allocation indicates the department responsible for the expected consumption amount. Business information may include: consumption purpose, project name or project code, department information, employee information, application number, and budget item. The historical consumption sequence can be the historical consumption records of any employee in the past preset time period, which can be the past 90 days. Historical consumption records may include: time, amount, merchant MCC, payment strategy, review result, compliance status, abnormality status, and rejection status.

[0022] In practice, employees submit consumption requests in advance through their employee terminals and obtain the request status through business approval. The request status can be approved, not approved, withdrawn, or invalidated.

[0023] In another embodiment of this application, upon receiving a target consumption request sent by an employee that has passed business approval, the departmental budget of the employee's department is frozen from the company's cash pool.

[0024] In another embodiment of this application, after receiving a consumption request submitted by an employee, the consumption request is verified to be compliant according to the configured request verification rules. Specifically, this may include: verifying whether the department budget of the employee's department in the company's fund pool is greater than the expected consumption amount; verifying whether the employee's job level corresponds to the consumption scenario; and verifying whether the business information conforms to the configured business rules.

[0025] Step S220: Determine the target payment strategy based on historical consumption sequences and target consumption requests.

[0026] In practice, multiple target candidate payment strategies are matched to different consumption scenarios from a table of different candidate payment strategies. Each candidate payment strategy is pre-configured with parameters such as the MCC whitelist (allowed merchant category codes), single transaction limit, cumulative limit, effective time window, cross-border mode, and usage mode. The cross-border mode can include cross-border and non-cross-border options, indicating whether the payment strategy supports cross-border payments. The usage mode can include one-time use and recurring use. For example, when the consumption scenario is business travel, the MCC whitelist can include: airlines, hotels, and railways; when the consumption scenario is advertising, the MCC whitelist can include: Facebook, Google, and TikTok; when the consumption scenario is SaaS, the MCC whitelist can include: AWS, Adobe, and Slack; candidate payment strategies can include: one-time purchase strategy, limited to 1 transaction, valid for 24 hours, limit = application amount + 10% (to reserve for exchange rate fluctuations or taxes), applicable to purchasing equipment and booking airline tickets; subscription strategy, limited to 1 transaction per month, single transaction limit = monthly fee, valid for 1 year, applicable to software subscriptions; reserve fund strategy, limited to all merchants (or only blocking high-risk industries), total limit = fixed value, automatic recharge when the balance is insufficient or reapplication is required; The historical consumption sequence is input into a pre-trained compliance probability prediction model to obtain the predicted compliance probability and predicted anomaly index of the enterprise's employees. The compliance probability prediction model can be an LSTM time series prediction model. The predicted compliance probability is used to characterize the probability of the employee's approval when executing any candidate payment strategy. The predicted anomaly index is used to characterize the degree to which this consumption may trigger an anomaly alarm. If the predicted compliance probability is greater than the configured compliance probability threshold, then the configuration parameters of each target candidate payment strategy and historical payment data within a preset time period are obtained. The configuration parameters include: strategy priority, constraint coefficient, effective time period, MCC whitelist (allowed merchant category codes), single transaction limit, cumulative limit, effective time period, cross-border mode, and usage mode. The constraint coefficient characterizes the constraint strength of the target candidate payment strategy; the stricter the MCC whitelist, the lower the limit, and the more stringent other configuration parameters, the smaller the constraint coefficient. The compliance probability threshold can be 0.7. Specifically, when the predicted compliance probability is not greater than the configured compliance probability threshold, the target consumption request and historical consumption sequence are submitted to the employee's department head and the finance department for manual review. The preset time period can be the past 30 days. Based on the expected consumption time, predicted anomaly index, configuration parameters, and historical payment data, the target weights of each candidate payment strategy are determined. Specifically, for any candidate payment strategy, a timeliness factor is determined based on the expected consumption time and the effective period. If the expected consumption time is within the effective period, the timeliness factor is 0; if the expected consumption time is less than 24 hours from the end of the effective period, the timeliness factor is 10; if it has expired, the candidate payment strategy is removed. Based on historical payment data, the success rate of the candidate payment strategy within the past preset time period is calculated to obtain the success rate factor. The success rate within the past preset time period is the ratio of the number of successful payments within the past preset time period to the total number of uses. Based on the predicted anomaly index and constraint coefficient, a behavioral factor is determined for the candidate payment strategy. The behavioral factor is calculated as 100 * (1 - predicted anomaly index * constraint coefficient). Based on the strategy priority, timeliness factor, success rate factor, and behavioral factor, the target weights of the candidate payment strategies are determined. Specifically, the sum of the priority factor corresponding to the strategy priority, the timeliness factor, the success rate factor, and the behavioral factor is used to determine the target weight. Based on the target weights of each target candidate payment strategy, a target payment strategy is selected from multiple target candidate payment strategies. Specifically, a roulette wheel algorithm is used to randomly select a strategy according to the proportion of the target weight. At the same time, a strategy is randomly selected uniformly from all candidate strategies with a preset probability. The selected strategy is the target payment strategy.

[0027] Step S230: Generate a target virtual payment tool based on the target payment strategy and the target consumption request.

[0028] The target virtual payment tool includes fund control rules, payment credentials, and audit metadata bound to the target consumption request. The virtual payment tool may include: a New Virtual Card (New VCN), which generates a new PAN (card number) by calling the issuing bank's API. Its advantage is the highest security; merchant data leakage will not affect other businesses. Its disadvantage is the large number of cards if there are many merchants. A Shadow Card or Alias ​​Card, which generates multiple tokens or aliases based on a single physical primary card. A Quota Slice, which does not issue new cards but creates a logical sub-wallet in a corporate payment account (such as an Alipay corporate account), allocates a specific quota, and generates a unique payment link or QR code. Payment credentials may include: a 16-digit card number, CVV, and expiration date.

[0029] In practice, based on the configuration parameters of the target payment strategy, as well as the expected consumption amount and expected consumption time, a fund control rule instance is generated; the virtual payment tool generation API is controlled to generate payment vouchers for the target virtual payment tool; audit metadata is generated based on budget allocation and business information; and the fund control rule instance, audit metadata, and payment vouchers are associated to obtain the target virtual payment tool.

[0030] Step S240: In response to a payment request initiated by an employee based on the target virtual payment tool, perform payment verification on the payment request and the target virtual payment tool according to the fund control rules and the target consumption request.

[0031] The payment request includes the payment request time, payment amount, payee information, merchant type, and the country and region where the merchant is located. In practice, it is verified whether the payment request time falls within the effective period of the target virtual payment tool; when the payment request time falls within the effective period of the target virtual payment tool, it indicates that the target virtual payment tool is in an Active state. Verify whether the target consumption request has been approved at the time of the payment request; if it has not been approved, has been withdrawn, or has been invalidated, this verification fails. Verify whether the payee information and merchant type meet the consumption scenario and business information; specifically, obtain multiple merchant types corresponding to the consumption scenario; verify whether the payee information and merchant type are consistent with the merchant type corresponding to the consumption scenario, and whether the consumption purpose in the business information corresponds to the payee information and merchant type; if they are consistent and correspond, then pass this verification. Verify that the payment amount is not greater than the sum of the expected consumption amount and the configured tolerance amount; Example of verifying whether the payment request time, payment amount, payee information, and merchant type meet the fund control rules; The payment verification passes if and only if all of the above verifications pass.

[0032] In another embodiment of this application, the method may further include: if it is a subscription card, whether the payment has already been deducted this month to prevent the merchant from being charged repeatedly; if the country or region where the merchant is located in the payment request is different from the country or region where the enterprise is located, then verify whether the cross-border permission setting in the configuration parameters of the target virtual payment tool is enabled; when the usage mode in the configuration parameters of the target virtual payment tool is one-time use, verify whether the number of uses of the target virtual payment tool is 0; if it is 0, then this verification is passed.

[0033] In yet another embodiment of this application, the method may further include: Obtain the device fingerprints, IP addresses, geographical locations, operation times, and payment frequencies of the company's employees; Risk scores are calculated based on the company's employees' device fingerprints, IP addresses, geographical locations, operation times, and payment frequencies. Specifically, a predefined risk rule model (or a lightweight machine learning model) is used to score device fingerprints, IP addresses, geographical locations, operation times, and payment frequencies, and the scores are weighted and summed to obtain the risk score. The risk threshold is then adjusted based on the employee's historical behavior: Dynamic risk threshold = Configured base risk threshold × (1 + 0.5) ),in, This indicates the predicted anomaly index; if the risk score is less than the risk threshold, the risk verification passes; otherwise, it is rejected.

[0034] Step S250: When the payment request passes the payment verification, control the target virtual payment tool to complete the payment.

[0035] In practice, the payment amount is temporarily frozen (pre-authorized) to prevent over-use during payment processing; the pending_amount of the virtual tool is increased by the payment amount to ensure that the limit is not exceeded under concurrent payment requests; and the payment request is submitted to the bank / payment channel to complete the actual deduction.

[0036] In another embodiment of this application, the method may further include: Upon receiving payment information, the system sends invoice upload reminders to company employees; upon successful transaction, it retrieves bank clearing data; based on the application number in the target consumption request, it automatically establishes a transaction-application association; it triggers a document collection robot via IM (DingTalk / WeChat Work) or email to send invoice upload reminders to company employees; and it uses an NLP cleaning engine to map bank clearing data to standard merchant names and identify the transaction location, original currency, and exchange rate. The system receives invoices uploaded by employees and verifies payment information, invoices, and target consumption requests. Specifically, it builds an automated reconciliation engine. The three data sources are: the expected consumption amount, purpose, and budget item in the target consumption request; the payment amount, payee information, merchant type, and payment time in the payment information; and the face value, product details, and seller identified from the invoice or receipt. Verification is divided into three levels, including: strong verification: verifying whether the error between the payment amount in the payment information and the face value of the invoice is less than the configured amount error threshold; where the amount error threshold can be 1 cent or the exchange rate difference; weak verification: verifying whether the similarity between the payee information in the payment information and the seller's name corresponding to the invoice is greater than the configured similarity threshold; verifying whether the product details include prohibited items corresponding to the consumption purpose, such as cigarettes and alcohol mixed in with an invoice for office supplies purchased at a supermarket; if the face value of the invoice is less than the payment amount, it is marked as partial reconciliation, requiring employees to issue a supplementary invoice or refund the difference.

[0037] In yet another embodiment of this application, the method may further include: If the target virtual payment tool is configured to use a one-time use mode, it will be marked as expired, and the remaining amount will be returned to the corresponding department's budget in the company's cash pool. If the target virtual payment tool is configured to use a revolving use mode, the available amount will be reduced by the payment amount, and the available amount will be updated until it reaches zero, at which point it will be marked as exhausted and expired. For subscription cards, they will be automatically frozen on non-deduction dates (e.g., the 2nd to the 29th of each month) and unfrozen only on the expected deduction date (the 1st of each month) to minimize risk.

[0038] In yet another embodiment of this application, the method may further include: Based on audit metadata and the consumption purpose and budget item in the target consumption request, ERP vouchers are automatically generated. The voucher summary is automatically concatenated as [Department][Project]Payment[Merchant Name][Purpose]. At the same time, the target consumption request, bank receipt, and invoice image are packaged and stored as voucher attachments, realizing fully automated accounting processing.

[0039] In another embodiment of this application, after generating the target virtual payment tool, the method may further include: Configure a dynamic access token of the corresponding type based on the usage pattern of the target virtual payment tool; the dynamic access token can be a one-time token or a time-limited token. Bind the dynamic access token to the device information of the terminal used by the enterprise employee to initiate the target consumption request; In response to payment requests initiated by enterprise employees based on the target virtual payment tool, verify the validity of the dynamic access token and the consistency of the device.

[0040] This application completely eliminates the risk of payment fraud and theft: Through one card per transaction and an MCC whitelist, even if the card number is leaked, attackers cannot make purchases at unauthorized merchants, and the cards are destroyed after use, improving security by several orders of magnitude; it increases financial accounting efficiency by 95%: because each transaction is bound to the project and account through metadata, the system automatically completes the accounting, eliminating the need for manual reconciliation and allocation by finance personnel, reducing month-end closing time from several days to several hours; it achieves extremely granular budget control: budget control is refined from departmental totals to individual transactions and specific merchants, preventing situations where there is still budget available but funds are misused in non-compliant areas, ensuring that every penny is spent on approved purposes; it provides a "zero" experience for employee reimbursements: employees do not need to advance funds, attach receipts, or fill out complicated reimbursement forms, only need to apply for a credit line -> make payment -> take a photo and upload the invoice, the rest of the process is fully automated, greatly improving employee satisfaction; and it enhances data transparency: companies can see the expenditure of funds around the world in real time, instead of waiting to see reports next month, thus enabling more agile financial decisions.

[0041] Corresponding to the above method, embodiments of this application also provide a secure payment control device for enterprises, such as... Figure 3 As shown, the device includes: The acquisition unit 310 is used to acquire the historical consumption sequence of enterprise employees and the target consumption requests sent by enterprise employees that have passed business approval; The determining unit 320 is used to determine the target payment strategy based on historical consumption sequences and target consumption requests; The generation unit 330 is used to generate a target virtual payment tool based on the target payment strategy and the target consumption request; wherein, the target virtual payment tool includes fund control rules bound to the target consumption request; The verification unit 340 is used to respond to payment requests initiated by enterprise employees based on the target virtual payment tool, and to perform payment verification on the payment request and the target virtual payment tool according to the fund control rules and the target consumption request; The control unit 350 is used to control the target virtual payment tool to complete the payment when the payment request passes the payment verification.

[0042] The functions of each functional unit of the enterprise secure payment control device provided in the above embodiments of this application can be implemented through the above methods and steps. Therefore, the specific working process and beneficial effects of each unit in the enterprise secure payment control device provided in the embodiments of this application will not be repeated here.

[0043] This application also provides an electronic device, such as... Figure 4As shown, it includes a processor 410, a communication interface 420, a memory 430, and a communication bus 440, wherein the processor 410, the communication interface 420, and the memory 430 communicate with each other through the communication bus 440.

[0044] Memory 430 is used to store computer programs; When the processor 410 executes the program stored in the memory 430, it performs the following steps: Obtain the historical consumption sequence of enterprise employees and the target consumption requests sent by enterprise employees that have been approved by business departments; Determine the target payment strategy based on historical consumption patterns and target consumption requests; Based on the target payment strategy and the target consumption request, a target virtual payment tool is generated; wherein, the target virtual payment tool includes fund control rules bound to the target consumption request; In response to payment requests initiated by enterprise employees based on target virtual payment tools, the payment request and target virtual payment tool are verified according to fund control rules and target consumption requests; When the payment request passes the payment verification, the target virtual payment tool is controlled to complete the payment.

[0045] The communication bus mentioned above can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not mean that there is only one bus or one type of bus.

[0046] The communication interface is used for communication between the aforementioned electronic devices and other devices.

[0047] The memory may include random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0048] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0049] The implementation methods and beneficial effects of the various components of the electronic device in the above embodiments for solving the problem can be found in [reference needed]. Figure 2 The steps in the illustrated embodiments are used to implement the electronic device. Therefore, the specific working process and beneficial effects of the electronic device provided in this application will not be repeated here.

[0050] In another embodiment provided in this application, a computer-readable storage medium is also provided, which stores instructions that, when executed on a computer, cause the computer to perform any of the secure payment control methods for enterprises described in the above embodiments.

[0051] In another embodiment provided in this application, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to execute any of the secure payment control methods for enterprises described in the above embodiments.

[0052] Those skilled in the art will understand that the embodiments in this application can be provided as methods, systems, or computer program products. Therefore, the embodiments in this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the embodiments in this application can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0053] This application describes embodiments of methods, apparatus (systems), and computer program products according to embodiments of this application with reference to flowchart illustrations and / or block diagrams. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0054] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0055] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0056] Although preferred embodiments have been described in this application, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments of this application.

[0057] Obviously, those skilled in the art can make various modifications and variations to the embodiments of this application without departing from the spirit and scope of the embodiments of this application. Therefore, if these modifications and variations to the embodiments of this application fall within the scope of this application and its equivalents, then these modifications and variations are also intended to be included in the embodiments of this application.

Claims

1. A secure payment control method for enterprises, characterized in that, The method includes: Obtain the historical consumption sequence of enterprise employees and the target consumption requests sent by the enterprise employees that have passed business approval; Based on the historical consumption sequence and the target consumption request, a target payment strategy is determined; A target virtual payment tool is generated based on the target payment strategy and the target consumption request; wherein, the target virtual payment tool includes fund control rules bound to the target consumption request; In response to a payment request initiated by an employee based on the target virtual payment tool, the payment request and the target virtual payment tool are verified according to the fund control rules and the target consumption request; When the payment request passes the payment verification, the target virtual payment tool is controlled to complete the payment.

2. The method as described in claim 1, characterized in that, The target consumption request includes: consumption scenario, expected consumption amount, expected consumption time, budget allocation, and business information; The target virtual payment tool also includes: payment credentials and audit metadata.

3. The method as described in claim 2, characterized in that, The step of determining the target payment strategy based on the historical consumption sequence and the target consumption request includes: From the comparison table of different consumption scenarios and different candidate payment strategies, match multiple target candidate payment strategies corresponding to the consumption scenario; The historical consumption sequence is input into a pre-trained compliance probability prediction model to obtain the predicted compliance probability and predicted anomaly index of the enterprise's employees. If the predicted compliance probability is greater than the configured compliance probability threshold, then obtain the configuration parameters of each target candidate payment strategy and historical payment data within the past preset time period. Based on the expected consumption time, the predicted anomaly index, the configuration parameters, and the historical payment data, the target weight of each target candidate payment strategy is determined. Based on the target weights of each target candidate payment strategy, a target payment strategy is selected from multiple target candidate payment strategies.

4. The method as described in claim 3, characterized in that, The configuration parameters include: policy priority, constraint coefficient, and effective time period; Based on the expected consumption time, the predicted anomaly index, the configuration parameters, and the historical payment data, the target weights of each target candidate payment strategy are determined, including: For any target candidate payment strategy, the timeliness factor of the target candidate payment strategy is determined based on the expected consumption time and the effective time period; Based on the historical payment data, the success rate of the target candidate payment strategy within a preset time period is calculated to obtain the success rate factor of the target candidate payment strategy. Based on the predicted anomaly index and the constraint coefficient, the behavioral factors of the target candidate payment strategy are determined; The target weight of the target candidate payment strategy is determined based on the strategy priority, the timeliness factor, the success rate factor, and the behavior factor.

5. The method as described in claim 4, characterized in that, Based on the target payment strategy and the target consumption request, a target virtual payment tool is generated, including: Based on the configuration parameters of the target payment strategy, the expected consumption amount, and the expected consumption time, generate a fund management rule instance; Control the API to generate payment credentials for the target virtual payment tool; Based on the budget allocation and business information, generate audit metadata; By associating the fund control rule instance, the audit metadata, and the payment voucher, a target virtual payment tool is obtained.

6. The method as described in claim 5, characterized in that, The payment request includes the payment request time, payment amount, payee information, and merchant type; Based on the fund control rules and the target consumption request, payment verification is performed on the payment request and the target virtual payment tool, including: Verify whether the payment request time falls within the effective period of the target virtual payment tool; Verify whether the request status of the target consumption request is "approved" at the time of the payment request; Verify whether the payee information and merchant type meet the consumption scenario and the business information; Verify that the payment amount is not greater than the sum of the expected consumption amount and the configured tolerance amount; Verify whether the payment request time, payment amount, payee information, and merchant type meet the fund control rule instance.

7. The method as described in claim 6, characterized in that, After controlling the target virtual payment tool to complete the payment, the method further includes: Upon receiving payment information, the company sends an invoice upload notification to its employees. The system receives invoices uploaded by the company's employees and verifies the payment information, the invoices, and the target consumption request.

8. A secure payment control device for an enterprise, characterized in that, The device includes: The acquisition unit is used to acquire the historical consumption sequence of enterprise employees and the target consumption requests sent by the enterprise employees that have passed business approval; The determining unit is configured to determine a target payment strategy based on the historical consumption sequence and the target consumption request; A generation unit is configured to generate a target virtual payment tool based on the target payment strategy and the target consumption request; wherein the target virtual payment tool includes fund control rules bound to the target consumption request; The verification unit is used to respond to a payment request initiated by an enterprise employee based on the target virtual payment tool, and to perform payment verification on the payment request and the target virtual payment tool according to the fund control rules and the target consumption request; The control unit is used to control the target virtual payment tool to complete the payment when the payment request passes the payment verification.

9. An electronic device, characterized in that, The electronic device includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; A processor, when executing a program stored in memory, implements the method of any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method described in any one of claims 1-7.

Images