US20080162340A1

Movatterモバイル変換

Info

Publication number: US20080162340A1
Application number: US11/616,767
Authority: US
Inventors: Robert Zimmer; Joachim Sander
Original assignee: Individual
Current assignee: SAP SE
Priority date: 2006-12-27
Filing date: 2006-12-27
Publication date: 2008-07-03

Abstract

Techniques for displaying a graphical user interface operable to receive user input specifying a payment to be made to a payee and a payment method to be used to make the payment are described. The payment method is one of multiple ways of making the payment using the graphical user interface. The techniques include making a determination as to whether the specified payment method involves a third-party on-line payment system. In response to a determination that the specified payment method involves a third-party on-line payment system, a message is provided to the third-party on-line payment system. The message includes payment information such that the third-party on-line payment system is able to process the payment to pay the payee. In response to a determination that the specified payment method involves a payment system other than a third-party on-line payment system, the specified method to pay the payee is initiated.

Description

TECHNICAL FIELD

This description relates to the integration of enterprise information technology systems with a third-party on-line payment system.

BACKGROUND

Computer systems often are used to manage and process business data. To do so, a business enterprise may use various application programs running on one or more enterprise IT systems. Application programs may be used to process business transactions, such as taking and fulfilling customer orders, providing supply chain and inventory management, performing human resource management functions, and performing financial management functions. A computer system may include a financial transaction component that enables payment of invoices and other payable items.

SUMMARY

In one general aspect, a graphical user interface is displayed. The graphical user interface is operable to receive user input specifying a payment to be made to a payee and a payment method to be used to make the payment. The payment method is one of multiple ways of making the payment using the graphical user interface. A determination as to whether the specified payment method involves a third-party on-line payment system is made. In response to a determination that the specified payment method involves a third-party on-line payment system, a message is provided to the third-party on-line payment system. The message includes payment information is provided to the third-party on-line payment system such that the third-party on-line payment system is able to process the payment to pay the payee. In response to a determination that the specified payment method involves a payment system other than a third-party on-line payment system, the specified payment method is initiated to pay the payee.

Implementations may include one or more of the following features. For example, the specified payment method may be a bank transfer. Data representing unpaid invoices associated with the payee may be accessed. The accessed unpaid invoice data may be displayed within the graphical user interface such that the graphical user interface is operable to receive user input specifying one or more unpaid invoices to pay from among the accessed unpaid invoice data.

The payment information may be provided through a file transfer to the third-party on-line payment system. A notification to the payor system including information associated with processing the payment to the payee system may be provided. A notification to the payee system including information associated with processing the payment to the payee system may be provided.

A user input indicating confirmation of the specified payment to be made may be received. The specified payment may include unpaid invoices associated with the payee. A graphical user interface associated with the third-party on-line payment system may be initiated.

Implementations of any of the techniques described above may include a method or process, an apparatus or system, or computer software on a computer-accessible medium. The details of particular implementations are set forth in the accompanying drawings and description below. Other features will be apparent from the following description, including the drawings, and the claims.

DESCRIPTION OF DRAWINGS

FIG. 1 is a block diagram of a network of computer systems.

FIG. 2 is a flow chart of a process for making a payment to a payee system.

FIG. 3 is a flow chart of a process for making payments to multiple payee systems.

FIGS. 4A and 4B are illustrations of example graphical user interfaces that may be used to define a payment.

FIG. 5 is an illustration of an example financial transaction.

FIG. 6 is a block diagram of a computer system.

DETAILED DESCRIPTION

To fully understand the techniques presented in this description, the challenges and issues related to integrating enterprise information technology systems with a third-party on-line payment system are discussed. An enterprise information technology system may include a financial transaction component that enables payment of invoices or other payable items. Managing (e.g., paying and tracking) the payment of a large number invoices using different payment systems may require reconciliation between the different payment systems. When the different payment systems are not able to communicate or otherwise exchange financial data, the reconciliation of payments made with the different payment systems may be more challenging. Integration of the enterprise information technology system with a third-party on-line payment system may streamline the management of the payment of a large number of invoices or other payable items across different payment systems. Integration of the enterprise information technology system with a third-party on-line payment system enables a user of the enterprise technology system to pay invoices or other payable items through the third-party on-line payment system from within the enterprise information technology system. Additionally, integration may enable the user to pay invoices and other payable items through a variety of payment methods that otherwise would only be available through the use of different financial or payment systems. Moreover, the integration may enable more precise tracking of invoice payments, thus improving the enterprise's ability to maintain accurate accounting records.

Accordingly, techniques are provided for integrating an enterprise information technology system with a third-party on-line payment system.

