WO2006110605A2 - System and method for merchant acquisition data capture - Google Patents

Abstract

A merchant-data capture system has an interface adapted to capture merchant information, information storage for receiving and maintaining the merchant information captured using the interface, a profile library that preferably stores editable profÊle(s) for use in entering data, and a processor adapted to manage the mentioned other components, and to submit the merchant information to at least one external system. Tables containing information used in processing the merchant information, including for example tables of high-risk industries, of bank terminals, etc., are provided, and can be edited in real time. Workgroups of users can be constructed and changed by an administrator as needed, with varying levels of authorization for different members.

Description

TΓΓLE

SYSTEM AND METHOD FOR MERCHANT ACQUISITION DATA CAPTURE

RELATED APPLICATIONS

[0001] This application claims benefit of the filing date of U.S. provisional patent application 60/669,488, filed April 8, 2005, the entire contents of which are incorporated herein by reference.

BACKGROUND OF THE INVENTION

Field of the Invention

[0002] The present invention relates generally to the acquisition of information to be incorporated into a database quickly and accurately, and pertains more specifically to the acquisition of data relating to a merchant who wishes to become able to accept payment from an acquirer using a financial transaction instrument from a particular issuer.

Related Art

[0003] The use of financial transaction instruments such as charge cards, credit cards and debit cards, among others, is an extremely widespread and well- established feature of commerce. An acquirer enrols merchants who are willing to accept the instrument of this issuer as a medium of payment for goods sold or services rendered, and the holder of the instrument can use the instrument to make purchases at all such merchants. The customer has the convenience of not having to carry large amounts of cash, being able to make unforeseen purchases even when not in possession of sufficient cash and even when there is no convenient bank branch or automatic teller machine (ATM) available, and the merchant of course has a competitive advantage in that this convenience for the customer represents an incentive, sometimes a powerful one, for the customer to choose the merchant over a competitor that does not accept payment via the particular financial transaction instrument that the customer has. [0004] One important part of the financial network's (acquirer's) business, therefore, is recruiting and registration of merchants as new participants in the system. It is important to both the merchant and the issuer that the registration process by which the merchant is enrolled and becomes able to begin accepting the issuer's instrument is as speedy as possible, and sophisticated systems have been developed for this purpose.

[0005] Such a system must enable the acquisition of all relevant, data about the merchant, including information needed by the acquirer to determine that the merchant is acceptable as an enrollee in the acquirer's system, information needed to authorize individual transactions at the merchant, information needed to settle accounts with the merchant in each accounting period, and information used for auditing purposes or needed for other purposes related to the corporate governance of the acquirer.

[0006] The information relating to the merchant is not necessarily all used for the same set of purposes, and is not necessarily kept in a single database. In one conventional system for the acquisition of merchant data, the information relating to a new merchant may be acquired by means of an interface application that passes the information to the appropriate application(s) and d_.atabase(s) at the. acquirer. Alternatively, new-merchant information may be stored locally and submitted to the acquirer in batches.

[0007] Such an interface system may be a client-server application that acquires the merchant data and passes it to the acquirer's accounts-payable application (hereinafter, "APA"), for example. (The merchant data of course need not actually be stored in the APA, but could be held in a database shared by the APA and other applications; nonetheless, for brevity's sake, the acquirer's applications which use the captured merchant data are collectively referred to herein sometimes as the "APA" and sometimes as an "external system" of the acquirer.) A front-end application is used to enter the actual data, which are passed via the interface to the acquirer's APA. Alternatively, a local agent ("ESA") who does not have access to the interface system may use their own system to acquire the data, and they then convert the data into a data file having the format required by the interface system.

[0008] Typically, however, such a system is customized for each geographical market, and for each language. When the acquirer wishes to expand operations into a new region, therefore, new software must be written for that, purpose.. While the new software may be very similar to existing code, the effort required is nonetheless significant, and represents an undesirable cost in both time and money. The same consideration applies with the development of software to perform the system's functions for merchants who use a language not previously accommodated by the system.

[0009] In addition, such a system may have a front-end application to acquire data, an application to process the information and store it, and a batch application to load it periodically to the acquirer's APA system. The use of multiple applications naturally increases the complexity and cost of system maintenance, as well as complicating the process of developing enhancements. [0010] Other improvements to the conventional system described above would be desirable, as well. Because newly acquired information is passed to the acquirer's APA system only periodically, such as once a day, the identification of any error in the acquired information requiring correction and re-submission of that information, entails a delay of at least one more day in the setting up of the merchant to accept the issuer's card. It would be highly desirable to have a system that avoids, or at least greatly reduces, errors and the resulting delays and rejections of merchant applications due to such errors, all of which can be very frustrating for all concerned. It would moreover be desirable to accelerate the normal enrolment process even where no errors are made, and to reduce the average cost of merchant enrolment.

[0011] Also, the described conventional system does not provide for automatically archiving data. Such a capability would be highly desirable.

[0012] Existing systems have other limitations that it would be desirable to eliminate. For example, various types of arrangements are made with different merchants (e.g., different terms of payment may be required). It would be desirable to be able to accommodate all such variations suing a single, unified system.

[0013] Given the foregoing, what is needed is a system, method and computer program product for merchant-data capture.

BRIEF DESCRIPTION OF THE INVENTION

[0014] The present invention meets the above-identified needs by providing a system, method and computer program product for merchant-data capture. [0015] An advantage of the present invention is that it is a portable and robust data capture system that enables standardized capture of merchant set-up data , across multiple geographic regions. Where the application processing needs to be customized for a particular market as to language or in any other regard, this can be achieved quickly and easily, with little or no special software needing to be written.

[0016] Another advantage of the present invention is that the system of the invention can be utilized by all users, and can if desired be used from outside the physical facilities of the acquirer. Thus, while users external to the organization of the acquirer can still use their own data capture system and then convert the format of the data file(s), or can provide the information in handwritten form if they wish, the system makes it possible for such outside agents to access.the system via the Internet or the like, and input their enrolment applications directly, without the information being handwritten or being entered in the agent's own capture system first. This ability has great potential to simplify and accelerate procedure, and to prevent errors and the consequent delays. [0017] Another advantage of the present invention is that it reduces the costs involved in its maintenance and the cost of making future enhancements, and provides support personnel and systems with the benefit of management information systems ("MIS") reports.

[0018] Still another advantage is that the system of the invention can support the establishment of merchant accounts having different payment terms, or varying from each other in other ways.

