Virtual card transaction execution method and device based on consumption scenario driving

Abstract

The application provides a virtual card transaction execution method and device based on a consumption scenario, comprising: performing scene element analysis on a virtual card application submitted by a user to obtain scene elements of the virtual card; generating a control factor set based on the scene elements and preset fee control rules, and generating an authorization strategy of the virtual card based on the control factor set; when a transaction request of the virtual card is monitored to reach a payment gateway, verifying the transaction request based on the authorization strategy, and if the verification result is not compliant, intercepting the transaction request. The application improves the security of funds and the risk control capability.

Description

Technical Field

[0001] This invention relates to the field of virtual card management technology, and in particular to a method and apparatus for executing virtual card transactions based on consumption scenarios. Background Technology

[0002] With the expansion of global business and the digital transformation of corporate expense control, employees' travel and procurement activities are becoming increasingly frequent and complex. Especially for international business trips and remote procurement scenarios, traditional physical card management suffers from inefficiency and risk of uncontrolled risk. Virtual credit cards (VCCs) are widely used as a flexible payment tool. However, existing VCC management mechanisms are mostly statically configured, typically involving manually setting relatively broad restrictions. For example, an employee applying for a three-day European travel card should have its card permissions strictly limited to Euro payments and travel-related merchants (such as transportation and accommodation), but the actual permissions are much broader, thus increasing the potential risk of fund misuse and fraud. Summary of the Invention

[0003] In view of this, the purpose of the present invention is to provide a virtual card transaction execution method and apparatus based on consumption scenario-driven approach, so as to improve the security of funds and risk control capabilities.

[0004] To achieve the above objectives, the technical solutions adopted in the embodiments of the present invention are as follows: In a first aspect, embodiments of the present invention provide a virtual card transaction execution method based on a consumption scenario, comprising: parsing the scenario elements of a virtual card application submitted by a user to obtain the scenario elements of the virtual card; generating a set of control factors based on the scenario elements and preset fee control rules, and generating an authorization strategy for the virtual card based on the set of control factors; when a transaction request for a virtual card is detected to arrive at the payment gateway, verifying the transaction request based on the authorization strategy, and if the verification result is non-compliant, intercepting the transaction request.

[0005] Optionally, the scenario elements include at least: destination information and time information; based on the scenario elements and preset fee control rules, a set of control factors is generated, including: determining the geographic location restriction code and currency code based on the destination information; filtering preset merchant category groups based on the destination information, preset fee control rules, and the user's corresponding job level to obtain a subset of merchant categories; determining the expiration time of the virtual card based on the time information; and generating a set of control factors based on the geographic location restriction code, currency code, merchant category subset, and expiration time.

[0006] Optionally, the authorization strategy for generating virtual cards based on the set of control factors includes: encrypting and encoding each control factor in the set of control factors to obtain the token metadata of the authorization strategy for virtual cards; applying for account information to create virtual cards based on virtual cards, converting the account information into payment tokens, and associating the payment tokens with the token metadata. Optionally, after associating the payment token with the token metadata, the method further includes: sending the payment token to the finite state machine corresponding to the virtual card, and managing the current state of the payment token based on the finite state machine; when a state transition trigger event is detected, driving the finite state machine to transition the current state of the payment token; wherein the state of the payment token includes at least: pending approval, active, in transaction, temporarily frozen, expired, and settled.

[0007] Optionally, the transaction request is validated based on the authorization policy, including: obtaining the current status of the payment token; if the current status is active, obtaining the transaction time, transaction currency, merchant type and transaction amount of the transaction request; and validating the transaction request based on the transaction time, transaction currency, merchant type and transaction amount.

[0008] Optionally, the transaction request can be validated based on the transaction time, transaction currency, merchant category, and transaction amount, including: determining whether the transaction time is later than the deadline; if so, the transaction request is blocked; if not, the transaction currency, merchant category, and transaction amount are compared with the token metadata; if any comparison result fails, the transaction request is determined to be non-compliant.

[0009] Optionally, it also includes: if the current status is expired, returning the remaining funds in the virtual card account to the enterprise's master account and migrating the status of the payment token to settled.

