Payment processing method based on self-checkout device, electronic device, and storage medium

Abstract

The application provides a payment processing method based on a self-service checkout device, an electronic device and a storage medium. According to an embodiment of the application, in response to a request for a target payment process corresponding to an editing target payment channel submitted in an editing interface, a plurality of payment nodes commonly used for a plurality of payment channels in a payment scenario are obtained and displayed in the editing interface, a target payment node selected from the plurality of displayed payment nodes is obtained, and a target payment template is constructed according to a node configuration file group, and then the target payment template is associated and bound with the target payment channel. The scheme of the embodiment of the application disassembles the payment process into reusable payment nodes, defines node attributes through a node configuration file, and can complete the construction and adjustment of the payment template through the interactive operation of the editing interface. When a payment channel needs to be added or changed, the payment channel can be quickly put into operation and flexibly configured through the editing interface.

Description

Technical Field

[0001] This application relates to the field of commodity transaction technology, and in particular to a payment processing method, electronic device, storage medium, and computer program product based on self-checkout equipment. Background Technology

[0002] With the advancement of digital transformation in the retail industry, self-checkout machines have been widely used in offline physical stores such as supermarkets, convenience stores, and shopping malls to replace or assist manual cashiers, thereby reducing labor costs and improving customer checkout efficiency. Self-checkout machines typically integrate functions such as product scanning, weight comparison, card / scan payment, and receipt printing, allowing customers to complete product scanning and payment operations independently without cashier intervention.

[0003] Compared to online e-commerce payment methods, offline self-checkout machines need to be compatible with various payment channels, including physical cards, payment codes, and different merchants or physical stores, creating a multi-channel offline payment environment. Each payment channel often requires a separately customized payment process, which presents challenges such as deployment difficulties, high time costs, and frequent version iterations. Therefore, a new payment processing solution is needed. Summary of the Invention

[0004] This application provides a payment processing method, electronic device, storage medium, and computer program product based on self-checkout equipment to solve one or more of the above-mentioned technical problems.

[0005] In a first aspect, embodiments of this application provide a payment processing method based on a self-service checkout device, comprising: responding to a request submitted in an editing interface to edit a target payment process corresponding to a target payment channel; obtaining multiple payment nodes applicable to multiple payment channels in a payment scenario, and displaying the multiple payment nodes in the editing interface; obtaining multiple target payment nodes selected from the displayed multiple payment nodes, and combining the multiple target payment nodes into a target payment template according to the node configuration file of the target payment nodes; the node configuration file records the node attributes of the payment nodes; associating and binding the target payment template with a target payment channel, so that when a payment is initiated through the target payment channel, the target payment template is invoked to execute the corresponding payment process; wherein, the payment nodes are extracted from a pre-configured payment scenario model, and the payment scenario model defines multiple payment nodes applicable to the payment scenario.

[0006] Secondly, embodiments of this application provide a method for invoking a target payment channel in response to a payment request from a self-checkout device; Obtain the target payment template bound to the target payment channel. The target payment template is composed of multiple target payment nodes based on the node configuration file of the selected target payment node. The target payment node is selected from multiple payment nodes that are applicable to multiple payment channels under the payment scenario displayed in the editing interface. The multiple payment nodes displayed in the editing interface are obtained in response to the request submitted in the editing interface to edit the target payment process corresponding to the target payment channel. The payment node is extracted from a pre-configured payment scenario model. The payment scenario model defines multiple payment nodes that are common to the payment scenario. The node configuration file records the node attributes of the payment node. Call the payment template to execute the corresponding payment process.

[0007] Thirdly, embodiments of this application provide an electronic device, including a memory, a processor, and a computer program stored in the memory, wherein the processor implements the above-described method when executing the computer program.

[0008] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method.

[0009] Fifthly, embodiments of this application provide a computer program product, wherein the computer program product includes a computer program that, when executed by a processor, implements the above-described method.

[0010] According to the embodiments of this application, in response to a request submitted in the editing interface to edit the target payment process corresponding to the target payment channel, multiple payment nodes applicable to various payment channels in the payment scenario are obtained and displayed in the editing interface. The target payment node selected from the displayed multiple payment nodes is obtained and constructed into a target payment template according to its node configuration file. Then, the target payment template is associated and bound to the target payment channel, thereby realizing the visual orchestration and dynamic configuration of the payment process. Thus, the solution of this application embodiment decomposes the payment process into general, reusable payment nodes and defines node attributes through node configuration files. The construction and adjustment of the payment template can be completed through interactive operations in the editing interface. When a new or changed payment channel is needed, only the corresponding payment template needs to be rearranged and bound to the new channel through the editing interface to achieve rapid deployment and flexible configuration of the payment channel. There is no need to modify the underlying code or redeploy the software version, fundamentally avoiding the frequent release problems caused by the explosive growth of payment channels or interface changes in traditional solutions. In summary, this application realizes the node-based production, visual orchestration, and dynamic connection of the payment process, significantly improving the compatibility and operational efficiency of offline self-checkout equipment with multiple payment channels, and solving the technical problems in the prior art such as strong coupling between payment channels and business code, frequent version iterations, and difficulties in deployment across physical stores.

[0011] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application, it can be implemented according to the contents of the specification. In order to make the above and other objects, features and advantages of this application more obvious and understandable, specific embodiments of this application are given below. Attached Figure Description

