System, method, and computer program product for rendering, creation, and management of dynamic application forms

Abstract

Systems, methods, and computer program products are provided for rendering, creation, and management of dynamic application forms. An example system may include at least one processor configured to receive an input from a first user via a graphical user interface (GUI). The input may be associated with a graphical element associated with a field of a form and an attribute associated with the field. A schema file may be generated based on the input associated with the graphical element associated with the field of the form and the attribute associated with the field. The schema file may be validated based on the attribute associated with the field. In response to validating the schema file, the schema file may be stored in a database. The schema file may be retrieved from the database and communicated to a user device to render and display the form based on the schema file.

Description

SYSTEM, METHOD, AND COMPUTER PROGRAM PRODUCT FOR RENDERING, CREATION, AND MANAGEMENT OF DYNAMIC APPLICATION FORMSCROSS REFERENCE TO RELATED APPLICATION

[0001] The present application claims the benefit of United States Provisional Patent Application No. 63 / 540,466, filed on September 26, 2023, the disclosure of which is hereby incorporated by reference in its entirety.BACKGROUND1 . Technical Field

[0002] This disclosure relates generally to dynamic application forms and, in some non-limiting embodiments or aspects, to systems, methods, and computer program products for rendering, creation, and management of dynamic application forms.2. Technical Considerations

[0003] Certain forms (e.g., web-based forms) rely on certain information being hard-coded into a source code, which may include different portions for different functionality related to each form (e.g., front-end functionality related to the user interface, visual content, audio content, other content, and / or other interactive components, which may be displayed and / or presented on a user device; back-end functionality related to server-side processing, attributes, rules, logic, and / or structure; and / or the like). For example, such forms may include fields that are displayed on a user device (e.g., based on front-end portions of the source code), and data entered by the user into the fields may be received and / or processed by a server (e.g., based on back-end portions of the source code related to attributes of each field).

[0004] However, when fields are hard-coded into the source code, the fields and the attributes of such fields are defined in a static way. For example, to add, remove, update, and / or modify the fields and / or attributes thereof, the source code must be manually updated by someone with technical knowledge of the hard-coded information related to such fields in the source code. This can be further complicated when different portions of the source code (e.g., front-end portion(s) and / or back-end portion(s)) each have information related to the same field(s), and multiple different portions of the source code must be separately updated in a consistent manner. For example, adding a new field to an existing form may require updating the front-end source code to display a new graphical element associated with the field andseparately updating the back-end source code to include attributes of that new field. The technical nature and time consuming process of making such changes often leads to inconsistencies between different portions of the source code (e.g., front-end portions and / or back-end portions). Further, such changes are usually tied to release cycles, which may result in users being required to wait a long time, even for simple changes. Additionally, the different portions of the source code may be in different programming languages (e.g., front-end portions may be in HyperText Markup Language (HTML), JavaScript, Extensible Markup Language (XML), Cascading Style Sheets (CSS), and / or the like; and back-end portions may be in Python, Java, Ruby, PHP, and / or the like) and / or stored on different computing devices (e.g., a front-end server or partition of a server, a back-end server or partition of a server, and / or the like).SUMMARY

[0005] Accordingly, provided are improved systems, methods, and computer program products for rendering, creation, and management of dynamic application forms.

[0006] According to some non-limiting embodiments or aspects, provided is a system for rendering, creation, and management of dynamic application forms. In some non-limiting embodiments or aspects, the system may include at least one processor configured to receive an input from a first user via a first graphical user interface (GUI), the input associated with a graphical element associated with a field of a form and at least one attribute associated with the field. In some non-limiting embodiments or aspects, the at least one processor may be further configured to direct the at least one processor to generate a schema file based on the input associated with the graphical element associated with the field of the form and the at least one attribute associated with the field. In some non-limiting embodiments or aspects, the at least one processor may be further configured to validate the schema file based on the at least one attribute associated with the field. In some non-limiting embodiments or aspects, the at least one processor may be further configured to, in response to validating the schema file, store the schema file in a database. In some non-limiting embodiments or aspects, the at least one processor may be further configured to retrieve the schema file from the database. In some non-limiting embodiments or aspects, the at least one processor may be further configured to communicate theschema file to a user device of a second user to render and display the form based on the schema file.

[0007] In some non-limiting embodiments or aspects, the at least one attribute may include at least one of a rule, a dependency on at least one other field of the form, a name of the field, a type of graphical element, or any combination thereof.

[0008] In some non-limiting embodiments or aspects, when retrieving the schema file from the database, the at least one processor may be configured to receive a request message associated with the form from the user device of the second user and / or retrieve the schema file from the database in response to receiving the request message.

[0009] In some non-limiting embodiments or aspects, the user device of the second user may display the form via a second GUI.

[0010] In some non-limiting embodiments or aspects, the at least one processor may be further configured to receive data from the user device of the second user based on an input to the form displayed via the second GUI. In some non-limiting embodiments or aspects, the at least one processor may be further configured to validate the data received from the user device of the second user. In some nonlimiting embodiments or aspects, the at least one processor may be further configured to store the data received from the user device of the second user.

[0011] In some non-limiting embodiments or aspects, the at least one processor may be further configured to receive a request message associated with the form from the first user via the first GUI. In some non-limiting embodiments or aspects, the at least one processor may be further configured to retrieve the schema file from the database in response to receiving the request message. In some non-limiting embodiments or aspects, the at least one processor may be further configured to receive a second input from the first user via the first GUI, and the second input may be associated with a second graphical element associated with a second field of the form and at least one second field attribute associated with the second field. In some non-limiting embodiments or aspects, the at least one processor may be further configured to generate a modified schema file based on the schema file and the second input associated with the second graphical element associated with the second field of the form and the at least one second field attribute associated with the second field. In some non-limiting embodiments or aspects, the at least one processor may be further configured to validate the modified schema file based on the at leastone attribute associated with the field and the at least one second field attribute associated with the second field. In some non-limiting embodiments or aspects, the at least one processor may be further configured to, in response to validating the modified schema file, store the modified schema file in the database.

[0012] In some non-limiting embodiments or aspects, the at least one processor may be further configured to receive a request message from the user device of the second user comprising a request to access the form. In some non-limiting embodiments or aspects, the at least one processor may be further configured to retrieve the modified schema file from the database in response to receiving the request message. In some non-limiting embodiments or aspects, the at least one processor may be further configured to communicate the modified schema file to the user device of the second user to render and display the form based on the modified schema file.

[0013] According to some non-limiting embodiments or aspects, provided is a computer-implemented method for rendering, creation, and management of dynamic application forms. In some non-limiting embodiments or aspects, the computer- implemented method may include receiving an input from a first user via a first graphical user interface (GUI). In some non-limiting embodiments or aspects, the input may be associated with a graphical element associated with a field of a form and at least one attribute associated with the field. In some non-limiting embodiments or aspects, the computer-implemented method may further include generating a schema file based on the input associated with the graphical element associated with the field of the form and the at least one attribute associated with the field. In some non-limiting embodiments or aspects, the computer-implemented method may further include validating the schema file based on the at least one attribute associated with the field. In some non-limiting embodiments or aspects, the computer-implemented method may further include, in response to validating the schema file, storing the schema file in a database. In some non-limiting embodiments or aspects, the computer- implemented method may further include retrieving the schema file from the database. In some non-limiting embodiments or aspects, the computer-implemented method may further include communicating the schema file to a user device of a second user to render and display the form based on the schema file.

[0014] In some non-limiting embodiments or aspects, the at least one attribute may include at least one of a rule, a dependency on at least one other field of the form, a name of the field, a type of graphical element, or any combination thereof.

[0015] In some non-limiting embodiments or aspects, retrieving the schema file from the database may include receiving a request message associated with the form from the user device of the second user and / or retrieving the schema file from the database in response to receiving the request message.

[0016] In some non-limiting embodiments or aspects, the user device of the second user may display the form via a second GUI.

[0017] In some non-limiting embodiments or aspects, the computer-implemented method may include receiving data from the user device of the second user based on input to the form displayed via the second GUI. In some non-limiting embodiments or aspects, the computer-implemented method may further include validating the data received from the user device of the second user. In some non-limiting embodiments or aspects, the computer-implemented method may include storing the data received from the user device of the second user.

[0018] In some non-limiting embodiments or aspects, the computer-implemented method may further include receiving a request message associated with the form from the first user via the first GUI. the computer-implemented method may further include retrieving the schema file from the database in response to receiving the request message. A second input may be received from the first user via the first GUI, and the second input may be associated with a second graphical element associated with a second field of the form and at least one second field attribute associated with the second field, the computer-implemented method may further include generating a modified schema file based on the schema file and the second input associated with the second graphical element associated with the second field of the form and the at least one second field attribute associated with the second field, the computer- implemented method may further include validating the modified schema file based on the at least one attribute associated with the field and the at least one second field attribute associated with the second field, the computer-implemented method may further include, in response to validating the modified schema file, storing the modified schema file in the database.

[0019] In some non-limiting embodiments or aspects, the computer-implemented method may include receiving a request message from the user device of the seconduser including a request to access the form. In some non-limiting embodiments or aspects, the computer-implemented method may include retrieving the modified schema file from the database in response to receiving the request message. In some non-limiting embodiments or aspects, the computer-implemented method may include communicating the modified schema file to the user device of the second user to render and display the form based on the modified schema file.

[0020] According to some non-limiting embodiments or aspects, provided is a computer program product for rendering, creation, and management of dynamic application forms. In some non-limiting embodiments or aspects, the computer program product may include at least one non-transitory computer-readable medium including program instructions that, when executed by at least one processor, cause the at least one processor to receive an input from a first user via a first graphical user interface (GUI), and the input may be associated with a graphical element associated with a field of a form and at least one attribute associated with the field. In some nonlimiting embodiments or aspects, the program instructions may further cause the at least one processor to generate a schema file based on the input associated with the graphical element associated with the field of the form and the at least one attribute associated with the field. In some non-limiting embodiments or aspects, the program instructions may further cause the at least one processor to validate the schema file based on the at least one attribute associated with the field. In some non-limiting embodiments or aspects, the program instructions may further cause the at least one processor to, in response to validating the schema file, store the schema file in a database. In some non-limiting embodiments or aspects, the program instructions may further cause the at least one processor to retrieve the schema file from the database. In some non-limiting embodiments or aspects, the program instructions may further cause the at least one processor to communicate the schema file to a user device of a second user to render and display the form based on the schema file.

[0021] In some non-limiting embodiments or aspects, the at least one attribute may include at least one of a rule, a dependency on at least one other field of the form, a name of the field, a type of graphical element, or any combination thereof.