[0019] Yet another advantage is that the system of the invention provides an audit trail, and permits the running of reports easily to assess performance, both of the hardware/software system itself and of the organization system of which it is a part, including the performance of particular teams using the system. [0020] These advantages are afforded by a merchant-data capture system . according to the invention, which has an interface adapted to capture merchant information, information storage for receiving and maintaining the merchant information captured using the interface, a profile library that preferably stores editable profile(s) for use in entering data, and a processor adapted to manage the mentioned other components, and to submit the merchant information to at least one external system. Tables containing information used in processing the merchant information, including for example tables of high-risk industries, of bank terminals, etc., are provided, and can be edited in real time. Workgroups of users can be constructed and changed by an administrator as needed, with varying levels of authorization for different members. The invention also includes a method of using such system, and includes any combination of hardware, software and firmware for performing the functions of such system. [0021] Further features and advantages of the present invention as well as the structure and operation of various embodiments of the present invention are described in detail below with reference to the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

[0022] The features and advantages of the present invention will become more apparent from the detailed description set forth below when taken in conjunction with the drawings, in which like reference numbers indicate identical or functionally similar elements. Additionally, the left-most digit of a reference number identifies the drawing in which the reference number first appears.

[0023] Figure 1 is a high-level diagram illustrating main components of an exemplary embodiment of the invention, showing its relation to other applications with which it is used.

[0024] Figures 2 - 16 and 18 - 21 are flowcharts illustrating portions of the processing performed in using the embodiment of Figure 1.

[0025] Figure 17 is a diagram of a workgroup.

[0026] Figure 22 is a schematic diagram illustrating a computer-based system that can be used, according to one embodiment, for practicing the present invention.

DETAILED DESCRIPTION

I. Overview

[0027] The present invention is directed to a system, method and computer program product for capturing merchant data. The present invention is now described in more detail herein in terms of the above exemplary system. This is for convenience only and is not intended to limit the application of the present invention. In fact, after reading the following description, it will be apparent to one skilled in the relevant art(s) how to implement the following invention in alternative embodiments.

[0028] The term "user" and the plural form of this term are used interchangeably throughout herein to refer to those persons or entities capable of accessing, using, being affected by and/or benefitting from the tool that the present invention provides for capturing merchant data. Also, while this specification distinguishes between the acquirer of merchant information and the issuer of the card or other financial transaction instrument that the merchant wishes to be able to accept, the acquirer and the issuer may be the same entity. [0029] Furthermore, the terms "business" and "merchant" are. used interchangeably with each other and shall mean any person, entity, distributor system, software and/or hardware that is a provider, broker and/or any other entity in the distribution chain of goods or services. For example, a merchant may be a grocery store, a retail store, a travel agency, a service provider, an online merchant or the like.

II. System

[0030] Referring to Figure 1, a system diagram of an exemplary system 100 in which the present invention, in an embodiment, would be implemented is shown. [0031] System 100 includes the components of an embodiment of the present invention; Figure 1 shows also a number of other systems with which the system 100 of the invention interacts. (most of those elements, i.e., those numbered 152, 156, 158 and 160, are not essential, and may be used with system 100, or not; all such arrangements and variations are within the broad scope of the invention). The main components of the system of the invention are the interactive component 102, the file service component 104, and the data capture processor component 106. The precise software and hardware used is not specified, as those skilled in the relevant art(s) can easily select such from commercially available types, suitable for performing as described herein. [0032] The interactive component 102 or presentation layer is a browser-based interface for users. It is employed for registration of all types of users, and for authentication and authorization of a user, by means of the standard single sign on ("SSO").

[0033] This component also is used to enter and store the merchant information, and to submit the merchant's application for set up in the APA, through the system processor 108. Component 102 also interfaces with the system processor 108 to permit a user to review the status of a merchant set-up. [0034] The file services component 102 provides a number of functions and services in this embodiment, including supporting the authentication and authorization of users, receiving and storing the new-merchant file from external sales agents (ESA), editing the merchant information, and submitting the merchant for set up.

[0035] The data capture processor component 106: interfaces with the interactive component 102 and the file services component 104 to set up a new service establish ("SE"); interfaces with an email address repository 152 to maintain the email address of new merchants in a central email address repository; interfaces with the APA 154 to set the new merchant up; interfaces with an illustrated holdout and new signing lead system 156, the purpose of which is described below; and interfaces with a welcome acceptance processor 158 (which for example, sends a welcome letter together with the acceptance letter to a new merchant). In addition, in one version of the invention, the system processor 108 interfaces with an electronic capability processor 160 to enable merchants to submit their applications electronically, for example. The system processor 108 also provides necessary metrics such as MIS reports. [0036] This processor 108, among other services, manages status information relating to a new-merchant set up file, and provides the editing and transformation of the new-merchant information.

[0037] Also illustrated in Figure 1 is email address capture (EAC) component 152, which is a global email repository. When a new merchant is set up, its email addresses are captured here for further marketing and servicing purposes. [0038] The APA system 154 is an accounts payable system with functionalities that cover every aspect of a merchant's relationship with the acquirer. The basic idea of the present invention is to simplify the merchant set up process in APA 154.

[0039] The use of the holdout and new signing lead processor 156 enables cardmembers to request the card acquirer to sign up non-company merchants. Some of these may be holdout merchants (who have been reluctant to enrol previously): If the issuer signs up such a merchant, this processor notifies the cardmember(s) who made the request. This can be achieved by sending letters to cardmembers regarding new merchants.

[0040] After a merchant record is set up, the acquirer sends a welcome pack to the merchant. This is performed automatically by the welcome acceptance processor 158. This communication, or others, provides a means to train the new merchant how to process its transactions, as well as to encourage the merchant to accept the issuer's cards.