A network ofcomputer systems100, in which a third-party on-line payment system140 is integrated with an enterprise information technology (IT)system110 having a financial transaction processing component120 (collectively, “financial system110”), is shown inFIG. 1. A third-party on-line payment system integration component (“integration component”)130 integrates a third-party on-line payment system140 with thefinancial system110 as described more fully below. In general, theintegration component130 enables a user, from within a user interface displayed by financialtransaction processing component120, to select a third-party on-line payment system140. The user may then pay one or more payees for selected payable items through the selected third-party on-line payment system140. The user of thefinancial system110 or the enterprise operating thefinancial system110 may be referred to the payor.

The user may define a payment to be made by indicating a payee, or payees, and the method of payment. In response to the user's definition of a payment to be made and the user's selection of a third-party on-line payment system140 to be used to make the payment, theintegration component130 creates amessage144 to be transferred from thefinancial system110 to the third-party on-line payment system140. Themessage144 enables thefinancial system110 to access the services provided by the third-party on-line payment system140 to make the payment to the payee by sending a payment through the third-party on-line payment system. Themessage144 generally includes information regarding a financial transaction that is included in thefinancial system110 but not otherwise included in the third-party on-line payment system140. For example, themessage144 may include information such as, for example, data identifying the payee, data indicating the amount of payment, and data identifying the currency in which to make the payment.

Integration of thefinancial system110 and the third-party on-line payment system140 may enable the payor and/or payee to receive rapid notice of a payment, which, in turn, may enable more accurate record keeping. In some implementations, the payor and/or the payee may receive notice of payment that is substantially concurrent with payment transfer of the payment itself. This may be referred to as providing payment notice substantially in real-time with making the payment. Moreover, transferring funds through the third-party on-line payment system140 may help to minimize or, perhaps to eliminate, global transfer fees associated with some types of international fund transfers.

More particularly, the network ofcomputer systems100 includes thefinancial system110 and the third-party on-line payment system140. Thenetwork100 also includes at least onepayee system160, which may be a financial system for a commercial enterprise that is to receive payment from the payor. The systems,110,140, and160, each are capable of executing instructions on data, and the systems are indirectly interconnected with one another. Communication between thefinancial system110 and the third-party on-line payment system140 (as well as communication between the third-party on-line payment system140 and the payee system160) may be provided, for example, through a variety of established networks, such as, for example, the Internet, a Public Switched Telephone Network (PSTN), the Worldwide Web (WWW), a wide-area network (“WAN”), a local area network (“LAN”), a wired network, or a wireless network. The communication may be provided through the use of a middleware messaging system. Thefinancial system110 may deliver and exchange data with the third-party on-line payment system140 through a communication gateway. For example, themessage144 may be transferred from thefinancial system110 to the third-party on-line payment system140 through a gateway. Similarly, the third-party on-line payment system140 may deliver and exchange data with thepayee system160 through a communication gateway.

Thefinancial system110 includes a financialtransaction processing component120 that is used to view, modify, store, and process data related to financial transactions. In one example, the financialtransaction processing component120 may be a commercial computer application that is developed and licensed (or sold) by a commercial software developer for sale to, and use by, many business enterprises. In another example, the financialtransaction processing component120 and theintegration component130 may be part of a suite of commercial applications that are developed and licensed (or sold) by a commercial software developer.

The financialtransaction processing component120 includes atransaction data store122. In particular, thetransaction data store122 includes information about payable items. Information about the payable items may include, for example, the number of open invoices for a particular payee, the amount owed on each open invoice, the currency in which each open invoice is to be paid, the date of any previous payment made to the payee, the current account balance owed to the payee, contact information for the payee, and information regarding the default payment method for the payee. Thetransaction data store122 may be, for example, a relational database that logically organizes data into a series of database tables. Each database table arranges data in a series of columns (where each column represents an attribute of the data stored in the database) and rows (where each row represents attribute values). Thetransaction data store122 may be, for example, an object-oriented database that logically or physically organizes data into a series of objects. Each object may be associated with a series of attribute values. Thetransaction data store122 also may be a type of database management system that is not necessarily a relational or object-oriented database. For example, a series of XML (Extensible Mark-up Language) files or documents may be used, where each XML file or document includes attributes and attribute values.

The financialtransaction processing component120 also includes a definepayment component124. The definepayment component124 includes instructions that, when executed, enable a user offinancial system110 to define the payments to be made to the payee. The definepayment component124 also may include instructions, that when executed, for display and control a user interface that enables the user offinancial system110 to view information in thetransaction data store122. For example, executing the instructions in the definepayment component124 may result in the display of some or all of the payable items that are owed to a particular payee. In another example, executing the instructions may display all of the payable items that are owed to multiple payees. Additionally, the interface also enables the user to define the payment to be made. For example, the user may select multiple payable items owed to a particular payee as the payment to be made. In another example, the user may view payable items that are owed to more than one payee and the user may select particular payable items as the payments to be made to each of the various payees.