[0012] In the accompanying drawings, unless otherwise specified, the same reference numerals throughout the various drawings denote the same or similar parts or elements. These drawings are not necessarily drawn to scale. It should be understood that these drawings depict only some embodiments according to this application and should not be construed as limiting the scope of this application.

[0013] Figure 1 A schematic diagram of a payment scenario model provided in an embodiment of this application is shown; Figure 2 A schematic diagram of a design architecture of an embodiment of the present application is shown; Figure 3 A schematic diagram illustrating the execution process of each party in the embodiments of this application is shown; Figure 4 A schematic diagram illustrating the payment process in an embodiment of this application is shown; Figure 5 A flowchart of a payment processing method based on a self-checkout device provided in an embodiment of this application is shown; Figure 6 A flowchart of another payment processing method based on a self-checkout device provided in an embodiment of this application is shown; Figure 7 This paper shows a structural block diagram of a payment processing device based on a self-checkout device provided in an embodiment of this application; Figure 8 This application shows a structural block diagram of another payment processing device based on a self-checkout device provided in an embodiment of the present application; and Figure 9 A block diagram of an electronic device used to implement embodiments of this application is shown. Detailed Implementation

[0014] In the following description, only certain exemplary embodiments are briefly described. As those skilled in the art will recognize, the described embodiments can be modified in various ways without departing from the concept or scope of this application. Therefore, the drawings and description are considered to be exemplary in nature and not restrictive.

[0015] To facilitate understanding of the technical solutions of the embodiments of this application, the relevant technologies of the embodiments of this application are described below. The following relevant technologies are optional solutions and can be combined with the technical solutions of the embodiments of this application in any way, and all of them fall within the protection scope of the embodiments of this application.

[0016] Compared to online e-commerce (such as payments via apps or websites), offline self-checkout devices face significantly different payment processing scenarios. The main technical challenges lie in the fact that online payment channels are relatively unified, typically requiring integration with only a few mainstream payment service providers. Furthermore, each online platform can independently select and integrate its own payment interfaces, unconstrained by physical devices. In contrast, offline self-checkout devices must be compatible with the numerous existing payment channels already in use at manual checkout counters, including but not limited to: various bank cards (debit / credit cards), transportation cards, prepaid membership cards, shopping / gift cards, third-party payment codes, and some regional payment tools (such as local transit cards). Different merchants, different physical stores, and even different regional stores within the same chain often support different sets of payment channels, creating a "multi-channel, heterogeneous, and highly compatible" offline payment environment.

[0017] To address the compatibility requirements of multiple payment channels, existing technologies typically integrate all payment channels of a physical store into the software system of the self-checkout device, with each channel corresponding to an independent payment call logic. However, this approach suffers from the problem of strong coupling between payment channels and business code. When a new payment channel is added or the interface of a channel changes, the entire checkout software needs to be modified, tested, and redeployed, resulting in long iteration cycles and high maintenance costs.

[0018] To address the aforementioned issues, this application provides a payment processing solution based on self-checkout equipment. The payment channels involved refer to the diverse payment methods that customers can choose when settling accounts for goods or services, including but not limited to: cash payment, software QR code payment, physical gift cards or stored-value cards issued by various merchants, bank card (debit / credit card) swiping or inserting card payment, transportation card payment, third-party prepaid card payment, and regional e-wallet payment, etc.

[0019] The payment process refers to the series of steps or interactions from when a customer initiates a payment request to when the payment is finally deducted. This process varies depending on the payment channel used. For example, cash payments typically only require recording the amount of cash the customer inserts and calculating change, without needing to call a third-party payment interface; software payments require generating a QR code, waiting for the customer to scan it, receiving a payment callback notification, and verifying the payment result; merchant gift card payments may involve multiple dedicated steps such as card balance inquiry, password verification, amount deduction, and balance update. Therefore, different payment channels correspond to different payment processes, involving different node configurations, interface call rules, exception handling mechanisms, and user interfaces.

[0020] In the solution of this application embodiment, a payment scenario model is pre-configured. This model defines multiple payment nodes that are common to payment scenarios. Multiple payment nodes that are applicable to multiple payment channels are extracted from the pre-configured payment scenario model and displayed in the editing interface for selection.

[0021] The editing interface is a visual configuration interface provided to the operations or R&D personnel of physical stores. It's used to orchestrate, combine, and manage payment processes. It's displayed when a request to edit the payment process is triggered. For example, when operations personnel need to create or modify a payment template for a merchant's gift card payment channel, they access the editing function in the payment channel management software, triggering an editing request, loading, and displaying the editing interface. The editing interface displays multiple common payment nodes extracted from the payment scenario model. Users can select a target payment node from the displayed nodes through drag-and-drop, point-and-click, or line-connection interactions to combine the target payment template. Through this editing interface, the payment process can be configured without writing code.