[0010] Secondly, embodiments of the present invention provide a virtual card transaction execution device driven by a consumption scenario, comprising: a scenario parsing module, used to parse scenario elements of a virtual card application submitted by a user to obtain scenario elements of the virtual card; an authorization strategy generation module, used to generate a set of control factors based on the scenario elements and preset fee control rules, and generate an authorization strategy for the virtual card based on the set of control factors; and a transaction interception module, used to verify the transaction request based on the authorization strategy when a transaction request of a virtual card is detected to arrive at the payment gateway, and to intercept the transaction request if the verification result is non-compliant.

[0011] Thirdly, embodiments of the present invention provide an electronic device including a processor and a memory, the memory storing computer-executable instructions executable by the processor, the processor executing the computer-executable instructions to implement the steps of any of the methods provided in the first aspect above.

[0012] Fourthly, embodiments of the present invention provide a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the steps of the method provided in any of the first aspects above.

[0013] The embodiments of the present invention bring the following beneficial effects: The present invention provides a virtual card transaction execution method and apparatus based on consumption scenario-driven principles. First, the user-submitted virtual card application is analyzed for scenario elements to obtain the virtual card's scenario elements. Then, based on the scenario elements and preset fee control rules, a set of control factors is generated, and an authorization strategy for the virtual card is generated based on the control factor set. When a virtual card transaction request arrives at the payment gateway, the transaction request is verified based on the authorization strategy. If the verification result is non-compliant, the transaction request is intercepted. This method dynamically generates the virtual card's authorization strategy based on the scenario elements in the virtual card application and preset fee control rules. When the virtual card is used for a transaction, the generated authorization strategy is used to verify the transaction request, thereby ensuring that each transaction is limited to the preset scenario range, improving fund security and risk control capabilities.

[0014] Other features and advantages of the invention will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention are realized and obtained in accordance with the structures particularly pointed out in the description, claims and drawings.

[0015] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0016] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0017] Figure 1 A flowchart illustrating a virtual card transaction execution method driven by a consumption scenario, provided as an embodiment of the present invention; Figure 2 A schematic diagram of the structure of a virtual card transaction execution device based on a consumption scenario driven by an embodiment of the present invention; Figure 3This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0019] Currently, most existing VCC management mechanisms are statically configured, typically involving manually setting relatively broad restrictions. For example, when an employee applies for a three-day European travel card, the card's permissions should be strictly limited to Euro payments and travel-related merchants (such as transportation and accommodation). However, the actual permissions are often broader, thus increasing the potential risks of fund misuse and fraud.

[0020] Based on this, the present invention provides a virtual card transaction execution method and apparatus driven by consumption scenarios, which can improve the security of funds and risk control capabilities.

[0021] To facilitate understanding of this embodiment, a detailed description of a virtual card transaction execution method based on a consumption scenario driven by this invention will be provided first. This method can be executed by electronic devices, such as computers, smartphones, and tablets. See also... Figure 1 The flowchart shown illustrates a virtual card transaction execution method based on a consumption scenario, indicating that the method mainly includes the following steps S101 to S103: Step S101: Analyze the scene elements of the virtual card application submitted by the user to obtain the scene elements of the virtual card.

[0022] In one implementation, when a user submits a virtual card application, they fill in scenario elements including destination, expected usage period, and estimated amount. After receiving the virtual card application, the system parses the scenario elements to obtain the scenario elements of the virtual card.

[0023] Step S102: Based on scene elements and preset cost control rules, generate a set of control factors, and generate an authorization strategy for virtual cards based on the set of control factors.

[0024] In one implementation, a scene element parsing engine is used to convert unstructured or semi-structured scene elements (such as country codes and number of days) into a set of structured dynamic control factors. For example, “Business trip country: Japan” is mapped to “Available currency: JPY” and “Merchant region restriction: Japan”, and “Expected business trip duration: 5 days” is mapped to “Card hard deadline: application date + 5 days”.

[0025] Then, using the obtained set of structured dynamic control factors, a dynamic strategy generation algorithm is executed to generate a set of temporary, highly binding authorization policies based on preset fee control rules (e.g., default merchant category (MCC) restrictions for different countries or departments). These policies include at least: a maximum spending limit, a strictly allowed list of MCCs, a unique list of available currencies, and a hard cutoff time accurate to the second.