[0022] In some non-limiting embodiments or aspects, when retrieving the schema file from the database, the program instructions may further cause the at least one processor to receive a request message associated with the form from the user deviceof the second user and / or retrieve the schema file from the database in response to receiving the request message.

[0023] In some non-limiting embodiments or aspects, the user device of the second user may display data associated with the form via a second GUI.

[0024] In some non-limiting embodiments or aspects, the program instructions may further cause the at least one processor to receive data from the user device of the second user based on an input to the form displayed via the second GUI. In some non-limiting embodiments or aspects, the program instructions may further cause the at least one processor to validate the data received from the user device of the second user. In some non-limiting embodiments or aspects, the program instructions may further cause the at least one processor to store the data received from the user device of the second user.

[0025] In some non-limiting embodiments or aspects, the program instructions may further cause the at least one processor to receive a request message associated with the form from the first user via the first GUI. In some non-limiting embodiments or aspects, the program instructions may further cause the at least one processor to retrieve the schema file from the database in response to receiving the request message. In some non-limiting embodiments or aspects, the program instructions may further cause the at least one processor to receive the second input from the first user via the first GUI, and the second input may be associated with a second graphical element associated with a second field of the form and at least one second field attribute associated with the second field. In some non-limiting embodiments or aspects, the program instructions may further cause the at least one processor to generate a modified schema file based on the schema file and second input associated with the second graphical element associated with the second field of the form and the at least one second field attribute associated with the second field. In some non-limiting embodiments or aspects, the program instructions may further cause the at least one processor to validate the modified schema file based on the at least one attribute associated with the field and the at least one second field attribute associated with the second field. In some non-limiting embodiments or aspects, the program instructions may further cause the at least one processor to, in response to validating the modified schema file, store the modified schema file in the database.

[0026] In some non-limiting embodiments or aspects, the program instructions may further cause the at least one processor to receive a request message from the userdevice of the second user comprising a request to access the form. In some nonlimiting embodiments or aspects, the program instructions may further cause the at least one processor to retrieve the modified schema file from the database in response to receiving the request message. In some non-limiting embodiments or aspects, the program instructions may further cause the at least one processor to communicate the modified schema file to the user device of the second user to render and display the form based on the modified schema file.

[0027] Further non-limiting embodiments or aspects will be set forth in the following numbered clauses:

[0028] Clause 1 : A system, comprising: at least one processor configured to: receive an input from a first user via a first graphical user interface (GUI), the input associated with a graphical element associated with a field of a form and at least one attribute associated with the field; generate a schema file based on the input associated with the graphical element associated with the field of the form and the at least one attribute associated with the field; validate the schema file based on the at least one attribute associated with the field; in response to validating the schema file, store the schema file in a database; retrieve the schema file from the database; and communicate the schema file to a user device of a second user to render and display the form based on the schema file.

[0029] Clause 2: The system of clause 1 , wherein the at least one attribute comprises at least one of a rule, a dependency on at least one other field of the form, a name of the field, a type of graphical element, or any combination thereof.

[0030] Clause 3: The system of clause 1 or 2, wherein, when retrieving the schema file from the database, the at least one processor is configured to: receive a request message associated with the form from the user device of the second user; and retrieve the schema file from the database in response to receiving the request message.

[0031] Clause 4: The system of any of clauses 1 -3, wherein the user device of the second user displays the form via a second GUI.

[0032] Clause 5: The system of any of clauses 1 -4, wherein the at least one processor is further configured to: receive data from the user device of the second user based on an input to the form displayed via the second GUI; validate the data received from the user device of the second user; and store the data received from the user device of the second user.

[0033] Clause 6: The system of any of clauses 1 -5, wherein the at least one processor is further configured to: receive a request message associated with the form from the first user via the first GUI; retrieve the schema file from the database in response to receiving the request message; receive a second input from the first user via the first GUI, the second input associated with a second graphical element associated with a second field of the form and at least one second field attribute associated with the second field; generate a modified schema file based on the schema file and the second input associated with the second graphical element associated with the second field of the form and the at least one second field attribute associated with the second field; validate the modified schema file based on the at least one attribute associated with the field and the at least one second field attribute associated with the second field; and in response to validating the modified schema file, store the modified schema file in the database.

[0034] Clause 7: The system of any of clauses 1 -6, wherein the at least one processor is further configured to: receive a request message from the user device of the second user comprising a request to access the form; retrieve the modified schema file from the database in response to receiving the request message; and communicate the modified schema file to the user device of the second user to render and display the form based on the modified schema file.

[0035] Clause 8: A computer-implemented method, comprising: receiving, with at least one processor, an input from a first user via a first graphical user interface (GUI), the input associated with a graphical element associated with a field of a form and at least one attribute associated with the field; generating, with at least one processor, a schema file based on the input associated with the graphical element associated with the field of the form and the at least one attribute associated with the field; validating, with at least one processor, the schema file based on the at least one attribute associated with the field; in response to validating the schema file, storing, with at least one processor, the schema file in a database; retrieving, with at least one processor, the schema file from the database; and communicating, with at least one processor, the schema file to a user device of a second user to render and display the form based on the schema file.

[0036] Clause 9: The computer-implemented method of clause 8, wherein the at least one attribute comprises at least one of a rule, a dependency on at least one otherfield of the form, a name of the field, a type of graphical element, or any combination thereof.

[0037] Clause 10: The computer-implemented method of clause 8 or 9, wherein retrieving the schema file from the database comprises: receiving a request message associated with the form from the user device of the second user; and retrieving the schema file from the database in response to receiving the request message.

[0038] Clause 1 1 : The computer-implemented method of any of clauses 8-10, wherein the user device of the second user displays the form via a second GUI.

[0039] Clause 12: The computer-implemented method of any of clauses 8-1 1 , further comprising: receiving, with at least one processor, data from the user device of the second user based on input to the form displayed via the second GUI; validating, with at least one processor, the data received from the user device of the second user; and storing, with at least one processor, the data received from the user device of the second user.

[0040] Clause 13: The computer-implemented method of any of clauses 8-12, further comprising: receiving, with at least one processor, a request message associated with the form from the first user via the first GUI; retrieving, with at least one processor, the schema file from the database in response to receiving the request message; receiving, with at least one processor, a second input from the first user via the first GUI, the second input associated with a second graphical element associated with a second field of the form and at least one second field attribute associated with the second field; generating, with at least one processor, a modified schema file based on the schema file and the second input associated with the second graphical element associated with the second field of the form and the at least one second field attribute associated with the second field; validating, with at least one processor, the modified schema file based on the at least one attribute associated with the field and the at least one second field attribute associated with the second field; and in response to validating the modified schema file, storing, with at least one processor, the modified schema file in the database.

[0041] Clause 14: The computer-implemented method of any of clauses 8-13, further comprising: receiving, with at least one processor, a request message from the user device of the second user comprising a request to access the form; retrieving, with at least one processor, the modified schema file from the database in response to receiving the request message; and communicating, with at least one processor,the modified schema file to the user device of the second user to render and display the form based on the modified schema file.

[0042] Clause 15: A computer program product, the computer program product comprising at least one non-transitory computer-readable medium comprising program instructions that, when executed by at least one processor, cause the at least one processor to: receive an input from a first user via a first graphical user interface (GUI), the input associated with a graphical element associated with a field of a form and at least one attribute associated with the field; generate a schema file based on the input associated with the graphical element associated with the field of the form and the at least one attribute associated with the field; validate the schema file based on the at least one attribute associated with the field; in response to validating the schema file, store the schema file in a database; retrieve the schema file from the database; and communicate the schema file to a user device of a second user to render and display the form based on the schema file.

[0043] Clause 16: The computer program product of clause 15, wherein the at least one attribute comprises at least one of a rule, a dependency on at least one other field of the form, a name of the field, a type of graphical element, or any combination thereof.

[0044] Clause 17: The computer program product of clause 15 or 16, wherein, when retrieving the schema file from the database, the program instructions, when executed by the at least one processor, further cause the at least one processor to: receive a request message associated with the form from the user device of the second user; and retrieve the schema file from the database in response to receiving the request message.

[0045] Clause 18: The computer program product of any of clauses 15-17, wherein the user device of the second user displays data associated with the form via a second GUI.

[0046] Clause 19: The computer program product of any of clauses 15-18, wherein the program instructions, when executed by the at least one processor, further cause the at least one processor to: receive data from the user device of the second user based on an input to the form displayed via the second GUI; validate the data received from the user device of the second user; and store the data received from the user device of the second user.

[0047] Clause 20: The computer program product of any of clauses 15-19, wherein the program instructions, when executed by the at least one processor, further cause the at least one processor to: receive a request message associated with the form from the first user via the first GUI; retrieve the schema file from the database in response to receiving the request message; receive a second input from the first user via the first GUI, the second input associated with a second graphical element associated with a second field of the form and at least one second field attribute associated with the second field; generate a modified schema file based on the schema file and the second input associated with the second graphical element associated with the second field of the form and the at least one second field attribute associated with the second field; validate the modified schema file based on the at least one attribute associated with the field and the at least one second field attribute associated with the second field; and in response to validating the modified schema file, store the modified schema file in the database.

[0048] Clause 21 : The computer program product of any of clauses 15-20, wherein the program instructions, when executed by the at least one processor, further cause the at least one processor to: receive a request message from the user device of the second user comprising a request to access the form; retrieve the modified schema file from the database in response to receiving the request message; and communicate the modified schema file to the user device of the second user to render and display the form based on the modified schema file.

[0049] These and other features and characteristics of the present disclosure, as well as the methods of operation and functions of the related elements of structures and the combination of parts and economies of manufacture, will become more apparent upon consideration of the following description and the appended claims with reference to the accompanying drawings, all of which form a part of this specification, wherein like reference numerals designate corresponding parts in the various figures. It is to be expressly understood, however, that the drawings are for the purpose of illustration and description only and are not intended as a definition of the limits of the disclosed subject matter.BRIEF DESCRIPTION OF THE DRAWINGS

[0050] Additional advantages and details are explained in greater detail below with reference to the non-limiting, exemplary embodiments that are illustrated in the accompanying schematic figures, in which:

[0051] FIG. 1 is a schematic diagram of a system for rendering, creation, and management of dynamic application forms, according to some non-limiting embodiments or aspects;

[0052] FIG. 2 is a schematic diagram of example components of one or more devices of FIG. 1 , according to some non-limiting embodiments or aspects;

[0053] FIG. 3 is a flow diagram of a method for rendering, creation, and management of dynamic application forms, according to some non-limiting embodiments or aspects;

