Payment channel test method and device, computer equipment and readable storage medium

Abstract

The invention relates to a payment channel testing method and device, computer equipment and a readable storage medium. The method comprises the following steps: in response to a payment test instruction, determining a payment channel to be tested and test parameters of different payment dimensions associated with the payment channel, and determining a payment tool matched with the payment channel; determining at least one target currency type from a preset currency list according to the payment channel and the tool type of the payment tool; determining a test case corresponding to each test parameter and a dependency relationship among the test parameters; determining a test sequence of the test cases according to the dependency relationship among the test parameters; and for each target currency type, obtaining test data of the payment channel according to the test cases corresponding to the test sequence in sequence. By adopting the method, the test efficiency can be improved.

Description

Technical Field

[0001] The present application relates to the field of testing technology, and in particular to a payment channel testing method, apparatus, computer equipment and readable storage medium. Background Art

[0002] With the continuous emergence of new businesses, new products, and new management models in the payment field, payment-related departments have formulated standard specifications for relevant payment products, thereby effectively constraining the technical specifications of various payment products and ultimately ensuring network interoperability. At the same time, the testing methods used to detect the compliance of payment product standards are necessary to ensure resource security management. For example, when making cross-regional payments, it is necessary to connect to different payment channels to cover users in different regions for payment. After connecting to different payment channels, payment tests need to be performed on different channels.

[0003] However, traditional payment testing performs testing tasks manually to conduct corresponding tests on different payment channels, resulting in low efficiency of payment testing. Summary of the invention

[0004] Based on this, it is necessary to provide a payment channel testing method, device, computer equipment, computer-readable storage medium and computer program product that can improve the efficiency of payment testing in response to the above-mentioned technical problems.

[0005] In a first aspect, the present application provides a payment channel testing method, comprising: In response to the payment test instruction, determining a payment channel to be tested and a plurality of test parameters associated with the payment channel; Determining a payment instrument that matches the payment channel; Determining at least one target currency type from a preset currency list according to the payment channel and the instrument type of the payment instrument; Determine the test cases corresponding to the test parameters and the dependencies between the test parameters; Determining the test order of each of the test cases according to the dependency relationship between the test parameters; For each of the target currency types, the test cases corresponding to the test sequence are sequentially checked to obtain the test data of the payment channel.

[0006] In one embodiment, the test parameters include a specified currency type and a specified amount corresponding to the specified currency type, and a transaction type, and for each target currency type, the test cases corresponding to the test sequence are sequentially obtained to obtain test data of the payment channel, including: For each of the target currency types, if the target currency type in the business order is different from the specified currency type, determining a data conversion value between the target currency type and the specified currency type; Determining a test amount of the target currency type according to the data conversion value and the specified amount; A payment request is initiated to the payment channel based on the test amount and the transaction type to obtain test data of the payment channel.

[0007] In one embodiment, the test parameter further includes quota unit conversion, and determining the test quota of the target currency type according to the data conversion value and the specified quota includes: Determine a candidate test amount corresponding to the target currency type according to the data conversion value and the specified amount; The minimum quota unit of the target currency type is determined, and the quota unit of the candidate test quota is converted according to the minimum quota unit to obtain a test quota including only the minimum quota unit.

[0008] In one embodiment, the initiating a payment request to the payment channel based on the test amount and the transaction type to obtain test data of the payment channel includes: Initiate a payment request to the payment channel according to the test amount and the transaction type, and receive a test amount transfer result fed back by the payment channel in response to the payment request; When the test credit transfer result is a preset test credit transfer result, in response to a transaction operation associated with the transaction type triggered by the test credit transfer result, executing the transaction operation, and performing transaction rollback processing on the test credit; If the processing result of the transaction rollback process is the same as the preset result, it is determined that the payment channel is normal.

[0009] In one embodiment, in response to the transaction operation associated with the transaction type triggered by the test credit transfer result, executing the transaction operation and performing transaction rollback processing on the test credit includes: In the case where the transaction operation is a full refund / cancellation, in response to the transaction operation triggered by the test credit transfer result, the transaction operation is executed to perform transaction rollback processing on the test credit; In the case where the transaction operation is a partial refund / cancellation, in response to the transaction operation triggered by the test credit transfer result, determining the operation number of the transaction operation; Determine the refund amount for each execution of the transaction operation according to the number of operations and the test amount; The transaction operation is executed the number of times, and the test amount is subjected to transaction rollback processing according to the rollback amount corresponding to each operation.

[0010] In one embodiment, the test parameters include abnormal scenario testing, and the method further includes: When the test of the target currency type is completed, an abnormal scenario test is performed on the payment channel; the abnormal scenario test includes at least one or more of initiating payment without transmitting the payment password, initiating payment with an incorrect payment password, and initiating payment with an incorrect validity date.

[0011] In one embodiment, the method further comprises: Identify the payment tool and extract identification information of the payment tool; Determining the target region to which the payment tool belongs according to the identification information; Based on the target region, determining first attribute information of a holder of the payment instrument; The second attribute information and the first attribute information of the payment tool are sent to the payment channel for risk control verification. When there is no risk, the step of determining at least one target currency type from a preset currency list based on the payment channel and the tool type of the payment tool is performed.

[0012] In a second aspect, the present application also provides a payment channel testing device, including: an interaction module, configured to determine, in response to a payment test instruction, a payment channel to be tested and a plurality of test parameters associated with the payment channel; A data determination module, used to determine a payment instrument that matches the payment channel; Determining at least one target currency type from a preset currency list according to the payment channel and the instrument type of the payment instrument; A data processing module, used to determine the test cases corresponding to each of the test parameters, and the dependency relationship between the test parameters; Determining the test order of each of the test cases according to the dependency relationship between the test parameters; The test module is used to obtain the test data of the payment channel according to the test cases corresponding to each target currency type in the test sequence.

[0013] In a third aspect, the present application further provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, the following steps are implemented: In response to the payment test instruction, determining a payment channel to be tested and a plurality of test parameters associated with the payment channel; Determining a payment instrument that matches the payment channel; Determining at least one target currency type from a preset currency list according to the payment channel and the instrument type of the payment instrument; Determine the test cases corresponding to the test parameters and the dependencies between the test parameters; Determining the test order of each of the test cases according to the dependency relationship between the test parameters; For each of the target currency types, the test cases corresponding to the test sequence are sequentially checked to obtain the test data of the payment channel.