[0026] Step S103: When a transaction request from a virtual card is detected to arrive at the payment gateway, the transaction request is verified based on the authorization policy. If the verification result is non-compliant, the transaction request is intercepted.

[0027] In one implementation, each VCC transaction request arriving at the payment gateway must undergo real-time verification and interception. This involves checking whether the transaction complies with authorization policies, such as whether the currency and merchant MCC are on the allowed list, and whether the transaction amount exceeds the remaining available credit limit. Transaction requests that do not comply with the authorization policies will be directly intercepted and rejected.

[0028] The virtual card transaction execution method based on consumption scenario driven by the present invention can dynamically generate the authorization strategy of the virtual card based on the scenario elements in the virtual card application and the preset fee control rules. When the virtual card is used for a transaction, the transaction request is verified according to the generated authorization strategy, thereby ensuring that each transaction is limited to the preset scenario range, improving the security of funds and risk control capabilities.

[0029] In one implementation, the scene elements include at least: destination information and time information; for the aforementioned step S102, that is, when generating a set of control factors based on scene elements and preset fee control rules, the following methods may be adopted, including but not limited to: First, based on the destination information, determine the geographic location restriction code and currency code; then, based on the destination information, preset fee control rules, and the user's corresponding job level, filter the preset merchant category group to obtain a subset of merchant categories; next, based on the time information, determine the expiration time of the virtual card; finally, based on the geographic location restriction code, currency code, merchant category subset, and expiration time, generate a set of control factors.

[0030] In practice, scenario elements include, but are not limited to: destination information (e.g., ISO 3166 code), time information (e.g., expected start and end dates), expected total budget amount, and expected main consumption categories (e.g., transportation, dining, accommodation).

[0031] In this embodiment of the invention, the system has a built-in Scene Element Parser (SEP). This parser works in conjunction with global geographic services, exchange rates, currency databases, and expense control rule databases to convert identified scene elements into a set of control factors. Specifically, this includes: determining the corresponding geographic location restriction code and allowed currency code based on destination information; automatically selecting and filtering the minimum necessary subset, i.e., the merchant category subset, from a pre-defined broad group of merchant categories based on the user's business trip destination and employee job level; and determining the hard cutoff time of the virtual card, accurate to the second, based on time information.

[0032] For example, when SEP identifies "Destination Country: United Kingdom (GBR)", it will query: 1. Allowed Currency Library: Extract GBP as the primary currency and optionally add USD as a backup; 2. Geographic Restriction Library: Generate geographic restriction codes (such as UK address ranges); 3. Expense Control Rule Library: Based on the user's job level and business trip country, automatically select and filter the minimum required subset of MCCs from a preset broad MCC group (e.g., only allowing 4111-train tickets, 4511-airline tickets, 7011-hotel tickets). Finally, the extracted and filtered information (including currency codes, MCC subsets, geographic restriction codes, and hard cutoff times accurate to the second) is integrated into a structured control factor JSON object. In this embodiment of the invention, the control factor set may also include the user's maximum spending limit.

[0033] In this embodiment of the invention, the above process is fully automated and can accurately transform employees' business intentions into a set of dynamic rules that can be executed by machines, laying the foundation for subsequent tokenized authorization.

[0034] In this embodiment of the invention, when generating the control factor set, the scenario elements can also be optimized and corrected by combining the user's historical travel data. Specifically, for each merchant in the merchant type subset, the system can verify whether the merchant is a high-risk merchant based on the merchant's information and transaction behavior characteristics; detect whether the user submits multiple small VCC applications in a short period of time, or submits large applications on non-working days or late at night; check whether the payee has an abnormal association with the employee (e.g., the payee's registered address coincides with the employee's home address); based on the above check results, a risk score is generated for each merchant, and the merchants in the merchant type subset are filtered based on the risk scores to obtain the final subset of merchants allowed for consumption.

