US20160267449A1 - Internet payment system and method - Google Patents

Abstract

A system and method for facilitating payment for online purchases is disclosed. The system allows consumers/customers who shop online to select, at the time of checkout, direct payment from an account as the payment option. An electronic bill (ebill), independent of any confidential financial information pertaining to the consumer, is automatically displayed and emailed to the consumer. The consumer pays the ebill at their bank the same way they pay their utility bill, which then results in a payment confirmation sent from the bank to the payee. Payment information from the bank is sent to the system to update the purchase transactions. Once the payment information is processed, the consumer and merchant accounts are balanced and both receive automatic notification of the payment.

Description

CROSS-REFERENCES TO RELATED APPLICATIONS
• This application is a continuation of U.S. patent application Ser. No. 14/040,314, filed Sep. 27, 2013, and entitled, “INTERNET PAYMENT SYSTEM AND METHOD,” which is a continuation of U.S. patent application Ser. No. 12/016,647, filed Jan. 18, 2008, and entitled, “INTERNET PAYMENT SYSTEM AND METHOD,” which is a continuation-in-part of U.S. patent application Ser. No. 10/697,984, filed on Oct. 31, 2003, and entitled, “INTERNET PAYMENT SYSTEM AND METHOD,” which claims the benefit of and priority to U.S. Provisional Patent Application No. 60/506,873 filed on Sep. 30, 2003, and entitled, “E-PAYMENT INFRASTRUCTURE FOR PROCESSING WEB, TELE OR MOBILE BANKING TRANSACTIONS,” and U.S. Provisional Patent Application No. 60/422,640 filed on Nov. 1, 2002, and entitled, “COMPUTER METHOD WITH A WEB INTERFACE DESIGNED TO ENABLE USERS TO PAY AT THEIR BANKS FOR MULTIPLE TRANSACTIONS TO MULTIPLE ORGANISATIONS USING A SINGLE ACCOUNT.” The entire disclosures of the above applications are hereby incorporated by reference, for all purposes, as if fully set forth herein.
FIELD OF THE INVENTION
• The present invention relates to an Internet payment system and method.
BACKGROUND OF THE INVENTION
• Currently users who have purchased goods and services over the Internet are faced with few payment options. The credit card companies dominate the market, while the users pay high processing fees and shy away from making online payments for trust and security reasons. Digital cash has lower rates than credit card companies, but the adoption has been slow and there are no turnkey solutions still in place.
• Some problems of the current methods include credit card fraud that deters users from using their credit card numbers on the web; high cost of processing that deters merchants from setting up eCommerce sites; and inability to buy items from multiple merchants with one payment transaction that makes the process cumbersome.
SUMMARY OF THE INVENTION
• An object of the present invention is to provide an improved Internet payment system and method.
• A payment method and system are provided using electronic media and in particular the Internet to allow a secure and trusted exchange of money, to broaden the choices of users and allow merchants to receive payment using means other than credit cards and digital cash, to reduce the cost of electronic transactions for both user and merchant and to allow users to make payment for multiple merchants using a single account.
• The Internet Debit Manager (IDM) functions as a payment processing infrastructure that processes online purchases completed by buyers via web banking, telebanking and mobile banking. The present invention supports purchase processing, payment processing, as well as service provider and merchant tools. The system is able to clear and settle funds for both the buyers as well as merchants participating in transactions.
• The system enables secure confidential debit payment for goods and services purchased over the Internet. The system has flexible payment handling and supports payment flow from the bank to the service provider to the merchant or directly from the bank to the merchant.
• The system allows consumers who shop online to select, at the time of checkout, direct payment from an account as the payment option. A bill is automatically displayed and emailed to the consumer. The consumer pays the bill at their bank the same way they pay their utility bill, which then results in a payment confirmation sent from the bank to the payee. Payment information from the bank is sent to the system manually by the service provider administrator using the Debit Manager interface or by running an automated batch process to update the purchase transactions. Once the payment information is processed, the consumer and merchant accounts are balanced and both receive automatic notification of the payment. The system also advises if underpayment or overpayment has been made. The system handles error scenarios during the processing of the transaction and notifies consumer, merchant or service providers with the necessary error codes and appropriate action that needs to be taken.
• In accordance with an aspect of the present invention there is provided a payment processing system for facilitating payment for online purchase transactions comprising: a merchant interface, a messaging manager, a payment interface, an account settlement module, and a database. The merchant interface receives, from an online merchant, purchase transaction information related to an online purchase transaction by a consumer. The purchase transaction information includes merchant and consumer account identification, a transaction description, and a transaction amount related to the online purchase transaction. The purchase transaction information is independent confidential financial information pertaining to the consumer.
• The messaging manager generates an electronic bill based on the received purchase transaction information. The electronic bill includes the transaction description, amount due, payment due date, and payee information to which payment for the online purchase is made at a financial institution trusted by the consumer thereby avoiding disclosure of the consumer's confidential financial information to the online merchant.
• The payment interface receives, from the financial institution, payment information upon payment of the electronic bill by the consumer, and provides, to the online merchant and the consumer, a payment notification. The account settlement module processes parsed payment information and allocates payments to outstanding online purchase transactions. The database stores information pertaining to the online merchant, the consumer, and the electronic bills associated with the online purchase transactions.
• In accordance with another aspect of the present invention there is provided a payment method for online purchase transactions. According to the method, purchase transaction information related to an online purchase transaction by a consumer is received from an online merchant. The purchase transaction information includes online merchant and consumer account identification, a transaction description, and a transaction amount related to the online purchase transaction. The purchase transaction information is independent of confidential financial information pertaining to the consumer.
• An electronic bill based on the received purchase transaction information is generated and provided to the consumer. The electronic bill includes the transaction description, amount due, payment due date, and payee information to which payment for the online purchase is made at a financial institution trusted by the consumer, thereby avoiding disclosure of the consumer's confidential financial information to the online merchant. Payment information is received, from the financial institution, upon payment of the electronic bill by the consumer. Based on parsed payment information, payments are automatically allocated to outstanding online purchase transactions. The payments are routed to outstanding online purchase transactions based on data introspection according to predefined rules. The online merchant and the consumer are provided a payment notification. Information pertaining to the online merchant, the consumer, and the electronic bills associated with the online purchase transactions is stored in a database.
BRIEF DESCRIPTION OF THE DRAWINGS
• The present invention will be further understood from the following detailed description with reference to the drawings in which:
• FIG. 1 illustrates a payment processing system in accordance with an embodiment of the present invention;
• FIGS. 2a, 2b, and 2care flow charts illustrating processes for set up, purchase and payment, respectively, for the system ofFIG. 1 in accordance with an embodiment of the present invention;
• FIG. 3 illustrates a functional block diagram the modules of the system ofFIG. 1 in accordance with an embodiment of the present invention;
• FIG. 4 illustrates, in bold, the modules of the system ofFIG. 1 used to process a purchase transaction in accordance with an embodiment of the present invention;
• FIG. 5 illustrates, in bold, the modules of the system ofFIG. 1 used to process a payment transaction in accordance with an embodiment of the present invention;
• FIG. 6 illustrates, in bold, the modules of the system ofFIG. 1 used to send a message in accordance with an embodiment of the present invention;
• FIG. 7 illustrates, in bold, the modules of the system ofFIG. 1 used to provide business to business transactions in accordance with an embodiment of the present invention; and
• FIG. 8 illustrates an alternate embodiment of the system ofFIG. 1 for Internet card loading.
DETAILED DESCRIPTION OF THE INVENTION
• Generally, the present invention provides a system and method for facilitating payment for online purchases. The system allows consumers/customers who shop online to select, at the time of checkout, direct payment from an account as the payment option. An electronic bill (ebill), independent of any confidential financial information pertaining to the consumer, is automatically displayed and emailed to the consumer. The consumer pays the ebill at their bank the same way they pay their utility bill, which then results in a payment confirmation sent from the bank to the payee. Payment information from the bank is sent to the system to update the purchase transactions. Once the payment information is processed, the consumer and merchant accounts are balanced and both receive automatic notification of the payment.
• Referring toFIG. 1, there is illustrated a payment processing system in accordance with an embodiment of the present invention. The payment processing system orIDM service provider10 facilitates payments for online purchases made by a user orconsumer80 at anonline merchant82. TheIDM service provider10 supports the online transaction during the purchase loop and the payment loop, as shown inFIG. 1 and described below.
• As is typical in an online or e-commerce transaction, aconsumer80 accessesmerchant web sites82 via the Internet. Theconsumer80 selects the goods and services they wish to purchase by filling a shopping cart (step1). Themerchant82 displays a payment web page to theconsumer80 at checkout with one or more payment options, one of which includes the debit payment option according to an embodiment of the present invention. If theconsumer80 selects the debit payment option, themerchant82 sends purchase details of the consumer's order to the IDM service provider10 (step2). TheIDM service provider10 then generates and provides an ebill to theconsumer80 showing, among other information, the order details, amount due, and due date along with instructions to theconsumer80 to make payment to the indicated payee using the payee's assigned account number at afinancial institution84 of the consumer's choice (step3). The ebill is independent of any confidential financial information pertaining to the consumer.
• Upon receipt of the ebill, theconsumer80 completes payment of the ebill at the chosen financial institution84 (step4). Once thefinancial institution84 processes the payment, payment logs or information is sent to the IDM service provider10 (step5). TheIDM service provider10 processes the payment information and provides notification (receipt) of the payment to themerchant82 and the consumer80 (step6). Shipment and fulfillment of the order occurs after receipt of notification of payment by the merchant82 (step7). Themerchant82 receives payment directly from thefinancial institution84 or through the IDM service provider10 (step8).
• The financial institution84 (such as an RPPS—Remote Payment and Presentment Service or ePay) provides an existing infrastructure for payment or electronic funds transfer from a consumer's bank account to the IDM service provider or the online merchant's bank account using an online banking payment system (these accounts could be at the same institution or at different institutions). The financial institution network can be an existing remittance and payment-processing network for registered bill and consumer service providers (e.g., for utility companies).
• FIGS. 2a, 2b, and 2care flow charts illustrating processes for set up, purchase and payment for the system ofFIG. 1 in accordance with an embodiment of the present invention. Anonline merchant82 that wishes to offer web banking as a payment option (debit payment option) for online purchases of goods or services contacts theIDM service provider10 to receive integration information. Once the registration form is completed, the information is setup on the IDM system database (to be described later) along with a unique account id and number identifying themerchant82.
• Prior to the purchase and payment process, theIDM service provider10 and/or theonline merchant82 is set up as a payee with financial institutions, in accordance with an embodiment of the present invention, as shown inFIG. 2a. TheIDM Service Provider10 registers itself as a payment receiver with all major banks84 (step100). Alternatively, an online merchant account is created with theIDM service provider10 and either theIDM service provider10 or theonline merchant82 is registered as a payment receiver (payee) with the financial institutions84 (step102). This process is only performed once before the system is deployed. At the completion of this step any person orconsumer80 can visit their banks web page, mobile banking or telebanking and search for the payee name. Once the company information is displayed a user adds payee to their bill list. Theonline merchant82 integrates their shopping cart (direct payment as check out option) with the IDM service provider10 (step104).
• Currently all transaction processing software components are only capable of processing payments based on one account—one merchant basis. For example, each Utility Company creates an account number for each client or consumer, which limits the client to only pay that particular utility. The system according to the present invention leverages the existing banking infrastructure and improves it by allowing users to pay multiple merchants using one account through the IDM service provider.
• FIG. 2billustrates, in a flow chart, the purchase process in accordance with an embodiment of the present invention. The method provided enables merchants to accept debit payments for online purchases as follows. A user/consumer visits the merchant website and selects the goods or services they wish to purchase (step110). Once the user decides to proceed to checkout and selects direct payment from account as the payment option the transaction information is posted to the IDM service provider system via the Merchant Integration Application Programming Interface API (to be described later) (Step112).
• Each Transaction includes the merchant identification and at least one purchase item. Each purchase item has a positive dollar value attached to it. The transaction also includes all mandatory fields and correct field formats as defined by the Merchant Integration API.
• The information passed may include the payment occurrence indicating whether the transaction is a single payment or re-occurring payment and the type of the transaction, for example, Test or Live. For re-occurring payment the frequency of the payments is also passed to the IDM service provider system.
• The information passed may include overdue account information indicating the terms of sales to be applied to overdue accounts. This information will be applied to any reminder bills generated. For example, a merchant may pass net “30, 1.5%, overdue reminder=yes”. After thirty days if the account remains unpaid an ebill reminder will be sent including the 1.5% interest charges against the transaction.
• The transaction information is checked for errors (step114). Any errors detected are returned to the IDM service provider system or presented to the user (step116). Either the user or the merchant's system administrator must correct the error in order to proceed with the purchase.
• Verification is made as to whether an account exists for the user in the IDM service provider system. The consumer is then authenticated as a user of the payment system (step118). If the consumer is a new user, an account is created and the consumer is provided their account information and password (step120).
• The consumer is displayed a confirmation page to accept the purchase order and consent to the direct (web banking) payment method (step122). A transaction is created in the IDM service provider database and flagged as payment pending (step124). All transaction information is tracked in the IDM service provider system, as discussed later.
• An ebill is emailed to the consumer showing, among others, the order details, amount due, due date and instructing them to make payment to the payee using the payee's assigned account number at their own bank (step126). The process now enters the payment loop (step128) as illustrated in detail inFIG. 2c. As described earlier, the ebill is independent of any confidential financial information pertaining to the consumer.
• FIG. 2c illustrates, in a flow chart, the payment process in accordance with an embodiment of the present invention. This method enables merchants to process bank payment notifications as follows. Consumers visit their banks online (or in person), and pay their bills, using the account number and amount specified in the ebill (step130). The first time the user makes an online payment; they also add the payment receiver to the list of vendors in their bill list. Thus, payment for the online purchase is made at a financial institution trusted by the consumer thereby avoiding disclosure of the consumer's confidential financial information to the online merchant.
• On a scheduled basis, the banks send the payment receiver, i.e., the IDM service provider or the merchant, an electronic feed for the transactions completed (step132). Upon receipt of the payment information, the IDM service provider process the information either automatically or manually.
• For automatic processing, the IDM service provider system receives the payment information files from the banks, parses them, extracts the data and populates the system database making the appropriate entries in the consumer account tables. The process also notifies the user that the payee received a payment and that further action is required on their part if they chose the manual payment processing option to complete the transaction.
• For manual processing, such as for smaller operations, the bank feed can be received via fax and the database manually updated by an authorized administrator. The administrator will use the debit manager interface (to be described later) to enter account number and amount received from the bank. The system will then update the database records. The process also notifies the user that the payee received a payment and that further action is required on their part if they chose the manual payment processing option to complete the transaction.
• Each consumer can choose to allocate funds manually or let the Account Settlement module process the payments in relation to one or more transactions, and route the payment to an order based on a matching algorithm. The matching algorithm performs data introspection according to predefined payment routing rules, for example, based on merchant operating needs. The matching algorithm can include any number of criteria and/or comparisons, on the basis of which the payment can be routed to one or more orders or transactions. Money can then be credited to each matching transaction and marked as Paid. Unpaid transactions retain their status as payment pending. The consumer account carries a balance if the were insufficient funds to cover the bill.
• If the consumer chooses to allocate funds manually, then each time a payment is made at the bank, and the processing is completed by the system as outlined above, the consumer is sent an email and is asked to revisit the system and complete the transaction by allocating the funds appropriately. When the consumer logs into their Wallet (to be described below), they see a list of their outstanding transactions and account balance. The consumer manually allocates funds to each transaction. Transactions that have been completed successfully are marked as payment complete. The remaining balance is credited to the consumer's account; outstanding transactions remain as payment pending. Based on the transaction requirements, the consumer can only allocate full payment against any specific transactions; partial payment may not be accepted.
• The system verifies if sufficient payment has been received (Step136). If the consumer makes a decision to allocate the funds automatically, the Account Settlement module (to be described below) of the system will process the payments. For example, payments can be processed daily using the following three scenarios.
• Scenario 1: The amount deposited equals the amount owing in the consumers account. In such a case all transactions are processed, and marked as payment completed (step138).
• Scenario 2: The amount paid is larger than the amount owing on the consumer account. In such a case all transactions are credited and their status is changed to payment competed. The remaining funds will remain in the consumers account and can be refunded or used at a later time to complete other payments against future transactions (step140).
• Scenario 3: If the money paid is less than the total amount owing on all transactions, then Account Settlement processes the transactions starting with the service that was purchased first, money is credited to each transaction and marked payment completed. Once the system determines that cash on hand is not sufficient to complete a transaction, the process stops. The remaining transactions retain their status as payment pending. The remaining funds stay in the users account. A transaction summary and account status is then emailed to the consumer (step142).
• The merchant has the option of sending reminder bills to consumers with overdue accounts. The bill sent to the consumer may reflect the outstanding balance, and interest incurred and a total owing.
• The IDM system will now be described in further detail with reference toFIG. 3.FIG. 3 illustrates, in a functional block diagram, the on-line direct debit payment system in accordance with an embodiment of the present invention. Thesystem10 includes aService Layer12,Process Layer14 andBusiness Components Layer16 that communicate with adatabase18.
• Theservice layer12 includes apresentation view20 having amerchant administration module22, a serviceprovider administration module24, aconsumer wallet26 and aforms module28. Theservice layer12 also includes amerchant interface30 having a merchantintegration API module32, a service layer business-to-business (B2B)interface34. The service layer also includes apayment interface36.
• Theprocess layer14 includes business logic and data conversion and sharespersistent objects40 and42 with theservice layer12 andbusiness component layer16, respectively. Theprocess layer14 acts as a messenger between theservice layer12 andbusiness component layer16. It takes requests fromservice layer12, performs first level validations on inputs, does data conversion on the inputs and passes it on to thebusiness component layer16 for further validations and data storage functions. Theprocess layer14 takes responses from thebusiness component layer16 and passes it to theservice layer12 in the appropriate formats.
• Thebusiness component layer16 includes auser authentication module44, atransaction processing module46, apayment manager module48, a businesscomponent B2B interface50 and asales tool module52. Thepayment manager48 includes adebit manager module54, anaccount settlement module56, amessaging manager module58 and abilling manager60. The businesscomponent B2B interface50 includes aconfiguration manager62, ascheduler64 and asecure transfer module66.
• Referring toFIG. 4, there is illustrated, in bold, the modules of thesystem10 ofFIG. 3 used to process a purchase transaction in accordance with an embodiment of the present invention.
• The modules of thesystem10 that interact to process a purchase transaction are shown inFIG. 4. The modules include the merchantintegration API module32, theuser authentication module44, thetransaction processing module46, thedebit manager module54, theaccount settlement module56, and themessaging manager module58.
• TheMerchant Integration API32 receives information in an HTML post, XML or client server secure interface. The information includes the merchant identification and at least one purchase item. Each purchase item has a positive dollar value attached to it. The transaction also includes all mandatory fields and correct field formats as defined by theMerchant Integration API32.
• The general format of the purchase information passed to the IDM system in the HTML post is shown below as an example:

• <form action=https://www.modasolutions.com/MODAPay/
  ProcessPayment ” method=“POST”>
  <input type=hidden name=merchant_id value=“MP0001”>
  <input type=hidden name=item_name_1 value=“computer”>
  <input type=hidden name=item_desc_1 value=“DELL Dimension”>
  <input type=hidden name=item_amount_1 value=“1400”>
  <input type=hidden name=item_quantity_1 value=“1”>
  <input type=hidden name=item_name_2 value=“Monitor”>
  <input type=hidden name=item_desc_2
  value=“Samsung 14” LCD”>
  <input type=hidden name=item_amount_2 value=“1400”>
  <input type=hidden name=item_quantity_2 value=“1”>
  <input type=hidden name=item_count value=“2”>
  <input type=hidden name=currency value=“CAD”>
  <input type=hidden name=cmd value=“_mTrans”>
  </form>

• Thesystem10 is capable of processing single or recurring payment. For recurring payments the frequency of the payments is also passed to thesystem10. The payment schedule is stored in thedatabase18. Thebilling manager60 is invoked periodically and searches due bills and sends the information to themessaging manager58 to prepare and deliver the necessary bills to the user orconsumer80. For single billing, the transaction process invokes thebilling manager60 in real-time.
• Thesystem10 is capable of managing overdue accounts. To enable this feature the information passed includes overdue account information indicating the terms of sales to be applied to overdue accounts. Thebilling manager60 applies this information to any reminder bills generated. For example, a merchant may pass net “30, 1.5%, overdue reminder=yes”. After thirty days if the account remains unpaid, an ebill reminder will be sent including the 1.5% interest charges against the transaction.
• System generated errors are returned to the system or presented to the user. Either the user or the merchant's system administrator must correct the error in order to proceed with the purchase.
• Thesystem10 includes a User Authentication orVerification Module44. Prior to thesystem10 committing a sales transaction to thedatabase18, the consumer information is passed to theuser authentication module44. If the consumer is a new user theuser authentication module44 of thesystem10 creates an account, the system returns the account and password information for the consumer to accept.
• The system is also capable of receiving bulk purchase information in a batch process. This information is passed through theMerchant Interface30 to the system via HTML or XML. The system processes batch purchases the same way it processes individual requests made to theMerchant Integration API32.
• Referring toFIG. 5, there is illustrated, in bold, the modules of thesystem10 ofFIG. 3 used to process a payment transaction in accordance with an embodiment of the present invention.
• The modules of the system that interact to process a payment transaction are shown inFIG. 5, in bold. These modules include themerchant administration module22, thepayment interface36, theprocess layer14, thedebit manager module54, theaccount settlement module56, themessaging manager module58 and thedatabase18.
• In one embodiment, the payment information is received electronically and is processed by thesystem10. ThePayment Interface36 receives payment information in an electronic feed from the banks. ThePayment Interface36 may be configured to receive the files and information in different formats to accommodate different banks. Thepayment interface36 parses the information to ensure that it is in the pre-defined bank format. For example, ACH format on the RPPS network. The parsing of the information may be triggered manually through themerchant administration view22 or scheduled to run at different intervals.
• All generated errors are written to a log file. The errors must be corrected in order to proceed with the processing of the payment file.
• TheAccount Settlement module56 processes all valid payment transactions by extracting the data and populating thedatabase18. Theaccount settlement module56 processes parsed payment information and allocates payments to outstanding online purchase transactions. The system is capable of managing correct payments, overpayment and underpayment. The transactions are processed as follows:
• When the amount received equals the amount owing in the consumers account all transactions are processed, and marked as Paid.
• When the amount received is larger than the amount owing on the consumer account all transactions are credited and their status is changed to Paid. The account balance will reflect the unused portion of the amount received.
• When the amount received is less than the total amount owing on all transactions, theAccount Settlement module56 processes the payment in relation to one or more transactions, and routes the payment to an order based on a payment matching algorithm. The payment-matching algorithm includes steps to perform data introspection according to predefined rules defined, such as rules based on merchant operating needs. The matching algorithm can include any number of criteria and/or comparisons, on the basis of which the payment can be routed to one or more orders or transactions. Money can then be credited to each matching transaction and marked as Paid. Unpaid transactions retain their status as payment pending. The consumer account carries a balance if the were insufficient funds to cover the bill.
• The payment process triggers theMessaging Manager module58 to notify the user that a payment has been received, the status of the account and if further action is required on their part to complete the transaction.
• In a second embodiment, the payment information is received by fax and entered into the system manually. The transactions are manually typed into theDebit Manager54 by entering the account number and amount received from the bank. Thesystem10 then processes the transactions the same way it processes the electronic feeds.
• Referring toFIG. 6, there is illustrated, in bold, the modules of thesystem10 ofFIG. 3 used to send a message in accordance with an embodiment of the present invention.
• As shown inFIG. 6 themessaging manager58 receives system calls from theMerchant Interface30,Account Settlement module56 and Billing Scheduler/Manager60 to trigger the sending of a message.
• The system call includes parameters such as message type, message format, preconfigured account number and transaction reference number. Based on these parameters themessage manager58 queries thedatabase18 for the content of the message.
• The type of messages generated by themessaging manager58 are, typically, ebill, Payment Reminder, Payment Received, Over Payment, Insufficient Payment, Coupons, and Order Cancellation or Amendment. The content of each of the messages may be system default or composed using themerchant interface30 and stored in thedatabase18. The automatic sending of a message may be suppressed. Themessaging manager58 sends email, or messages in SMS and MMS formats.
• An embodiment of the invention further includes a method of facilitating consumers to manage their account funds using theConsumer Wallet26 in an Internet browser. TheConsumer Wallet26 queries thedatabase18 to present a history of transactions, a list of outstanding transactions and the account balance. Available funds can be allocated to unpaid bills and theAccount Settlement module56 updates thedatabase18. Bills that have been completed successfully are marked as Paid. The remaining balance is credited to the consumers account; outstanding transactions remain as payment pending.
• Using a GUI interface a consumer can choose to allocate funds manually or configure theAccount Settlement56 module to allocate money on their behalf using a payment matching algorithm, such as First in first out (FIFO) system. When the “Allocate Funds Manually” option is enabled, each time a payment transaction is processed theMessaging Manager58 sends the consumer an email instructing the consumer to log on to the system to complete the transaction by allocating the funds appropriately.
• Thesystem10 includes a module known as the ServiceProvider Administration Tool24.Service Provider Tools24 enable service providers to offer the system as a service to their merchant base. The Service Provider Administration is an application accessed through an Internet browser that allows authorized administrators to view and manage the information pertaining to their merchants, transactions billing, and merchant reimbursements stored in thedatabase18.
• The ServiceProvider Administration Tools24 provide the following functionality: view, search, sort, and edit merchant account information belonging to that service provider; setup and tear down merchant accounts; view, search, sort transaction information generated by their merchants; view, search, sort consumer account information; generate merchant statements; and reconcile settlement with merchants.
• The ServiceProvider Administration Tools24 also allow service providers to retrieve records of all payments received for a specified period of time and to flag transaction records as “reimbursed” when payments of funds have been reimbursed to the merchants.
• Thesystem10 includes a module known as theMerchant Administration Tools22. TheMerchant Administration Tools22 is an application accessed through an Internet browser that allows authorized administrators to view and manage the information stored in thedatabase18.
• TheMerchant Administration Tools22 provide the following functionality: view, search, sort, and edit consumer account information belonging to that merchant; setup and tear down merchant accounts; view, search, sort transaction information generated by their consumer; perform bill adjustments; view, search, sort consumer account information; generate consumer statements; generate and configure message manager; and reconcile settlement with payees.
• TheMerchant Administration Tools22 also allow merchants to retrieve records of all payments received for a specified period of time and to retrieve records of all payments reimbursed by the payee for a specified period of time.
• In addition, Merchant Tools such as sales closing tools enable merchants to send various notifications as follows.
• Systems notifications—enable merchants to select default system generated emails to be sent to buyers. As an example, the merchant can select a “Thank you for buying” email that is sent to consumers who paid directly. Another example is when merchant can send a “reminder to pay” email for those with payment pending status
• Merchant defined notifications—enables merchants to compose and send emails to buyers who completed their payments or people who have not paid yet. These emails are typically not predefined and can be written by the merchant and may include the opportunity for cross-selling or up selling. The system supports text-based emails and formatted based ones.
• Wireless SMS/MMS Systems notifications—enables merchants to select predefined system generated SMS or MMS messages to be sent to buyers on their mobile phones. As an example, the merchant can select a “Thank you for buying” SMS that is sent to consumers who paid directly. Another example is when merchant can send a “reminder to pay” SMS/MMS for those with payment pending status.
• Wireless merchant defined notifications—enables merchants to compose and send SMS or MMS messages to buyers who completed their payments or people who have not paid yet. These emails are typically not predefined and can be written by the merchant and may include the opportunity for cross-selling or up selling.
• In an embodiment of thesystem10, the merchant administration enables merchants to make adjustments to existing bills. The bill adjustment includes bill presentment to the administrator and the functions to perform order cancellations, item cancellation, and item modifications. Adjustments to orders can trigger theaccount settlement module56 to make the required changes to the consumer account when billing is affected. Themessage manager58 can be automatically or manually invoked to send notification of the change to the consumer.
• Another embodiment of the invention includes a system for generating and settling coupons. The system comprises of an interface to create and manage the coupons, a database to store coupon details and the method that enables merchants to send coupons once the ebill has been received by the buyer. The coupon contains the consumer account and the discount amount that is applied to a purchase or left in the account for future purchases. The coupon management interface accepts individual coupons or batch loading of coupons into the system. When a payment is processed theAccount Settlement module56 searches thedatabase18 for coupons that are linked to the consumer account and applies the discount to settle the account balance.
• Coupon issuing enables merchants to send coupons once the buyer has received the ebill. The coupon can include discounts that can be used to reduce payments or a credit that can be left in account for future purchases.
• In an exemplary scenario, below is a walkthrough of how coupon issuing can work. A buyer fills a shopping cart, checks out and selects direct payment from bank account. The buyer then receives an ebill by email with the payment amount specified in the ebill. The merchant uses the couponing tools to issue a $100 discount coupon. The coupon can be issued at the same time the ebill is emailed or sent by the merchant at a later time to motivate the buyer to complete payment. Upon receiving the coupon, the buyer pays for entire amount less than the $100 coupon. The system processes transaction and matches the transaction with the account and settles the account.
• Coupon creation and distribution module enables a coupon to be created via the web manually and sent via email to the buyer; a coupon to be created via the web manually and sent via SMS/MMS to the buyer; a batch of coupons to be uploaded to the system and sent to buyers by email; a batch of coupons to be uploaded to the system and sent to buyers by SMS/MMS; and enables the merchant to define a credit coupon or a discount coupon.
• Discount coupons can be applied against an outstanding bill. Credit coupons can be applied any time after the coupon is issued.
• The Coupon Processing module enables the system to store, track, and process coupons sent to the buyer. The module maps coupon numbers to an account number held by the buyer. The module enables discounts coupons to be matched against outstanding bills. On processing of transactions the number of coupons are matched against the ebill amount. The module enables credit coupons to be added to the buyer's account. The system processes the credit coupons and updates the balance in the buyer's account.
• Yet another embodiment of the system includes enabling merchants to define the payment schedule for recurring payments. The payment schedule can be defined on a weekly, monthly, or quarterly basis. The method enables merchants to track the number of recurring payments completed by the buyer. For example, merchant can view the administrator reports and determine that consumer x has completed 3 out of 7 payments. The merchant can also have the option to utilize any of the resources available by the system such as notifications and coupons.
• Another embodiment of the system includes enabling the merchants to use Leasing Tools to break down the amount of a transaction into multiple smaller amounts. An example of this scenario is as follows: A merchant sells $1000 computers, which a buyer wants to buy but cannot afford the full amount. The buyer agrees for the merchant's leasing program and selects leasing terms. The system sets up transaction as a recurring payment transaction and manages the ebills, the interest on the leasing as well as the conditions and policies in the event of a non-payment.
• Referring toFIG. 7, there is illustrated, in bold, the modules of thesystem10 ofFIG. 3 used to provide business-to-business transactions in accordance with an embodiment of the present invention.
• Thesystem10 includes a module known as the businesscomponent B2B Interface50 that interfaces on the backend with third party applications such as sales order processing and accounting systems residing in the merchants' premises. The order processing information is exported off the system over an HTML or XML servicelayer B2B interface34. As shown inFIG. 7 the business component B2B Interface includes three components viz.,Configuration Module62;Scheduler Module64; and SecureTransfer Module66.
• Theconfiguration module62 is used to record in thedatabase18 the batch processing triggers, information to be transmitted, interface destination, output formats and error handling destination.
• Thescheduler64 runs to invoke the secure transfer of the order information on a scheduled basis. Thesecure transfer module66 establishes a secure link with the host destination. A file is created and the information is transferred to the host destination.
• Referring toFIG. 8, there is illustrated communication with the system ofFIG. 3 for Internet card loading in accordance with an embodiment of the present invention. Internet Card Loading is a method that enables merchants and consumer acquirers to load prepaid value cards using the IDM system. The stored value cards could be one of the following: prepaid credit cards; prepaid phone cards used for land line/mobile telephony; prepaid value cards run and owned by the provider of the IDM system.
• In an exemplary embodiment, as illustrated in theFIG. 8, the following steps highlight the functionality of the Internet Card Loading operation. Auser80visits merchant site82 that is selling prepaid cards. The user selects card, and the amount of money to be loaded and subsequently receives an ebill. The user pays the ebill at their bank account using the pre-assigned account number. The funds are now allocated in the user's account. Thesystem10 maps the account number to the prepaid card number. The mapping enables prepaid card to be used as desired by theuser80.
• The Internet loading can happen in multiple possible configurations. For example, themerchant82 assigns an account to theconsumer80 and maps the IDM account to the prepaid cards. Alternatively, themerchant82 configures thesystem10 to issue accounts that are equivalent to the prepaid cars. Once the account is loaded, there is no need for mapping between multiple accounts to be made.
• In summary, purchase processing supports an API to accept user authentication information and purchase transaction details from a shopping cart or other web application such as an invoicing or event management application. Purchase processing also enables posting of transaction information to the IDM database, and triggers electronic bill delivery and electronic receipt delivery.
• Payment processing allows processing by batch or individually of bank payment logs. Payment processing also allows consumers to allocate funds to purchases as desired when multiple pending payments exist. Processed payments can trigger automatic notification of incomplete payment, over payment and full payment received.
• Merchant tools allow merchants to view, search and sort transactions, manage sales transactions, export data from the IDM system, generate notification and marketing messages over SMS, email, MMS or instant messaging, generate coupons, and create pre-assigned consumer accounts.
• Service Provider Tools allows administrators to view, create and maintain merchant and user accounts and settle merchant reimbursements.
• It is contemplated that each merchant may assign one or more administrators to maintain support of the system and to track and manage transactions. All administrators are given access to a sophisticated reporting and management tool.
• A merchant can have two options for system interface based on their level of sophistication and size of business. The merchant can use web banking with IDM Service Provideronline order form28 or integrate web banking with shopping cart software using the Merchant Integration API, as shown inStep104 ofFIG. 2a.
• The merchant can choose to be the payee or chose the service provider to be the payee. When the merchant is the payee, the consumers will make their bill payments directly to the merchant via their bank and the bank will pay the merchant. When the service provider is chosen to be the payee, the consumer will make their bill payments to service provider via their bank. The bank will pay the Service Provider, which will then reimburse the merchants.
• The system can also include a default or configurable “Checkout” button. This graphic and text can be inserted in HTML web pages, emails or electronic documents to enable buyers to select the direct pay at my bank option. The preconfigured/default option includes presentation and text.
• It is also contemplated that thesystem10 can support embedded payments in direct marketing campaigns. The system enables merchants to preauthorize prospective buyers and send them marketing campaigns that include pre-assigned account numbers that enable the buyer to pay for the items enclosed in the campaign. In an exemplary embodiment, the merchant compiles list of potential prospects and sends campaign to the list with details of product/service in the body of the email. The system assigns a predefined account number to the buyer. The buyer receives email, reads information and then decides to pay using the pre-defined account for merchant's product/service. The Buyer can click on a button that routes to a pre-filled form in which the user reviews information and then confirms a request for an ebill if payment has not been made to the pre-defined account. The user then carries on with the payment process as defined throughout this document. In the alternative, the buyer has the opportunity to proceed and pay from their bank account to the pre-defined account number without requesting an ebill.
• Enterprise Deployment: It is contemplated that thesystem10 can be supported as a software license that can be hosted on the web or deployed at the consumer premise behind a firewall. A software license with installable tools to be deployed on standalone redundant servers and has all the modules to support direct payment from bank account.
• Backend interfaces enable merchants to pull data from the IDM system via a XML interface; Proprietary interface; and Email. The backend interfaces also enable the IDM to push the data via a XML interface or Installable software at merchant premise that retrieves data from the system and presents it on the screen. The data from IDM containing information deposited in the database and passed to the system through the frontend interface includes, among other information, transaction details; payment status; sales closing information; and coupon usage information.
• Another embodiment extends the system to mobile phones, wireless devices, and PDAs that enables the purchase loop and the payment loop to be executed on a mobile device. In the form of an installable software module on a mobile device with menus and functionality that enables buyer to complete purchase and or payment loop on their mobile device and to manage their account status, payments and profiles.
• Wireless adaptation enables merchants to offer web-banking payments for purchases completed from a wireless device.
• The IDM engine can be built using any CGI Web enabled programming language, along with any data storage facilities. For example, JAVA, JSP, xHTML, Oracle can be used to build the engine. There are several classes and database tables required to implement this engine. Also there are shell scripts and EDI used to transfer and extract the data between the banks and IDM.
• The IDM interface is also available for immediate use by clients with access to an IP enabled mobile phones. Since IDM wired interface is written using xHTML the translation to a wireless devise is instantaneous and requires minimal code modifications
• The IDM interface can also be developed to accommodate mobile devices that require a mobile interface. For this purpose IDM can be supported using different technologies such as J2ME Web services, ASP.NET, Python and other technologies.
• The mobile device can use navigation where a user can easily allocate funds using their mobile towards their IDM account. Once the payment is received by the IDM the data is processed in the same manner as before. An email is sent out as well as an SMS message (if client is set up with the service) instructing the client to allocate payments towards the transactions. The Wireless banking module is then invoked from the main menu, where a user is then displayed the balance in their account and a list of transactions that are pending. The user can then select each item and hit the enter button on their phone. Once the button is selected, the appropriate tables are updated and the corresponding emails and SMS/MMS messages are sent.
• Embodiments of the invention can be represented as a software product stored in a machine-readable medium (also referred to as a computer-readable medium, a processor-readable medium, or a computer usable medium having a computer-readable program code embodied therein). The machine-readable medium can be any suitable tangible medium, including magnetic, optical, or electrical storage medium including a diskette, compact disk read only memory (CD-ROM), memory device (volatile or non-volatile), or similar storage mechanism. The machine-readable medium can contain various sets of instructions, code sequences, configuration information, or other data, which, when executed, cause a processor to perform steps in a method according to an embodiment of the invention. Those of ordinary skill in the art will appreciate that other instructions and operations necessary to implement the described invention can also be stored on the machine-readable medium. Software running from the machine-readable medium can interface with circuitry to perform the described tasks.
• The above-described embodiments of the invention are intended to be examples only. Alterations, modifications and variations can be effected to the particular embodiments by those of skill in the art without departing from the scope of the invention, which is defined solely by the claims appended hereto.