[0022] Each payment node can be understood as corresponding to an atomic payment operation. Furthermore, the multiple nodes involved in the payment process can be divided into multiple node sets (or domains). Each node set can be viewed as an aggregate category of payment nodes, used to categorize and organize nodes belonging to the same payment stage. The payment scenario model also describes multiple node sets and the correspondence between node sets and payment nodes. Figure 1 This illustration shows a schematic diagram of a payment scenario model provided in an embodiment of this application. Exemplarily, the payment process is divided into multiple domains according to business stages, specifically including: an input domain, a verification domain, a query domain, a payment domain, a cancellation domain, and a hook domain. The input domain is further subdivided into three node types: QR code input, manual input, and card swipe input, corresponding to three parameter acquisition methods: barcode scanner reading, manual input, and card reader reading, respectively. The verification domain is further subdivided into multiple node branches such as code verification, card verification, coupon verification, and single verification, multiple verification, and no verification required, used to perform corresponding legality verification based on different payment media and verification strategies. The query domain is further subdivided into nodes such as online query, offline query, and multiple query, used to obtain order or payment status information based on network status and business needs. The payment domain is further subdivided into nodes such as online payment, offline payment, and automatic payment, used to perform deduction operations under different modes. The cancellation domain is further subdivided into nodes such as manual cancellation, automatic cancellation, and no cancellation required, used to handle order cancellation or refund logic. The hook domain is further subdivided into nodes such as additional information hooks, used to insert custom extended logic at specific locations in the payment process. By dividing the domains and refining the nodes within each domain, this application can structurally decompose the complex offline payment process according to business semantics, making the management of payment nodes clearer and facilitating the independent configuration, reuse, and orchestration of nodes in different domains.

[0023] The payment scenario model is configured with scenario annotation data, which describes the node set attributes of the payment node set and the node attributes corresponding to the payment node. Specifically, node set attributes may include one or more of the following: node set type (used to identify the domain to which the node belongs, such as input domain, validation domain, etc.) and node set name (used to uniquely identify the name or identifier of the payment domain); node attributes may further include at least one of the following: node function (defining the specific functional logic called when the node is executed), node connection relationship (used to specify the previous node of the current node and the nodes to be connected to, thus forming a directed acyclic graph structure of the payment process), calling interface (defining the external API or internal service interface to be called when the node is executed), and interface parameters (defining the parameter name, type, and format to be passed when calling the above interface). By configuring the above scenario annotation data, this application achieves the decoupling of the payment node from its specific implementation logic, allowing the same payment node to reuse the same node definition in different scenarios or different payment channels. Only the functions, interfaces, or parameters in the annotation data need to be adjusted to adapt to different business needs, thereby improving the configurability and scalability of the payment process.

[0024] In one implementation, the complete payment process within a payment scenario can be analyzed to identify multiple common payment stages. For each payment stage, a corresponding node set is created, with one or more payment nodes pre-configured for each stage. For example, in the input stage, QR code input nodes and manual input nodes are configured; in the verification stage, code verification nodes, card verification nodes, and coupon verification nodes are configured. The payment node sets and the payment nodes within each set are organized according to a preset data structure to generate a payment scenario model. The payment scenario model can be stored in JSON, XML, or database tables to describe the multiple common payment nodes and their logical relationships. Furthermore, set attributes are configured for each node set, and corresponding node attributes are configured for each payment node, organized according to a preset format (such as JSON, XML, or Java annotation syntax) to generate scenario annotation data. This data can be stored in association with the payment scenario model for later retrieval during parsing.

[0025] By parsing the payment scenario model and the associated scenario annotation data, multiple node sets and corresponding payment nodes can be obtained, such as QR code input nodes under the input domain, card verification nodes under the verification domain, and online payment nodes under the payment domain. After obtaining the payment nodes, a corresponding node configuration file is generated for each payment node according to the node attributes defined in the scenario annotation data. This file records the node attributes of the payment node. Through this step, the abstract scenario model and annotation data are automatically converted into computer-recognizable and executable node configuration files, thus providing a structured data foundation for subsequent visualization orchestration, payment template construction, and dynamic execution of the payment process.

[0026] During the process of acquiring and displaying payment nodes in the editing interface, the node attributes of each payment node can be extracted from the node configuration file. These node attributes include at least the node function, node connection relationship, calling interface, and interface input parameters. After acquiring the node attributes of all candidate payment nodes, the logical sequence and dependency relationship between each payment node is determined based on the node connection relationship described in the node attributes (e.g., if the previous node of node A is empty, it indicates that it is the starting node, and its successor node is node B; the previous node of node B is node A, and its successor node is node C, etc.). Based on the above connection relationship, multiple payment nodes are displayed in the editing interface in the order of process execution. For example, nodes A, B, and C are connected and presented in sequence in the form of a flowchart, allowing the overall structure of the payment process and the upstream and downstream relationships between each node to be viewed intuitively on the editing interface. This provides a visual operational basis for subsequent node selection and payment template arrangement. Through this display method, this application realizes a visual mapping of payment node configuration information to the interface, reducing the understanding cost and operational threshold of arranging payment processes.

[0027] In one embodiment, the editing interface can also display the node set obtained from the payment scenario model and scenario annotation data, as well as the correspondence between the node set and the payment nodes. In the process of acquiring and displaying multiple payment nodes in the editing interface, on the one hand, multiple payment nodes are acquired through parsing, and on the other hand, the node attributes of the payment nodes are extracted from the node configuration file. The node connection relationship between the nodes is found from the node attributes. Then, based on the node set, the correspondence between the node set and the payment nodes, and the node connection relationship, the multiple payment nodes are displayed in association in the editing interface. Through this display method, it is convenient to quickly locate the required payment node according to the payment stage, and to arrange and adjust the nodes in a certain node set in a targeted manner, thereby improving the configuration efficiency and intuitiveness of the payment template.