[0054] FIGS. 4A and 4B are diagrams of an implementation of a process for rendering, creation, and management of dynamic application forms, according to some non-limiting embodiments or aspects;

[0055] FIG. 5 is an exemplary diagram of an editable form, according to some nonlimiting embodiments or aspects; and

[0056] FIG. 6 is an exemplary diagram of an environment in which systems, methods, and / or computer program products, described herein, may be implemented, according to some non-limiting embodiments or aspects.DETAILED DESCRIPTION

[0057] For purposes of the description hereinafter, the terms “end,” “upper,” “lower,” “right,” “left,” “vertical,” “horizontal,” “top,” “bottom,” “lateral,” “longitudinal,” and derivatives thereof shall relate to the embodiments as they are oriented in the drawing figures. However, it is to be understood that the present disclosure may assume various alternative variations and step sequences, except where expressly specified to the contrary. It is also to be understood that the specific devices and processes illustrated in the attached drawings, and described in the following specification, are simply exemplary and non-limiting embodiments or aspects of the disclosed subject matter. Hence, specific dimensions and other physical characteristics related to the embodiments or aspects disclosed herein are not to be considered as limiting.

[0058] Some non-limiting embodiments or aspects are described herein in connection with thresholds. As used herein, satisfying a threshold may refer to a valuebeing greater than the threshold, more than the threshold, higher than the threshold, greater than or equal to the threshold, less than the threshold, fewer than the threshold, lower than the threshold, less than or equal to the threshold, equal to the threshold, etc.

[0059] No aspect, component, element, structure, act, step, function, instruction, and / or the like used herein should be construed as critical or essential unless explicitly described as such. Also, as used herein, the articles “a” and “an” are intended to include one or more items and may be used interchangeably with “one or more” and “at least one.” Furthermore, as used herein, the term “set” is intended to include one or more items (e.g., related items, unrelated items, a combination of related and unrelated items, and / or the like) and may be used interchangeably with “one or more” or “at least one.” Where only one item is intended, the term “one” or similar language is used. Also, as used herein, the terms “has,” “have,” “having,” or the like are intended to be open-ended terms. Further, the phrase “based on” is intended to mean “based at least partially on” unless explicitly stated otherwise. In addition, reference to an action being “based on” a condition may refer to the action being “in response to” the condition. For example, the phrases “based on” and “in response to” may, in some non-limiting embodiments or aspects, refer to a condition for automatically triggering an action (e.g., a specific operation of an electronic device, such as a computing device, a processor, and / or the like).

[0060] As used herein, the term “acquirer institution” may refer to an entity licensed and / or approved by a transaction service provider to originate transactions (e.g., payment transactions) using a payment device associated with the transaction service provider. The transactions the acquirer institution may originate may include payment transactions (e.g., purchases, original credit transactions (OCTs), account funding transactions (AFTs), and / or the like). In some non-limiting embodiments or aspects, an acquirer institution may be a financial institution, such as a bank. As used herein, the term “acquirer system” may refer to one or more computing devices operated by or on behalf of an acquirer institution, such as a server computer executing one or more software applications.

[0061] As used herein, the term “account identifier” may include one or more primary account numbers (PANs), tokens, or other identifiers associated with a customer account. The term “token” may refer to an identifier that is used as a substitute or replacement identifier for an original account identifier, such as a PAN.Account identifiers may be alphanumeric or any combination of characters and / or symbols. Tokens may be associated with a PAN or other original account identifier in one or more data structures (e.g., one or more databases, and / or the like) such that they may be used to conduct a transaction without directly using the original account identifier. In some examples, an original account identifier, such as a PAN, may be associated with a plurality of tokens for different individuals or purposes.

[0062] As used herein, the terms “client” and / or “client device” may refer to one or more client-side devices or systems (e.g., remote from a transaction service provider system) used to initiate or facilitate a transaction (e.g., a payment transaction). As an example, a “client device” may refer to one or more POS devices used by a merchant, one or more acquirer host computers used by an acquirer, one or more mobile devices used by a user, and / or the like. In some non-limiting embodiments or aspects, a client device may be an electronic device configured to communicate with one or more networks and initiate or facilitate transactions. For example, a client device may include one or more computers, portable computers, laptop computers, tablet computers, mobile devices, cellular phones, wearable devices (e.g., watches, glasses, lenses, clothing, and / or the like), PDAs, and / or the like. Moreover, a “client” may also refer to an entity (e.g., a merchant, an acquirer, and / or the like) that owns, utilizes, and / or operates a client device for initiating transactions (e.g., for initiating transactions with a transaction service provider).

[0063] As used herein, the term “communication” may refer to the reception, receipt, transmission, transfer, provision, and / or the like of data (e.g., information, signals, messages, instructions, commands, and / or the like). For one unit (e.g., a device, a system, a component of a device or system, combinations thereof, and / or the like) to be in communication with another unit means that the one unit is able to directly or indirectly receive information from and / or transmit information to the other unit. This may refer to a direct or indirect connection (e.g., a direct communication connection, an indirect communication connection, and / or the like) that is wired and / or wireless in nature. Additionally, two units may be in communication with each other even though the information transmitted may be modified, processed, relayed, and / or routed between the first and second unit. For example, a first unit may be in communication with a second unit even though the first unit passively receives information and does not actively transmit information to the second unit. As another example, a first unit may be in communication with a second unit if at least oneintermediary unit processes information received from the first unit and communicates the processed information to the second unit. In some non-limiting embodiments or aspects, a message may refer to a network packet (e.g., a data packet and / or the like) that includes data. It will be appreciated that numerous other arrangements are possible.

[0064] As used herein, the term “computing device” may refer to one or more electronic devices configured to process data. A computing device may, in some examples, include the necessary components to receive, process, and output data, such as a processor, a display, a memory, an input device, a network interface, and / or the like. A computing device may be a mobile device. As an example, a mobile device may include a cellular phone (e.g., a smartphone or standard cellular phone), a portable computer, a wearable device (e.g., watches, glasses, lenses, clothing, and / or the like), a personal digital assistant (PDA), and / or other like devices. A computing device may also be a desktop computer or other form of non-mobile computer.

[0065] As used herein, the terms “electronic wallet” and “electronic wallet application” refer to one or more electronic devices and / or software applications configured to initiate and / or conduct payment transactions. For example, an electronic wallet may include a mobile device executing an electronic wallet application, and may further include server-side software and / or databases for maintaining and providing transaction data to the mobile device. An “electronic wallet provider” may include an entity that provides and / or maintains an electronic wallet for a customer, such as Google Pay®, Android Pay®, Apple Pay®, Samsung Pay®, and / or other like electronic payment systems. In some non-limiting examples, an issuer bank may be an electronic wallet provider.

[0066] As used herein, the term “issuer institution” may refer to one or more entities, such as a bank, that provide accounts to customers for conducting transactions (e.g., payment transactions), such as initiating credit and / or debit payments. For example, an issuer institution may provide an account identifier, such as a PAN, to a customer that uniquely identifies one or more accounts associated with that customer. The account identifier may be embodied on a portable financial device, such as a physical financial instrument, e.g., a payment card, and / or may be electronic and used for electronic payments. The term “issuer system” refers to one or more computer devices operated by or on behalf of an issuer institution, such as a servercomputer executing one or more software applications. For example, an issuer system may include one or more authorization servers for authorizing a transaction.

[0067] As used herein, the term “merchant” may refer to an individual or entity that provides goods and / or services, or access to goods and / or services, to customers based on a transaction, such as a payment transaction. The term “merchant” or “merchant system” may also refer to one or more computer systems operated by or on behalf of a merchant, such as a server computer executing one or more software applications.

[0068] As used herein, the term “payment device” may refer to an electronic payment device, a portable financial device, a payment card (e.g., a credit or debit card), a gift card, a smartcard, smart media, a payroll card, a healthcare card, a wristband, a machine-readable medium containing account information, a keychain device or fob, an RFID transponder, a retailer discount or loyalty card, a cellular phone, an electronic wallet mobile application, a PDA, a pager, a security card, a computing device, an access card, a wireless terminal, a transponder, and / or the like. In some non-limiting embodiments or aspects, the payment device may include volatile or nonvolatile memory to store information (e.g., an account identifier, a name of the account holder, and / or the like).

[0069] As used herein, the term “payment gateway” may refer to an entity and / or a payment processing system operated by or on behalf of such an entity (e.g., a merchant service provider, a payment service provider, a payment facilitator, a payment facilitator that contracts with an acquirer, a payment aggregator, and / or the like), which provides payment services (e.g., transaction service provider payment services, payment processing services, and / or the like) to one or more merchants. The payment services may be associated with the use of portable financial devices managed by a transaction service provider. As used herein, the term “payment gateway system” may refer to one or more computer systems, computer devices, servers, groups of servers, and / or the like, operated by or on behalf of a payment gateway.

[0070] As used herein, a “point-of-sale (POS) device” may refer to one or more devices, which may be used by a merchant to conduct a transaction (e.g., a payment transaction) and / or process a transaction. For example, a POS device may include one or more client devices. Additionally or alternatively, a POS device may include peripheral devices, card readers, scanning devices (e.g., code scanners), Bluetooth®communication receivers, near-field communication (NFC) receivers, radio frequency identification (RFID) receivers, and / or other contactless transceivers or receivers, contact-based receivers, payment terminals, and / or the like. As used herein, a “point- of-sale (POS) system” may refer to one or more client devices and / or peripheral devices used by a merchant to conduct a transaction. For example, a POS system may include one or more POS devices and / or other like devices that may be used to conduct a payment transaction. In some non-limiting embodiments or aspects, a POS system (e.g., a merchant POS system) may include one or more server computers programmed or configured to process online payment transactions through webpages, mobile applications, and / or the like.

[0071] As used herein, the term “server” may refer to or include one or more computing devices that are operated by or facilitate communication and processing for multiple parties in a network environment, such as the Internet, although it will be appreciated that communication may be facilitated over one or more public or private network environments and that various other arrangements are possible. Further, multiple computing devices (e.g., servers, POS devices, mobile devices, etc.) directly or indirectly communicating in the network environment may constitute a “system.”

[0072] As used herein, the term “system” may refer to one or more computing devices or combinations of computing devices (e.g., processors, servers, client devices, software applications, components of such, and / or the like). Reference to “a device,” “a server,” “a processor,” and / or the like, as used herein, may refer to a previously-recited device, server, or processor that is recited as performing a previous step or function, a different device, server, or processor, and / or a combination of devices, servers, and / or processors. For example, as used in the specification and the claims, a first device, a first server, or a first processor that is recited as performing a first step or a first function may refer to the same or different device, server, or processor recited as performing a second step or a second function.