Claims (21)

1. (canceled)

2. A system for conducting a transaction between a first party and a second party using a payment processing system, comprising:

a payment processing system configured to:

receive, from a first party, transaction information related to a transaction with a second party, the transaction information including:

identification of the second party;

payment processing system account identification for the first party; and

a transaction amount;

send an invoice for the transaction based on the transaction information received, the invoice including:

the transaction amount; and

payee information specifying the payment processing system or the first party as a payee for the transaction;

cause the invoice for the online transaction to be displayed to the second party;

receive, from the financial institution, payment information indicating the second party has directed payment the invoice in favor of the payee;

record that a payment for the transaction amount from the second party to the first party has occurred; and

cause, after recordation of the payment, a list of pending transactions to be displayed to the first party or the second party.

3. The system for conducting a transaction between a first party and a second party using a payment processing system ofclaim 2, wherein the payment processing system is further configured to:

create payment processing system account identification for the second party prior to sending the invoice for the transaction.

4. The system for conducting a transaction between a first party and a second party using a payment processing system ofclaim 2, wherein the transaction information further includes:

identification of a currency type of the transaction amount.

5. The system for conducting a transaction between a first party and a second party using a payment processing system ofclaim 4, wherein the invoice further includes:

identification of the currency type of the transaction amount.