[0028] This application extracts predefined payment nodes from the payment scenario model, facilitating their selection, combination, and arrangement within an editing interface. This allows standardized node units to be reused in the process configuration of different payment channels. By breaking down each payment process into reusable payment nodes and supporting visual arrangement and dynamic binding through an editing interface, this application enables flexible invocation of corresponding payment templates to execute relevant processes based on different payment channels on the same self-checkout device. This ensures that each payment method can complete the payment operation correctly and efficiently according to its business logic.

[0029] Upon receiving a request to edit the payment process, there are two ways to obtain the payment nodes to be displayed: one is to parse the pre-configured payment scenario model in real time and dynamically extract multiple payment nodes from it; the other is to directly obtain the payment nodes that have already been parsed and cached. After obtaining the payment nodes, these payment nodes are further displayed in a visual form in the editing interface for selection, arrangement, and combination.

[0030] After selecting several target payment nodes from the displayed payment nodes through the editing interface, and based on the node configuration files corresponding to the selected target payment nodes, the multiple target payment nodes are logically linked and combined according to the connection relationships between the nodes to form a complete and executable target payment template. This target payment template is essentially a process definition file that arranges multiple payment nodes in a specific order. When a payment is initiated through a payment channel, this target payment template can be directly invoked, executing the node sequence defined in the template sequentially to complete the corresponding payment process.

[0031] Furthermore, a mapping relationship can be established between the newly constructed payment template and the target payment channel (such as cash, payment software, merchant gift cards, etc.), and this binding record can be stored. When a customer initiates a payment request through the target payment channel on a terminal device such as a self-checkout machine, the target payment template corresponding to the payment channel is automatically obtained according to the bound mapping relationship, and multiple pre-arranged payment nodes in the template are called. The corresponding payment logic is executed sequentially according to the connection relationship and execution order between the nodes, thereby completing the complete payment process from parameter collection, verification, deduction to result query. Through the above-mentioned association binding and dynamic calling mechanism, this application achieves the decoupling of payment channels and specific payment processes. The same payment channel can adjust the payment logic by changing the binding template, and the same payment template can also be reused by multiple payment channels without modifying the code or redistributing the software version, thus flexibly supporting the addition and modification of payment channels and the differentiated configuration of payment processes.

[0032] Once the target payment template is built, a corresponding template version number can be assigned and stored to identify the template's iteration version, facilitating subsequent version management, canary releases, or rollback operations. Simultaneously, the payment template can be associated with the runtime environment attributes corresponding to the target payment channel. Runtime environment attributes include, but are not limited to, at least one of the following: merchant information (e.g., merchant name, merchant ID), physical store information (e.g., physical store ID, physical store address, device ID), and payment codes (e.g., physical store QR code, order QR code). By configuring template versions, version control of the payment process is achieved. Different versions of payment templates can be bound to the same payment channel, and configurations can even be made based on physical store region, device type, or grouping, gradually verifying the stability of new templates and effectively reducing deployment risks. By associating runtime environment attributes, this application can refine the application scope of the payment template to the specific merchant, physical store, and even terminal device level, allowing different physical stores to use different payment process configurations according to their own business needs, thereby meeting the differentiated deployment needs of multiple channels and multiple physical stores in offline retail scenarios.

[0033] Correspondingly, on the self-checkout device side, in response to the payment request triggered by the customer, the target payment channel is invoked, and the target payment template bound to the target payment channel is obtained. The target payment template is composed of multiple target payment nodes. The target payment nodes are selected from multiple payment nodes that are applicable to multiple payment channels under the payment scenario displayed in the editing interface. The multiple payment nodes displayed in the editing interface are obtained in response to the request submitted in the editing interface to edit the target payment process corresponding to the target payment channel. The payment nodes are extracted from the pre-configured payment scenario model. The payment scenario model defines multiple payment nodes that are common under the payment scenario. After obtaining the target payment template, the payment template can be invoked to execute the corresponding payment process.

[0034] When invoking a payment template to execute the corresponding payment process, the payment template can be parsed to obtain multiple payment nodes corresponding to this payment and their node attributes. The starting payment node is then determined from these multiple payment nodes, and the execution of the starting payment node is triggered based on its attributes. In one specific implementation, the payment template bound to the current payment channel is first obtained, and then parsed. If parsing fails, the process ends; if parsing succeeds, all payment nodes constituting the template are extracted. Next, the starting node of the process is searched and determined among all nodes. If not found, the process ends; if found, the payment process begins. During execution, parameters are assembled for the current node (i.e., based on the interface parameters defined in the node configuration file, the required parameters are obtained from the context environment and filled in), and then the function logic of that node is executed. After execution, the system determines whether a next node exists (i.e., based on the node connection relationship, the successor node pointed to by the current node is found): if it exists, the system jumps to that successor node to continue the loop of parameter assembly and node execution; if it does not exist, the process ends. Through the above process, this application achieves dynamic parsing of payment templates and sequential execution of payment nodes.