When executed, the instructions of the definepayment component124 also may allow the user of thefinancial system110 to select a method of payment for each payment. For example, the user may select to pay the payee through a third-party on-line payment system. Examples of third-party on-line payment systems include PayPal®, available from PayPal, Incorporated of San Jose, Calif.; e-gold®, available from Gold & Silver Reserve, Incorporated of Melborne, Fla.; and NetPay®, available from Chugach Electric Association, Incorporated of Anchorage, Ak. In another example, the user may select to pay the payee through a traditional bank draft, a credit card, or an electronic transfer. In yet another example, the user may select the account from which to pay the defined payment from among multiple available accounts on a particular third-party on-line payment system140. In still another example, the payee may be associated with a default method of payment that the user may elect to use. After the payment is defined, the definepayment component124 may persistently store the payment information in thetransaction data store122.

Theintegration component130 is configured to package a portion of the financial data in thetransaction data store122 as amessage144 for transmission to the third-party on-line payment system140. In particular, the message includes data that defines the payments to be made using the third-party on-line payment system140. As described above with respect to the definepayment component124, this information defining the payment may be stored intransaction data store122. Theintegration component130 enables financial transaction data that is defined in thefinancial system110 to be used to initiate payment to a payee using the third-party payment system140. This allows the third-party on-line payment system140 and thefinancial transaction system110 to be used together.

Theintegration component130 also includes a paymenttransfer details component136. The paymenttransfer details component136 includes instructions that, when executed, allows information identifying thepayee system160 to be specified. The paymenttransfer details component136 may allow the user to directly specify information that identifies the payee's account on the third-party on-line payment system140. The user may have the option of indicating that the information identifying the payee be used for the current transaction only. Alternatively, information identifying the payee's account may be predefined and retrieved by the paymenttransfer details component136 from thetransaction data store122. The information identifying the payee's account may be information that uniquely identifies the payee, such as, for example, an email address. The information identifying the payee may also correspond to an account on the third-party on-line payment system140 that is associated with the recipient. Thus, the payee's contact information may identify the payee's account on the third-party payment system140. Finally, the paymenttransfer details component136 may also include instructions that, when executed, persistently store the information identifying the payee in thetransaction data store122.

Theintegration component130 also includesinstructions138 that, when executed, create amessage144 for the third-party on-line payment system140. Themessage144 may include information defining the payment to be made as well as data required to access an account on the third-party on-line payment system140. When executed, theinstructions138 access the information that defines the payment to be made that was created using the definepayment component124. The payment information may include, for example, information identifying the invoices to be paid to the payee, the total amount of payment to be made to a payee, the method of payment, and the currency in which the payment is to be made to the payee.

Theinstructions138 also may access information from the third-party on-line payment store134 that enables access to the enterprise's account on a particular third-party on-line payment system. For example, such information may include the username and password for the enterprise's account on the third-party on-line payment system. Theinstructions138 also may access information, from the paymenttransfer details component136, that identifies the payee's account on the third-party on-line payment system140. Theexecutable instructions138 package the information intomessage144. Thefinancial system110 then provides themessage144 to the third-party on-line payment system140 such that the defined payments may be processed by the third-party on-line payment system140.

In some implementations, the information included inmessage144 may be provided to the third-party on-line payment system140 in a Microsoft Excel® file. In these implementations execution of theinstructions138, for example, may cause a Microsoft Excel® file to be created. Thefinancial system110 then provides the Microsoft Excel® file to the third-party on-line payment system140 such that the defined payments may be processed by the third-party on-line payment system140. In another implementation, the information included inmessage144 may be provided to the third-party on-line payment system140 in an ASCII text file or an XML file.

In the example ofsystem100, theintegration component130 is a component of thefinancial system110, though this need not necessary be so. For example, theintegration component130 may be a separate component that is interoperable with thefinancial system110.

As discussed above, the third-party on-line payment system140 can be one of multiple available on-line payment systems. For example, the third-party on-line payment system140 may be an Internet-based on-line payment intermediary, such as PayPal®, e-gold®, or NetPay®. The third-party on-line payment system application (“third-party application”)150 includes an import payment data routine152. The import payment data routine152 imports the data that thefinancial system110 sent to the third-party on-line payment system140 usingmessage144. The third-party application150 also includesaccount data154, which includes information about the enterprise's account on the third-party on-line payment system140.Account data154, as shown in this example, includesbalance data154A, account-holder identification154B, andtransaction log data154C.

In addition, the third-party application150 includes aninterface generation routine156. Theinterface generation routine156 includes instructions that, when executed, display and control an interface that enables information related to the enterprise's account on the third-party on-line payment system140 to be presented to the user of thefinancial system110. The interface may be displayed within thefinancial system110, and the interface enables the user of thefinancial system110 to pay the transactions that were defined using the definepayment component124. The interface also may show a summary of the payment information, such as, for example, the account from which the payment will be made, information that identifies the payment recipient, the amount of the payment, and the invoice numbers of the individual payments. Display of this information enables the user to confirm that the information related to the payment to be made is correct before the third-party application150 processes the payment. The interface also may allow the user to access other functionality of the third-party on-line payment system140. For example, the interface may enable the user to view the transaction log for their account.