6. The system for conducting a transaction between a first party and a second party using a payment processing system ofclaim 2, wherein:

the transaction information is independent of confidential financial information pertaining to the first party.

7. The system for conducting a transaction between a first party and a second party using a payment processing system ofclaim 2, wherein:

the payment information is independent of confidential financial information pertaining to the second party.

8. The system for conducting a transaction between a first party and a second party using a payment processing system ofclaim 2, wherein the payment processing system is further configured to:

allocate the payment to the invoice only after the payment is allocated to any historical invoices which predate the invoice.

9. A method for conducting a transaction between a first party and a second party using a payment processing system, comprising:

receiving, at the payment processing system from a first party, transaction information related to a transaction with a second party, the transaction information including:

identification of the second party;

payment processing system account identification for the first party; and

a transaction amount;

sending, from the payment processing system to the second party, an invoice for the transaction based on the transaction information previously received, the invoice including:

the transaction amount; and

payee information specifying the payment processing system or the first party as a payee for the transaction;

receiving, at the payment processing system from the financial institution, payment information indicating the second party has directed payment of the invoice in favor of the payee;

recording, with the payment processing system, that a payment for the transaction amount from the second party to the first party has occurred; and

causing, with the payment processing system, after recordation of the payment, a list of pending transactions to be displayed to the first party or the second party.