[0035] Figure 2This diagram illustrates a design architecture of one embodiment of the present application. Functionally, this architecture is divided into three core modules: a process template editor, a function point management page, and a process engine. The process template editor module provides a payment template management page for creating, editing, saving, and deleting payment templates. This includes a version management submodule for version control and canary release management of payment templates; a node process management submodule for configuring the arrangement order and connection relationships of each payment node in the payment template; and a release process management submodule responsible for releasing the edited payment template to different environments (such as test, pre-release, and production environments). Furthermore, the multi-environment template release function supports independent deployment and verification of the same payment template in different environments. The function point management page module is responsible for the basic data management of payment nodes and payment domains. The payment process is comprised of several modules: a domain node management submodule for defining and maintaining various domains; a node resolver for parsing configured node definitions into recognizable node metadata; a node addition / modification submodule for supporting the addition and modification of payment nodes; a payment method mapping submodule for establishing the binding relationship between payment channels and payment templates; and a node version management submodule for independently managing the iterative versions of each payment node. The process engine module is the core of the payment process's runtime execution, responsible for loading and executing the corresponding payment template based on the call request. Specifically, a template resolver parses the structure and node composition of the payment template; a process resolver parses the complete payment process execution path based on node connections; a process scheduler schedules the execution of each payment node sequentially; and a pre-compilation processor pre-compiles and optimizes the template before execution, improving runtime performance.

[0036] Furthermore, the entire architecture relies on an underlying payment scenario model (domain model) and scenario annotation data (domain annotation) system. The domain model defines the structure and behavior of various domains; domain annotations are used to mark metadata for payment domains; node attributes (node ​​annotations) define the attribute information of payment nodes; attribute annotations describe the input and output parameters of node functions; and navigation annotations describe the connection relationships and jump logic between nodes. Through this layered architecture and annotation-driven mechanism, this application achieves configurable management of payment nodes, visual orchestration of payment templates, and flexible dynamic execution of payment processes.

[0037] Figure 3The diagram illustrates the execution process of each party in the embodiment of this application. On the R&D side, R&D personnel first generate node configuration files for payment nodes through pre-compilation, defining and developing the nodes. Simultaneously, they add metadata tags to the nodes and templates using annotations, including node set attributes and node attributes. Furthermore, the R&D side is responsible for importing and exporting configuration files, managing template versions, handling node additions and modifications, and maintaining the mapping relationship between payment methods and nodes. After completing the above configuration, it is imported into the platform for subsequent use. On the operations / R&D side, operations or R&D personnel import the pre-configured templates from the R&D side, then select a payment channel according to business needs, and bind the imported template to the selected channel, forming a "payment channel - payment template" mapping relationship. On the POS side of the self-service checkout device, when a customer initiates a payment request on the POS terminal or payment client, the process engine obtains the payment template bound to that channel from the platform based on the payment channel information carried in the request, then parses the node sequence and execution logic in the template, and sequentially schedules and executes each payment node according to the connection relationship between nodes, ultimately completing the payment process.

[0038] Figure 4 This diagram illustrates the payment process in an embodiment of this application. The diagram, presented as a flowchart, shows the execution of a payment process based on a payment template, specifically including the following steps: After the process begins, it first enters the "Barcode Scanner Input" node, where a barcode scanner reads the payment code or product information. Then, it enters the "Payment Code Verification" node, where the read payment code is validated, including its format, validity period, and whether it is disabled. After successful verification, it enters the "General Payment" node, calling the corresponding payment channel interface to perform the deduction operation. After executing the "General Payment" node, the process proceeds to different branches based on the payment result: if the payment is in a processing state, it enters the "Payment Result Query" node, polling for the payment result until a clear status is obtained; if the payment fails or an error occurs, it enters the "Payment Cancellation" node, initiating a cancellation request to cancel the transaction; if the payment is successful, it directly enters the "Payment Successful" end state. When the process reaches the "Payment Result Inquiry" node, it branches further based on the query result: if the payment is successful, it enters the "Payment Successful" end state; if the payment fails or times out, it enters the "Payment Cancellation" node to execute the cancellation operation; if an error occurs during the query process, it enters the "Payment Error" end state. When the process reaches the "Payment Cancellation" node, it branches based on the cancellation result: if the cancellation is successful, it enters the "Payment Successful" end state (indicating a successful refund) or ends directly; if the cancellation fails or an error occurs, it enters the "Payment Error" end state. Through the above process design, this application realizes a complete payment closed loop from QR code input, code verification, payment execution to result inquiry and abnormal cancellation.

[0039] The execution entity in this application embodiment can be an application, service, instance, functional module in software form, virtual machine (VM), container, or cloud server, or hardware device with data processing capabilities (such as server or terminal device) or hardware chip (such as CPU, GPU, FPGA, NPU, AI accelerator card, or DPU). The device for providing the service can be deployed on the computing device of the application providing the corresponding service or on a cloud computing platform providing computing power, storage, and network resources. The cloud computing platform can provide services in the following modes: IaaS (Infrastructure as a Service), PaaS (Platform as a Service), SaaS (Software as a Service), or DaaS (Data as a Service). Taking the platform providing SaaS (Software as a Service) as an example, the cloud computing platform can utilize its own computing resources to provide the implementation of one or more of the above steps, and the specific application architecture can be built according to service requirements.

[0040] 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, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0041] The technical solution of this application and how it solves the aforementioned technical problems are described in detail below with specific embodiments. The listed specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0042] This application provides a payment processing method based on self-service checkout equipment, such as... Figure 5The diagram shows a flowchart of a payment processing method 500 based on a self-service checkout device according to an embodiment of this application. The method 500 may include: in step 501, in response to a request submitted in the editing interface to edit the target payment process corresponding to the target payment channel, obtaining multiple payment nodes applicable to various payment channels in the payment scenario, and displaying the multiple payment nodes in the editing interface; in step 502, obtaining multiple target payment nodes selected from the displayed multiple payment nodes, and combining the multiple target payment nodes into a target payment template according to the node configuration file of the target payment nodes; the node configuration file records the node attributes of the payment nodes; in step 503, associating and binding the target payment template with the target payment channel, so that when payment is initiated through the target payment channel, the target payment template is invoked to execute the corresponding payment process; wherein, the payment nodes are extracted from a pre-configured payment scenario model, and the payment scenario model defines multiple payment nodes common to the payment scenario.