The third-party application150 also includespayment processing instructions158. When executed, thepayment processing instructions158 process a particular defined payment such that funds may be transferred from the enterprise's account to the payee's account. Additionally, when executed, thepayment processing instructions158 determine whether the enterprise's account includes sufficient funds to make the defined payments. If there are insufficient funds in the account, thepayment processing instructions158 may ask the user to specify another account from which to make the payment.

Once it is determined that the enterprise's account has sufficient funds to make the defined payment, execution of thepayment processing instructions158 causes the third-party on-line payment system140 to send atransaction notification144 to thefinancial system110. Thetransaction notification144 includes information related to the payment, such as, for example, information identifying the payee, an indication of whether the transaction was processed successfully, a time stamp indicating the time the payment was processed, the amount of the payment processed, the currency in which the payment was made, the payment method, and the payee's contact information. Thetransaction notification144 also may include information that allows thefinancial system110 to track the payment. For example, thetransaction notification144 may include information, such as invoice numbers, to identify which payable items were paid. Thefinancial system110 may persistently store the information contained in thetransaction notification144 in thetransaction data store122.

Additionally, if the payee and the payor both have an account on the same third-party on-line payment system140, the third-party on-line payment system140 may transfer the funds to the payee as soon as the payment is processed by thepayment processing component158. In this case, thetransaction notification message144 may also include an indication that the finds have been transferred to the payee.

In addition, execution of thepayment processing instructions158 also causes apayment notification146 to be sent to thepayee system160. Similar to thetransaction notification144, thepayment notification146 informs thepayee system160 that a payment has been made. Additionally, if the payee has an account on the same third-party on-line payment system140 as the payor, thepayment notification146 may include an indication that funds have been placed in the payee's account on the third-party on-line payment system140. If the user offinancial system110 specified payments to multiple payees, the third-party on-line payment system140 may be able to send apayment notification146 to eachpayee system160 and thetransaction notification144 will indicate that multiple transactions occurred.

FIG. 2 depicts anexample process200 for making a payment to a payee system such as thepayee system160 described with respect toFIG. 1. Theprocess200 may be performed by one or more processors in a system, such as, for example, thefinancial system110. The processor is directed by a method, script, or other type of computer program that includes executable instructions for performing theprocess200. Theprocess200 may be manually initiated by, for example, a business analyst or any other user offinancial system110 who wants to make a payment to a payee.

Theprocess200 begins when a user of thefinancial system110 initiates theprocess200, and the processor generates a graphical user interface that is operable to receive user input that defines a payment to make to a payee, user input specifying a method of making the payment, and user input that specifies an account from which the payment is to be made (step210). Theprocess200 continues when the processor receives user input specifying the payee (step220). This may be accomplished, for example, by the user selecting a particular payee from a list of all payees to which the payor owes payable items. In another example, the user may enter the name of the payee into a dialog box, or other control, on the graphical user interface.

Once the user has identified the payee, theprocess200 continues when the processor causes the graphical user interface to display the payable items owed to the payee (step230). The graphical user interface also may display information associated with each payable item such as, for example, the amount owed for the payable item, a unique identifier for the payable item (e.g., an invoice number), the due date of the payable item, the status of the payable item, information on the payment terms for the payable item, the default method of payment associated with the payable item, and the currency in which the payable item is to be paid. The graphical user interface also may display the total owed for all of the payable items associated with the payee.

Theprocess200 continues when the processor receives user input specifying the payable items the user intends to pay (step240). For example, the user may select to pay one of many payable items owed to the payee, or the user may select to pay some of the payable items. In another example, the user may select to pay all of the payable items owed to the payee. The processor may use the definepayment component124, described above with respect toFIG. 1, to receive user input regarding the payable items to pay and define the payment to be made.

Theprocess200 continues when the processor receives user input specifying the method of payment by which to pay the payment defined by the user (step250). For example, the user may specify that the defined payment be made through an Internet-based third-party on-line payment system such as PayPal®, e-gold®, or NetPay®. In another example, the user may indicate that the defined payment be made through a check, credit card, or electronic transfer. In another example, the payee may be associated with a default method of payment, and the user may elect to pay the payee through the default payment method.

Once the user has specified the method of payment, theprocess200 continues when the processor receives user input specifying the account from which the payable items is to be paid (step260). For example, if the user selected to pay the defined payment through PayPal®, the interface may display several PayPal® accounts available to the enterprise such that the user may specify that the payment be made from a particular PayPal® account. In another example, the user may specify that the payment be made through an electronic transfer or a traditional bank draft drawn from a bank or other financial institution.