[0073] As used herein, the term “transaction service provider” may refer to an entity that receives transaction authorization requests from merchants or other entities and provides guarantees of payment, in some cases through an agreement between the transaction service provider and an issuer institution. For example, a transaction service provider may include a payment network such as Visa® or any other entity that processes transactions. The term “transaction processing system” may refer to one or more computer systems operated by or on behalf of a transaction serviceprovider, such as a transaction processing server executing one or more software applications. A transaction processing server may include one or more processors and, in some non-limiting embodiments or aspects, may be operated by or on behalf of a transaction service provider.

[0074] Provided are systems, methods, and computer program products for rendering, creation, and management of dynamic application forms. Non-limiting embodiments or aspects of the present disclosure may include a system that includes at least one processor and at least one non-transitory computer-readable medium comprising instructions to direct the at least one processor to create, modify, and / or render dynamic application forms. In some non-limiting embodiments or aspects, the at least one processor may be directed to receive an input from a first user via a first graphical user interface (GUI). For example, the input may be associated with a graphical element associated with a field of a form and / or at least one attribute associated with the field. In some non-limiting embodiments or aspects, the at least one processor may be further directed to generate a schema file based on the input associated with the graphical element associated with the field of the form and / or the at least one attribute associated with the field. In some non-limiting embodiments or aspects, the at least one processor may be further directed to validate the schema file based on the at least one attribute associated with the field. In some non-limiting embodiments or aspects, the at least one processor may be further directed to, in response to validating the schema file, store the schema file in a database. In some non-limiting embodiments or aspects, the at least one processor may be further directed to retrieve the schema file from the database. In some non-limiting embodiments or aspects, the at least one processor may be further directed to communicate the schema file to a user device of a second user to render and display the form based on the schema file.

[0075] In this way, the present disclosure enables users to create and / or update forms and / or fields thereof without requiring knowledge of coding or schema file syntax. Additionally, the forms are rendered dynamically by loading the schema files rather than having form fields hard-coded into software, making the deployment of new and / or updated forms faster and more efficient. Moreover, the fields created by the drag-and-drop interface can have custom syntax, rules, and variables without requiring changes to the underlying software code, thereby enabling deployment of any desired number of customized fields without the need to change the softwarecode. Furthermore, previous versions of schema files may be stored so that, if there is an error or another problem with a new schema file, the previous version can be deployed instantly while the new version is repaired. In particular, a user can use a drag-and-drop GUI to add or modify one or more fields of a form (e.g., a web form). As the user edits the form, a schema file (e.g., JSON Schema file) defining each field and the attributes of each field is generated / modified. For example, attributes may include possible values (e.g., in a dropdown menu) and / or rules, such as ranges of acceptable values, dependencies on other fields, etc. The schema file may be saved and / or communicated to a back-end schema manager, which may validate the schema file and / or save the file in a database. Thereafter, when a second user (e.g., end user) needs to fill out the form, the schema file may be retrieved from the database and used to render the form in a second GUI based on the schema file.

[0076] Additionally, in some non-limiting embodiments or aspects, the at least one processor may be further directed to receive data from the user device of the second user based on an input to the form displayed via the second GUI, validate the data received from the user device of the second user, and / or store the data received from the user device of the second user. As such, the second user may input data into the field(s) of the form, and the data may be communicated to the back-end, where the data may be validated (e.g., based on the rules / attributes of the fields) and / or stored in the database.

[0077] In some non-limiting embodiments or aspects, the at least one processor may be further directed to receive a request message associated with the form from the first user via the first GUI. In some non-limiting embodiments or aspects, the at least one processor may be further directed to retrieve the schema file from the database in response to receiving the request message. In some non-limiting embodiments or aspects, the at least one processor may be further directed to receive a second input from the first user via the first GUI, the second input associated with a second graphical element associated with a second field of the form and at least one second field attribute associated with the second field. In some non-limiting embodiments or aspects, the at least one processor may be further directed to generate a modified schema file based on the schema file and second input associated with the second graphical element associated with the second field of the form and the at least one second field attribute associated with the second field. In some non-limiting embodiments or aspects, the at least one processor may be furtherdirected to validate the modified schema file based on the at least one attribute associated with the field and the at least one second field attribute associated with the second field. In some non-limiting embodiments or aspects, the at least one processor may be further directed to, in response to validating the modified schema file, store the modified schema file in the database. As such, the first user may modify the form and / or fields thereof quickly and efficiently without requiring knowledge of coding or schema file syntax. In particular, a user can use a drag-and-drop GUI to add, delete, or otherwise modify one or more fields of an existing form (e.g., a web form) to generate a modified form. As the user edits the existing form, a modified schema file (e.g., JSON Schema file) defining each field and the attributes of each field is generated. For example, attributes may include possible values (e.g., in a dropdown menu) and / or rules, such as ranges of acceptable values, dependencies on other fields, etc. The modified schema file may be saved and / or communicated to a back- end schema manager, which may validate the modified schema file and / or save the modified schema file in a database. Thereafter, when a second user (e.g., end user) needs to fill out the form, the modified schema file may be retrieved from the database and used to render the modified form in a second GUI based on the modified schema file.

[0078] Referring now to FIG. 1 , shown is a schematic diagram of a system 100 for rendering, creation, and management of dynamic application forms, according to some non-limiting embodiments or aspects. As shown in FIG. 1 , system 100 may include schema system 102, database 104, first user device 106, and / or second user device 108. Schema system 102, database 104, first user device 106, and / or second user device 108 may interconnect (e.g., establish a connection to communicate) via wired connections, wireless connections (e.g., via a communication network), or a combination of wired and wireless connections.

[0079] Schema system 102 may include one or more devices configured to communicate with database 104, first user device 106, and / or second user device 108 (e.g., via a wired or wireless communication connection). For example, schema system 102 may include a server, a group of servers, and / or other like devices. In some non-limiting embodiments or aspects, schema system 102 may be associated with a transaction service provider system, as described herein. In some non-limiting embodiments or aspects, schema system 102 may be in communication with a data storage device (e.g., database 104), which may be local or remote to schema system102. In some non-limiting embodiments or aspects, schema system 102 may be capable of receiving information from, storing information in, transmitting information to, and / or searching information stored in the data storage device (e.g., database 104).

[0080] Database 104 may include one or more devices configured to communicate with schema system 102 (e.g., via a wired or wireless communication connection). For example, database 104 may include a computing device, such as a server, a group of servers, and / or other like devices. In some non-limiting embodiments or aspects, database 104 may be associated with a transaction service provider system, as discussed herein. In some non-limiting embodiments or aspects, database 104 may be part of schema system 102. In some non-limiting embodiments or aspects, database 104 may include a data storage device. In some non-limiting embodiments or aspects, database 104 may be capable of receiving information from, storing information in, transmitting information to, and / or searching information stored in the data storage device.

[0081] First user device 106 and / or second user device 108 may include a computing device configured to communicate with schema system 102 (e.g., via a wired or wireless communication connection). For example, first user device 106 and / or second user device 108 may include a computing device, such as a desktop computer, a portable computer (e.g., a tablet computer, a laptop computer, and / or the like), a mobile device (e.g., a cellular phone, a smartphone, a PDA, a wearable device, and / or the like), and / or other like devices. In some non-limiting embodiments or aspects, first user device 106 and / or second user device 108 may be associated with a user (e.g., an individual operating first user device 106 and / or second user device 108). For example, first user device 106 may be associated with a first user, and second user device 108 may be associated with a second user. In some non-limiting embodiments or aspects, the first user (e.g., of first user device 106) may be a developer and / or product manager associated with the form (e.g., whose responsibilities include designing the form, selecting which field(s) to include with the form, defining the attribute(s) of each field, and / or the like). Additionally or alternatively, the second user (e.g., of second user device 108) may be an end user (e.g., who is providing user data via the form).

[0082] In some non-limiting embodiments or aspects, first user device 106 may receive an input from a first user via a first GUI. The input may be associated with a graphical element associated with a field of a form and / or at least one attributeassociated with the field. In some non-limiting embodiments or aspects, first user device 106 may communicate (e.g., with schema system 102) based on the input. For example, first user device 106 may communicate the input (and / or data associated with the input) to schema system 102. In some non-limiting embodiments or aspects, schema system 102 may receive the communication (e.g., the input and / or data associated therewith) from first user device 106.

[0083] In some non-limiting embodiments or aspects, first user device 106 and / or schema system 102 may generate a schema file. For example, first user device 106 and / or schema system 102 may generate the schema file based on the input associated with the graphical elements associated with the field of the form and / or the at least one attribute associated with the field. In some non-limiting embodiments or aspects, first user device 106 may communicate the schema file to schema system 102, which may receive the schema file.

[0084] In some non-limiting embodiments or aspects, first user device 106 and / or schema system 102 may validate the schema file. For example, first user device 106 and / or schema system 102 may validate the schema file based on the at least one attribute associated with the field. In some non-limiting embodiments or aspects, first user device 106 may communicate the schema file to schema system 102 in response to validating the schema file.

[0085] In some non-limiting embodiments or aspects, first user device 106 and / or schema system 102 may store the schema file. For example, schema system 102 may store the schema file in database 104 (e.g., in response to validating the schema file and / or in response to receiving the validated schema file from first user device 106).

[0086] In some non-limiting embodiments or aspects, schema system 102 may retrieve the schema file. For example, schema system 102 may retrieve the schema file from database 104. In some non-limiting embodiments or aspects, schema system 102 may receive a request message from second user device 108 associated with a request to access the form. Schema system 102 may retrieve the schema file from database 104 in response to receiving the request message.

[0087] In some non-limiting embodiments or aspects, schema system 102 may communicate the schema file. For example, schema system 102 may communicate the schema file to second user device 108 to render and display the form based on the schema file. In some non-limiting embodiments or aspects, schema system 102may communicate the schema file to second user device 108 in response to receiving the request message.

[0088] In some non-limiting embodiments or aspects, second user device 108 may render and display the form based on the schema file.

[0089] The number and arrangement of devices and networks shown in FIG. 1 are provided as an example. There may be additional devices and / or networks, fewer devices and / or networks, different devices and / or networks, or differently arranged devices and / or networks than those shown in FIG. 1. Furthermore, two or more devices shown in FIG. 1 may be implemented within a single device, or a single device shown in FIG. 1 may be implemented as multiple, distributed devices. Additionally or alternatively, a set of devices (e.g., one or more devices) of system 100 may perform one or more functions described as being performed by another set of devices of system 100.