[0035] Regarding the VCC limit, considering that existing technologies typically set the VCC limit based on the total estimated budget amount filled in by the user during application, this embodiment of the invention can employ an intelligent pre-approval mechanism based on the user's historical behavior to determine the virtual card limit in order to avoid problems such as insufficient VCC limit or excessive fund occupation. Specifically, the following process is included: (1) Constructing a consumer profile of the user.

[0036] Specifically, historical consumption data of users is extracted from ERP systems, OA systems and historical VCC transaction databases, and the historical consumption data is tagged, including but not limited to: employee job level, historical average consumption in the same country, historical consumption of the same project type, seasonal fluctuation factors and supplier price index, etc.

[0037] (2) Train the dynamic benchmark prediction model.

[0038] Specifically, a lightweight machine learning algorithm (such as XGBoost or LightGBM) is used to train the pre-credit prediction model. The input of the model is the scenario elements of the previous application (destination, time, project ID, etc.), and the output is the recommended amount range and recommended time window in that scenario.

[0039] (3) Real-time pre-credit calculation.

[0040] Specifically, after receiving a user's virtual card application, the pre-trained pre-approved credit prediction model is invoked to obtain the recommended amount range and recommended time window for that scenario. The user's estimated total budget amount and the recommended amount output by the model are then weighted and fused to obtain the final VCC limit.

[0041] In one implementation, upon receiving a user's virtual card application, the system first identifies scenario elements from the application; then, based on the user's user ID, it retrieves a snapshot of the employee's historical data from the employee consumption profile database, including but not limited to: the employee's average daily spending in similar countries over the past 6 months, the highest single purchase, and the default expense control standard for that job level; finally, it calls an external API (e.g., exchange rate API, destination cost of living index API) to automatically convert the estimated total budget amount into the base currency and weight it using the destination cost of living coefficient.

[0042] Furthermore, the extracted data is input into a pre-trained pre-credit prediction model to obtain the recommended amount, and the final VCC limit is obtained based on the expected total budget amount and the recommended amount output by the model. Specifically, the difference rate between the expected total budget amount and the recommended amount output by the model is first calculated. That is: D eviation =∣ A user A model | / A model in, A user The total estimated budget amount entered by the user. A model The recommended amount output by the model. D eviation This represents the difference rate.