[0043] In one embodiment, the multiple payment nodes are divided into multiple node sets according to the payment stage. The payment scenario model is also used to describe the multiple node sets and the correspondence between the node sets and the payment nodes. The payment scenario model is configured with corresponding scenario annotation data. The scenario annotation data is used to describe the node set attributes of the payment node sets and the node attributes corresponding to the payment nodes. The node set attributes include the node set name and / or node set type. The node attributes include at least one of node functions, node connection relationships, calling interfaces, and interface input parameters.

[0044] In one embodiment, the method further includes: parsing the payment scenario model and scenario annotation data to obtain multiple node sets and multiple payment nodes corresponding to the node sets, and generating node configuration files corresponding to each payment node based on the node attributes of the payment nodes.

[0045] In one embodiment, obtaining multiple payment nodes included in the payment process and displaying the multiple payment nodes in the editing interface includes: obtaining multiple payment nodes obtained through parsing, and extracting node attributes of the payment nodes from the node configuration file; and displaying the multiple payment nodes in association in the editing interface according to the parsed node set, the correspondence between the node set and the payment nodes, and the node connection relationship between the nodes included in the node attributes.

[0046] In one embodiment, the method further includes: configuring a corresponding template version and an operating environment attribute corresponding to the target payment channel for the target payment template, wherein the operating environment attribute includes at least one of merchant information, physical store information, and payment code.

[0047] This application also provides a payment processing method based on self-service checkout equipment, such as... Figure 6 The diagram shows a flowchart of a payment processing method 600 based on a self-checkout device according to an embodiment of this application. This method can be applied to self-checkout devices. The method 600 may include: in step 601, invoking a target payment channel in response to a payment request from the self-checkout device; in step 602, obtaining a target payment template bound to the target payment channel, wherein the target payment template is composed of multiple target payment nodes based on the node configuration file of the selected target payment node, the target payment node being selected from multiple payment nodes applicable to various payment channels under a payment scenario displayed in the editing interface, the multiple payment nodes displayed in the editing interface being obtained in response to a request submitted in the editing interface to edit the target payment process corresponding to the target payment channel, the payment node being extracted from a pre-configured payment scenario model, the payment scenario model defining multiple payment nodes common to the payment scenario, and the node configuration file recording the node attributes of the payment node; and in step 603, invoking the payment template to execute the corresponding payment process.

[0048] In one embodiment, the step of calling the payment template to execute the corresponding payment process includes: parsing the payment template to obtain multiple payment nodes corresponding to this payment and the node attributes of the payment nodes; determining the starting payment node from the multiple payment nodes, and executing the starting payment node according to the node attributes to trigger the execution of the payment process.

[0049] According to the embodiments of this application, in response to a request submitted in the editing interface to edit the target payment process corresponding to the target payment channel, multiple payment nodes applicable to various payment channels in the payment scenario are obtained and displayed in the editing interface. The target payment node selected from the displayed multiple payment nodes is obtained and constructed into a target payment template according to its node configuration file. Then, the target payment template is associated and bound to the target payment channel, thereby realizing the visual orchestration and dynamic configuration of the payment process. Thus, the solution of this application embodiment decomposes the payment process into general, reusable payment nodes and defines node attributes through node configuration files. The construction and adjustment of the payment template can be completed through interactive operations in the editing interface. When a new or changed payment channel is needed, only the corresponding payment template needs to be rearranged and bound to the new channel through the editing interface to achieve rapid deployment and flexible configuration of the payment channel. There is no need to modify the underlying code or redeploy the software version, fundamentally avoiding the frequent release problems caused by the explosive growth of payment channels or interface changes in traditional solutions. In summary, this application realizes the node-based production, visual orchestration, and dynamic connection of the payment process, significantly improving the compatibility and operational efficiency of offline self-checkout equipment with multiple payment channels, and solving the technical problems in the prior art such as strong coupling between payment channels and business code, frequent version iterations, and difficulties in deployment across physical stores.

[0050] Corresponding to the examples and method embodiments provided in this application, this application also provides a payment processing device based on a self-service checkout device. For example... Figure 7 The diagram shows a structural block diagram of a payment processing device 700 based on a self-service checkout device according to an embodiment of this application. The device 700 may include: a node acquisition module 701, used to acquire multiple payment nodes applicable to various payment channels in a payment scenario in response to a request submitted in the editing interface to edit the target payment process corresponding to the target payment channel, and display the multiple payment nodes in the editing interface; a node selection module 702, used to acquire multiple target payment nodes selected from the displayed multiple payment nodes; a template creation module 703, used to combine the multiple target payment nodes into a target payment template according to the node configuration file of the target payment node; the node configuration file records the node attributes of the payment node; and a template binding module 704, used to associate and bind the target payment template with the target payment channel, so that when payment is initiated through the target payment channel, the target payment template is invoked to execute the corresponding payment process; wherein the payment nodes are extracted from a pre-configured payment scenario model, and the payment scenario model defines multiple payment nodes applicable to the payment scenario.