[0090] Referring now to FIG. 2, shown is a schematic diagram of example components of a device 200, according to some non-limiting embodiments or aspects. Device 200 may correspond to schema system 102 (e.g., one or more devices of schema system 102), database 104 (e.g., one or more devices of database 104), first user device 106, and / or second user device 108, as an example. In some non-limiting embodiments or aspects, such systems or devices may include at least one device 200 and / or at least one component of device 200. In some non-limiting embodiments or aspects, such systems or devices may include the at least one device 200 and / or the at least one component of device 200. The number and arrangement of components shown are provided as an example. In some non-limiting embodiments or aspects, device 200 may include additional components, fewer components, different components, or differently arranged components than those shown. Additionally or alternatively, a set of components (e.g., one or more components) of device 200 may perform one or more functions described as being performed by another set of components of device 200.

[0091] As shown in FIG. 2, device 200 may include bus 202, processor 204, memory 206, storage component 208, input component 210, output component 212, and communication interface 214. Bus 202 may include a component that permits communication among the components of device 200. In some non-limiting embodiments or aspects, processor 204 may be implemented in hardware, firmware, or a combination of hardware and software. For example, processor 204 may includea processor (e.g., a central processing unit (CPU), a graphics processing unit (GPU), an accelerated processing unit (APU), etc.), a microprocessor, a digital signal processor (DSP), and / or any processing component (e.g., a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), etc.) that can be programmed to perform a function. Memory 206 may include random access memory (RAM), read only memory (ROM), and / or another type of dynamic or static storage device (e.g., flash memory, magnetic memory, optical memory, etc.) that stores information and / or instructions for use by processor 204.

[0092] With continued reference to FIG. 2, storage component 208 may store information and / or software related to the operation and use of device 200. For example, storage component 208 may include a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optic disk, a solid-state disk, etc.) and / or another type of computer-readable medium. Input component 210 may include a component that permits device 200 to receive information, such as via user input (e.g., a touch screen display, a keyboard, a keypad, a mouse, a button, a switch, a microphone, etc.). Additionally or alternatively, input component 210 may include a sensor for sensing information (e.g., a global positioning system (GPS) component, an accelerometer, a gyroscope, an actuator, etc.). Output component 212 may include a component that provides output information from device 200 (e.g., a display, a speaker, one or more light-emitting diodes (LEDs), etc.). Communication interface 214 may include a transceiver-like component (e.g., a transceiver, a separate receiver and transmitter, etc.) that enables device 200 to communicate with other devices, such as via a wired connection, a wireless connection, or a combination of wired and wireless connections. Communication interface 214 may permit device 200 to receive information from another device and / or provide information to another device. For example, communication interface 214 may include an Ethernet interface, an optical interface, a coaxial interface, an infrared interface, a radio frequency (RF) interface, a universal serial bus (USB) interface, a Wi-Fi® interface, a cellular network interface, and / or the like.

[0093] Device 200 may perform one or more processes described herein. Device 200 may perform these processes based on processor 204 executing software instructions stored by a computer-readable medium, such as memory 206 and / or storage component 208. A computer-readable medium may include any non- transitory memory device. A memory device includes memory space located insideof a single physical storage device or memory space spread across multiple physical storage devices. Software instructions may be read into memory 206 and / or storage component 208 from another computer-readable medium or from another device via communication interface 214. When executed, software instructions stored in memory 206 and / or storage component 208 may cause processor 204 to perform one or more processes described herein. Additionally or alternatively, hardwired circuitry may be used in place of or in combination with software instructions to perform one or more processes described herein. Thus, embodiments described herein are not limited to any specific combination of hardware circuitry and software. The term “configured to,” as used herein, may refer to an arrangement of software, device(s), and / or hardware for performing and / or enabling one or more functions (e.g., actions, processes, steps of a process, and / or the like). For example, “a processor configured to” may refer to a processor that executes software instructions (e.g., program code) that cause the processor to perform one or more functions.

[0094] Referring now to FIG. 3, shown is a flow diagram of a method 300 for rendering, creation, and management of dynamic application forms, according to some non-limiting embodiments or aspects. In some non-limiting embodiments or aspects, one or more steps of method 300 may be performed (e.g., completely, partially, etc.) by schema system 102 (e.g., one or more devices of schema system 102). In some non-limiting embodiments or aspects, one or more steps of method 300 may be performed (e.g., completely, partially, etc.) by another device or group of devices separate from or including schema system 102 (e.g., one or more devices of schema system 102), database 104 (e.g., one or more devices of database 104), first user device 106 and / or second user device 108.

[0095] As shown in FIG. 3, at step 302, method 300 includes receiving an input from a first user via a first GUI. The input may be associated with a graphical element associated with a field of a form and / or at least one attribute associated with the field. In some non-limiting embodiments or aspects, first user device 106 may communicate (e.g., with schema system 102) based on the input. For example, first user device 106 may communicate the input (and / or data associated with the input) to schema system 102. In some non-limiting embodiments or aspects, schema system 102 may receive the communication (e.g., the input and / or data associated therewith) from first user device 106.

[0096] In some non-limiting embodiments or aspects, the input may be associated with the graphical element. For example, the input may be associated with the graphical element associated with a field of a form and / or at least one attribute associated with the field.

[0097] In some non-limiting embodiments or aspects, the form may include a plurality of fields. Each of the plurality of fields may be associated with at least one graphical element. Additionally or alternatively, each of the plurality of fields may be associated with at least one attribute.

[0098] In some non-limiting embodiments or aspects, the form may be an existing form (e.g., stored in database 104 and / or retrieved by schema system 102 from database 104). In some non-limiting embodiments or aspects, the form may be a new form generated (e.g., by first user device 106 and / or schema system 102). For example, first user device 106 and / or schema system 102 may generate a new form based on the input.

[0099] In some non-limiting embodiments or aspects, the attribute(s) associated with a field may include at least one of a rule, a dependency on at least one other field of the form, a name of the field, a type of the graphical element, any combination thereof, and / or the like.

[0100] In some non-limiting embodiments or aspects, the first GUI may be displayed on a display of first user device 106. A user of first user device 106 may enter the input via the first GUI. In some non-limiting embodiments or aspects, the user may select and / or interact with a graphical element associated with a field of a form. For example, the user may drag a selected graphical element into the form displayed via the first GUI and drop the selected graphical element into the form. In some non-limiting embodiments or aspects, the first GUI may be configured to update based on the selected field being dropped into the form. Additionally or alternatively, the user may select a graphical element displayed by the first GUI and drag the selected graphical element to a different position within the form and / or out of the form displayed by the first GUI (e.g., to reposition and / or remove the graphical element from the form, respectively).

[0101] As shown in FIG. 3, at step 304, method 300 includes generating a schema file. For example, schema system 102 and / or first user device 106 may generate and / or modify a schema file (e.g., in response to receiving the input).

[0102] In some non-limiting embodiments or aspects, schema system 102 and / or first user device 106 may generate (and / or modify) the schema file based on the input associated with the graphical element associated with the field of the form and the at least one attribute associated with the field.

[0103] In some non-limiting embodiments or aspects, first user device 106 may communicate the schema file to schema system 102.

[0104] As shown in FIG. 3, at step 306, method 300 includes validating the schema file. For example, schema system 102 and / or first user device 106 may validate the schema file based on the at least one attribute associated with the field.

[0105] In some non-limiting embodiments or aspects, first user device 106 may communicate the schema file to schema system 102 in response to validating the schema file.

[0106] As shown in FIG. 3, at step 308, method 300 includes storing the schema file in a database. For example, schema system 102 may store the schema file in database 104 (e.g., in response to generating the schema file, validating the schema file, and / or receiving the (validated) schema file from first user device 106).

[0107] As shown in FIG. 3, at step 310, method 300 includes retrieving the schema file. For example, schema system 102 may retrieve the schema file from database 104.

[0108] In some non-limiting embodiments or aspects, retrieving the schema file from database 104 may include receiving a request message associated with the form. For example, schema system 102 may receive the request message from a second user via second user device 108. In some non-limiting embodiments or aspects, the request message may include a request to access the form.

[0109] In some non-limiting embodiments or aspects, retrieving the schema file may include retrieving the schema file from database 104 in response to receiving the request message. For example, schema system 102 may retrieve the schema file from database 104 in response to receiving the request message.

[0110] As shown in FIG. 3, at step 312, method 300 includes communicating the schema file to a user device of a second user. For example, schema system 102 may communicate the schema file to second user device 108.

[0111] In some non-limiting embodiments or aspects, second user device 108 may render and display the form based on the schema file. For example, second user device 108 may render and display the form via a second GUI based on the schemafile. In some non-limiting embodiments or aspects, a second user may input data (e.g., user data associated with at least one field of the form) to the form via the second GUI. In some non-limiting embodiments or aspects, schema system 102 may receive data (e.g., the user data) from second user device 108. For example, schema system 102 may receive the data (e.g., the user data) from second user device 108 based on the input to the form displayed via the second GUI. For example, second user device 108 may communicate the data (e.g., user data) to schema system 102 based on receiving the input associated with the user data via the second GUI.

[0112] In some non-limiting embodiments or aspects, second user device 108 and / or schema system 102 may validate the data received from the user of second user device 108. In some non-limiting embodiments or aspects, the data received from the user may be validated based on the at least one attribute of the field of the form. In some non-limiting embodiments or aspects, second user device 108 may communicate the data received from the user to schema system 102 in response to validating the data.

[0113] In some non-limiting embodiments or aspects, schema system 102 may store the data received from the user of second user device 108. For example, schema system 102 may store the data received from the user of second user device 108 in database 104 in response to validating the data and / or in response to receiving the data (e.g., validated data) from second user device 108.

[0114] In some non-limiting embodiments or aspects, schema system 102 may repeat step 310 and / or 312. For example, schema system 102 may repeat step 310 and / or 312 in response to receiving another request message from second user device 108.

[0115] In some non-limiting embodiments or aspects, first user device 106 may receive a second input from the first user via the first GUI. In some non-limiting embodiments or aspects, first user device 106 may communicate the second input to schema system 102. In some non-limiting embodiments or aspects, the second input may be associated with a second graphical element associated with a second field of the form and at least one second field attribute associated with the second field.

[0116] In some non-limiting embodiments or aspects, schema system 102 may generate a modified schema file. For example, schema system 102 may generate a modified schema file based on the schema file and the second input associated withthe second graphical element associated with the second field of the form and the at least one second field attribute associated with the second field.

[0117] In some non-limiting embodiments or aspects, schema system 102 may validate the modified schema file. For example, schema system 102 may validate the modified schema file based on the at least one attribute associated with the field and the at least one second field attribute associated with the second field.