[0043] Then, the weights are dynamically adjusted based on the deviation rate to calculate the final recommended amount. A final : If the deviation rate is less than a first threshold (e.g., 10%), then trust the user. A final = A user ×1.0; If the deviation rate is greater than the first threshold and less than the second threshold (e.g., the deviation rate is between 10% and 30%), then A final =( A user ×0.4)+( A model (×0.6), where the weighting coefficients of 0.4 and 0.6 are only examples and can be 0.3 and 0.7, which can be set according to actual needs; If the deviation rate exceeds the second threshold, mandatory intervention is triggered, and... A final = A model The forced intervention process includes sending a prompt to the user to ask if they need to adjust their budget.

[0044] In this embodiment of the invention, the final recommended amount can also be... A final Add an emergency fund (e.g., 10%) to ensure that transactions are not blocked due to small overspending. The final recommended amount. A final As one of the control factors in the set of control factors.

[0045] (4) Human-machine collaborative feedback.

[0046] Specifically, if the deviation between a user's final consumption and the predicted VCC limit exceeds a threshold (e.g., +50%), the system will automatically trigger an approval process or generate a consumption analysis report, and will use this data as a new sample to flow back to the data lake for incremental training of the model.

[0047] In one implementation, for the aforementioned step S102, i.e., when generating the authorization strategy for the virtual card based on the set of control factors, the following methods may be adopted, including but not limited to: First, encrypt and encode each control factor in the set of control factors to obtain the token metadata of the authorization strategy for the virtual card; then, apply for the creation of account information for the virtual card based on the virtual card, convert the account information into a payment token, and associate the payment token with the token metadata. In practice, the system invokes the authorization policy encoding service. This service receives structured control factors and encrypts and encodes them into a set of token metadata. This metadata is highly compressed and includes: VCC-ID (VCC card number), ExpiryTimestamp (expiration time), AllowedCurrencyListHash (allowed currency codes), AllowedMCCListHash (MCC subset), and MaxLimit (maximum spending amount).

[0048] Furthermore, the system invokes the payment tokenization service, using the aforementioned dynamic authorization policy as metadata, and binds it to the newly created VCC account information to generate a VCC-Token (payment token) with a lifecycle and permission constraints. This token not only represents the card itself but also embeds all the dynamic control rules, enabling real-time encoding of VCC permissions and a one-card-one-policy approach.

[0049] In this embodiment of the invention, the primary account information of the VCC card is replaced with a payment token (VCC-Token), and all transactions will be conducted using this payment token. This VCC-Token is associated one-to-one with the aforementioned encrypted token metadata at the database level. This tokenization process hardcodes the control policies previously stored in the central authorization server into the token's associated metadata in an encrypted and tamper-proof form, enabling subsequent transaction verification to be completed quickly and atomically, avoiding the need to query a complex business approval system for each transaction.

[0050] In this embodiment of the invention, to achieve automated and highly reliable management of the entire lifecycle of VCC cards, a VCC-specific Finite State Machine (FSM) is used for card lifecycle control. Specifically, after associating the payment token with the token metadata, the payment token is sent to the finite state machine corresponding to the virtual card, and the current state of the payment token is managed based on the finite state machine. When a state transition trigger event is detected, the finite state machine is driven to transition the current state of the payment token. The states of the payment token include at least: pending approval, active, in transaction, temporarily frozen, expired, and settled.

[0051] In practice, the newly generated VCC-Token is immediately imported into the FSM management module. This module is responsible for the entire lifecycle state migration of the VCC card from application to final settlement. FSM pre-defines key states such as Pending, Active, In Use, Suspended, Expired, and Settled, as well as the events and actions that drive state migration.

[0052] The system drives state machine transitions by listening for external state transition trigger events (such as approval, real-time clock reaching the deadline, and transaction settlement completion). For example, when approval is detected, the state transitions from Pending to Active; when the real-time clock reaches the set hard deadline, the FSM will automatically transition the card state from Active to Expired without any manual intervention and issue a fund return instruction. The introduction of FSM ensures automation, real-time performance, and high reliability of card lifecycle management.

[0053] In one implementation, the system monitors the status of payment tokens via a real-time clock monitoring service. This service continuously monitors the ExpiryTimestamp of all Active VCC-Tokens. Once the real-time time Current reaches or exceeds the ExpiryTimestamp, the system automatically injects an internal event, Event:AutoExpire. Upon receiving Event:AutoExpire, the FSM immediately executes a locking action (migrating the card state to Expired, preventing any new transaction authorization) and triggers an asynchronous fund rollback task. This time-event-based hard migration mechanism, requiring no manual intervention, ensures that the card expires precisely at the predetermined time.

[0054] In one implementation, for the aforementioned step S103, i.e. when verifying the transaction request based on the authorization policy, the following methods may be used, including but not limited to: First, obtain the current status of the payment token; if the current status is active, obtain the transaction time, transaction currency, merchant category and transaction amount of the transaction request; then, verify the transaction request based on the transaction time, transaction currency, merchant category and transaction amount.

[0055] In practice, when the payment gateway receives a transaction request for VCC-Token, it sends the transaction request to the real-time verification and interception module for multi-dimensional verification, including: first, obtaining the current status of the payment token and checking whether the status of VCC-Token in FSM is Active; if so, further verifying the transaction request based on the transaction time, transaction currency, merchant type and transaction amount.

[0056] Specifically, it determines whether the transaction time is later than the deadline. If so, the transaction request is intercepted; if not, the transaction currency, merchant type, and transaction amount are compared with the token metadata. If any comparison result fails, the transaction request is determined to be non-compliant.

[0057] In practice, the system checks if the current transaction time is later than the VCC deadline. If it is, the transaction request is blocked, and the transaction is prohibited. If the current transaction time is not later than the deadline, the transaction currency, merchant category, and transaction amount are compared with the token metadata. The system checks if the transaction currency is within the allowed range, if the merchant category is within a subset of merchant categories, and if the transaction amount exceeds the maximum transaction amount. The transaction is authorized only if all verification items pass. If any verification item fails, the current transaction request is blocked, and a chargeback code is returned.

[0058] In one implementation, the method further includes: if the current status is expired, returning the remaining funds in the virtual card's account to the enterprise's main account and migrating the status of the payment token to settled.

[0059] In practice, when the FSM enters the Expired state, the system triggers the settlement and rollback service, queries the real-time balance (Balance_Remaining) of the VCC account, and automatically generates and sends a transfer instruction of Balance_Remaining through a preset bank-enterprise direct connection or internal fund transfer interface to transfer funds back to the enterprise's main account. After the transfer instruction is successfully executed, the FSM finally migrates to the Settled state and disconnects the VCC-Token from any physical account, achieving complete card obsolescence.

[0060] To improve the efficiency and turnover speed of funds, this embodiment of the invention can employ a virtual corporate fund pool and an intelligent scheduling engine to allocate corporate funds, specifically including the following process: (1) Construct a global fund view.

[0061] Specifically, the enterprise master account balance, the remaining quota of all issued VCCs, and funds in transit (consumed but not settled) are mapped to a unified virtual in-memory table to obtain a global fund view. The total available liquidity is calculated as: Master Account Balance + ∑(Remaining Quota of All Cards) - ∑(Frozen Funds Pending Settlement). Simultaneously, the engine monitors every VCC status change in the FSM in real time. For example, when the status of a VCC changes from Active to Settled (settled) or Expired (expired), the engine immediately captures the event and identifies that this portion of the funds is about to be released.

[0062] (2) Capital heat map and demand forecast.

[0063] Specifically, based on the time-slice algorithm, all VCCs in use are scanned, and the estimated amount of funds that will be returned to the virtual fund pool due to card expiration or unused quotas in the next 24 hours is calculated, generating a fund inflow forecast table.

[0064] If a user submits a new VCC application and the amount of the new application exceeds the current cash balance of the main account, it will be placed in the scheduling queue and marked with priority (e.g., emergency procurement > regular business travel).

[0065] (3) Intelligent scheduling.

[0066] Specifically, when employee A's card expires tomorrow, it is expected to release 10,000 yuan; and employee B urgently needs 10,000 yuan today, but there is no money in the main account, the logic is executed to transfer funds and record an internal account in the system background: the amount that employee A is about to release is pre-allocated to employee B.

[0067] When a high-priority task (such as an emergency purchase) is short of funds, scan the cards of low-priority tasks (such as non-urgent team building reserve funds), temporarily reduce the remaining amount of the low-priority card, and real-time allocate the freed-up amount to the high-priority card.

[0068] The method provided in this invention, based on a dynamic and highly binding authorization strategy generated from scenario elements and combined with real-time transaction verification, ensures that every transaction is strictly limited to a preset currency and MCC range, fundamentally eliminating the risk of fund misappropriation and fraud. The granularity of card permissions is refined from the company level to the scenario level of a single business trip / purchase, improving fund security and risk control capabilities.

[0069] Through the FSM and real-time clock monitoring mechanism, the remaining funds after the card expires can be returned instantly and automatically, reducing the time for funds to travel from several hours or even days in the traditional manual or batch processing mode to seconds, which greatly improves the efficiency of enterprise capital utilization and liquidity.

[0070] From employee application to automatic card freezing and fund refund, the entire process requires no manual intervention, greatly reducing the workload of finance and business personnel and achieving seamless expense control management with one-click application and automatic closed loop.

[0071] Dynamic restrictions on available currencies and geographic locations ensure transactions comply with local financial and tax regulations. Simultaneously, the FSM records all card status migrations, providing a complete and tamper-proof chain of evidence for auditing and compliance checks, thus enhancing transaction compliance and traceability.

[0072] In addition to the consumption scenario-driven virtual card transaction execution method provided in the foregoing embodiments, this invention also provides a consumption scenario-driven virtual card transaction execution device, see [link to related documentation]. Figure 2 The diagram shows a structural schematic of a virtual card transaction execution device driven by a consumption scenario. The device may include the following parts: The scene analysis module 201 is used to analyze the scene elements of the virtual card application submitted by the user to obtain the scene elements of the virtual card.

[0073] The authorization strategy generation module 202 is used to generate a set of control factors based on scene elements and preset cost control rules, and generate an authorization strategy for virtual cards based on the set of control factors.

[0074] The transaction interception module 203 is used to verify the transaction request based on the authorization policy when a transaction request of a virtual card arrives at the payment gateway. If the verification result is not compliant, the transaction request is intercepted.

[0075] The virtual card transaction execution device based on consumption scenario driven by the present invention can dynamically generate the authorization strategy of the virtual card based on the scenario elements in the virtual card application and the preset fee control rules. When the virtual card is used for transaction, the transaction request is verified according to the generated authorization strategy, thereby ensuring that each transaction is limited to the preset scenario range, improving the security of funds and risk control capabilities.

[0076] In one implementation, the scenario elements include at least: destination information and time information; the authorization strategy generation module 202 is specifically used to: determine the geographic location restriction code and currency code based on the destination information; filter the preset merchant category group based on the destination information, preset fee control rules and the user's corresponding job level to obtain a subset of merchant categories; determine the expiration time of the virtual card based on the time information; and generate a set of control factors based on the geographic location restriction code, currency code, subset of merchant categories and expiration time.

[0077] In one implementation, the authorization policy generation module 202 is specifically used to: encrypt and encode each control factor in the control factor set to obtain the token metadata of the authorization policy of the virtual card; apply for and create account information for the virtual card based on the virtual card, convert the account information into a payment token, and associate the payment token with the token metadata. In one embodiment, the above-mentioned device further includes: a state management module, configured to: send the payment token to the finite state machine corresponding to the virtual card, and manage the current state of the payment token based on the finite state machine; when a state transition trigger event is detected, drive the finite state machine to transition the current state of the payment token; wherein the state of the payment token includes at least: pending approval, active, in transaction, temporarily frozen, expired, and settled.

[0078] In one implementation, the transaction interception module 203 is specifically used to: obtain the current status of the payment token; if the current status is active, obtain the transaction time, transaction currency, merchant category and transaction amount of the transaction request; and verify the transaction request based on the transaction time, transaction currency, merchant category and transaction amount.

[0079] In one implementation, the transaction interception module 203 is specifically used to: determine whether the transaction time is later than the deadline; if so, intercept the transaction request; if not, compare the transaction currency, merchant type and transaction amount with the token metadata; if any comparison result fails, determine that the transaction request is non-compliant.

[0080] In one implementation, the transaction interception module 203 is specifically used to: if the current status is expired, return the remaining funds in the virtual card account to the enterprise's main account, and migrate the status of the payment token to settled.

[0081] The device provided in this embodiment of the invention has the same implementation principle and technical effect as the aforementioned method embodiment. For the sake of brevity, any parts not mentioned in the device embodiment can be referred to the corresponding content in the aforementioned method embodiment.

[0082] This invention also provides an electronic device, specifically, the electronic device includes a processor and a storage device; the storage device stores a computer program, and the computer program, when run by the processor, executes the method described in any of the above embodiments.

[0083] Figure 3This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. The electronic device 100 includes: a processor 30, a memory 31, a bus 32 and a communication interface 33. The processor 30, the communication interface 33 and the memory 31 are connected through the bus 32. The processor 30 is used to execute executable modules, such as computer programs, stored in the memory 31.

[0084] The memory 31 may include high-speed random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Communication between this system network element and at least one other network element is achieved through at least one communication interface 33 (which can be wired or wireless), such as the Internet, wide area network, local area network, metropolitan area network, etc.

[0085] Bus 32 can be an ISA bus, PCI bus, or EISA bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 3 The symbol is represented by a single double-headed arrow, but this does not mean that there is only one bus or one type of bus.

[0086] The memory 31 is used to store programs. After receiving an execution instruction, the processor 30 executes the program. The method executed by the device for defining the flow process disclosed in any of the foregoing embodiments of the present invention can be applied to the processor 30 or implemented by the processor 30.

[0087] Processor 30 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of processor 30 or by instructions in software form. Processor 30 can be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it can also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this invention. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this invention can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules can reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory 31. The processor 30 reads the information in memory 31 and, in conjunction with its hardware, completes the steps of the above method.

[0088] The computer program product of the readable storage medium provided in the embodiments of the present invention includes a computer-readable storage medium storing program code. The instructions included in the program code can be used to execute the methods described in the foregoing method embodiments. For specific implementation, please refer to the foregoing method embodiments, which will not be repeated here.

[0089] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, essentially, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0090] Finally, it should be noted that the above-described embodiments are merely specific implementations of the present invention, used to illustrate the technical solutions of the present invention, and not to limit it. The scope of protection of the present invention is not limited thereto. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments within the technical scope disclosed in the present invention, or make equivalent substitutions for some of the technical features; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A virtual card transaction execution method based on a consumption scenario, characterized in that, include: The scene elements of the virtual card application submitted by the user are analyzed to obtain the scene elements of the virtual card; Based on the scenario elements and preset cost control rules, a set of control factors is generated, and an authorization strategy for the virtual card is generated based on the set of control factors. When a transaction request from the virtual card is detected to arrive at the payment gateway, the transaction request is verified based on the authorization policy. If the verification result is non-compliant, the transaction request is intercepted.