Theexample process200 also includes creating a message (step270) that the processor is to provide to the payment system specified by the user. The message may include, for example, data that enables thesystem running process200 to access an account on a third-party on-line payment system. Thus, the graphical user interface running on the processor may allow the user to access the third-party on-line payment system from within the user interface. The data provided in the message may include, for example, the username and password associated with the account on the third-party on-line payment system, an account identifier, and the network address of the particular third-party on-line payment system. The message also may include data that defines the payment to be made. The message also may include data that identifies the payee and the payee's account, if any, on the third-party on-line payment system.

Theprocess200 continues when the processor provides the message (created in step270) to the third-party on-line payment system (step280) such that the third-party on-line payment system is able to process the defined payment. Additionally, the user interface displayed on thesystem running process200 may display the third-party on-line payment system such that the user of the interface may access the functionality of the third-party on-line payment system.

As illustrated by theprocess200, a user is able to use the same process to initiate, define, or make payments through a third-party on-line payment system as well as through other payment techniques, such as issuing a bank transfer.

FIG. 3 depicts anexample process300 that allows a user of a system, such as thefinancial system110 described with respect toFIG. 1, to make payments to multiple payees using a graphical user interface. Similar to theprocess200, theprocess300 may be performed by one or more processors in a system, such as, for example, thefinancial system110. The processor is directed by a method, script, or other type of computer program that includes executable instructions for performing theprocess300. Theprocess300 may be manually initiated by, for example, a business analyst or any other user offinancial system110 who wants to make a payment to a payee.

Theprocess300 begins when the processor generates a graphical user interface that is operable to receive user input that defines payments to be made to multiple payees, specifies the method of payment for each defined payment, and specifies the account or accounts from which each payment is to be made (step310). The processor also causes the graphical user interface to display payable items owed to the payees (step320). In some implementations, the user has the option of specifying the payees for which to see payable items.

Theprocess300 continues when the processor receives user input specifying which payable items to pay to each of the payees (step330). The processor may use, for example, the definepayment component120, described with respect toFIG. 1, to define the payment once the user input specifying the payable items is received. The processor also receives user input specifying the method by which each of the defined payments will be made (step340). For example, similar toprocess200, the user may specify that a defined payment be made through a third-party on-line payment system such as PayPal®, NetPay®, or e-gold®. In another example, the user may specify that a defined payment be made using a check, credit card, bank draft, or electronic transfer. Once the user has specified the method of payment, the processor receives user input specifying an account or accounts from which the defined payments are to be made (step350). The user may continue to specify a method of payment and an account from which payment is made until all a method of payment and an account are specified for each defined payment (step355).