[0014] In a fourth aspect, the present application further provides a computer-readable storage medium having a computer program stored thereon, wherein when the computer program is executed by a processor, the following steps are implemented: In response to the payment test instruction, determining a payment channel to be tested and a plurality of test parameters associated with the payment channel; Determining a payment instrument that matches the payment channel; Determining at least one target currency type from a preset currency list according to the payment channel and the instrument type of the payment instrument; Determine the test cases corresponding to the test parameters and the dependencies between the test parameters; Determining the test order of each of the test cases according to the dependency relationship between the test parameters; For each of the target currency types, the test cases corresponding to the test sequence are sequentially checked to obtain the test data of the payment channel.

[0015] In a fifth aspect, the present application further provides a computer program product, including a computer program, which implements the following steps when executed by a processor: In response to the payment test instruction, determining a payment channel to be tested and a plurality of test parameters associated with the payment channel; Determining a payment instrument that matches the payment channel; Determining at least one target currency type from a preset currency list according to the payment channel and the instrument type of the payment instrument; Determine the test cases corresponding to the test parameters and the dependencies between the test parameters; Determining the test order of each of the test cases according to the dependency relationship between the test parameters; For each of the target currency types, the test cases corresponding to the test sequence are sequentially checked to obtain the test data of the payment channel.

[0016] The above-mentioned payment channel testing method, device, computer equipment, computer-readable storage medium and computer program product, in order to realize testing of different payment channels, automatically determine the payment channel to be tested and the test parameters of different payment dimensions associated with the payment channel, and determine the payment tool matching the payment channel by responding to the payment test instruction; determine at least one target currency type from the preset currency list according to the tool type of the payment channel and the payment tool; determine the test cases corresponding to each test parameter, and the dependency relationship between the test parameters; determine the test order of each test case according to the dependency relationship between the test parameters; for each target currency type, obtain the test data of the payment channel according to the test cases corresponding to the test order, that is, split each currency into a single task for cyclic execution to obtain the test result of each test task. This testing method can perform payment function testing in batches on the payment channel, and the test tasks for different payment tools and different payment dimensions do not need to be manually processed, thereby improving the efficiency of the test. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] In order to more clearly illustrate the technical solutions in the embodiments of the present application or related technologies, the drawings required for use in the embodiments of the present application or related technical descriptions will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying creative work.

[0018] Figure 1 An application environment diagram of a payment channel testing method in one embodiment; Figure 2 A schematic diagram of a flow chart of a payment channel testing method in one embodiment; Figure 3 is a schematic flow chart of step 212 in one embodiment; Figure 4 A flowchart of a transaction type testing method in one embodiment; Figure 5 A schematic diagram of a flow chart of a payment channel testing method in one embodiment; Figure 6 A schematic diagram of the system architecture of a testing tool in an embodiment; Figure 7 It is a structural block diagram of a testing device for a payment channel in one embodiment; Figure 8 FIG. 4 is a diagram showing the internal structure of a computer device in one embodiment. DETAILED DESCRIPTION

[0019] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0020] SALE (consumption) refers to consumption on a credit card, with the amount directly deducted.

[0021] REFUND refers to the refund of credit card consumption, which is the refund of deductions.

[0022] AUTH (pre-authorization) refers to credit card pre-authorization, which freezes the amount but does not deduct any payment.

[0023] CAPTURE (pre-authorization confirmation) refers to the credit card pre-authorization confirmation, and the amount is directly deducted.

[0024] VOID refers to the cancellation of credit card pre-authorization and the release of the frozen amount.

[0025] SALE-REFUND, deduction and refund process.

[0026] AUTH-VOID, amount freezing and amount releasing process.

[0027] AUTH-CAPTURE-REFUND, amount freezing, amount deduction and refund process.

[0028] International credit cards are credit cards issued by international credit card organizations, including VISA, Mastercard, JCB, American Express, DinersClub, and UnionPay.

[0029] Card bin, bank identification code, indicates the issuing bank or institution.

[0030] International credit cards are currently the most commonly used payment method. When making cross-border payments, different payment channels need to be connected to cover users in different regions for payment. After connecting to different payment channels, payment tests need to be performed on different channels. During this test, some problems were encountered, such as: multiple payment currencies, multiple test transaction types (including: SALE (consumption) / AUTH (pre-authorization), and corresponding tests: REFUND (refund) / VOID (cancellation), REFUND (refund) / VOID (cancellation) of partial amounts), inconsistent amount units of different currencies, inconsistent amount sizes, and personal information needs to match credit cards. In other words, the generation of test parameter information and the execution of tests in international credit card payment tests are not automated and efficient enough, and there are many manual tasks and low work efficiency.

[0031] In actual business scenarios, the following scenarios may exist: Scenario 1: You need to test different international credit card channels, such as Paypal / Adyen / Worldpay, etc. The test content is repetitive and there are many tasks.

[0032] Scenario 2: There are many currencies to be tested. The tests in related technologies all require manual execution of each test, which is very time-consuming.

[0033] Scenario 3: The amount units of each currency are different. For example, the smallest unit of some currencies is an integer and does not support decimals, while the smallest unit of some currencies supports two decimal places. When testing different currencies, you need to test with different amount units and modify the amount accordingly.

[0034] Scenario 4: The amount in each currency is different. When the same amount is used in different currencies for testing, the payment amount may be inconsistent, and the payment amount may be too large.

[0035] Scenario 5: International credit card payment requires testing different modes: SALE (consumption) / AUTH (pre-authorization), and corresponding tests: REFUND (refund) / VOID (cancellation), including partial amount tests: REFUND (refund) / VOID (cancellation). In the past, the test needed to wait for the payment to be successful before executing it manually, which was not automated enough. The entire execution process was cumbersome and time-consuming.

[0036] Scenario 6: The international credit card test also includes some abnormal scenarios (payment password not uploaded, wrong payment password uploaded, wrong validity period uploaded) that need to be tested, which need to be manually executed in the relevant technology.

[0037] Scenario 7: International credit card payment requires that the card information and personal information be sent to the payment channel. The payment channel will perform a system check on the card information and personal information. When the information does not match, there is a risk and the transaction will be blocked or subject to risk control verification. Therefore, credit cards require corresponding personal information, but the relevant technology does not generate personal information.