[0051] In one embodiment, multiple payment nodes are divided into multiple node sets according to the payment stage. The payment scenario model is also used to describe the multiple node sets and the correspondence between the node sets and the payment nodes. The payment scenario model is configured with corresponding scenario annotation data. The scenario annotation data is used to describe the node set attributes of the payment node sets and the node attributes corresponding to the payment nodes. The node set attributes include the node set name and / or node set type. The node attributes include at least one of node functions, node connection relationships, calling interfaces, and interface input parameters.

[0052] In one embodiment, the device further includes: a parsing module, configured to parse the payment scenario model and scenario annotation data, obtain multiple node sets and multiple payment nodes corresponding to the node sets, and generate node configuration files corresponding to each payment node based on the node attributes of the payment nodes.

[0053] In one embodiment, the node acquisition module is specifically used to acquire multiple payment nodes obtained through parsing, and extract the node attributes of the payment nodes from the node configuration file; based on the parsed node set, the correspondence between the node set and the payment nodes, and the node connection relationship between the nodes included in the node attributes, the multiple payment nodes are associated and displayed in the editing interface.

[0054] In one embodiment, the device further includes: a template configuration module, configured to configure a corresponding template version and an operating environment attribute corresponding to the target payment template for the target payment template, wherein the operating environment attribute includes at least one of merchant information, physical store information and payment code.

[0055] Corresponding to the examples and method embodiments provided in this application, this application also provides a payment processing device based on a self-service checkout device. For example... Figure 8The diagram shows a structural block diagram of a payment processing device 800 based on a self-checkout device according to an embodiment of this application. This device 800 can be deployed on a self-checkout device and may include: a channel invocation module 801, used to invoke a target payment channel in response to a payment request from the self-checkout device; a template acquisition module 802, used to acquire a target payment template bound to the target payment channel, wherein the target payment template is composed of multiple target payment nodes based on the node configuration file of the selected target payment node, the target payment node being selected from multiple payment nodes applicable to various payment channels under the payment scenario displayed in the editing interface, the multiple payment nodes displayed in the editing interface being acquired in response to a request submitted in the editing interface to edit the target payment process corresponding to the target payment channel, the payment node being extracted from a pre-configured payment scenario model, the payment scenario model defining multiple payment nodes common to the payment scenario, and the node configuration file recording the node attributes of the payment node; and a process execution module 803, used to invoke the payment template to execute the corresponding payment process.

[0056] In one embodiment, the process execution module is specifically used to parse the payment template to obtain multiple payment nodes corresponding to this payment and the node attributes of the payment nodes; determine the starting payment node from the multiple payment nodes, and execute the starting payment node according to the node attributes to trigger the execution of the payment process.

[0057] According to the embodiments of this application, in response to a request submitted in the editing interface to edit the target payment process corresponding to the target payment channel, multiple payment nodes applicable to various payment channels in the payment scenario are obtained and displayed in the editing interface. The target payment node selected from the displayed multiple payment nodes is obtained and constructed into a target payment template according to its node configuration file. Then, the target payment template is associated and bound to the target payment channel, thereby realizing the visual orchestration and dynamic configuration of the payment process. Thus, the solution of this application embodiment decomposes the payment process into general, reusable payment nodes and defines node attributes through node configuration files. The construction and adjustment of the payment template can be completed through interactive operations in the editing interface. When a new or changed payment channel is needed, only the corresponding payment template needs to be rearranged and bound to the new channel through the editing interface to achieve rapid deployment and flexible configuration of the payment channel. There is no need to modify the underlying code or redeploy the software version, fundamentally avoiding the frequent release problems caused by the explosive growth of payment channels or interface changes in traditional solutions. In summary, this application realizes the node-based production, visual orchestration, and dynamic connection of the payment process, significantly improving the compatibility and operational efficiency of offline self-checkout equipment with multiple payment channels, and solving the technical problems in the prior art such as strong coupling between payment channels and business code, frequent version iterations, and difficulties in deployment across physical stores.

[0058] The functions of each module in each device in the embodiments of this application can be found in the corresponding description in the above method, and they have corresponding beneficial effects, which will not be repeated here.

[0059] Figure 9 This is a block diagram of an electronic device used to implement embodiments of this application. For example... Figure 9 As shown, the electronic device includes a memory 901 and a processor 902. The memory 901 stores a computer program that can run on the processor 902. When the processor 902 executes the computer program, it implements the method described in the above embodiments. The number of memories 901 and processors 902 can be one or more.

[0060] The electronic device also includes: The communication interface 903 is used to communicate with external devices and exchange and transmit data.

[0061] If the memory 901, processor 902, and communication interface 903 are implemented independently, they can be interconnected via a bus to communicate with each other. This bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. This bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 9 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0062] Optionally, in a specific implementation, if the memory 901, processor 902, and communication interface 903 are integrated on a single chip, then the memory 901, processor 902, and communication interface 903 can communicate with each other through an internal interface.

[0063] This application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method provided in this application.

[0064] This application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the methods provided in any embodiment of this application.

[0065] This application also provides a chip including a processor for calling and executing instructions stored in a memory, causing a communication device with the chip installed to perform the method provided in this application.

[0066] This application also provides a chip, including: an input interface, an output interface, a processor, and a memory. The input interface, output interface, processor, and memory are connected through an internal connection path. The processor is used to execute code in the memory. When the code is executed, the processor is used to execute the method provided in this application.