10. The method for conducting a transaction between a first party and a second party using a payment processing system ofclaim 9, further comprising:

creating payment processing system account identification for the second party prior to sending the invoice for the transaction.

11. The method for conducting a transaction between a first party and a second party using a payment processing system ofclaim 9, wherein the transaction information further includes:

identification of a currency type of the transaction amount.

12. The method for conducting a transaction between a first party and a second party using a payment processing system ofclaim 11, wherein the invoice further includes:

identification of the currency type of the transaction amount.

13. The method for conducting a transaction between a first party and a second party using a payment processing system ofclaim 9, wherein:

the transaction information is independent of confidential financial information pertaining to the first party.

14. The method for conducting a transaction between a first party and a second party using a payment processing system ofclaim 9, wherein:

the payment information is independent of confidential financial information pertaining to the second party.

15. The method for conducting a transaction between a first party and a second party using a payment processing system ofclaim 9, further comprising:

allocating the payment to the invoice only after the payment is allocated to any historical invoices which predate the invoice.

16. A non-transitory computer readable medium having instructions stored thereon for conducting a transaction between a first party and a second party, wherein the instructions are executable by one or more processors to at least:

receive, from a first party, transaction information related to a transaction with a second party, the transaction information including:

identification of the second party;

payment processing system account identification for the first party; and