[0038] Scenario 8: Printing / storing card information during international credit card testing may lead to information leakage.

[0039] In view of the technical problem of low efficiency of payment testing in the above problem, a testing method for payment channels is proposed. Specifically, by responding to a payment test instruction, a payment channel to be tested and test parameters of different payment dimensions associated with the payment channel are determined; a payment tool matching the payment channel is determined; according to the tool types of the payment channel and the payment tool, at least one target currency type is determined from a preset currency list; test cases corresponding to each test parameter and the dependency relationship between the test parameters are determined; according to the dependency relationship between the test parameters, a test order of each test case is determined; for each target currency type, the test cases corresponding to the test order are sequentially determined to obtain test data of the payment channel.

[0040] The payment channel testing method provided in the embodiment of the present application can be applied to Figure 1In the application environment shown. Among them, the terminal 102 communicates with the server 104 through the network, and the server 104 communicates with the payment channel 106 to be tested. The data storage system can store the data that the server 104 needs to process. The data storage system can be integrated on the server 104, or it can be placed on the cloud or other network servers, and the test tools for testing the payment channel are deployed on the server. Among them, the number of terminals 102 can be multiple, such as terminal 1, terminal 2...terminal n. For example, the terminal 102 can include the buyer's terminal and the seller's terminal. The user terminal 102 can be, but is not limited to, various personal computers, laptops, smart phones, tablets, Internet of Things devices and portable wearable devices. The Internet of Things devices can be smart speakers, smart TVs, smart air conditioners, smart car devices, projection devices, etc. Portable wearable devices can be smart watches, smart bracelets, head-mounted devices, etc. The head-mounted device can be a virtual reality (VR) device, an augmented reality (AR) device, smart glasses, etc. Server 104 can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides cloud computing services. The payment channel 106 to be tested can be payment channels of different types, and the number of payment channels 106 to be tested can be multiple, including payment channel 1 to be tested, payment channel 2 to be tested, etc. There is no limitation on the type and number of payment channels.

[0041] In an exemplary embodiment, Figure 2 As shown, a payment channel testing method is provided, which is applied to Figure 1 The server in the example is used to illustrate, including the following steps 202 to 206. Among them: Step 202, in response to the payment test instruction, determining the payment channel to be tested and the test parameters of different payment dimensions associated with the payment channel.

[0042] The payment test instruction may be triggered and generated on the terminal interaction interface, and the payment channel to be tested and the test parameters of different payment dimensions associated with the payment channel may be configured on the interaction interface, and the test parameters may include at least a specified currency type and a specified amount corresponding to the specified currency type, amount unit conversion, and transaction type. The terminal interaction interface may be, but is not limited to, a browser page.

[0043] Exemplarily, in response to a test start instruction triggered by a browser page, the browser jumps to a payment test page, and in response to a payment test instruction triggered by the payment test page, determines the payment channel to be tested and the test parameters of different payment dimensions associated with the payment channel. Furthermore, the payment test instruction may also be triggered when a new payment tool is detected on an existing payment channel or a new currency type is generated on an existing payment channel.

[0044] Step 204, determining a payment tool that matches the payment channel.

[0045] Among them, the payment tool can be but not limited to a credit card. The payment channel, as a carrier of the payment tool, can realize the cross-regional transfer of resources. In this embodiment, the payment tool is a credit card as an example for explanation. The number of payment tools matching the payment channel can be multiple, and the number of payment tools is not limited here.

[0046] Step 206: Determine at least one target currency type from a preset currency list according to the payment channel and the instrument type of the payment instrument.

[0047] It is understandable that the types of currencies supported by payment channels and payment tools can be the same or different. Furthermore, the types and quantities of currencies supported by different payment channels and payment tools are also different. Therefore, in the existing method, when testing the payment channel, each supported currency test needs to be performed manually one by one.

[0048] Therefore, in response to this situation, you can build a currency list with the existing currency types. When testing a credit card on the payment channel, you can traverse the currency list to determine the matching target currency type, and automatically match test cases of different payment dimensions for each target currency type, without the need for manual single testing.

[0049] Optionally, in an exemplary embodiment, before determining at least one target currency type from a preset currency list, it is necessary to identify the payment instrument and extract the identification information of the payment instrument; determine the target region to which the payment instrument belongs based on the identification information; determine the first attribute information of the holder of the payment instrument based on the target region; send the second attribute information and the first attribute information of the payment instrument to the payment channel for risk control verification, and in the absence of risks, execute the step of determining at least one target currency type from the preset currency list based on the payment channel and the instrument type of the payment instrument.

[0050] For example, the card information in the request parameters is received, and the corresponding issuing bank / institution information is queried according to the first six digits of the card number (card bin) to obtain the country to which the credit card belongs. For example: the country to which the card bin of 420000 belongs is country A. The program generates personal information based on the internally stored names corresponding to each country and the address information of different regions in each country, including: state / province (some countries do not have), city, zip code, detailed address, and mobile phone number. It randomly selects the country of the credit card and generates personal information.

[0051] This method does not require manual generation of personal information during the credit card testing process, avoiding the risk of transactions being intercepted or verified by risk control when the information does not match, improving the efficiency of the test and ensuring the reliability of the test. In addition, it also avoids information leakage during the test.

[0052] Step 208: determine the test cases corresponding to each test parameter and the dependency relationship between the test parameters.

[0053] Among them, the test parameters are the specified currency type and the specified amount corresponding to the specified currency type. The corresponding test case is to test according to the specified currency type and the specified amount. It is necessary to exchange the currency corresponding to the target currency type to obtain the test amount. The test parameter is the amount unit conversion. The corresponding test case is to round the amount according to the minimum amount unit limit of the currency (that is, the minimum amount unit regulation). The test parameter is the transaction type. The corresponding test type is to execute the transaction operation corresponding to the transaction type when the payment is successful, so that the test amount can realize resource interaction between the resource transferor and the resource receiver. The resource here can be understood as the currency amount corresponding to the target currency type. The test parameter is the abnormal scenario test. The corresponding test case is to perform an abnormal scenario test on the payment channel when the target currency type has completed the test.