Theprocess300 continues when the processor creates a file summarizing the defined payments, the data describing the account, or accounts, from which the defined payments are to be made, and the data identifying the payees (step360). In one example, the file may be a Microsoft Excel® file in which the data required to make a payment to a particular payee is included in the Microsoft Excel® file regardless of how many invoices the user selected to pay to that payee. The data required to make a payment to the payee may include, for example, the total amount of the payment, the method of payment, data identifying the account from which to make the payment, and the currency in which the payment will be made. In this example, the Microsoft Excel® file has a similar entry for each payee that is to receive a payment. In another implementation, the data required to make the payments to multiple payees may be contained in an ASCII text file or an XML file, with the ASCII text file or the XML file including substantially the same type of information described above for the Excel(g file example.

Theprocess300 provides the file (created in step360) to a third-party on-line payment system (step370). The third-party on-line payment system may be, for example, the third-party on-line payment system140 described with respect toFIG. 1. Once the third-party on-line payment system140 receives the file, the contents of the file are imported by the third-party on-line payment system140 such that the third-party on-line payment system140 is able to process the defined payments.

FIG. 4A is an illustration of an examplegraphical user interface400A that may be used to define a payment to be made to a payee through a third-party on-line payment system. In one implementation, thegraphical user interface400A may be accessible through a financial system such as thefinancial system110 described above in the context ofFIG. 1. In the example shown inFIG. 4A, the user has elected to make a payment to one payee (“Johnson & Partner Inc.”).

Thegraphical user interface400A includes a payable items display410 that displays the payable items,412,413, and414, that the payor owes to the payee. The payable items display410 also enables the payor to define the payment to be made to the payee by selecting the payable items to pay. For example, the payor may define the payment by clicking on the payable items to pay using a mouse or other user-input device. In other implementations, the selected payable items may be indicated by an activated checkbox. As shown in the examplegraphical user interface400A, the payable items display410 may include information about each payable item. The payable items display410 may show a summary of the payable items owed to the payee in asummary section415. For the example illustration, thesummary section415 displays the total amount owed to the payee for the payable items,412,413, and414. For example, the invoice number, due date, payment terms, payment currency, and amount may be shown for each payable item. The payable items display410 may indicate that certain payable items have been selected by graying the background of the selected payable items. In the example shown inFIG. 4A, the user of the graphical interface has defined the payment to be made to the payee as

payable items

412 and413.

Thegraphical user interface400A also includes apayment system section420. Thepayment system section420 includes aselector422 that allows the user of theinterface400A to specify the method of payment with which to make the defined payment. In the example shown, the user specified an on-line payment transfer as the method of payment. The on-line payment transfer may be made through an Internet-based payment intermediary such as PayPal®. However, as discussed above in the context ofFIG. 1, other methods of payment may be specified such as, for example, an electronic transfer, a credit card, or a traditional bank draft. In some implementations, the method of payment may be predefined for the particular payee, and retrieved by the processor running theinterface400A and then displayed withinselector422. In some implementations, the user may directly specify a method of payment besides the ones shown usingselector422.

Thepayment system section420 also includes anaccount selector424 that enables the user to specify the account through which to make the payment to the payee. In the example illustration, the user has indicated that payment will be made through the enterprise's Toronto account. Thepayment system section420 further includes a total definedpayment display426. The total definedpayment display426 shows the user the total amount of the payment that is to be made to the payee as well as the currency in which the payment is to be made. In the example shown, the total amount of the defined payment is $3,871.57 and the currency is United States dollars.

Thegraphical user interface400A also includes a paymenttransfer details section430 that enables the user to specify the account information of the payee. The payment transfer details section includespayee contact information432.Payee contact information432 displays the contact information, such as the name and electronic mail (“email”) address, of the payee. If the payee has an account on the third-party on-line payment system that is being used to process the payment, the contact information may identify the payee's account on the payment system. In general, the payee's contact information is predefined, and the graphical user interface retrieves it and displays it within thepayee contact information432. In some implementations, thecontact information432 may be entered directly by the user of thegraphical interface400A.

Thepayment transfer details430 also includes a one-time email checkbox434 that allows the user to specify the payee's email contact information that identifies the payee's account on the third-party on-line payment system for this transaction only. When the user selects the one-time email checkbox434, the payee's one-time email address is shown in the one-time email display436.

The graphical user interface400 also includes a third-party on-line payment system integration display (“integration display”)440 that enables the user of theinterface400A to use the third-party on-line payment system from within theinterface400A. In the illustration shown inFIG. 4A, PayPal® is the third-party on-line payment system. Using theintegration display440 of theinterface400A is capable of enabling access to other third-party on-line payment systems from within theinterface400A.

Theintegration display440 may include alogin control444 that specifies information required for the user of graphical user interface400 to login to the account on the third-party on-line payment system. Theintegration display440 also includes a third-party on-line payment system display446 (“payment system display”). Thepayment system display446 enables the user of the graphical user interface400 to interact with and use the third-party on-line payment system. In the example shown, thepayment system display446 also includes a summary of the payment to be made such that the user may confirm the payment prior to completing the transaction. The information shown in thepayment system display446 may be imported from a message or file sent from the processor displaying the graphical user interface. Thepayment system display446 also includes apayment control448 that enables the user to finalize the transaction by making the payment to the payee.

FIG. 4B is an illustration of an examplegraphical user interface400B that may be used to define payments to be made to multiple payees through a third-party on-line payment system. Thegraphical user interface400B may be running on a financial system such as thefinancial system110 described above in the context ofFIG. 1.

Graphical user interface

400B also may include apayable items section460 that allows the user to view items owed to various payees. The user may define a payment by selecting one or more payable items. In the example shown inFIG. 4B, thepayable items section460 displays only some of the payable items that the user may select from to specify the defined payment. Theinterface400B also displays information about each payable item summarized by payee. For example, for each payee, the method ofpayment462, a number of payable items control464, the total amount owed466 for all payable items associated with the payee, and thecurrency468 in which the payment to be made are shown within thepayable items section460. In some implementations, the number of payable items control464 may be a hyperlink such that, by clicking on the number of payable items control464, the user may view each payable item associated with a particular payee. Once the user clicks on the number of payable items control464, the user may specify which payable items to pay for that particular payee.

Thegraphical user interface400B also includes a definedpayments section470 that displays the defined payments that the user specified as summarized by payee. For each payable item, theuser interface400B displays theaccount472 from which the payment will be made, the number ofpayable items474 being paid for each payee, theamount476 of the defined payment for each payee, and thecurrency470 in which defined payment will be paid. The definedpayments section470 may also include asummary section479 that displays the total defined payments summarized by the currency used to make the defined payments.

Similar to thegraphical user interface400A, thegraphical user interface400B also may include a log-indata section480 that allows the user of thegraphical user interface400B to specify the data required to give the user access to the account, or accounts, from which the defined payments are to be made. The log-indata section480 may enable the user of thegraphical user interface400B to specify the data required to log into more than one account.

Thegraphical user interface400B also may include a third-party on-line payment system display490 (“payment system display”) that enables the user of theinterface400B to use the third-party on-line payment system from within theinterface400B. In the illustration shown inFIG. 4B, PayPal® is the third-party on-line payment system, but, using theintegration display490, theinterface400B is capable of enabling access to other third-party on-line payment systems from within theinterface400B. Additionally, in the illustration shown inFIG. 4B, the third-party on-line payment system has imported the data that the user specified in thepayable items section460 such that the user may view the payments to be made prior to making the payment. This enables the user to confirm that the information about the payments is correct prior to making the payments.

FIG. 5 shows an example transaction made between an enterpriseinformation technology system510 having a financial transaction processing component and multiple payee systems,560,562, and564. The transaction is made using a network ofcomputer systems500, in which a third-party on-line payment system540 is integrated with theenterprise information system510. In the example transaction, a user of thefinancial system510 defines

payments

512,514, and516 to be made, respectively, to the NewYork payee system560, theBerlin payee system562, and theTokyo payee system564. The user of thefinancial system510 may also specify the method of payment for each defined payment and the account from which each defined payment is to be made. Once the user has defined the payments and the method of payment, thefinancial system510 provides the third-party on-line payment system540 with afile520 that includes, for example,payment data522 and logininformation524.

In the example transaction shown inFIG. 5, the user of thefinancial system510 defined apayment512 to be made to the NewYork payee system560, apayment514 to be made to theBerlin payee system562, and apayment516 to be made to theTokyo payee system564. The user offinancial system510 may have defined these three payments using executable instructions such as the definepayment component124 described with respect toFIG. 1. In the exemplary transaction shown inFIG. 5, the user specified that the payments to the NewYork payee system560 and theTokyo payee system564 be made through theSan Francisco account542 on the third-party on-line payment system540, and the user specified that the payment made to theBerlin payee system562 be made through theHouston account544 on the third-party on-line system540. Each defined payment may include more than payable item. In the example transaction shown inFIG. 5, the definedpayment A522 includes three payable items. Despite being in different currencies, payable to different payees, and paid from different accounts, the three defined

payments

512,514, and516, were defined using one interface running onfinancial system510.

Once the user of thefinancial system510 has defined the payments to be made, thefinancial system510 creates afile520. Thefile520 may be created using, for example, theinstructions138 discussed in the context ofFIG. 1. Thefile520 includespayment definition data522 and logininformation524. Thepayment definition data522 includes one line of data for each defined payment. For example, in thetransaction500, thefile520 has a line specifying that total payment to the NewYork payee system560 is 18,000 USD, and it is to be made from theSan Francisco account542 on the third-party on-line payment system540. Thelogin information524 includes data required to access the

accounts

542 and544 on the third-party on-line payment system540 such as, for example, the username and password associated with each account and the network address of the third-party on-line payment system540. In one implementation, file520 is a Microsoft Excel® file that includes substantially the same information for each defined payment. In another implementation, thefile520 is an ASCII text file that includes substantially the same information for each defined payment.

Thefinancial system510 sends thefile520 to the third-party on-line payment system540. Thefile520 contains data that enables the user of thefinancial system510 to access

accounts

542 and544 on the third-party payment system540 and information that enables the third-party on-line payment system540 to process the defined payments. After processing the payments, the third-party on-line payment system540 sends atransaction notification535 to thefinancial system510. Thetransaction notification535 may include information that allows thefinancial system510 to track payment information, such as the invoice numbers of the payable items that were paid, the time and date of payment, and an indication of whether the payment was successful.

The third-party on-line payment system540 also sends

payment notifications

552,554, and556, respectively, to the NewYork payee system560, theBerlin payee system562, and theTokyo payee system564.

FIG. 6 is a block diagram of acomputer system600 that can be used in the operations described above, according to one embodiment. Thesystem600 includes aprocessor610, amemory620, astorage device630 and an input/output device640. Each of the

components

610,620,630 and640 are interconnected using asystem bus650. Theprocessor610 is capable of processing instructions for execution within the system2000. In some implementations, theprocessor610 is a single-threaded processor. In another implementation, theprocessor610 is a multi-threaded processor. Theprocessor610 is capable of processing instructions stored in thememory620 or on thestorage device630 to display graphical information for a user interface on the input/output device640.

Thememory620 stores information within thesystem600. In one implementation, thememory620 is a computer-readable medium. In another implementation, thememory620 is a volatile memory unit. In still another embodiment, thememory620 is a non-volatile memory unit.

Thestorage device630 is capable of providing mass storage for thesystem600. In one embodiment, thestorage device630 is a computer-readable medium. In various different embodiments, thestorage device630 may be a floppy disk device, a hard disk device, an optical disk device, or a tape device.

For example, thefinancial system110, discussed previously with respect toFIG. 1, may include theprocessor610 executing computer instructions that are stored in one ofmemory620 andstorage device630.

The input/output device640 provides input/output operations for thesystem600. In one implementation, the input/output device640 includes a keyboard and/or pointing device. In another implementation, the input/output device640 includes a display unit for displaying graphical user interface as discussed above.

The techniques can be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations of them. The techniques can be implemented as a computer program product, i.e., a computer program tangibly embodied in an information carrier, e.g., in a machine-readable storage device, in machine-readable storage medium, in a computer-readable storage device, in computer-readable storage medium, or in a propagated signal, for execution by, or to control the operation of, data processing apparatus, e.g., a programmable processor, a computer, or multiple computers. A computer program can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program can be deployed to be executed on one computer or on multiple computers at one site or distributed across multiple sites and interconnected by a communication network.

Method steps of the techniques can be performed by one or more programmable processors executing a computer program to perform functions of the invention by operating on input data and generating output. Method steps can also be performed by, and apparatus of the techniques can be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit).

Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor will receive instructions and data from a read-only memory or a random access memory or both. The essential elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data. Generally, a computer will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, such as, magnetic, magneto-optical disks, or optical disks. Information carriers suitable for embodying computer program instructions and data include all forms of non-volatile memory, including by way of example semiconductor memory devices, such as, EPROM, EEPROM, and flash memory devices; magnetic disks, such as, internal hard disks or removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The processor and the memory can be supplemented by, or incorporated in special purpose logic circuitry.