2. The method according to claim 1, characterized in that, The scene elements include at least: destination information and time information; based on the scene elements and preset cost control rules, a set of control factors is generated, including: Based on the destination information, determine the geographic location restriction code and currency code; Based on the destination information, the preset cost control rules, and the user's corresponding job level, the preset merchant category groups are filtered to obtain a subset of merchant categories; Based on the time information, the expiration time of the virtual card is determined; A set of control factors is generated based on the geographic location restriction code, the currency code, the merchant category subset, and the deadline.

3. The method according to claim 2, characterized in that, The authorization strategy for generating the virtual card based on the set of control factors includes: Each control factor in the control factor set is encrypted and encoded to obtain the token metadata of the authorization policy of the virtual card; The system applies for account information to create a virtual card based on the virtual card application, converts the account information into a payment token, and associates the payment token with the token metadata.

4. The method according to claim 3, characterized in that, After associating the payment token with the token metadata, the method further includes: The payment token is sent to the finite state machine corresponding to the virtual card, and the current state of the payment token is managed based on the finite state machine; Upon detecting a state transition trigger event, the finite state machine is driven to transition the current state of the payment token; wherein the state of the payment token includes at least: pending approval, active, in transaction, temporarily frozen, expired, and settled.

5. The method according to claim 4, characterized in that, The transaction request is validated based on the authorization policy, including: Obtain the current state of the payment token; If the current status is active, then obtain the transaction time, transaction currency, merchant type, and transaction amount of the transaction request; The transaction request is verified based on the transaction time, the transaction currency, the merchant category, and the transaction amount.