a transaction amount;

send, to the second party, an invoice for the transaction based on the transaction information previously received, the invoice including:

the transaction amount; and

payee information specifying the payment processing system or the first party as a payee for the transaction;

receive, from the financial institution, payment information indicating the second party has directed payment of the invoice in favor of the payee;

record that a payment for the transaction amount from the second party to the first party has occurred; and

cause, after recordation of the payment, a list of pending transactions to be displayed to the first party or the second party.

17. The non-transitory computer readable medium having instructions stored thereon for conducting a transaction between a first party and a second party ofclaim 16, wherein the instructions are further executable by one or more processors to also:

create payment processing system account identification for the second party prior to sending the invoice for the transaction.

18. The non-transitory computer readable medium having instructions stored thereon for conducting a transaction between a first party and a second party ofclaim 16, wherein the transaction information further includes:

identification of a currency type of the transaction amount.

19. The non-transitory computer readable medium having instructions stored thereon for conducting a transaction between a first party and a second party ofclaim 18, wherein the invoice further includes:

identification of the currency type of the transaction amount.

20. The non-transitory computer readable medium having instructions stored thereon for conducting a transaction between a first party and a second party ofclaim 16, wherein:

the transaction information is independent of confidential financial information pertaining to the first party.

21. The non-transitory computer readable medium having instructions stored thereon for conducting a transaction between a first party and a second party ofclaim 16, wherein:

the payment information is independent of confidential financial information pertaining to the second party.

Images