[0041] The electronic capability processor 160 provides the ability for a prospective merchant to process its transaction electronically (an EDC terminal is required to be installed in the merchant's premises for this purpose). Then a set up is required for that terminal, and the system of the invention may interface with component 160 to provide such service for the merchant.

III. Process

[0042] Referring to Figures 2 - 16 and 18 - 21, flowcharts, illustrating the processing according to one embodiment of the present invention, are shown. [0043] The system 100 shown in Fig. 1 affords users a great many types of functionality, as will now be described. A user of course can, as the basic purpose of the system indicates, use it to set up a new merchant (referred to hereinafter as "SE setup" or simply "setup"). This is the process of directly inputting and capturing data for a new merchant applying to be affiliated with the financial network in question. The user, in addition to being able to set up and submit an application of a new merchant, is also able to terminate this process part-way through and store the entered information for later use. Later, the user can open the saved file, complete the application and submit it. Also, the system 100 checks submitted applications for errors of certain types, and if such are detected, automatically sends back to the user a message rejecting the application and, preferably, identifying the nature of the error or errors. The system permits the user to retrieve the rejected application and make corrections to it, and then to resubmit the application for reconsideration.

[0044] In addition, in order to streamline the process of submitting information for a new merchant who has several branch stores, the user is able in setting up an application for a given location to start by retrieving an existing submission and simply modifying the data fields that do not apply to the new submission. Thus, if a merchant applying has three sites which it is desired to make eligible to accept payment using the card issuer's card, once the submission has been completed for the first site, the user can prepare the submissions for the second and third sites in this fashion, and thus avoid the need to key in the information multiple times, except of course the information unique to the respective stores. [0045] This process can be performed in either of two ways, the user reverting either to a submission that has just been made, or to a submission made some time earlier. Thus, the system accommodates both situations in which a merchant is applying to have multiple sites approved, and one in which a merchant who has already been set up in the system, is now making a application to have a new store location included as well.

[0046] In addition, because of the human propensity to make certain types of errors, especially those relating to strings of numbers and the like, the system preferably includes a requirement that certain data appeals in a file being prepared, be entered multiple times, to ensure that the data has been entered in those fields correctly.

[0047] For supervisory purposes, the system permits certain users to view submissions that have been made (subject to necessary security requirements). In addition, an employee responsible for reviewing and either approving or rejecting an application is able to view the submission in the system 100 for that purpose. [0048] Since the exact nature and number of data fields required will vary from one market to another, the system also provides the ability for a user to establish profiles, which require input of only those data fields needed for the market where the user in question is operating.

[0049] In addition, of course, the system provides for its maintenance and modification as necessary from time to time, including the ability to modify certain tables of information as described below, as well as defining the set of individuals who have the authority to use the system, and specifying different levels of access permitted to the users, or different levels or types of activity, permitted to them.

[0050] In the following, the processing that supports these various functionalities will be described.

[0051] The process of user authentication and authorization is illustrated in the flow chart of Fig. 2. As described above, it is contemplated that the system of the invention will be used by a number of people, possibly a large number, not all whom are intended to have the same level or type of authority regarding the handling of information in the system. In addition, it is desired to restrict the access to the system to people who actually need access, as part of the acquirer's efforts to maintain the information secure, both because it is of great commercial value to the acquirer itself and because the information includes confidential and sensitive financial details of the merchants. [0052] As shown above, it is contemplated that users will access the system via the Internet or other network, and upon reaching the web cite, the user is shown a log in page. The log in process employs single sign-on authentication (SSO), in which the user enters a User ID and a Password. The system matches the entered User ID and Password against stored data, and if both match, processing proceeds to the next step; otherwise, a message indicating that authentication has failed is sent to the user and displayed on the user's screen.

[0053] Once the authentication has succeeded, the system checks the role of the logged-in user against stored information to ascertain the level of user privileges accorded to that user.

[0054] As described below, it is particularly contemplated that the levels of authorization will include those of "Operator", "Approver", "Workgroup . Owner", "Viewer" and "Administrator". (The two last-named. are not levels that; will relate to a person who ordinarily uses the system for the capturing of merchant data, but rather pertain most typically to managerial personnel responsible for the system.) It will be understood of course that the invention is by no means limited to this particular set of user types, or to this number of different types.

[0055] Before the user is shown the system home page, the user is required to indicate whether or not it is intended in the present session to capture merchant data. If that is not the user's intention, the system home page is now shown, and the user can proceed to use the system (in a number of the drawing figures, the system, or at least certain of its functions, is referred to using the term "MADCAT"). If capturing of merchant data is intended, then the user is required to view a page stating relevant acquisition policies. These may include, for example, anything from the legal requirements and company policies regarding the handling of merchant data, set out in full with a statement of penalties for violation, to merely a reminder that the information being handled is extremely confidential and sensitive and must not be shared with outsiders, or the like. [0056] The user is presented with an opportunity to accept the policy or not, and if the user does accept it, the user is then allowed to proceed to the system home page; if the user does not accept the policy, the system returns automatically to the log in page. In this embodiment, thus, it is not possible for the user to capture merchant data without having first viewed and explicitly accepted the acquisition policy.

[0057] Fig. 3 illustrates the processing for a new SE set up. The user, viewing the system home page, clicks to select from a menu "New SE set up". The user may be asked whether the new set up is to be based on a stored profile, or not (as described below, the use of profiles is highly advantageous in reducing unnecessary labor on the part of the operators, and thus it is particularly contemplated that profiles will be established and used wherever possible; nonetheless, the invention also encompasses making the use of profiles optional with the user, as well as employing the system without providing profiles). [0058] If the user indicates that a profile is to be used, the user selects among available profiles. (This selection can be done in any fashion deemed suitable and convenient, including the presentation to the user of the available pre-stored profiles in a menu, or by requiring the user to input a file name or a profile name.) If a profile is selected, the system displays the SE set up page, with certain fields pre-populated. Which fields are pre-populated, and with what information, is determined by the selection of profile. The pre-stored profiles may serve various purposes, including the following examples.. If a merchant has a large number of places of business, and regularly opens new ones, it will be convenient to have a profile for that merchant, with those fields common to all branches or stores pre-populated. As new stores are opened and the data for them needs to be captured by the system, only the new data unique to the new store needs to be entered. As another possibility, if the user is responsible for capturing data for stores in a variety of countries in which the normal form of street addresses is not the same, then the SE set-up page of course must be able to accommodate the entry of addresses in the forms used in any of those countries. Nonetheless, it may be convenient to pre-store a profile for each country, so that if a given country's custom involves a smaller number of lines, for example, the unnecessary fields can be excluded from the display (or can be "pre-populated" . by being grayed out). [0059] Once the SE set-up page is displayed, whether a completely blank one or with some fields pre-populated as described, the user keys in the data required for the remaining fields. The set-up page may require the user to input certain items of information twice, particularly where experience shows that the item is of a type which people are particularly likely to enter incorrectly. That is, if both entries of the item are identical, the entered infoπnation is accepted, whereas if there is a discrepancy, an error message is displayed to warn the user, who must reenter the item properly. After entry of all required information, the user submits the SE set-up, as for example, by clicking a displayed button on the screen. The system validates the submitted set up, by checking to be certain that all required information has been entered, hi addition, the entries in one or more fields may be compared against a table of acceptable entries for that field, for example, comparing the identification of a state or province against a list of actual existing states or provinces for the country in question. It is also within the scope of the invention, of course, to prevent errors of this type, by requiring, such fields to be entered by selection from a list rather than by keystroke entry by the user.

[0060] Upon successful validation, the system stores the information in the submission in a repository, from which it is entered by a data base server into the system data base. If the validation process fails in any regard, a message to this effect is displayed for the user, who thus knows that the submission has not been accepted, and must be redone. Preferably, the error message identifies the field or fields that cannot be accepted.

[0061] Fig. 4 shows the processing involved in a new set up that is based, on an existing one. This processing is useful if the operator needs, for. example, to capture data for a new store of an existing merchant. Of course, if a pre-stored profile exists for that purpose for the merchant in question, the profile can be used as described above. If no such profile exists, however, the operator can still avoid the need to enter data that merely duplicates data already captured for that merchant, in the following way. The operator, on the system's home page, clicks on a menu option to enter a new set up based on an existing complete set up. The system then requires the operator to select the existing set up that is to be used as the basis of the new one. While this can be done in any convenient way, and could for example involved presenting the user with a list of such existing setups, it is particularly contemplated that the operator will prefer to identify the existing setup by searching. The processing for such a search is described below in connection with Fig. 8. Once the operator has identified the desired existing setup, the system retrieves the data of that setup from the system data base, and presents it on the user's screen. This is done in the form of a dialogue box. The operator clears out the fields where new information (that is information different from that in the existing setup) is required, and leaves the information common to the existing and the new setups alone. The operator then enters the new data in the cleared out fields, and completes the set up just as explained above in connection with Fig. 3. After the new setup is completed, the operator submits it as above, the new submission is validated, and if correct is stored in the repository, whence it is stored in the system data base, while the presence of an unidentifiable error in the setup results in the user being advised that the submission cannot be made.

[0062] Fig. 5 shows the processing for a variation of that of Fig.4. In the processing of Fig. 5, a new setup is based on a previous setup, that it, when which has previously been completed and saved (as described below in connection with connection with Fig. 6) but has not yet been submitted. To do this, the operator on the system home page indicates that this is the procedure to be used, and is required to identify the file stored in memory of the previous setup. This can be done either by listing the available files, permitting the operator to perform a search of files in the memory or in any other way. As before, the operator is presented with a dialogue box presenting the information in the previous setup, and clears out the entries in the fields for which the previous information is not to be used. The empty fields are filled in with the new information, and the setup when completed is submitted, and subjected to the same validation processing as above.

[0063] Fig. 6 illustrates the processing involved in saving a setup. This processing is useful when the operator has to interrupt work before finishing a new setup, as it prevents the need for the set up to be recommenced altogether when the operator is able to resume work. Again, the saving processing can be used if for any reason the operator decides not to submit the setup at present. In Fig. 6, it is assumed as an example that the operator starts by choosing to make a new setup based on a pre-existing profile, retrieves the profile and enters data in those fields which are not pre-populated; this is just as was done in the processing in Fig. 3 where a profile was used. Either after completing the entry of data, or without completing it, the operator decides it is necessary to save this setup, and selects a virtual button on the display provided for this purpose. Activation of that virtual button causes the setup to be stored in the repository, and ultimately in the system data base. The setup file is marked in any suitable way, as for example by a flag, to indicate that it is not being submitted yet. In addition, as can be seen from Fig. 6, no validation is performed at this point. [0064] Fig 7 illustrates the resumption of a saved setup. The operator selects to work on a saved setup, and is required to identify the saved setup. This can be done any convenient manner, as discussed above. The relevant data is retrieved from the system data base, and is displayed. The operator resumes filling in the fields, and can of course change the entries in existing fields if needed. When complete, the setup is submitted and subjected to validation processing, resulting in either the storage of the details in the repository, and subsequently in the system data base, as an accepted completed setup, or in an error message sent to the operator if the validation fails. As is indicated in Fig. 7, the fact that the setup had been saved previously does not in any way preclude the operator from saving it a second (or subsequent) time, if such is needed.

[0065] The searching processing is outlined in Fig. 8. On the system home page, the operator is offered as one option to search setups, and selects this link. The user is now presented with a list of the search criteria that can be used, and defines the criteria for the search. The system processor searches in the data base and identifies those setups which match the entered search criteria. The matching setups are listed and the list is presented to the operator after being subjected to a filtering process. As is described below, the users of the system are divided into workgroups, and a member of a given workgroup can view and otherwise access only those setups belonging to that workgroup. Thus, the list presented to the operator consists of those setups which both match or the entered search criteria and meet the additional criteria of belonging to the operator's own workgroup. [0066] As shown in Fig. 8, the results are formatted for display to the user, and this formatting may consists either of the organization of the results into a predetermined format that is not under the operator's control, or their arrangement into a format that the user can define at the time of setting up the search criteria. Another possibility also within the scope of the invention is that the formatting may be defined for a given workgroup, and not thereafter be changeable by individual members of the workgroup.

[0067] In Fig. 9 is shown the processing for the verification of a new setup. This is used where there is any doubt about the accuracy of a submission, and specifically involves the verification of certain fields. As mentioned above,; some fields are as a practical matter more susceptible to the mis-keying of information than are others, and in particular, fields requiring the entry of sequences of numbers or other relatively arbitrary sequences are apt to containe input errors. In the verification processing, the operator opens the set up that has already been submitted, this being done through the same type of selection processing as described above. The extracted set up is obtained from the system data base, and the information contained in the fields of interest (referred to in Fig. 9 as "double keyed fields") is deleted. These values, however, are not simply discarded, but are stored for later reference. The operator is presented with the setup information, with the double keyed field vacant, and field by field re-enters the previously entered values for each field. As each such field is re-entered, the new entry is compared to the stored old value for that field. If the two coincide, the operator is invited to enter the value for the next vacant field. If a re-entered value and the corresponding or old value do not match, however, the operator is alerted, preferably by displaying the old and the new entries, and asking the operator to choose one or the other. When all the fields in question have been successfully populated, the verified information is stored back in the system data base.

[0068] Although it is a purpose of the present invention to automate to a high degree the acquisition and capturing of new merchant information, it is still intended to have human review of a submission to determined whether the submission is to be approved or rejected. Fig. 10 shows processing for this portion of the system. The user, who in this case is one authorized to perform the approval process, opens a set up that already has been submitted and verified. (It is worth noting at this juncture that the system home page is not displayed in the same form to all users, but is varied according to the authorization level of the person logging on.) The identification and selection of such a submission is done using the same known techniques as described above, for example, the operator or user opening a list of all submitted and verified setups that have not yet been approved, and identifying one to be handled at present. The setup in question is extracted from the system data base, and the contents shown on a set-up screen. If the submission meets with the approval of the user, the user actuates a virtual button or the like on the screen, and the approved information is now sent back to the system data base, being stored as and approved setup. [0069] Figs. 11 and 12 show processing involved in viewing setups that have been entered, particularly by other operators, although there is of course nothing to prevent an operator from viewing a setup that they themselves have entered. In Fig. 11, the viewing is of a partial (saved) setup. The operator selects "View SE (Partial)" on the system home page, and activation of the link causes . extraction of the list of set up made by that operator that are currently incomplete. The list is formatted appropriately and displayed for the user, permitting the user to select the setup or setups of interest.

[0070] In Fig. 12. is shown the very similar processing permitting a viewer to view a rejected setup. By clicking on the relevant link on the system home page, the operator causes the data base server to extract a list of setups created by that user and which have been rejected. (This rejection is not related to the validation processing described above, but rather to a higher-level vetting by the external system to which the system of the present invention exports the information.) The extracted setups are again formatted into an appropriate list, which is displayed for the user.

[0071] Again, while Figs. 11 and 12 both show processing in which it is contemplated that partial or rejected setups, respectively, are viewable only by the operator who input those specific setups, it is within the broad scope of the invention to enable an appropriate operator, for example the workgroup owner, to view such setups regardless of who input them, or even to permit each member of the workgroup viewing access to all such setups.

[0072] Fig. 13 shows processing for an administrative task supported by the system. As described above, it is particularly efficient to create a new setup by use of a pre-stored profile. The profile, as described, may reflect the particularities of the particular market in which the merchants whose applications will be submitted. by the working group in question are active, or on any other convenient bases. The example shown in Fig. 13 assumes that the profiles are being created for particular markets. The operator selects the virtual button on the system homepage for creating a new profile (as described below, it is contemplated, although not the only approach within the scope of the invention, that users having different levels of authorization are presented with different views of the system home page which correspond respectively to the level of authorization of the particular user). The system then presented the operator with a list of markets, one of which is selected by the operator. The system determines whether there is already a profile for that market and for the workgroup to whom the operator belongs, and if so, displays the profile page with the properties in that pre-existing profile pre-populating the relevant fields. The operator now overrides any or all other pre-populated field contents with the desired entries for the new profile, as well as filling in any other fields which may be appropriate for the new profile. After completing this construction of the contents of the. profile, the operator selects among several possible visibility levels for the profile. In this embodiment, it is contemplated that the profile may be designated "private", in which case only the operator or only that operator and other users having specified authorizations are able to view it; or "workgroup", in which case all user in that workgroup can access it; or "all", in which case all. users of the . system, not just those in that workgroup, can view it. When this has been done, the new profile is saved in a repository, and saved from there into the system data base. [0073] While Fig. 13 illustrates the particular situation where there is already a profile relating to the workgroup and market in question, if there is no such preexisting profile, it is also within the scope of the invention that the system displays to the operator a page with all relevant fields, but containing no information, so that the operator can construct a new profile from scratch. It is also contemplated that the system will for any given market have an established list of properties that would be included in such profile and that relate to that particular market, and which are expected not to change over time. If this is provided, then when a user in a given workgroup decides to create a new profile, even if no profile already exists for that workgroup and market, the designation of the market will result in the display of a profile form which does contain the information relevant to the market, to the extent of that information is considered to be unchangeable and thus is permanently set in the system. [0074] In addition, since different markets may not all use the same language, it is within the scope of the invention that the profile may include a designation of language, if the operators are likely to prefer working in one language to another. Alternatively, or in addition, a more-limited language designation is contemplated, by which the operator when printing a contract for a merchant applicant can have a choice of languages in which the contract is printed out. [0075] Fig. 14 illustrates processing for another administrative maintenance tasks. From experience it is well known to issuers of financial transaction instruments that there are certain types of business the merchants in which are likely to contribute far too little gain to the enterprise to compensate for likely problems if they are allowed to participate in the financial network. As a result, the acquirer and financial network are likely to have a list of industries participation in which is enough to make a given merchant an undesirable partner. Instead or in addition, an acquirer and financial network may also have a list of industries, participants in which are not necessarily to be barred completely, but whose applications need to be especially carefully considered before being accepted as participants in the network. Such lists are provided in the preferred embodiment of the present invention, and Fig. 14 illustrates the processing involved in maintaining a table that serves as such a list. The administrator, when it is needed to modify that table, for example by adding an identification of an additional industry to that table, activates a virtual button on the administration home page of the system. In the preferred embodiment, the system in response displays a page inviting the operator to enter the code representing the industry that is to be added to the list. This may be simply a place where the code may be typed in, or maybe a list of all codes, from which the administrator can simply choose. Once the code of the industry is entered, the system determined whether the code is already present in the table, and if so, returns en error message. (This has the extra benefit, of course, of helping to protect against the situation in which an administrator may enter the wrong code, although of course it does not provide complete protection against such errors.) If the entered code is not a duplicate of one already in the table, the code and any related information to be included in the table in association with it, are stored in a repository, and from there loaded by the data base server into the system data base. Again, if it is desired to delete an entry from the table, the operator is shown the industry code page, which may for example be a list of the codes already in the table, and the operator selects one or more codes for deletion. The modified table is then restored in the system data base. [0076] Fig. 15 illustrates the processing for maintaining bank terminals. This relates to the maintaining of a table which identifies bank terminals in the financial network that the issuer uses. After selecting bank terminal record on the administration home page of the system, the operator is asked whether it is intended to create a new bank terminal record. The subsequent processing depends on the reply to this inquiry. If creation of a new record is intended, the system displays to the user a bank terminal entry page, where the user keys in the relevant bank and terminal data. Again, this is compared to what is already in the table to determine whether the proposed new entry is a duplication, and if it is, an error message is sent to the user. Otherwise, the new information is stored in the repository, from where it is subsequently stored in the system data base. [0077] If on the other hand the user indicates that it is not intended to create a new record, the administrator is invited to enter a bank terminal code, in response to which the system displays the relevant bank terminal data, and upon receiving confirmation from the administrator, deletes that from the data. The modified table is then restored in the data base.

[0078] In this fashion, real-time updates of the system to match changes in the APA can be effected.

[0079] Fig. 16 illustrates the processing for the creation of a workgroup. This is done by an administrator, who identifies the creation of a new workgroup as being the task to be performed on the administration home page of the system. The system in response displays a page for that purpose, and the administrator enters the name to be given the workgroup. If this name duplicates one already in the table of workgroups, the administrator is given an error message. Once there has been entered a proposed workgroup named that is not a duplicate, the administrator is invited to identify one or more markets in which the members of the new workgroup will be working. The administrator also identifies the owner of the workgroup (the significance of this term is discusses below). If the designated owner is already associated with a different workgroup, an error message is provided to the administrator.

[0080] Once an eligible owner (that is, one not already associated with another workgroup) has been designated, the administrator is invited to input properties specific to the workgroup. This will include identifying the individual users who will belong to this workgroup, and identifying a level of authorization for each member.

[0081] This step includes as mentioned the designation of any market specific properties that may be relevant. For each market designated by the administrator, it is now possible to specify certain types of information to be entered (or to be omitted if a commonly needed item is not relevant to the given market), special procedures to be followed, particular policies that are to be displayed to members of the workgroup at certain points in the execution of their use of the system, and the like. Any such stipulations that apply to all the markets in the list, .may of course be established by the administrator at the workgroup level rather than in association with the individual markets. [0082] When all such properties have been designated, the administrator saves the workgroup designation in a repository, and it is then stored in the system data base.

[0083] User management in the preferred embodiment is a multi-step process.

The purpose of this user management in is to: control what the users can and what they cannot do using the system; organize them into workgroups each having an owner, who defines and controls their presence in the workgroup and their privileges in using the system; and pre-populate data fields during merchant data capture based on the characteristics of the workgroup to which the particular operator making the entry belongs. Thus, the users of the system are organized based on the workgroups, and fall into different categories based on their roles and responsibilities in the workgroup. The following roles are contemplated in the preferred embodiment:

[0084] Administrators: These are the people who are responsible for the integrity of the system. They have the authority to create, update and delete workgroups.

They decide the privileges of the workgroup, which the members inherit. Also, they are responsible for maintaining critical parameters of the system like the list of industries that are high risk or prohibited, the list of banks and the terminals they provide, etc. Typically, administrators will be the business heads of a market.

[0085] Operators: These are members of a workgroup and can capture merchant data and contracts. They also can verify the contracts captured by other operators belonging to the same workgroup. Typically, the operators will be_. capture . personnel employed by the acquirer, or external sales agents.

[0086] Approvers: These are members of a workgroup who are authorized to verify and approve merchant contracts captured by operators of their workgroup.

They also can create new merchant contracts. Typically, these will be supervisors.

[0087] Owner: This type of user is created directly by the system administrator and is associated to a particular workgroup. A workgroup has exactly one owner.

This user has the authority to create new users for their wbrkgroup and can designate them respectively as Operators or as Approvers. An owner's level of authorization includes all the privileges belonging to an Approver. Also, the owners are the ones who assign values to the workgroup and market-specific properties. Typically these will be sales channel heads. [0088] Viewer: Viewers are also created by the administrator, but are not associated to any workgroup. They have read-only authorization to see captured merchant contracts across any workgroup in the system. Typically, the viewers will be personnel such as teams in call centers who may need to look at a contract anywhere in the system to respond to an inquiry on the phone, etc. [0089] Thus, a workgroup is a logical entity created by an administrator to group a set of users together, with a single supervisor (the owner). The purpose of creating a workgroup can vary, from a new sales channel for a market, to all operations personnel in a particular shift, etc. Thus, the administrators can create as many workgroups as appropriate and associate each workgroup to one or more markets.

[0090] A workgroup has a set of attributes that serve as default values when a member of the workgroup tries to do a contract capture. Also, since a workgroup may be associated to multiple markets, it may, for each market, have some . ■ attributes that will consistently apply to all contracts in that market. These attributes are intended to be defined by the owner of the workgroup. If the owner does this, when an operator captures a contract, the appropriate market-specific attributes appear automatically as default data in the data capture screen, thus saving time. . . ..

[0091] Fig. 17 is a diagram illustrating one example of a workgroup. In this example are shown three workgroups, the composition of the first of which is illustrated. As shown, workgroup 1 has a single owner, two approvers and three operators. The number of operators and approvers will very depending on the size of markets to be dealt with by them (or more exactly the expected volume, of incoming merchant applications). Each workgroup, as stated above, however, has only one owner. Also shown in the figure is the presence of several administrators in the system, as well as of two viewers. [0092] Fig. 18 illustrates the processing for designating approvers for a workgroup. It is expected that ordinarily only those employees with specified levels of training and experience are acceptable as potential approvers. Typically, it is possible that the supply of such individuals may be limited. In any event, once a workgroup has been created, it is the responsibility of the workgroup owner to designate members of the workgroup who are to have the authorization level associated with approver. The owner, having signed onto the system, and being identified by the system as the workgroup owner, is shown a system home page for the workgroup owner level, and actuates a virtual button indicating that the desired task is the associating of one or more approver with the workgroup. The system responds by displaying an approver entry screen, and the owner identifies on that screen the approver to be associated to the workgroup. The system checks tables of workgroup members which may be organized by authorization level, to determine whether the nominated approver is part of another workgroup. An affirmative result leads to an error message. Assuming that the designated approver is not part of another workgroup, that approver is added to the workgroup, and that information is saved in the repository, and subsequently in the system data base. Although not illustrated, similar processing can be used by the workgroup owner to associate individual new operators to the workgroup. Again, when it is necessary to delete a workgroup member, whether operator or approver, a similar series of steps is followed. [0093] Fig. 19 illustrates the processing for associating an operator or verifier to a workgroup (although not discussed above, it is possible to have "verifier" as a type of user distinct from operators, but verification duties may be performed by ordinary operators). The owner again performs this task from the system home page appropriate to the owner authorization level. The system displays an operator entry screen, and the owner adds an identification of the person in question. As with the addition of approvers, the system determines whether the nominated operator or verifier is part of another workgroup, and if so, returns an error message. Assuming there is no such error, the system adds the identification of the individual in question as an operator verifier to the table identifying such members of that workgroup, and that information is saved in repository and later in the system data base. [0094] Fig. 20 illustrates similar processing, performed by the administrators, to create viewers. This is similar to the forgoing processing for the creation of new approvers and operators, except being carried out by the administrator, and need not be described in detail. Again, the concern is whether the nominated viewer already belongs to a workgroup (that is, in the illustrated embodiment, a viewer cannot be someone who is a member of any workgroup). [0095] The system 100, incorporating the foregoing processing, makes it possible to eliminate the conventional two-step handling of the application of a merchant, in which typically an application is filled out by hand, the merchant also manually signing a suitable contract, and the information from the application is then keyed in. As described at the beginning of the application, the conventional system invites mistakes, particularly, if the hand written application is difficult to read, and the occurrence of such mistakes, or any others which happen during keying in, result in a rejection of the application and thus a delay in getting the merchant on line. Because the processing described above can be performed across the Internet or the like by an agent in the field, who may be on the phone with the merchant or actually at the merchant's location, and can key in the information directly, thus eliminates the use of the hand-written application, and by virtue of the various validation and similar processing above, promotes to the greatest extent possible the inputting of error-free information. This of course requires the functionality of accepting and processing electronic signatures; any convenient known means of doing so can be adopted. [0096] As mentioned above, one benefit of the present invention is that it replaces the conventional two-stage data capture system with a one-stage approach. As the agent enters the information into the system, if the submission is successful, a standard contract suitable for the merchant in question (based on industry type, and identifying the merchant by name, address, place of incorporation if appropriate and all other needed information) is generated and sent to the agent, who can then print it out, either by means of a portable printer, or by transferring the file to a printer belonging to the merchant. That is, it is particularly contemplated that, where infrastructure permits, the agent may use an Internet hook-up at or near the merchant to communicate with the system of the invention, and thus be able to hand the printed contract to the merchant within a matter of minutes. The merchant, then can review the contract immediately, sign it and hand it to back to the agent.

[0097] Alternatively, the contract can be printed out by the agent after successful submission and mailed to the merchant (for example, if the agent is not actually visiting the merchant's site.) This of course ensures that all the merchant contracts are done uniformly and are legible.

[0098] Moreover, whether the printing out process just described is used in a given instance or not, once the contract for a new merchant has been signed by the merchant and returned to the acquirer, that contract is entered, preferably typed in, to produce a soft copy, and that soft copy is permanently stored in the acquirer's system. In addition, however, the soft copy of the contract is stored in the data base of the present invention, and is linked with the setup application of the merchant in question. Thus, if it becomes necessary to view the application (for example, if an error is identified in it); it is possible for the viewer to see the contract itself as well. This ability is also exercised by the approver who handles the application. ^• • ,

[0099] Fig. 21 illustrates the bulk-handling of files, permitting bulk submissions to the system of the invention, and from it to the external system of the merchant acquirer. This is particularly useful when processing a large number of applications in a short time, as may be particularly the case when enrolling a new merchant that has a large number of locations, a number of merchants in the same local or the like. .

[0100] As shown in Fig. 21, a batch file is defined and is populated with the setup records in the file handler 104 of the present invention. The resulting batch file is subjected to a validation processing, and if it passes, the contents of the files in that batch are saved in the repository and scheduled for the next batch loading into the external system 154. When the external system 154 is next able to receive input, the batch file is uploaded, and subjected to that system's own validation process. If the batch file is accepted, the files in it are entered into the external system 154, and a message is sent back to system 100 confirming success. If the validation processing fails in the external system 154, an error message to that effect is sent back instead.

[0101] Also, if the validation process has failed, a temporary list of erroneous setups is created, and stored in the system data base. These can later be reviewed and corrected by the original operators for re-submission.

Example Implementations

[0102] The present invention may be implemented using hardware, software or a combination thereof and may be implemented in one or more computer systems or other processing systems. However, the manipulations performed by the present invention were often referred to in terms, such as adding or comparing, which are commonly associated with mental operations performed by a human operator. No such capability of a human operator is necessary, or desirable in most cases, in any of the operations described herein which form part of the present invention. Rather, the operations are machine operations. Useful machines for performing the operation of the present invention include general purpose digital computers or similar devices.

[0103] In fact, in one embodiment, the invention is directed toward one or more computer systems capable of carrying out the functionality described herein. An example of a computer system 2200 is shown in Figure 22.

[0104] The computer system 2200 includes one or more processors, such as processor 2204. The processor 2204 is connected to a communication infrastructure 2206 (e.g., a communications bus, cross-over bar, or network).

Various software embodiments are described in terms of this exemplary computer system. After reading this description, it will become apparent to a person skilled in the relevant art(s) how to implement the invention using other computer systems and/or architectures.

[0105] Computer system 2200 can include a display interface 2202 that forwards graphics, text, and other data from the communication infrastructure 2206 (or from a frame buffer not shown) for display on the display unit 2230.

[0106] Computer system 2200 also includes a main memory 2208, preferably random access memory (RAM), and may also include a secondary memory 2210.

The secondary memory 2210 may include, for example, a hard disk drive 2212 and/or a removable storage drive 2214, representing a floppy disk drive, a magnetic tape drive, an optical disk drive, etc. The removable storage drive 2214 reads from and/or writes to a removable storage unit 2218 in a well known manner. Removable storage unit 2218 represents a floppy disk, magnetic tape, optical disk, etc. which is read by and written to by removable storage drive 2214. As will be appreciated, the removable storage unit 2218 includes a computer usable storage medium having stored therein computer software and/or data.

[0107] In alternative embodiments, secondary memory 2210 may include other similar devices for allowing computer programs or other instructions to be loaded into computer system 2200. Such devices may include, for example, a removable storage unit 2222 and an interface 2220. Examples of such may include a program cartridge and cartridge interface (such as that found in video game devices), a removable memory chip (such as an erasable programmable read only memory (EPROM), or programmable read only memory (PROM)) and associated socket, and other removable storage units 2222 and interfaces 2220, which allow software and data to be transferred from the removable, storage unit 2222 to computer system 2200.

[0108] Computer system 2200 may also include a communications interface 2224. Communications interface 2224 allows software and data to be transferred between computer system 2200 and external devices. Examples of communications interface 2224 may include a modem, a network interface (such as an Ethernet card), a communications port, a Personal Computer Memory Card International Association (PCMCIA) slot and card, etc. Software and data transferred via communications interface 2224 are in the form of signals 2228 which may be electronic, electromagnetic, optical or other signals capable of being received by communications interface 2224. These signals 2228 are provided to communications interface 2224 via a communications path (e.g., channel) 2226. This channel 2226 carries signals 2228 and may be implemented using wire or cable, fiber optics, a telephone line, a cellular link, a radio frequency (RF) link and other communications channels. [0109] In this document, the terms "computer program medium" and "computer usable medium" are used to generally refer to media such as removable storage drive 2214, a hard disk installed in hard disk drive 2212, and signals 2228. These computer program products provide software to computer system 2200. The invention is directed to such computer program products.

[0110] Computer programs (also referred to as computer control logic) are stored in main memory 2208 and/or secondary memory 2210. Computer programs may also be received via communications interface 2224. Such computer programs, when executed, enable the computer system 2200 to perform the features of the present invention, as discussed herein. In particular, the computer programs, when executed, enable the processor 2204 to perform the features of the present invention. Accordingly, such computer programs represent controllers of the computer system 2200.

[0111] In an embodiment where the invention is implemented using software, the software may be stored in a computer program product and loaded into computer system 2200 using removable storage drive 2214, hard drive 2212 or communications interface 2224. The control logic (software), when executed by the processor 2204, causes the processor 2204 to perform the .functions of the invention as described herein.

[0112] In another embodiment, the invention is implemented primarily in hardware using, for example, hardware components such as application specific integrated circuits (ASICs). Implementation of the hardware state machine so as to perform the functions described herein will be apparent to persons skilled in the relevant art(s),

[0113] In yet another embodiment, the invention is implemented using a combination of both hardware and software.

Conclusion

[0114] While various embodiments of the present invention have been described above, it should be understood that they have been presented by way of example, and not limitation. It will be apparent to persons skilled in the relevant art(s) that various changes in form and detail can be made therein without departing from the spirit and scope of the present invention. Thus, the present invention should not be limited by any of the above described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents. [0115] In addition, it should be understood that the figures illustrated in the attachments, which highlight the functionality and advantages of the present invention, are presented for example purposes only. The architecture of the present invention is sufficiently flexible and configurable, such that it may be utilized (and navigated) in ways other than that shown in the accompanying figures.

[0116] Further, the purpose of the foregoing Abstract is to enable the Patents Office and the public generally, and especially the scientists, engineers and practitioners in the art who are not familiar with patent or legal terms or phraseology, to determine quickly from a cursory inspection the nature and essence of the technical disclosure of the application. The Abstract is not intended to be limiting as to the scope of the present invention in any way. It is also to be understood that the steps and processes recited in the claims need not- be performed in the order presented.

Claims

WHAT IS CLAIMED IS:

1. A merchant-data capture system, comprising: an interface adapted to capture merchant information; information storage for receiving and maintaining the merchant information captured using said interface; a profile library; and a processor adapted to manage said interface, said profile library and said information storage, and to submit the merchant information to at least one external system.

2. The system of Claim 1, wherein said processor is adapted to permit a user to edit contents of the profile library, using said interface.

3. The system of Claim 1, wherein said processor is adapted to permit a user to edit contents of the profile library to produce a hierarchy of profiles such that a profile at a lower level in the hierarchy inherits all prepopulated fields of each profile above it in the hierarchy.

4. The system of Claim 1, wherein said processor is adapted to recognize individual users, and to accord different users different authorization levels for using various functionalities of said system.

5. The system of Claim 4, wherein a user has access to different sets of profiles in said profile library depending on that user's authorization level.

6. The system of Claim 1, wherein said processor also is adapted to permit a user to use said interface to edit the merchant information for submission to the at least one external system.

7. The system of Claim 1, wherein said processor is adapted to generate reports based on information stored in said information storage.

8. The system of Claim 1, wherein said interface is adapted to capture the merchant information via at least one display screen presented to a user for inputting of the information.

9. The system of Claim 1, wherein said interface is adapted to capture the merchant information by means of receiving transfer of at least one file containing the merchant information, from an external source.

10. The system of Claim 1, wherein said processor is adapted to permit a user to retrieve a set of merchant information previously captured and saved in said information storage, for editing and/or submission to the at least one external system.

11. The system of Claim 1 , further comprising a validation system for performing validation checking on merchant information prior to the merchant information being submitted to the at least one external system.

12. The system of Claim 1, wherein said processor is adapted to enable a user to edit merchant information that has been submitted to the at least one external system, at least in response to receipt from the at least one external system of a message indicating rejection of the submitted merchant information.

13. The system of Claim 1, further comprising an archive component, adapted to archive the merchant information automatically.

14. The system of Claim 13, further comprising a report component adapted to generate reports.

15. The system of Claim 1, wherein said interface is web-accessible such that a merchant can submit the merchant information for that merchant via the Internet.

16. The system of Claim 15, wherein said interface is adapted to process electronic signatures.

17. The system of Claim 14, wherein the archived merchant data includes an image of at least one merchant contract, the image being associated by means of a link to another portion of the merchant data, to permit a user to view the image by means of the link.

18. The system of Claim 1, further comprising a tracking interface, to permit a user to view contract status of a particular merchant, and to track progress of setting-up of that merchant.

19. The system of Claim 1, further comprising a contract generating component adapted to produce in printable form a contract based on a template contract, filled in for a particular merchant based on the merchant information corresponding to that merchant.

20. The system of Claim 19, wherein contents of the contract vary depending on what market the merchant is in, business address, industry.

21. The system of Claim 19, wherein the language the contract is printed in is dependent on the merchant information corresponding to that merchant.

22. The system of Claim 1, further comprising at least one table containing information that is based on contents of the at least one external system and that is used in processing the captured merchant information, and wherein said processor is adapted to permit a user to edit the contents of the at least one table.

23. The system of Claim 1, wherein said processor is adapted to enable a user to save a. partial or complete body of merchant information without submission to the at least one external system, and to access the saved information for at least one of further data capture, editing and submission to the at least one external system.

24. The system of Claim 1, wherein said processor is adapted to enable a user to input a body of merchant information by accessing a copy of a previously submitted body of merchant information and editing the copy for submission to the at least one external system.

25. A method of capturing merchant data using a merchant-data capture system that comprises an interface adapted to capture merchant information, information storage for receiving and maintaining the merchant information captured using the interface, a profile library and a processor adapted to manage the interface, profile library and information storage, and to submit the merchant information to at least one external system, said method comprising the steps of: entering the merchant information by means of the interface; storing the entered merchant information in the information storage; and submitting the merchant information to the at least one external system.

26. A computer-readable storage medium storing executable program code that, when executed, causes a computer system to perform a method of capturing merchant data using a merchant-data capture system that comprises an interface adapted to capture merchant information, information storage for receiving and maintaining the merchant information captured using the interface, a profile library and a processor adapted to manage the interface, profile library and information storage, and to submit the merchant information to at least one external system, said program code comprising: computer control logic code for entering the merchant information by means of the interface; computer control logic code for storing the entered merchant information in the information storage; and computer control logic code for submitting the merchant information to the at least one external system.