6. The method according to claim 5, characterized in that, The transaction request is verified based on the transaction time, the transaction currency, the merchant category, and the transaction amount, including: Determine whether the transaction time is later than the deadline; if so, intercept the transaction request. If not, the transaction currency, the merchant category, and the transaction amount are compared with the token metadata; If any comparison result fails, the transaction request is determined to be non-compliant.

7. The method according to claim 5, characterized in that, Also includes: If the current status is expired, the remaining funds in the virtual card account will be returned to the enterprise's main account, and the status of the payment token will be moved to settled.

8. A virtual card transaction execution device driven by a consumption scenario, characterized in that, include: The scene analysis module is used to analyze the scene elements of the virtual card application submitted by the user to obtain the scene elements of the virtual card; The authorization strategy generation module is used to generate a set of control factors based on the scene elements and preset cost control rules, and to generate the authorization strategy of the virtual card based on the set of control factors. The transaction interception module is used to verify the transaction request based on the authorization policy when the transaction request of the virtual card arrives at the payment gateway. If the verification result is not compliant, the transaction request is intercepted.

9. An electronic device, characterized in that, The method includes a processor and a memory, the memory storing computer-executable instructions executable by the processor, the processor executing the computer-executable instructions to implement the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program thereon, characterized in that, The computer program is executed by the processor to perform the steps of the method described in any one of claims 1 to 7.

Images