[0054] The test parameters may include, but are not limited to, at least two of a specified currency type and a specified amount corresponding to the specified currency type, an abnormal scenario test, an amount unit conversion, and a transaction type.

[0055] Step 210: Determine the test order of each test case according to the dependency relationship between each test parameter.

[0056] It is understandable that in order to complete the payment function on the payment channel, the corresponding test parameters need to be based on the dependencies between each other to complete the test of the payment channel. For example, in the case of a specified currency type and a specified amount corresponding to the specified currency type, it is necessary to convert the target currency type to obtain the test amount. After the exchange, if some amount units are converted, the test amount needs to be converted according to the minimum amount unit limit of the currency. Only then can a payment request be initiated to the payment channel to test the transaction type. Furthermore, when the target currency type has been tested, an abnormal scenario test is performed on the payment channel.

[0057] Step 212, for each target currency type, test cases corresponding to the test sequence are sequentially tested to obtain test data of the payment channel.

[0058] Exemplarily, for each target currency type, the corresponding test cases are sequentially tested in the test order to obtain test data of the payment channel. If the test data is preset data, it indicates that the payment channel is normal.

[0059] In the above-mentioned payment channel testing method, in order to realize the testing of different payment channels, by responding to the payment test instruction, the payment channel to be tested and the test parameters of different payment dimensions associated with the payment channel, as well as the payment tool matching the payment channel are automatically determined; according to the tool type of the payment channel and the payment tool, at least one target currency type is determined from the preset currency list; the test cases corresponding to each test parameter and the dependency relationship between the test parameters are determined; according to the dependency relationship between the test parameters, the test order of each test case is determined; for each target currency type, the test cases corresponding to the test order are sequentially followed to obtain the test data of the payment channel, that is, each currency is split into a single task for cyclic execution to obtain the test result of each test task. This testing method can perform payment function testing in batches on the payment channel, and the test tasks for different payment tools and different payment dimensions do not need to be manually processed, thereby improving the efficiency of the test.

[0060] In an exemplary embodiment, Figure 3 As shown, step 212 includes steps 302 to 306. Among them: Step 302: for each target currency type, if the target currency type in the business order is different from the specified currency type, determine the data conversion value between the target currency type and the specified currency type.

[0061] It is understandable that, considering the different amounts of each currency, when the same amount and different currencies are used for testing, there will be inconsistent payment amounts, and there will be situations where the payment amount is too large. If the test parameters include a specified currency type and a specified amount corresponding to the specified currency type, the currency corresponding to the target currency type can be exchanged according to the specified amount to obtain the test amount of the target currency type. If the test includes a specified amount (i.e., a specified currency type and a corresponding currency amount), when the specified amount is selected, the program will pay with the specified currency type as the target currency type. For example, when the specified amount is 1.7USD, and the exchange rate of US dollars to Korean won is approximately 1USD≈1,328.06KRW, the exchange rate of US dollars to euros is 1USD≈0.8959EUR. Then when the target currency type is KRW, the actual payment amount is 1.7USD×1328.06=2257.702KRW. Then when the target currency type is EUR, the actual payment amount is 1.7USD×0.8959=1.52EUR.

[0062] Step 304, determining the test amount of the target currency type according to the data conversion value and the specified amount.

[0063] Exemplarily, a currency exchange process is performed based on the data conversion value and the specified amount to determine the test amount of the target currency type.

[0064] Step 306: Initiate a payment request to the payment channel based on the test amount and transaction type to obtain test data of the payment channel.

[0065] Exemplarily, after completing the currency exchange process, a payment request can be initiated to the payment channel based on the test amount and transaction type, and the test case corresponding to the transaction type is executed on the payment channel to obtain test data for the payment channel.

[0066] In this embodiment, by specifying a currency type and a specified amount corresponding to the specified currency type, the target currency type is converted, which can solve the problem that different test amounts result from different currency exchange rates during the test and the amount needs to be manually calculated and modified.

[0067] It should be noted that the amount unit of each currency is different. For example, the smallest unit of some currencies is an integer and does not support decimals, while the smallest unit of some currencies supports two decimal places. Therefore, when testing different currencies, you need to test with different amount units and modify the amount accordingly.

[0068] Therefore, in an exemplary embodiment, the test limit of the target currency type is determined based on the data conversion value and the specified limit, including: determining the candidate test limit corresponding to the target currency type based on the data conversion value and the specified limit; determining the minimum limit unit of the target currency type, converting the limit unit of the candidate test limit according to the minimum limit unit, and obtaining a test limit that only includes the minimum limit unit.

[0069] Exemplarily, the automatic amount unit conversion carried by the payment test instruction is obtained, that is, the amount unit conversion is rounded to the nearest integer according to the minimum amount unit of the target currency type when the automatic amount unit conversion is selected. If the automatic amount unit conversion is not selected, the amount is not processed, and the payment is made according to the requested amount. For example: the minimum unit of currency type A is an integer, and decimal points are not supported. For 100 currency type A, no conversion is performed, 100.23 currency type A is converted to 100 currency type A, and 100.54 currency type A is converted to 101 currency type A. This method solves the problem of different currency amount units in the test and the need to manually modify the amount, thereby improving the efficiency of the test.

[0070] For international credit card payment, different modes need to be tested: SALE (consumption) / AUTH (pre-authorization), and corresponding tests need to be conducted: REFUND (refund) / VOID (cancellation), including partial amount tests: REFUND (refund) / VOID (cancellation). In addition, the previous test required waiting for the payment to be successful before executing it manually, which was not automated enough. The entire execution process was cumbersome and time-consuming.

[0071] In an exemplary embodiment, Figure 4 , a transaction type testing method is provided, including steps 402 to 406, wherein: Step 402: Initiate a payment request to a payment channel according to the test amount and transaction type, and receive a test amount transfer result fed back by the payment channel in response to the payment request.

[0072] Among them, the payment request can be consumption or pre-authorization. Each transaction type has associated transaction operations. Transaction types can include consumption and pre-authorization. SALE (consumption) refers to consumption on a credit card and the amount is directly deducted. AUTH (pre-authorization) refers to credit card pre-authorization and the amount is frozen without deduction. Consumption-related transaction operations include full refund and partial refund, and pre-authorization-related transaction operations include full cancellation and partial cancellation.