A number of implementations of the techniques have been described. Nevertheless, it will be understood that various modifications may be made without departing from the spirit and scope of the claims. For example, useful results still could be achieved if steps of the disclosed techniques were performed in a different order and/or if components in the disclosed systems were combined in a different manner and/or replaced or supplemented by other components. Accordingly, other implementations are within the scope of the following claims.

Claims

1. A computer-readable medium having embodied thereon a computer program having instructions that, when executed, cause a payment system integration component to perform operations comprising:

displaying a graphical user interface operable to receive user input specifying a payment to be made to a payee and a payment method to be used to make the payment, the payment method being one of multiple ways of making the payment using the graphical user interface;

making a determination as to whether the specified payment method involves a third-party on-line payment system;

in response to a determination that the specified payment method involves a third-party on-line payment system, providing a message including payment information to the third-party on-line payment system such that the third-party on-line payment system is able to process the payment to pay the payee; and

in response to a determination that the specified payment method involves a payment system other than a third-party on-line payment system, initiating the specified payment method to pay the payee.

2. The computer-readable medium ofclaim 1 wherein the specified payment method is a bank transfer.

3. The computer-readable medium ofclaim 1 further comprising accessing data representing unpaid invoices associated with the payee.

4. The computer-readable medium ofclaim 3 further comprising displaying the accessed unpaid invoice data within the graphical user interface such that the graphical user interface is operable to receive user input specifying one or more unpaid invoices to pay from among the accessed unpaid invoice data.