[0118] In some non-limiting embodiments or aspects, schema system 102 may store the modified schema file. For example, in response to validating the modified schema file, schema system 102 may store the modified schema file in database 104.

[0119] The number and arrangement of steps in FIG. 3 are provided as an example. In some non-limiting embodiments or aspects, method 300 may include additional steps, fewer steps, different steps, or differently arranged steps than those shown in FIG. 3.

[0120] Referring now to FIGS. 4A and 4B, shown are diagrams of an implementation of a process 400 (e.g., method 300) for rendering, creation, and management of dynamic application forms, according to some non-limiting embodiments or aspects. As shown in FIGS. 4A and 4B, implementation 400 may include schema system 402 (e.g., one or more devices of schema system 402) performing one or more steps of the process. In some non-limiting embodiments or aspects, schema system 402 may be the same as, similar to, and / or part of schema system 102. In some non-limiting embodiments or aspects, schema system 402 may include schema management system 402a and / or user data management system 402b. In some non-limiting embodiments or aspects, first user device 406 may be the same as or similar to first user device 106. In some non-limiting embodiments or aspects, second user device 408 may be the same as or similar to second user device 108. In some non-limiting embodiments or aspects, database 404 may be the same as or similar to database 104.

[0121] In some non-limiting embodiments or aspects, schema management system 402a may include at least one server (e.g., at least one front-end server, at least one back-end server, and / or the like). In some non-limiting embodiments or aspects, the at least one front-end server of schema management system 402a may be configured to communicate with first user device 406 and / or render the first GUI (e.g., via first user device 406), as described herein. In some non-limiting embodiments or aspects, the at least one front-end server of schema managementsystem 402a may generate the schema file (e.g., based on input received via the first GUI displayed on first user device 406), as described herein. In some non-limiting embodiments or aspects, the at least one back-end server of schema management system 402a may be configured to validate the schema file, store the schema file, retrieve the schema file, and / or modify the schema file, as described herein.

[0122] In some non-limiting embodiments or aspects, user data management system 402b may include at least one server (e.g., at least one front-end server, at least one back-end server, and / or the like). In some non-limiting embodiments or aspects, the at least one front-end server of user data management system 402b may be configured to communicate with second user device 408 and / or render the second GUI (e.g., via second user device 408), as described herein. In some non-limiting embodiments or aspects, the at least one back-end server of user data management system 402b may be configured to retrieve the schema file, validate user data, and / or store user data, as described herein.

[0123] In some non-limiting embodiments or aspects, implementation 400 may include database 404. In some non-limiting embodiments or aspects, database 404 may be part of schema system 402.

[0124] As shown in step 1 , first user device 406 may communicate an input to schema system 402. In some non-limiting embodiments or aspects, first user device 406 may receive the input from a first user via a first GUI. In some non-limiting embodiments or aspects, the input may be associated with a graphical element associated with a field of a form and at least one attribute associated with the field. In some non-limiting embodiments or aspects, in response to receiving the input from the user, first user device 406 may communicate the input to schema system 402. In some non-limiting embodiments or aspects, schema system 402 may receive the communication, including the input from first user device 406.

[0125] In some non-limiting embodiments or aspects, the form may include a plurality of fields. Each of the plurality of fields may be associated with at least one graphical element. Additionally or alternatively, each of the plurality of fields may be associated with at least one attribute.

[0126] In some non-limiting embodiments or aspects, the form may be an existing form (e.g., stored in database 404 and / or retrieved by schema system 402 from database 404). In some non-limiting embodiments or aspects, the form may be a new form generated (e.g., by first user device 406 and / or schema system 402). Forexample, first user device 406 and / or schema system 402 may generate a new form based on the input.

[0127] In some non-limiting embodiments or aspects, the attribute(s) associated with a field may include at least one of a rule, a dependency on at least one other field of the form, a name of the field, a type of the graphical element, any combination thereof, and / or the like.

[0128] In some non-limiting embodiments or aspects, the first GUI may be displayed on a display of first user device 406. A user of first user device 406 may enter the input via the first GUI. In some non-limiting embodiments or aspects, the user may select and / or interact with a graphical element associated with a field of a form. For example, the user may drag a selected graphical element into the form displayed via the first GUI and drop the selected graphical element into the form. In some non-limiting embodiments or aspects, the first GUI may be configured to update based on the selected field being dropped into the form. Additionally or alternatively, the user may select a graphical element displayed by the first GUI and drag the selected graphical element to a different position within the form and / or out of the form displayed by the first GUI (e.g., to reposition and / or remove the graphical element from the form, respectively).

[0129] In some non-limiting embodiments or aspects, schema management system 402a and / or first user device 406 may generate (and / or modify) a schema file based on the input associated with the graphical element associated with the field of the form and the at least one attribute associated with the field.

[0130] In some non-limiting embodiments or aspects, at least one front-end server of schema management system 402a may generate the schema file. Additionally or alternatively, first user device 406 may communicate the schema file to schema system 402.

[0131] In some non-limiting embodiments or aspects, schema system 402 may validate the schema file. For example, schema management system 402a may validate the schema file based on the at least one attribute associated with the field. In some non-limiting embodiments or aspects, at least one back-end server of schema management system 402a may validate the schema file.

[0132] In some non-limiting embodiments or aspects, first user device 406 may communicate the schema file to schema system 402 in response to validating the schema file.

[0133] As shown in step 2, schema system 402 may store the schema file in database 404. For example, schema management system 402a may communicate the schema file to database 404 (e.g., in response to generating the schema file, validating the schema file, and / or receiving the (validated) schema file from first user device 406). In some non-limiting embodiments or aspects, at least one back-end server of schema management system 402a may communicate the schema file to database 404.

[0134] In some non-limiting embodiments or aspects, database 404 may store the schema file in a memory of database 404.

[0135] As shown in step 3, schema system 402 may receive a request message from second user device 408. For example, user data management system 402b may receive a request message associated with the form from second user device 408. The request message may include a request to retrieve (e.g., fetch) the schema file from database 404. In some non-limiting embodiments or aspects, a front-end server of user data management system 402b may receive the request message from second user device 408.

[0136] As shown in step 4, schema system 402 may retrieve the schema file from database 404. For example, user data management system 402b may retrieve the schema file from database 404 in response to receiving the request message from second user device 408. In some non-limiting embodiments or aspects, at least one back-end server of schema management system 402a may retrieve the schema file from database 404.

[0137] As shown in step 5, schema system 402 may communicate the schema file to second user device 408. For example, user data management system 402b may communicate the schema file to second user device 408 to render and display the form based on the schema file. In some non-limiting embodiments or aspects, at least one front-end server of user data management system 402b may communicate the schema file to second user device 408.

[0138] In some non-limiting embodiments or aspects, second user device 408 may render and display the form based on the schema file. For example, second user device 408 may render and display the form via a second GUI based on the schema file. In some non-limiting embodiments or aspects, a second user may input data (e.g., user data associated with at least one field of the form) to the form via the second GUI.

[0139] In some non-limiting embodiments or aspects, a user of second user device 408 may input data into the form displayed on second user device 408 via the second GUI. In some non-limiting embodiments or aspects, schema system 402 may receive data (e.g., the user data) from second user device 408. For example, schema system 402 may receive the data (e.g., the user data) from second user device 408 based on the input to the form displayed via the second GUI. For example, second user device 408 may communicate the data (e.g., user data) to schema system 402 based on receiving the input associated with the user data via the second GUI.

[0140] As shown in step 6, second user device 408 may communicate data to schema system 402 based on the input to the form received by the user of second user device 408. For example, second user device 408 may communicate data to user data management system 402b based on the input to the form received by the user of second user device 408.

[0141] In some non-limiting embodiments or aspects, schema system 402 and / or second user device 408 may validate the data received from the user of second user device 408. For example, user data management system 402b may validate the data received from second user device 408 based on the at least one attribute of the field of the form. In some non-limiting embodiments or aspects, at least one back-end server of user data management system 402b may validate the data. In some nonlimiting embodiments or aspects, second user device 408 may validate the data based on the at least one attribute of the field of the form.

[0142] In some non-limiting embodiments or aspects, schema system 402 may store the data received from second user device 408.

[0143] As shown in step 7, schema system 402 may communicate the data received from second user device 408 to database 404. For example, user data management system 402b may communicate the data to database 404 in response to validating the data. In some non-limiting embodiments or aspects, at least one back-end server of user data management system 402b may communicate the data to database 404. In some non-limiting embodiments or aspects, second user device 408 may communicate the data to database 404 in response to validating the data.

[0144] In some non-limiting embodiments or aspects, database 404 may store the data. For example, database 404 may store the data in response to receiving the data (e.g., validated data) from user data management system 402b and / or second user device 408.

[0145] As shown in step 8, schema system 402 may receive a request message from first user device 406. For example, schema management system 402a may receive a request message associated with the form from the first user via the first GUI. In some non-limiting embodiments or aspects, at least one front-end server of schema management system 402a may receive the request message.

[0146] As shown in step 9, schema system 402 may retrieve the schema file from database 404. For example, schema management system 402a may retrieve the schema file from database 404 in response to receiving the request message. In some non-limiting embodiments or aspects, at least one back-end server of schema management system 402a may retrieve the schema file.

[0147] As shown in step 10, schema system 402 may receive a second input from first user device 406. For example, schema management system 402a may receive a second input from the first user via the first GUI. The second input may be associated with a second graphical element associated with a second field of the form and at least one second field attribute associated with the second field. In some nonlimiting embodiments or aspects, at least one front-end server of schema management system 402a may receive the second input.

[0148] In some non-limiting embodiments or aspects, schema system 402 may generate a modified schema file. For example, schema management system 402a may generate a modified schema file based on the schema file and the second input associated with the second graphical element associated with the second field of the form and the at least one second field attribute associated with the second field. In some non-limiting embodiments or aspects, at least one back-end server of schema management system 402a may generate the modified schema file.

[0149] In some non-limiting embodiments or aspects, schema system 402 may validate the modified schema file. For example, schema management system 402a may validate the modified schema file. In some non-limiting embodiments or aspects, at least one back-end server of schema management system 402a may validate the modified schema file.

[0150] As shown in step 1 1 , schema system 402 may store the modified schema file in database 404. For example, schema management system 402a may communicate the modified schema file to database 404 in response to generating and / or validating the modified schema file. In some non-limiting embodiments or aspects, at least one back-end server of schema management system 402a maycommunicate the modified schema file to database 404. In some non-limiting embodiments or aspects, at least one back-end server of schema management system 402a may communicate the modified schema file to database 404.