[0073] Exemplarily, based on the test limit and transaction type, a payment request is initiated to a payment channel. The payment channel can serve as a primary payment channel to send the payment request to a credit card organization via a secondary / tertiary payment channel. The credit card organization transfers the test limit corresponding to the payment request and feeds back the processing result to the primary payment channel, which receives the test limit transfer result fed back by the primary payment channel for the payment request.

[0074] Step 404, when the test credit transfer result is a preset test credit transfer result, in response to a transaction operation triggered by the test credit transfer result, execute a transaction operation to perform a transaction rollback process on the test credit.

[0075] It is understandable that the payment system may result in a full refund / reversal, but a partial refund / reversal may fail. To ensure the reliability of the refund / reversal, the transaction rollback process for the test amount includes the following two situations: Case 1: When the transaction operation is a full refund / cancellation, in response to the transaction operation triggered by the test quota transfer result, the transaction operation is executed to perform transaction rollback processing on the test quota.

[0076] Among them, full refund / cancellation can be understood as a full refund / cancellation can be achieved by executing a single transaction operation. For example, when the result of the payment channel, that is, the test credit transfer result, is obtained, when the test credit transfer result is the preset test credit transfer result, the user selects automatic (REFUND (refund) / VOID (cancellation)), if the payment is successful (SALE (consumption) / AUTH (pre-authorization)), it will automatically execute (REFUND (refund) / VOID (cancellation)) and record all results. If the test credit transfer result is not the preset test credit transfer result, that is, the payment fails (SALE (consumption) / AUTH (pre-authorization)), the payment (SALE (consumption) / AUTH (pre-authorization)) result will not be executed and recorded.

[0077] Case 2: When the transaction operation is a partial refund / cancellation, in response to the transaction operation triggered by the test quota transfer result, the number of operations of the transaction operation is determined; based on the number of operations and the test quota, the rollback amount for each transaction operation is determined; the number of operations of the transaction operation is executed, and the test quota is processed for transaction rollback according to the rollback amount corresponding to each operation.

[0078] Among them, the number of operations can be preset, and partial refund / cancellation can be understood as refund / cancellation in batches to achieve full refund / cancellation. For example, when the result of the payment channel, that is, the test credit transfer result, is obtained, when the test credit transfer result is the preset test credit transfer result, the user selects partial amount automatic (REFUND (refund) / VOID (cancellation)), if the payment is successful (SALE (consumption) / AUTH (pre-authorization)), automatically execute (REFUND (refund) / VOID (cancellation)), and record all results. The specific implementation method is to divide the order into two operations, first divide the amount by 2, if the decimal point exceeds two, round to two decimal places, get the first amount, then subtract the first amount from the total amount to get the second amount, execute (REFUND (refund) / VOID (cancellation)) and record all results. If the payment fails, the payment (SALE (consumption) / AUTH (pre-authorization)) result is not executed and recorded.

[0079] Step 406: If the result of the transaction rollback process is the same as the preset result, it is determined that the payment channel is normal.

[0080] Exemplarily, if the processing result of the transaction rollback process is the same as the preset result, it is determined that the payment channel is normal, and the SALE (consumption) / AUTH (pre-authorization), REFUND (refund) / VOID (cancellation) results of all selected target currency types and abnormal scenario results are summarized and returned to the web page for display to the user.

[0081] In the above embodiment, when requesting the payment channel to complete the payment, in response to the transaction operation associated with the transaction type triggered by the test limit transfer result, the transaction operation is executed, and the test limit is subject to transaction rollback, which solves the problem of different credit card payment modes requiring waiting for payment (SALE (consumption) / AUTH (pre-authorization)) to succeed before manually executing REFUND (refund) / VOID (cancellation).

[0082] Optionally, in an exemplary embodiment, the test parameters include abnormal scenario testing, and the method further includes: when the target currency type has been tested, performing abnormal scenario testing on the payment channel; the abnormal scenario testing at least includes one or more of initiating payment without transmitting the payment password, initiating payment with an incorrect payment password, and initiating payment with an incorrect validity date. This method solves the problem that some abnormal scenarios of credit card testing need to be manually executed.

[0083] In an exemplary embodiment, a payment channel testing method is provided, wherein the method is applied to Figure 1 The following is an example of a server in the example: In response to a payment test instruction, determine the payment channel to be tested and the test parameters of different payment dimensions associated with the payment channel; determine the payment tool that matches the payment channel; identify the payment tool according to the tool type of the payment channel and the payment tool, and extract the identification information of the payment tool; determine the target area to which the payment tool belongs according to the identification information; determine the first attribute information of the holder of the payment tool based on the target area; send the second attribute information and the first attribute information of the payment tool to the payment channel for risk control verification, and determine at least one target currency type from the preset currency list in the absence of risk; Determine the test cases corresponding to each test parameter and the dependencies between the test parameters; determine the test order of each test case based on the dependencies between the test parameters; for each target currency type, if the target currency type in the business order is different from the specified currency type, determine the data conversion value between the target currency type and the specified currency type; if the quota unit conversion is required, determine the candidate test quota corresponding to the target currency type based on the data conversion value and the specified quota; determine the minimum quota unit of the target currency type, and convert the quota unit of the candidate test quota based on the minimum quota unit to obtain a test quota that only includes the minimum quota unit. Initiate a payment request to the payment channel based on the test quota and transaction type, and receive the test quota transfer result fed back by the payment channel for the payment request.

[0084] In the case where the test credit transfer result is the preset test credit transfer result, if the transaction operation is a full refund / cancellation, in response to the transaction operation triggered by the test credit transfer result, the transaction operation is executed, and the test credit is processed for transaction rollback; in the case where the transaction operation is a partial refund / cancellation, in response to the transaction operation triggered by the test credit transfer result, the number of operations of the transaction operation is determined; based on the number of operations and the test credit, the rollback amount for each execution of the transaction operation is determined; the number of operations performed on the transaction operation is calculated, and the test credit is processed for transaction rollback according to the rollback amount corresponding to each operation.

[0085] After the tests for the target currency types have been completed, perform abnormal scenario tests on the payment channels; the abnormal scenario tests include at least one or more of initiating payment without transmitting the payment password, initiating payment with an incorrect payment password, and initiating payment with an incorrect validity date.

[0086] It should be noted that the specific implementation method of this embodiment can be achieved through the above-mentioned limitation method, which will not be elaborated here.