5. The computer-readable medium ofclaim 1 wherein the payment information is provided through a file transfer to the third-party on-line payment system.

6. The computer-readable medium ofclaim 1 further comprising providing a notification to a payor system including information associated with processing the payment to the payee system.

7. The computer-readable medium ofclaim 1 further comprising providing a notification to the payee system including information associated with processing the payment to the payee system.

8. The computer-readable medium ofclaim 1 further comprising receiving user input indicating confirmation of the specified payment to be made.

9. The computer-readable medium ofclaim 1 wherein the specified payment includes unpaid invoices associated with the payee.

10. The computer-readable medium ofclaim 1 further comprising initiating a graphical user interface associated with the third-party on-line payment system.

11. A computer-implemented method for making payments to a third-party on-line payment system, the method comprising:

providing, in response to a determination that the specified payment method involves a third-party on-line payment system, a message including payment information to the third-party on-line payment system such that the third-party on-line payment system is able to process the payment to pay the payee; and

initiating, in response to a determination that the specified payment method involves a payment system other than a third-party on-line payment system, the specified payment method to pay the payee.

12. The computer-implemented method ofclaim 11 wherein the specified payment method is a bank transfer.

13. The computer-implemented method ofclaim 11 further comprising accessing data representing unpaid invoices associated with the payee.

14. The computer-implemented method ofclaim 13 further comprising displaying the accessed unpaid invoice data within the graphical user interface such that the graphical user interface is operable to receive user input specifying one or more unpaid invoices to pay from among the accessed unpaid invoice data.

15. The computer-implemented method ofclaim 11 wherein the payment information is provided through a file transfer to the third-party on-line payment system.

16. The computer-implemented method ofclaim 11 further comprising providing a notification to a payor system including information associated with processing the payment to the payee system.

17. The computer-implemented method ofclaim 11 further comprising providing a notification to the payee system including information associated with processing the payment to the payee system.

18. The computer-implemented method ofclaim 11 further comprising receiving user input indicating confirmation of the specified payment to be made.

19. The computer-implemented method ofclaim 11 wherein the specified payment includes unpaid invoices associated with the payee.

20. The computer-implemented method ofclaim 11 further comprising initiating a graphical user interface associated with the third-party on-line payment system.