[0151] In some non-limiting embodiments or aspects, database 404 may store the schema file in a memory of database 404.

[0152] As shown in step 12, schema system 402 may receive a request message associated with the form from the user device of the second user. For example, user data management system 402b may receive a request message from second user device 408. The request message may include a request to access the form. In some non-limiting embodiments or aspects, at least one front-end server of user data management system 402b may receive the request message from second user device 408.

[0153] As shown in step 13, schema system 402 may retrieve (e.g., fetch) the modified schema file from database 404. For example, user data management system 402b may retrieve the modified schema file from database 404 in response to receiving the request message from second user device 408. In some non-limiting embodiments or aspects, at least one back-end server of user data management system 402b may retrieve the modified schema file database 404.

[0154] As shown in step 14, schema system 402 may communicate the modified schema file to second user device 408. For example, user data management system 402b may communicate the modified schema file to second user device 408 to render and display the form based on the modified schema file. In some non-limiting embodiments or aspects, at least one front-end server of user data management system 402b may communicate the modified schema file to second user device 408.

[0155] The number and arrangement of components and / or steps in FIGS. 4A and 4B are provided as an example. In some non-limiting embodiments or aspects, implementation 400 may include additional components and / or steps, fewer components and / or steps, different components and / or steps, or differently arranged components and / or steps than those shown in FIGS. 4A and 4B.

[0156] Referring now to FIG. 5, shown is an exemplary diagram of an editable form 500, according to some non-limiting embodiments or aspects. In some non-limiting embodiments or aspects, editable form 500 may include fields 502 and / or pop-up box 504. In some non-limiting embodiments or aspects, fields 502 may include Profile Name 502a, Countries 502b, Client Type 502c, Fee Rate % Value 502d, Fee MinAmount in Base Currency 502e, Trade Limit Amount in Base Currency 502f, Client Exchange ID 502g, and / or Fee Max Amount in Base Currency 502h.

[0157] In some non-limiting embodiments or aspects, editable form 500 may include a plurality of fields. In some non-limiting embodiments or aspects, a field of the plurality of fields may be configured to receive an input and / or a selection from a user. In some non-limiting embodiments or aspects, a field of the plurality of fields may be configured to receive text as an input from a user. For example, the field “Profile Name” may be configured to receive the text “testl 23” as an input from a user. The field may include a drop-down menu and / or pop-up box 504 associated with the field of the plurality of fields 502. For example, the field “Countries” may include a drop-down menu including a list of countries and the user may select a country from the list of countries (e.g., India). In some non-limiting embodiments or aspects, in order to render and display the selections in the drop-down menu, schema system 102 may generate and / or communicate an application programming interface (API) call to retrieve the list of countries.

[0158] In some non-limiting embodiments or aspects, the GUI on which editable form 500 is displayed may be configured to add a new field and / or remove an existing field. For example, a user may add a new field to editable form 500 by dragging and / or dropping the new field into editable form 500. Additionally or alternatively, a user may remove an existing field from editable form 500 by dragging the existing field and / or dropping the existing field outside of editable form 500.

[0159] In some non-limiting embodiments or aspects, the plurality of fields 502 may include mandatory fields which must be filled with specific data.