[0087] In an exemplary embodiment, Figure 5As shown, it is a flow chart of the testing method of the payment channel. The web page includes different types of input components, which can provide the following inputs to determine the test parameters. The supported inputs include: inputting the payment channel to be tested and the test amount, providing multiple choices of multiple currencies, whether to automatically convert the amount unit, whether to specify the currency type and the specified amount (for example, testing the amount of the test currency in which the US dollar is exchanged), whether to automatically REFUND (refund) / VOID (cancel), whether to automatically implement REFUND (refund) (void) (cancel) of a partial amount, and the user continues to enter the card number, validity period, payment password, and prepare to start the test.

[0088] Click on the page to start the test. The page initiates a request to the backend program. The program executes. The program tests the payment channel selected in the request parameter, that is, the payment channel to be tested, determines the credit cards supported by the payment channel, receives the card information in the request parameter, and queries the corresponding issuing bank / institution information according to the first six digits of the card number (card bin), and randomly selects according to the country of the credit card to generate personal information. The program loops through all the currencies in the parameters in turn. When there is a currency, the order number is generated in the format of year, month, day, hour, minute, second + random 4-digit letters for testing. When there is no currency loop, the currency-related test ends. The program accepts whether to specify the amount in the request parameter. When the specified amount is selected, the program will pay in US dollars as the test currency. The program accepts whether to perform automatic amount unit conversion in the request parameter. When automatic amount unit conversion is selected, the program will round the amount according to the minimum amount unit of the currency. If this parameter is not selected, the amount will not be processed and payment will be made according to the amount entered in the request.

[0089] The program accepts the transaction type in the request parameter to initiate payment (SALE (consumption) / AUTH (pre-authorization)). When the result of the payment channel is obtained, the user selects automatic (REFUND (refund) / VOID (cancellation)). If the payment is successful (SALE (consumption) / AUTH (pre-authorization)), if the payment is successful (SALE (consumption) / AUTH (pre-authorization)), it will automatically execute (REFUND (refund) / VOID (cancellation)) and record all the results. If the payment fails (SALE (consumption) / AUTH (pre-authorization)), it will not execute and record the payment (SALE (consumption) / AUTH (pre-authorization)) result. When the result of the payment channel is obtained, the user selects automatic partial amount (REFUND (refund) / VOID (cancellation)). If the payment is successful (SALE (consumption) / AUTH (pre-authorization)), it will automatically execute (REFUND (refund) / VOID (cancellation)) and record all the results. When there is no currency circulation, the currency test ends, and the program will execute the abnormal scenario, and return the SALE (consumption) / AUTH (pre-authorization), REFUND (refund) / VOID (cancellation) results of all selected currencies and the abnormal scenario results summary to the web page for display to the user.

[0090] In the above embodiment, by responding to the payment test instruction, the payment channel to be tested and the test parameters of different payment dimensions associated with the payment channel, as well as the payment tool matching the payment channel are automatically determined; according to the tool type of the payment channel and the payment tool, at least one target currency type is determined from the preset currency list; the test cases corresponding to each test parameter and the dependency relationship between the test parameters are determined; according to the dependency relationship between the test parameters, the test order of each test case is determined; for each target currency type, the test cases corresponding to the test order are sequentially selected to obtain the test data of the payment channel, that is, each currency is split into a single task for cyclic execution to obtain the test data of each test task. The test results show that after the target currency types have been tested, the payment channels are tested for abnormal scenarios, which solves the problems of low efficiency of batch currency testing of credit cards, different currency amount units in the test, which require manual modification of the amount, different test amounts due to different currency exchange rates in the test, which require manual calculation and modification of the amount, different payment modes of credit cards, which require waiting for payment (SALE / AUTH) to succeed before manually executing REFUND / VOID, credit card testing requiring manual generation of personal information, and information leakage in credit card testing. This improves test efficiency and ensures the security and reliability of payment, thereby improving user experience.

[0091] It is understandable that the above payment channel testing method can be applied to a terminal, on which a payment channel testing tool is deployed, such as Figure 6As shown, it is a schematic diagram of the system architecture of the test tool in an exemplary embodiment. The system architecture of the test tool includes a web page layer and a Python program. The specific structure includes a web page, an interaction layer, a control layer, a business processing layer, an external call layer, a payment channel under test (i.e., a payment channel to be tested) and an external payment channel. The payment channel under test can be called a first-level channel, and the external payment channel includes second-level, third-level and above channels.

[0092] Among them, in the web page layer, the web page is written by Bootstrap template, html and css and jquery library, and the browser forms a graphical interface through the above code. Users can use the browser (HTTP GET) to access the content of the web page. The interaction layer includes template engine rendering, POST request, Get request and Ajax request, the control layer includes Flask rendertemplate, Flask request, Flask jsonify and Python, the business processing layer includes Python multiprocessing module and program processing, the external call layer includes Python requests module, POST and GET, the tested payment channel can include but is not limited to tested payment channel 1 and tested payment channel 2, and the external payment channel can include multiple external payment channels, namely external payment channel 1, ..., external payment channel n. In the interaction layer, the web page is returned by the Flask render templete module of the control layer to complete the interaction. The request processing realizes the interaction through the jquery library.

[0093] Exemplarily, the user inputs the payment channel to be tested and each processing option (i.e., test parameter) through the web page of the test tool to initiate the test, initiates an HTTP (POST) request through the Ajax method of the jquery module for interaction, and the Flask request module of the control layer receives the requested processing options (test parameters).

[0094] When the control layer receives the processing options (test parameters), it stores the test parameters inside the program.

[0095] Then the program enters the business processing layer. Entering the business processing layer, the Python program first selects the payment channel to be tested, then determines the payment tool that matches the payment channel, enters the card information, automatically generates personal information based on the country of the credit card, and enters the next test phase. The next phase program splits each currency into a single task loop execution, and the task steps are as follows: generate an order number, determine the specified test amount, determine the automatic conversion amount unit, automatically select the payment mode, and then request the payment channel.

[0096] Entering the external call layer, the program initiates HTTP POST / GET requests through the Python requests module to interact with the payment channel under test. The payment channel under test returns the payment result.