[0067] It should be understood that the aforementioned processor can be a Central Processing Unit (CPU), or other general-purpose processors, Digital Signal Processors (DSPs), Application Specific Integrated Circuits (ASICs), Field-Programmable Gate Arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. General-purpose processors can be microprocessors or any conventional processor. It is worth noting that the processor can be a processor supporting Advanced Reduced Instruction Set Machines (ARM) architecture.

[0068] Further, optionally, the aforementioned memory may include read-only memory and random access memory. The memory may be volatile memory or non-volatile memory, or may include both. Non-volatile memory may include read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory may include random access memory (RAM), which serves as an external cache. By way of example, but not limitation, many forms of RAM are available. Examples include Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced Synchronous DRAM (ESDRAM), Sync Link DRAM (SLDRAM), and Direct Rambus RAM (DR RAM).

[0069] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. A computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions according to this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another.

[0070] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of those different embodiments or examples.

[0071] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "a plurality of" means two or more, unless otherwise explicitly specified.

[0072] Any process or method described in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing a particular logical function or process. Furthermore, the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functionality involved.

[0073] The logic and / or steps described in the flowchart or otherwise herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus or device (such as a computer-based system, a processor-included system or other system that can fetch and execute instructions from, an instruction execution system, apparatus or device).

[0074] It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. All or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware, the program being stored in a computer-readable storage medium, which, when executed, includes one or a combination of the steps of the method embodiments.

[0075] Furthermore, the functional units in the various embodiments of this application can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. This storage medium can be a read-only memory, a disk, or an optical disk, etc.

[0076] The above description is merely an exemplary embodiment of this application, but the scope of protection of this application is not limited thereto. Any person skilled in the art can easily conceive of various variations or substitutions within the technical scope described in this application, and these should all be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A payment processing method based on a self-checkout device, comprising: In response to a request submitted in the editing interface to edit the target payment process corresponding to the target payment channel, multiple payment nodes applicable to multiple payment channels in the payment scenario are obtained, and the multiple payment nodes are displayed in the editing interface; Obtain multiple target payment nodes selected from the displayed multiple payment nodes, and combine the multiple target payment nodes into a target payment template according to the node configuration file of the target payment nodes; the node configuration file records the node attributes of the payment nodes; The target payment template is associated with the target payment channel so that when a payment is initiated through the target payment channel, the target payment template is invoked to execute the corresponding payment process; The payment nodes are extracted from a pre-configured payment scenario model, which defines multiple payment nodes common to the payment scenario.

2. The method according to claim 1, wherein, Multiple payment nodes are divided into multiple node sets according to the payment stage. The payment scenario model is also used to describe the multiple node sets and the correspondence between the node sets and payment nodes. The payment scenario model is configured with corresponding scenario annotation data. The scenario annotation data is used to describe the node set attributes of the payment node set and the node attributes corresponding to the payment node. The node set attributes include the node set name and / or node set type. The node attributes include at least one of node function, node connection relationship, calling interface and interface input parameters.

3. The method according to claim 2, wherein, The method further includes: The payment scenario model and scenario annotation data are parsed to obtain multiple node sets and multiple payment nodes corresponding to the node sets. Then, node configuration files corresponding to each payment node are generated based on the node attributes of the payment nodes.

4. The method according to claim 3, wherein, The process of acquiring multiple payment nodes during payment and displaying these multiple payment nodes in the editing interface includes: Obtain multiple payment nodes obtained through parsing, and extract the node attributes of the payment nodes from the node configuration file; Based on the parsed node set, the correspondence between the node set and the payment node, and the node connection relationship between the nodes included in the node attributes, multiple payment nodes are displayed in association on the editing interface.

5. The method according to claim 1, wherein, Also includes: Configure the corresponding template version and the runtime environment attributes corresponding to the target payment channel for the target payment template. The runtime environment attributes include at least one of merchant information, physical store information, and payment code.

6. A payment processing method based on a self-checkout device, comprising: In response to a payment request from a self-checkout device, invoke the target payment channel; Obtain the target payment template bound to the target payment channel. The target payment template is composed of multiple target payment nodes based on the node configuration file of the selected target payment node. The target payment node is selected from multiple payment nodes that are applicable to multiple payment channels under the payment scenario displayed in the editing interface. The multiple payment nodes displayed in the editing interface are obtained in response to the request submitted in the editing interface to edit the target payment process corresponding to the target payment channel. The payment node is extracted from the pre-configured payment scenario model. The payment scenario model defines multiple payment nodes that are common under the payment scenario. The node configuration file records the node attributes of the payment node. The payment template is invoked to execute the corresponding payment process.

7. The method according to claim 6, wherein, The step of invoking the payment template to execute the corresponding payment process includes: The payment template is parsed to obtain multiple payment nodes corresponding to this payment and the node attributes of the payment nodes; The starting payment node is determined from the plurality of payment nodes, and the starting payment node is executed according to the node attributes to trigger the execution of the payment process.

8. An electronic device comprising a memory, a processor, and a computer program stored in the memory, wherein the processor, when executing the computer program, implements the method of any one of claims 1-7.

9. A computer-readable storage medium storing a computer program that, when executed by a processor, implements the method of any one of claims 1-7.

10. A computer program product, wherein, The computer program product includes a computer program that, when executed by a processor, implements the method described in any one of claims 1-7.

Images