[0160] In some non-limiting embodiments or aspects, the schema file and / or the modified schema file may be a JSON file. For the purpose of illustration, an example JSON file may be formatted as follows: “minAmount”:{“type”: [“integer”,“null”“title”: “Fee Min Amount in Base Currency”,“maxLength”: 6,“minimum”: 0,“maximum”: 100000,“_editable”: true,“_editableType”: “NOT_APPLICABLE”“maxAmount”:{“type”: [“integer”,“null”“title”: “Fee Max Amount in Base Currency”,“maxLength”: 6,“minimum”: 0,“maximum”: 100000,“_editable”: true,“_editableType”: “NOT_APPLICABLE”}

[0161] In some non-limiting embodiments or aspects, the schema file may include the plurality of fields. For example, as shown in the example JSON file, the schema file may include at least two fields (e.g., “minAmount” and “maxAmount”). In some non-limiting embodiments or aspects, each field of the plurality of fields may include at least one attribute (e.g., a plurality of attributes). For example, as shown in the example JSON file, the example fields may each include a plurality of attributes (e.g., type, title, maxLength (e.g., maximum length of the field), minimum (e.g., minimum value of the field), maximum (e.g., maximum value of the field), _editable, and / or _editableType).

[0162] In some non-limiting embodiments or aspects, each attribute may have at least one value associated with it. In some non-limiting embodiments or aspects, the at least one value may be a numerical value, a string, and / or a categorical value. For example, as shown in the example JSON file, the attribute “title” may have the string value “Fee Min Amount in Base Currency”. The attribute “type” may have two possible string values: “integer” or “null”. The attribute “_editable” may have a categorical (e.g., Boolean) value, “true”. The attribute “minimum” may have a numerical value of 0.

[0163] In some non-limiting embodiments or aspects, a JSON file may be associated with a version number. In some non-limiting embodiments or aspects,modifying a schema file may include updating the version number. In some nonlimiting embodiments or aspects, database 104 may store one or more versions of a JSON schema file. In some non-limiting embodiments or aspects, one version of a JSON schema file may be assigned as an active version. A user may choose any version number to set the schema file associated with the schema file as the active version.

[0164] In some non-limiting embodiments or aspects, an attribute of the plurality of attributes may be modified automatically based on an input from a user. In some nonlimiting embodiments or aspects, the attribute(s) may define one or more APIs that are exposed.

[0165] In some non-limiting embodiments or aspects, any field may be editable or non-editable. Whether a field is editable or non-editable may be defined by the user (e.g., the first user). In some non-limiting embodiments or aspects, a plurality of rules may be used to determine if a field is editable or not. In some non-limiting embodiments or aspects, a rule may disable a user’s ability to edit a value of a field once it is set or based on a dependency. For example, if a first field (e.g., field A) has a certain value, then a second field (e.g., field B) may be disabled. In some nonlimiting embodiments or aspects, the JSON schema file may define any sort of dependency or relationship between fields of the form. In some non-limiting embodiments or aspects, a value for one field may be dependent on a value for another field. For example, a user may define that an input in a field titled “Start Date” should always be less than (e.g., earlier than) an input for a field titled “End Date.”

[0166] In some non-limiting embodiments or aspects, the JSON schema file may be created by a user (e.g., a product owner) through a first GUI (e.g., an admin portal). The user may not be required to have any knowledge of JSON Schema (e.g., code). The user may simply create and / or modify the graphical elements of the first GUI, and the JSON schema file may be automatically generated, as described herein. In some non-limiting embodiments or aspects, the first GUI may include and / or be at least partially based on react-json-schema-form-builder.

[0167] In some non-limiting embodiments or aspects, schema system 102 may include and / or be at least partially based on a JSON Schema Validator. For example, the JSON Schema Validator may be used to validate a schema file (e.g., a JSON schema file). For example, the JSON Schema Validator may validate the syntax, hierarchy, data types, and / or any combination thereof of the JSON schema file. Insome non-limiting embodiments or aspects, validating the JSON schema file, the JSON Schema Validator may include generating and / or communicating an error message.

[0168] In some non-limiting embodiments or aspects, the JSON schema file may include a default error message for each field based on a hierarchy of fields. In some non-limiting embodiments or aspects, the error messages for each field may include a custom message set by the user.

[0169] In some non-limiting embodiments or aspects, one or more JSON schema files may be related to another one or more JSON schema files. In some non-limiting embodiments or aspects, a user may define (e.g., specify) dependencies and / or relationships between one or more JSON schema files. The user may define dependencies and / or relationships between the fields of one or more JSON schema files. For example, Form A may correspond to schema file A, and Form B may correspond to schema file B. Form A may contain data, such as personal information related to the user, and Form B may display payment options available to the user (e.g., credit card, debit card, and / or the like). Once the user inputs the personal information into the field of Form A, the payment options presented by Form B may be modified based on the user’s personal information. The user’s personal information may be used to determine a credit score for the user. If the credit score satisfies a threshold value, then Form B may include a selectable option for the user to make a payment using a credit card. If the credit score does not satisfy the threshold value, then Form B may not include a selectable option for the user to make the payment using the credit card.

[0170] Referring now to FIG. 6, shown is an exemplary diagram of an environment 600 in which systems, methods, and / or computer program products, described herein, may be implemented, according to some non-limiting embodiments or aspects. As shown in FIG. 6, environment 600 may include transaction service provider system 602, issuer system 604, customer device 606, merchant system 608, acquirer system 610, and communication network 612. In some non-limiting embodiments or aspects, schema system 102 and / or database 104 may be implemented by (e.g., part of) transaction service provider system 602. In some non-limiting embodiments or aspects, at least one of schema system 102, database 104, first user device 106, and / or second user device 108 may be implemented by (e.g., part of) another system, another device, another group of systems, or another group of devices, separate fromor including transaction service provider system 602, such as issuer system 604, customer device 606, merchant system 608, acquirer system 610, and / or the like. For example, first user device 106 and / or second user device 108 may be implemented by (e.g., part of) customer device 606 (e.g., a payment device), merchant system 608 (e.g., a POS device, a POS system, and / or the like), and / or the like. Additionally or alternatively, schema system 102 and / or database 104 may be implemented by (e.g., part of) issuer system 604, merchant system 608, acquirer system 610, and / or the like.

[0171] Transaction service provider system 602 may include one or more devices capable of receiving information from and / or communicating information to issuer system 604, customer device 606, merchant system 608, and / or acquirer system 610 via communication network 612. For example, transaction service provider system 602 may include a computing device, such as a server (e.g., a transaction processing server), a group of servers, and / or other like devices. In some non-limiting embodiments or aspects, transaction service provider system 602 may be associated with a transaction service provider, as described herein. In some non-limiting embodiments or aspects, transaction service provider system 602 may be in communication with a data storage device, which may be local or remote to transaction service provider system 602. In some non-limiting embodiments or aspects, transaction service provider system 602 may be capable of receiving information from, storing information in, communicating information to, or searching information stored in the data storage device.

[0172] Issuer system 604 may include one or more devices capable of receiving information and / or communicating information to transaction service provider system 602, customer device 606, merchant system 608, and / or acquirer system 610 via communication network 612. For example, issuer system 604 may include a computing device, such as a server, a group of servers, and / or other like devices. In some non-limiting embodiments or aspects, issuer system 604 may be associated with an issuer institution, as described herein. For example, issuer system 604 may be associated with an issuer institution that issued a credit account, debit account, credit card, debit card, and / or the like to a user associated with customer device 606.

[0173] Customer device 606 may include one or more devices capable of receiving information from and / or communicating information to transaction service provider system 602, issuer system 604, merchant system 608, and / or acquirer system 610 via communication network 612. Additionally or alternatively, each customer device 606may include a device capable of receiving information from and / or communicating information to other customer devices 606 via communication network 612, another network (e.g., an ad hoc network, a local network, a private network, a virtual private network, and / or the like), and / or any other suitable communication technique. For example, customer device 606 may include a client device and / or the like. In some non-limiting embodiments or aspects, customer device 606 may or may not be capable of receiving information (e.g., from merchant system 608 or from another customer device 606) via a short-range wireless communication connection (e.g., an NFC communication connection, an RFID communication connection, a Bluetooth® communication connection, a Zigbee® communication connection, and / or the like), and / or communicating information (e.g., to merchant system 608) via a short-range wireless communication connection.

[0174] Merchant system 608 may include one or more devices capable of receiving information from and / or communicating information to transaction service provider system 602, issuer system 604, customer device 606, and / or acquirer system 610 via communication network 612. Merchant system 608 may also include a device capable of receiving information from customer device 606 via communication network 612, a communication connection (e.g., an NFC communication connection, an RFID communication connection, a Bluetooth® communication connection, a Zigbee® communication connection, and / or the like) with customer device 606, and / or the like, and / or communicating information to customer device 606 via communication network 612, the communication connection, and / or the like. In some non-limiting embodiments or aspects, merchant system 608 may include a computing device, such as a server, a group of servers, a client device, a group of client devices, and / or other like devices. In some non-limiting embodiments or aspects, merchant system 608 may be associated with a merchant, as described herein. In some non-limiting embodiments or aspects, merchant system 608 may include one or more client devices. For example, merchant system 608 may include a client device that allows a merchant to communicate information to transaction service provider system 602. In some non-limiting embodiments or aspects, merchant system 608 may include one or more devices, such as computers, computer systems, and / or peripheral devices capable of being used by a merchant to conduct a transaction with a user. For example, merchant system 608 may include a POS device and / or a POS system.

[0175] Acquirer system 610 may include one or more devices capable of receiving information from and / or communicating information to transaction service provider system 602, issuer system 604, customer device 606, and / or merchant system 608 via communication network 612. For example, acquirer system 610 may include a computing device, a server, a group of servers, and / or the like. In some non-limiting embodiments or aspects, acquirer system 610 may be associated with an acquirer, as described herein.

[0176] Communication network 612 may include one or more wired and / or wireless networks. For example, communication network 612 may include a cellular network (e.g., a long-term evolution (LTE®) network, a third generation (3G) network, a fourth generation (4G) network, a fifth generation (5G) network, a code division multiple access (CDMA) network, and / or the like), a public land mobile network (PLMN), a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a telephone network (e.g., the public switched telephone network (PSTN)), a private network (e.g., a private network associated with a transaction service provider), an ad hoc network, an intranet, the Internet, a fiber optic-based network, a cloud computing network, and / or the like, and / or a combination of these or other types of networks.

[0177] The number and arrangement of systems, devices, and / or networks shown in FIG. 6 are provided as an example. There may be additional systems, devices, and / or networks; fewer systems, devices, and / or networks; different systems, devices, and / or networks; and / or differently arranged systems, devices, and / or networks than those shown in FIG. 6. Furthermore, two or more systems or devices shown in FIG. 6 may be implemented within a single system or device, or a single system or device shown in FIG. 6 may be implemented as multiple, distributed systems or devices. Additionally or alternatively, a set of systems (e.g., one or more systems) or a set of devices (e.g., one or more devices) of environment 600 may perform one or more functions described as being performed by another set of systems or another set of devices of environment 600.

[0178] Although embodiments have been described in detail for the purpose of illustration, it is to be understood that such detail is solely for that purpose and that the disclosure is not limited to the disclosed embodiments, but, on the contrary, is intended to cover modifications and equivalent arrangements that are within the spirit and scope of the appended claims. For example, it is to be understood that the present disclosurecontemplates that, to the extent possible, one or more features of any embodiment can be combined with one or more features of any other embodiment.

Claims

WHAT IS CLAIMED IS:1 . A system, comprising: at least one processor configured to: receive an input from a first user via a first graphical user interface (GUI), the input associated with a graphical element associated with a field of a form and at least one attribute associated with the field; generate a schema file based on the input associated with the graphical element associated with the field of the form and the at least one attribute associated with the field; validate the schema file based on the at least one attribute associated with the field; in response to validating the schema file, store the schema file in a database; retrieve the schema file from the database; and communicate the schema file to a user device of a second user to render and display the form based on the schema file.

2. The system of claim 1 , wherein the at least one attribute comprises at least one of a rule, a dependency on at least one other field of the form, a name of the field, a type of graphical element, or any combination thereof.

3. The system of claim 1 , wherein, when retrieving the schema file from the database, the at least one processor is further configured to: receive a request message associated with the form from the user device of the second user; and retrieve the schema file from the database in response to receiving the request message.

4. The system of claim 1 , wherein the user device of the second user displays the form via a second GUI.

5. The system of claim 4, wherein the at least one processor is further configured to:receive data from the user device of the second user based on an input to the form displayed via the second GUI; validate the data received from the user device of the second user; and store the data received from the user device of the second user.

6. The system of claim 1 , wherein the at least one processor is further configured to: receive a request message associated with the form from the first user via the first GUI; retrieve the schema file from the database in response to receiving the request message; receive a second input from the first user via the first GUI, the second input associated with a second graphical element associated with a second field of the form and at least one second field attribute associated with the second field; generate a modified schema file based on the schema file and the second input associated with the second graphical element associated with the second field of the form and the at least one second field attribute associated with the second field; validate the modified schema file based on the at least one attribute associated with the field and the at least one second field attribute associated with the second field; and in response to validating the modified schema file, store the modified schema file in the database.

7. The system of claim 6, wherein the at least one processor is further configured to: receive a request message from the user device of the second user comprising a request to access the form; retrieve the modified schema file from the database in response to receiving the request message; and communicate the modified schema file to the user device of the second user to render and display the form based on the modified schema file.

8. A computer-implemented method, comprising: receiving, with at least one processor, an input from a first user via a first graphical user interface (GUI), the input associated with a graphical element associated with a field of a form and at least one attribute associated with the field; generating, with at least one processor, a schema file based on the input associated with the graphical element associated with the field of the form and the at least one attribute associated with the field; validating, with at least one processor, the schema file based on the at least one attribute associated with the field; in response to validating the schema file, storing, with at least one processor, the schema file in a database; retrieving, with at least one processor, the schema file from the database; and communicating, with at least one processor, the schema file to a user device of a second user to render and display the form based on the schema file.

9. The computer-implemented method of claim 8, wherein the at least one attribute comprises at least one of a rule, a dependency on at least one other field of the form, a name of the field, a type of graphical element, or any combination thereof.

10. The computer-implemented method of claim 8, wherein retrieving the schema file from the database comprises: receiving a request message associated with the form from the user device of the second user; and retrieving the schema file from the database in response to receiving the request message.1 1 . The computer-implemented method of claim 8, wherein the user device of the second user displays the form via a second GUI.

12. The computer-implemented method of claim 1 1 , further comprising:receiving, with at least one processor, data from the user device of the second user based on an input to the form displayed via the second GUI; validating, with at least one processor, the data received from the user device of the second user; and storing, with at least one processor, the data received from the user device of the second user.

13. The computer-implemented method of claim 8, further comprising: receiving, with at least one processor, a request message associated with the form from the first user via the first GUI; retrieving, with at least one processor, the schema file from the database in response to receiving the request message; receiving, with at least one processor, a second input from the first user via the first GUI, the second input associated with a second graphical element associated with a second field of the form and at least one second field attribute associated with the second field; generating, with at least one processor, a modified schema file based on the schema file and the second input associated with the second graphical element associated with the second field of the form and the at least one second field attribute associated with the second field; validating, with at least one processor, the modified schema file based on the at least one attribute associated with the field and the at least one second field attribute associated with the second field; and in response to validating the modified schema file, storing, with at least one processor, the modified schema file in the database.

14. The computer-implemented method of claim 13, further comprising: receiving, with at least one processor, a request message from the user device of the second user comprising a request to access the form; retrieving, with at least one processor, the modified schema file from the database in response to receiving the request message; andcommunicating, with at least one processor, the modified schema file to the user device of the second user to render and display the form based on the modified schema file.

15. A computer program product, the computer program product comprising at least one non-transitory computer-readable medium including program instructions that, when executed by at least one processor, cause the at least one processor to: receive an input from a first user via a first graphical user interface (GUI), the input associated with a graphical element associated with a field of a form and at least one attribute associated with the field; generate a schema file based on the input associated with the graphical element associated with the field of the form and the at least one attribute associated with the field; validate the schema file based on the at least one attribute associated with the field; in response to validating the schema file, store the schema file in a database; retrieve the schema file from the database; and communicate the schema file to a user device of a second user to render and display the form based on the schema file.

16. The computer program product of claim 15, wherein the at least one attribute comprises at least one of a rule, a dependency on at least one other field of the form, a name of the field, a type of graphical element, or any combination thereof.

17. The computer program product of claim 15, wherein, when retrieving the schema file from the database, the program instructions, when executed by the at least one processor, further cause the at least one processor to: receive a request message associated with the form from the user device of the second user; and retrieve the schema file from the database in response to receiving the request message.

18. The computer program product of claim 15, wherein the user device of the second user displays data associated with the form via a second GUI.

19. The computer program product of claim 18, wherein the program instructions, when executed by the at least one processor, further cause the at least one processor to: receive data from the user device of the second user based on an input to the form displayed via the second GUI; validate the data received from the user device of the second user; and store the data received from the user device of the second user.

20. The computer program product of claim 19, wherein the program instructions, when executed by the at least one processor, further cause the at least one processor to: receive a request message associated with the form from the first user via the first GUI; retrieve the schema file from the database in response to receiving the request message; receive a second input from the first user via the first GUI, the second input associated with a second graphical element associated with a second field of the form and at least one second field attribute associated with the second field; generate a modified schema file based on the schema file and the second input associated with the second graphical element associated with the second field of the form and the at least one second field attribute associated with the second field; validate the modified schema file based on the at least one attribute associated with the field and the at least one second field attribute associated with the second field; in response to validating the modified schema file, store the modified schema file in the database; receive a request message from the user device of the second user comprising a request to access the form; retrieve the modified schema file from the database in response to receiving the request message; andcommunicate the modified schema file to the user device of the second user to render and display the form based on the modified schema file.

Images