[0097] Then continue to execute the next step of the task to determine whether to automatically perform REFUND (refund) / VOID (cancellation) and perform exception testing. The above tests collect test results through the json module module of the business processing layer. The python multiprocessing module can be used to implement parallel execution of multiple tasks and speed up test execution.

[0098] After all tests are completed, the business processing layer will return the test results to the control layer, and then the Flaskjsonify module of the control layer will convert the test results into HTTP content and return it to the Web page layer. Users can view the test results through the Web page.

[0099] This method solves the problems of low efficiency of batch currency testing of credit cards, different currency amount units during testing, which require manual modification of the amount, different currency exchange rates during testing resulting in different test amounts, which require manual calculation and modification of the amount, different payment modes of credit cards, which require waiting for payment (SALE / AUTH) to succeed before manually executing REFUND / VOID, credit card testing requiring manual generation of personal information, and information leakage during credit card testing. It improves testing efficiency and ensures the security and reliability of payment, thereby improving user experience.

[0100] It should be understood that, although the various steps in the flowcharts involved in the above-mentioned embodiments are displayed in sequence according to the indication of the arrows, these steps are not necessarily executed in sequence according to the order indicated by the arrows. Unless there is a clear explanation in this article, the execution of these steps does not have a strict order restriction, and these steps can be executed in other orders. Moreover, at least a part of the steps in the flowcharts involved in the above-mentioned embodiments can include multiple steps or multiple stages, and these steps or stages are not necessarily executed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily to be carried out in sequence, but can be executed in turn or alternately with other steps or at least a part of the steps or stages in other steps.

[0101] Based on the same inventive concept, the embodiment of the present application also provides a payment channel testing device for implementing the payment channel testing method involved above. The implementation scheme for solving the problem provided by the device is similar to the implementation scheme recorded in the above method, so the specific limitations in the embodiments of the testing device for one or more payment channels provided below can refer to the limitations of the payment channel testing method above, and will not be repeated here.

[0102] In an exemplary embodiment, Figure 7 As shown, a payment channel testing device is provided, including: an interaction module 702, a data determination module 704, a data processing module 706 and a testing module 708, wherein: An interaction module 702, for determining a payment channel to be tested and a plurality of test parameters associated with the payment channel in response to a payment test instruction; A data determination module 704, used to determine a payment instrument that matches a payment channel; According to the payment channel and the instrument type of the payment instrument, at least one target currency type is determined from the preset currency list; The data processing module 706 is used to determine the test cases corresponding to each test parameter and the dependency relationship between the test parameters; Determine the test order of each test case based on the dependency relationship between the test parameters; The testing module 708 is used to obtain the test data of the payment channel according to the test cases corresponding to each target currency type in the test sequence.

[0103] The above-mentioned payment channel testing device, in order to realize testing of different payment channels, automatically determines the payment channel to be tested and the test parameters of different payment dimensions associated with the payment channel, and determines the payment tool matching the payment channel by responding to the payment test instruction; determines at least one target currency type from the preset currency list according to the tool type of the payment channel and the payment tool; determines the test cases corresponding to each test parameter, and the dependency relationship between the test parameters; determines the test order of each test case according to the dependency relationship between the test parameters; for each target currency type, obtains the test data of the payment channel according to the test cases corresponding to the test order, that is, splits each currency into a single task for cyclic execution to obtain the test result of each test task. This testing method can perform payment function testing in batches on the payment channel, and the test tasks for different payment tools and different payment dimensions do not need to be manually processed, thereby improving the efficiency of the test.

[0104] In an exemplary embodiment, the testing device of the payment channel also includes a data conversion module, which is used to determine the data conversion value between the target currency type and the specified currency type for each target currency type if the target currency type in the business order is different from the specified currency type; and determine the test amount of the target currency type based on the data conversion value and the specified amount.

[0105] The testing module 708 is also used to initiate a payment request to the payment channel based on the test amount and transaction type, and obtain test data of the payment channel.

[0106] In an exemplary embodiment, the testing device of the payment channel further includes a unit conversion module for determining a candidate test amount corresponding to the target currency type according to the data conversion value and the specified amount; The minimum quota unit of the target currency type is determined, and the quota unit of the candidate test quota is converted according to the minimum quota unit to obtain the test quota including only the minimum quota unit.

[0107] The test module 708 is further used to initiate a payment request to the payment channel according to the test amount and the transaction type, and receive the test amount transfer result fed back by the payment channel in response to the payment request; When the test credit transfer result is a preset test credit transfer result, in response to a transaction operation associated with the transaction type triggered by the test credit transfer result, the transaction operation is executed to perform transaction rollback processing on the test credit; If the result of the transaction rollback process is the same as the preset result, it is determined that the payment channel is normal.

[0108] The test module 708 is further configured to execute a transaction operation in response to a transaction operation triggered by a test credit transfer result, and perform a transaction rollback process on the test credit when the transaction operation is a full refund / cancellation; In the case where the transaction operation is a partial refund / reversal, in response to the transaction operation triggered for the test credit transfer result, determining the operation count of the transaction operation; Determine the fallback amount for each transaction operation based on the number of operations and the test amount; The transaction operation is executed the number of times, and the test amount is rolled back according to the corresponding rollback amount of each operation.

[0109] The test module 708 is also used to perform abnormal scenario testing on the payment channel when the test of the target currency type has been completed; the abnormal scenario testing includes at least one or more of initiating payment without transmitting the payment password, initiating payment with an incorrect payment password, and initiating payment with an incorrect validity date.

[0110] The testing device of the payment channel also includes a personal information generation module, which is used to identify the payment tool and extract the identification information of the payment tool; Determine the target region to which the payment instrument belongs based on the identification information; Determining first attribute information of a holder of a payment instrument based on the target region; The second attribute information and the first attribute information of the payment instrument are sent to the payment channel for risk control verification.

[0111] Each module in the test device of the payment channel can be implemented in whole or in part by software, hardware and a combination thereof. Each module can be embedded in or independent of a processor in a computer device in the form of hardware, or can be stored in a memory in a computer device in the form of software, so that the processor can call and execute the operations corresponding to each module.

[0112] In an exemplary embodiment, a computer device is provided. The computer device may be a terminal, and its internal structure diagram may be as shown in FIG. Figure 8 As shown. The computer device includes a processor, a memory, an input / output interface, a communication interface, a display unit and an input device. Among them, the processor, the memory and the input / output interface are connected through a system bus, and the communication interface, the display unit and the input device are connected to the system bus through the input / output interface. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The input / output interface of the computer device is used to exchange information between the processor and the external device. The communication interface of the computer device is used to communicate with an external terminal in a wired or wireless manner, and the wireless manner can be implemented through WIFI, a mobile cellular network, near field communication (Near Field Communication, NFC) or other technologies. When the computer program is executed by the processor, a payment channel testing method is implemented. The display unit of the computer device is used to form a visually visible picture, which can be a display screen, a projection device or a virtual reality imaging device. The display screen can be a liquid crystal display screen or an electronic ink display screen, and the input device of the computer device can be a touch layer covering the display screen, or a button, trackball or touchpad set on the computer device shell, or an external keyboard, touchpad or mouse.

[0113] Those skilled in the art will understand that Figure 8The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.

[0114] In one embodiment, a computer device is further provided, including a memory and a processor, wherein a computer program is stored in the memory, and the processor implements the steps in the above method embodiments when executing the computer program.

[0115] In one embodiment, a computer device is further provided, including a memory and a processor, wherein a computer program is stored in the memory, and the processor implements the steps in the above method embodiments when executing the computer program.

[0116] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the steps in the above-mentioned method embodiments are implemented.

[0117] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with relevant regulations.

[0118] A person of ordinary skill in the art can understand that all or part of the processes in the above-mentioned embodiment method can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to the memory, database or other medium used in the embodiments provided in the present application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. As an illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The database involved in each embodiment provided in this application may include at least one of a relational database and a non-relational database. Non-relational databases may include distributed databases based on blockchains, etc., but are not limited to this. The processor involved in each embodiment provided in this application may be a general-purpose processor, a central processing unit, a graphics processor, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, an artificial intelligence (AI) processor, etc., but are not limited to this.

[0119] The technical features of the above embodiments may be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0120] The above-described embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be construed as limiting the scope of the present application. It should be noted that, for a person of ordinary skill in the art, several modifications and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the attached claims.

Claims

1. A payment channel testing method, characterized in that: The method comprises: In response to the payment test instruction, determining a payment channel to be tested and test parameters of different payment dimensions associated with the payment channel; Determining a payment instrument that matches the payment channel; Determining at least one target currency type from a preset currency list according to the payment channel and the instrument type of the payment instrument; Determine the test cases corresponding to the test parameters and the dependencies between the test parameters; Determining the test order of each of the test cases according to the dependency relationship between the test parameters; For each of the target currency types, the test cases corresponding to the test sequence are sequentially checked to obtain the test data of the payment channel.

2. The method according to claim 1, characterized in that The test parameters include a specified currency type, a specified amount corresponding to the specified currency type, and a transaction type. For each target currency type, the test cases corresponding to the test sequence are sequentially tested to obtain test data of the payment channel, including: For each of the target currency types, if the target currency type in the business order is different from the specified currency type, determining a data conversion value between the target currency type and the specified currency type; Determining a test amount of the target currency type according to the data conversion value and the specified amount; A payment request is initiated to the payment channel based on the test amount and the transaction type to obtain test data of the payment channel.

3. The method according to claim 2, characterized in that The test parameters also include quota unit conversion, and determining the test quota of the target currency type according to the data conversion value and the specified quota includes: Determine a candidate test amount corresponding to the target currency type according to the data conversion value and the specified amount; The minimum quota unit of the target currency type is determined, and the quota unit of the candidate test quota is converted according to the minimum quota unit to obtain a test quota including only the minimum quota unit.

4. The method according to claim 2, characterized in that: The initiating a payment request to the payment channel based on the test amount and the transaction type to obtain test data of the payment channel includes: Initiate a payment request to the payment channel according to the test amount and the transaction type, and receive a test amount transfer result fed back by the payment channel in response to the payment request; When the test credit transfer result is a preset test credit transfer result, in response to a transaction operation associated with the transaction type triggered by the test credit transfer result, executing the transaction operation, and performing transaction rollback processing on the test credit; If the processing result of the transaction rollback process is the same as the preset result, it is determined that the payment channel is normal.

5. The method according to claim 4, characterized in that The step of executing the transaction operation associated with the transaction type in response to the test credit transfer result and performing transaction rollback processing on the test credit includes: In the case where the transaction operation is a full refund / cancellation, in response to the transaction operation triggered by the test credit transfer result, the transaction operation is executed to perform transaction rollback processing on the test credit; In the case where the transaction operation is a partial refund / cancellation, in response to the transaction operation triggered by the test credit transfer result, determining the operation number of the transaction operation; Determine the refund amount for each execution of the transaction operation according to the number of operations and the test amount; The transaction operation is executed the number of times, and the test amount is subjected to transaction rollback processing according to the rollback amount corresponding to each operation.

6. The method according to any one of claims 1 to 5, characterized in that: The test parameters include abnormal scenario testing, and the method further includes: When the test of the target currency type is completed, an abnormal scenario test is performed on the payment channel; the abnormal scenario test includes at least one or more of initiating payment without transmitting the payment password, initiating payment with an incorrect payment password, and initiating payment with an incorrect validity date.

7. The method according to claim 1, characterized in that The method further comprises: Identify the payment tool and extract identification information of the payment tool; Determining the target region to which the payment tool belongs according to the identification information; Based on the target region, determining first attribute information of a holder of the payment instrument; The second attribute information and the first attribute information of the payment tool are sent to the payment channel for risk control verification. When there is no risk, the step of determining at least one target currency type from a preset currency list based on the payment channel and the tool type of the payment tool is performed.

8. A payment channel testing device, characterized in that: The device comprises: an interaction module, configured to determine, in response to a payment test instruction, a payment channel to be tested and a plurality of test parameters associated with the payment channel; A data determination module, used to determine a payment instrument that matches the payment channel; Determining at least one target currency type from a preset currency list according to the payment channel and the instrument type of the payment instrument; A data processing module, used to determine the test cases corresponding to each of the test parameters, and the dependencies between the test parameters; Determining the test order of each of the test cases according to the dependency relationship between the test parameters; The test module is used to obtain the test data of the payment channel according to the test cases corresponding to each target currency type in the test sequence.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 7 are implemented.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 7 are implemented.

11. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 7 are implemented.

Images