[0001] This application is related to a first provisional patent application filed with the U.S. patent office under application No. 60/422,640 with filing date Nov. 1, 2002 and a second provisional patent application filed with the U.S. patent office under application No. 60/506,873 with filing date Sep. 30, 2003.
[0002] The present invention relates to an Internet payment system and method.
[0003] 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 the solutions in place are still not turnkey. Following is a list of few problems that are imposed by the current methods:
[0004] a) Credit Card fraud deters users from using their credit card numbers on the web;
[0005] b) High cost of processing deters merchants from setting up eCommerce sites; and
[0006] c) Inability to buy items from multiple merchants with one payment transaction makes the process cumbersome.
[0007] An object of the present invention is to provide an improved Internet payment system and method.
[0008] A payment method and system 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.
[0009] 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.
[0010] 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.
[0011] The system allows consumers to shop online and at the time of checkout select direct payment from an account as the payment option. A bill is automatically displayed and emailed to the customer. The customer 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 customer 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 errors scenarios during the processing of the transaction and notifies customer, merchant or service providers with the necessary error codes and appropriate action that needs to be taken.
[0012] In accordance with an aspect of the present invention there is provided an apparatus for Internet payment comprising: a service layer including a presentation view and a merchant interface; a process layer including business logic and data conversion modules; and a business component layer including user authentication, transaction processing, payment manager, business-to-business interface and sales tools modules.
[0013] In accordance with another aspect of the present invention there is provided an Internet payment method comprising the steps of: creating user and merchant accounts; receiving from a user a selection of web banking as a payment option; creating and sending an electronic bill for the user representing a user account and a merchant account; receiving a transfer of electronic data from a banking institution, in response to a payment request by the user; parsing of electronic data received; updating a database using the parsed data; settling the user account; settling the merchant account; and sending confirmations of payments to both user and merchant.
[0014] The present invention will be further understood from the following detailed description with reference to the drawings in which:
[0015]
[0016]
[0017]
[0018]
[0019]
[0020]
[0021]
[0022]
[0023] Referring to
[0024]
[0025] The service layer
[0026] The process layer
[0027] The business component layer includes a user authentication module
[0028] Referring to
[0029] The modules of the system that interact to process a purchase transaction are shown in
[0030] The Merchant API receives information in an html post, XML or client server secure interface. The information must include the merchant identification and at least one purchase item. Each purchase item must have a positive dollar value attached to it. The transaction must also include all mandatory fields and correct field formats as defined by the Merchant Integration API.
[0031] The general format of the purchase information passed to the IDM system in the HTML post is shown below:
<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”> not to be changed </form>
[0032] The system
[0033] The system
[0034] 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.
[0035] The system
[0036] Referring to
[0037] The system is also capable of receiving bulk purchase information in a batch process. This information is passed through the Merchant Interface
[0038] The modules of the system that interact to process a payment transaction are shown in
[0039] In one embodiment, the payment information is received electronically and is processed by the system. The Payment Interface
[0040] 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.
[0041] The Account Settlement module
[0042] When the amount received equals the amount owing in the customers account all transactions are processed, and marked as Paid.
[0043] When the amount received is larger than the amount owing on the customer account all transactions are credited and their status is changed to Paid. The account balance will reflect the unused.
[0044] When the amount received is less than the total amount owing on all transactions the Account Settlement module processes the transactions starting with the transaction that was purchased first, money is credited to each transaction and marked as Paid. Unpaid transactions retain their status as payment pending. The customer account carries a balance if the were insufficient funds to cover the bill.
[0045] The payment process triggers the Messaging Manager module
[0046] In a second embodiment, the payment information is received by fax and entered into the system manually. The transactions are manually typed into the Debit Manager
[0047] Referring to
[0048] The system includes a module known as the Messaging Manager
[0049] The system call includes parameters such as message type, message format, preconfigured account number and transaction reference number. Based on these parameters the message manager
[0050] The type of messages generated by the messaging manager
[0051] An embodiment of the invention further includes a method of facilitating customers to manage their account funds using the Consumer Wallet
[0052] Using the GUI interface a customer can choose to allocate funds manually or configure the Account Settlement module to allocate money on their behalf using a First in first out (FIFO) system. When the “Allocate Funds Manually” option is enabled, then each time a payment transaction is processed the Messaging Manager sends the customer an email instructing the customer to log on to the system to complete the transaction by allocating the funds appropriately.
[0053] The system includes a module known as the Service Provider Administration Tool
[0054] The Service Provider Administration provides the following functionality:
[0055] 1. View, search, sort, and edit merchant account information belonging to that Service Provider, setup and tear down merchant accounts.
[0056] 2. View, search, sort transaction information generated by their merchants
[0057] 3. View, search, sort customer account information.
[0058] 4. Generate merchant statements
[0059] 5. Reconcile settlement with merchants:
[0060] a. Retrieve records of all payments received for a specified period of time
[0061] b. Flag transaction records as “reimbursed” when payments of funds have been reimbursed to the merchants.
[0062] The system includes a module known as the Merchant Administration Tool
[0063] The Merchant Administration provides the following functionality:
[0064] 1. View, search, sort, and edit customer account information belonging to that Merchant, setup and tear down merchant accounts
[0065] 2. View, search, sort transaction information generated by their customer
[0066] 3. Perform bill adjustments
[0067] 4. View, search, sort customer account information
[0068] 5. Generate customer statements
[0069] 6. Generate and configure message manager
[0070] 7. Reconcile settlement with payees:
[0071] a. Retrieve records of all payments received for a specified period of time
[0072] b. Retrieve records of all payments reimbursed by the payee for a specified period of time.
[0073] In an embodiment of the system 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 the account settlement module to make the required changes to the customer account when billing is affected. The message manager can be automatically or manually invoked to send notification of the change to the customer.
[0074] 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. A coupon contains the customer account and the discount amount that is applied to a purchased or left in the account for future purchases. The interface accepts individual coupons or batch loading of coupons into the system. When a payment is processed the Account Settlement module searches the database for coupons that are linked to the customer account and applies the discount to settle the account balance.
[0075] Referring to
[0076] The system includes a module known as the B2B Interface
[0077] 1 Configuration Module
[0078] 2 Scheduler Module
[0079] 3 Secure Transfer Module
[0080] The configuration module
[0081] The scheduler
[0082] Referring to
[0083] 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.
[0084] Payment processing allows processing by batch or individually of bank payment logs. Payment processing also allows customers 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.
[0085] 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, NMS or instant messaging, generate coupons, and create pre-assigned customer accounts.
[0086] Service Provider tools allows administrators to view, create and maintain merchant and user accounts and settle merchant reimbursements.
[0087] Referring to
[0088] Alternatively, Merchant as payee—The Merchant registers itself as a payment receiver with all major banks. This process is only performed once before IDM is deployed. At the completion of this step any person can visit their banks web page, mobile banking or telebanking and search for the merchant. Once the company information is displayed a user adds the merchant to their bill list
[0089] 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, which limits the client to only pay that particular utility. The system leverages the existing banking infrastructure and improves it by allowing users to pay multiple merchants using one account.
[0090] A method that enables a merchant to be configured on the system is illustrated in
[0091] 2. 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.
[0092] 3. A merchant has two system interface options based on their level of sophistication and size of business:
[0093] a. Use wed banking with IDM Service Provider online order form
[0094] b. Integrate web banking with shopping cart software using the Merchant Integration API,
[0095] 4. The merchant must choose the payee:
[0096] a. The Service provider will be the payee. The customer will make their bill payments to Service Provider, the bank will pay the Service Provider, which will then reimburse the merchants.
[0097] b. The merchant will be the payee. The customers will make their bill payments directly to the merchant and the bank will pay the merchant.
[0098]
[0099] 1. A user visits the merchant website
[0100] 2. The Merchant Integration API allows external parties (customers, suppliers or partners) to use the IDM for processing of payment. The API can be made public and offered as open source or it can be sold for a fee. The API will have calls to the IDM and will serve as a way to hide the inner details of the engine from the outside world.
[0101] 3. Each Transaction must include the merchant identification and at least one purchase item. Each purchase item must have a positive dollar value attached to it. The transaction must also include all mandatory fields and correct field formats as defined in by the Merchant Integration API.
[0102] 4. 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 Test or Live. For re-occurring payment the frequency of the payments must also be passed to the IDM system.
[0103] 5. 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.
[0104] 6. Errors
[0105] 7. The customer is then authenticated as a user of the payment system
[0106] 8. The customer is displayed a confirmation page
[0107] 9. An electronic bill is emailed
[0108] 10. All transaction information
[0109]
[0110] 1. Customers visit their banks online, and pay their bills, using the account number and amount specified in the email
[0111] 2. On a scheduled basis
[0112] Options 1—Automatic: The system receives
[0113] Option 2—Manual: For smaller operations the bank feed can be received via fax and the database manually updated by an authorized administrator. The admin will use the debit manager interface 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.
[0114] 3. Each customer can choose to allocate finds manually or let the account settlement module allocate money on their behalf using a First in first out (FIFO) system.
[0115] 4. If the customer 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 customer is sent an email and is asked to revisit system and complete the transaction by allocating the funds appropriately. When the customer logs into their Wallet, they will see a list of their outstanding transactions and account balance. The customer manually allocates funds to each transaction. Transactions that have been completed successfully are marked as payment complete. The remaining balance is credited to the customers account; outstanding transactions remain as payment pending. The customer can only allocate full payment against any specific transactions, partial payment are not accepted.
[0116] 5. If the customer makes a decision to allocate the funds automatically using FIFO, the Account Settlement module will process the payments daily using the following three scenarios.
[0117] 6. The amount deposited equals the amount owing
[0118] 7. The amount paid is larger than the amount owing on the customer account. In such a case all transactions are credited and their status is changed to payment competed. The remaining funds will remain in the customers account
[0119] 8. 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 customer
[0120] 9. The merchant has the option of sending reminder bills to customers with over due accounts. The bill sent to the customer will reflect the outstanding balance, and interest incurred and a total owing.
[0121] The system also includes a default or configurable “Checkout” button. This graphic and text can be inserted in html webpages, emails or electronic documents to enable buyers to select the direct pay at my bank option. A default button is provided by MODASolutions however this is a configurable option for both The Checkout button is The presentation and the wording on the checkout can be either supplied by MODASolutions or preconfigured by the merchant or provider. The preconfiguration includes presentation and text.
[0122] Service Provider Tools
[0123] Using the Service Provider tool enables Service Providers:
[0124] 1. to view, search, sort, and edit merchant account information, setup and tear down merchants belonging to that Service Provider;
[0125] 2. to view, search sort transaction information generated by their merchants;
[0126] 3. to view search sort customer account information;
[0127] 4. to generate merchant statements; and
[0128] 5. to reconcile settlement with merchants.
[0129] The tools also allow Service Providers to:
[0130] a. Retrieve records of all payments received for a specified period of time;
[0131] b. Flag transaction records as “reimbursed” when payments of funds have been reimbursed to the merchants; and
[0132] c. Generate a merchant statement
[0133] Merchant Tools such as sales closing tools enable merchants to send notifications as follows:
[0134] 1. 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
[0135] 2. Merchant defined notifications—enables merchants to compose and send emails to buyers who completed their payments or people who did not pay yet. These emails are not predefined and are written by the merchant and may include the opportunity for cross-selling or up selling. The system will support text-based emails and formatted based ones.
[0136] 3. 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
[0137] 4. Wireless merchant defined notifications—enables merchants to compose and send SMS or MMS messages to buyers who completed their payments or people who did not pay yet. These emails are not predefined and are written by the merchant and may include the opportunity for cross-selling or up selling.
[0138] 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. Below is a walkthrough of how coupon issuing can work
[0139] 1. Buyer fills a shopping cart, checks out and selects direct payment from bank account.
[0140] 2. Buyer receives eBill by email with the amount specified in the email.
[0141] 3. Merchant uses the couponing tools to issue a $100 discount coupon. The coupon can be issues at the same time the eBill is emailed or sent by the merchant at a later time to motivate the buyer to complete payment.
[0142] 4. Buyer receives coupon and decides to pay. Buyer pays for entire amount less than the $100 coupon
[0143] 5. System processes transaction and matches the transaction with the account and settles the account
[0144] Coupon creation and distribution module enables:
[0145] 1. a coupon to be created via the web manually and sent via email to the buyer;
[0146] 2. a coupon to be created via the web manually and sent via SMS to the buyer;
[0147] 3. a batch of coupons to be uploaded to the system and sent to buyers by email;
[0148] 4. a batch of coupons to be uploaded to the system and sent to buyers by SMS; and
[0149] 5. the merchant to define a credit coupon or a discount coupon.
[0150] Discount coupons can be applied against an outstanding bill. Credit coupons can be applied any time after the coupon is issued.
[0151] A 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 that 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
[0152] Embedded payments in direct marketing campaigns can also be supported by system
[0153] 1. Merchant compiles list of potential prospects
[0154] 2. Merchant sends campaign to list with details of product/service in the body of the email
[0155] 3. System assigns a predefined account number and assigns to the buyer
[0156] 4. Buyer receives email, reads information and then decides to pay
[0157] 5. Buyer uses pre-defined account to pay for merchant's product/service
[0158] 6. Buyer can click on a button that routs to a pre-filled form in which the user reviews information and then confirms a request for an eBill. The user then carries on with the payment process as defined throughout this document.
[0159] 7. Buyer has the opportunity to proceed and pay from their bank account without requesting an eBill.
[0160] Recurring Payments enable 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. Example, merchant can view the admin reports and determine that customer x has completed
[0161] Leasing tools enable merchants to break down the amount of a transaction into multiple smaller amounts. An example of this scenario is as follows:
[0162] 1. Merchant sells $1000 dollars computers
[0163] 2. Buyer wants to buy computer but cannot afford full amount
[0164] 3. Buyer agrees for the merchant's leasing program
[0165] 4. Buyer selects leasing terms
[0166] 5. System sets up transaction as a recurring payment transaction and manage the eBills, the interest on the leasing as well as the conditions and policies in the event of a non-payment.
[0167] Enterprise Deployment the system
[0168] Backend Interfaces:
[0169] 1. enable merchants to pull data from IDM system via a set of interfaces as follows:
[0170] a. XML interface
[0171] b. Proprietary interface
[0172] c. Email
[0173] 2. enable IDM to push the data via a set of tools as follows:
[0174] a. XML interface
[0175] b. Installable software at merchant premise that retrieves data from the system and presents it on the screen.
[0176] 3. A back end interface that include data from IDM containing information deposited in the database and passed to the system through the front end interface. The data includes the following:
[0177] a. Transaction details
[0178] b. Payment status
[0179] c. Sales closing information
[0180] d. Coupon usage information
[0181] 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.
[0182] Wireless adaptation enables merchants to offer web-banking payments for purchases completed from a wireless device.
[0183] 1. The IDM engine can be built using any CGI Web enabled programming language, along with any data storage facilities. For the initial release of the engine JAVA, JSP, xHTML, Oracle are 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.
[0184] 2. 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
[0185] 3. 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.
[0186] 4. 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 messages are sent.
[0187] Referring to
[0188] 1. prepaid credit cards
[0189] 2. prepaid phone cards used for land line/mobile telephony
[0190] 3. prepaid value cards run and owned by the provider of the IDM system
[0191] The following steps highlight the functionality for the system are illustrated in the
[0192] 1. user
[0193] 2. user selects card, and the amount of money to be loaded
[0194] 3. user receives an eBill
[0195] 4. user pays the eBill at their bank account using the pre-assigned account number
[0196] 5. Funds are now allocated in the user's account
[0197] 6. System
[0198] 7. mapping enables prepaid card to be used as desired by the user
[0199] The internet loading can happen in multiple possible configurations:
[0200] 1. The merchant acquirer
[0201] 2. The merchant acquirer
[0202] The IDM system enables the system operator, merchant acquirers, to execute on novel methods to acquire merchants. These methods are detailed as follows:
[0203] 1. inverted value based pricing—merchant is charged on a per transaction value where the discount rate assigned is inverted to the value of the transaction. The higher the value of the transaction the lower the discount rate. For example, if a merchant's average business transaction is $1000 dollars, then the discount rate is 0.5%. If the merchant's average business transaction is $2000, then the discount rate is 0.25%
[0204] 2. flat based pricing—merchant is charged a flat fee per month or on a yearly basis regardless of the volume or value of the transaction. Example a large merchant is charged 100,000 dollars per year for unlimited number of transactions. A small merchant could be charged 5,000 per year for unlimited number of transactions. Different packages can be assembled based on the size, and type of merchant.
[0205] 3. Free internet loading—merchant is not charged for loading stored value cards. The revenue could then be derived from float, and breakage or other supporting revenue streams
[0206] The IDM system enables the system operator to implement different business models by enabling the charging to be configured on a per merchant and per transaction basis. The following parameters can be configured by the merchant acquirer or the system administrator on a per merchant and per transaction basis.
[0207] 1. merchant setup fee
[0208] 2. monthly service charge
[0209] 3. per transaction processing fee
[0210] 4. per transaction discount fee
[0211] Each of these fees can be set to nullified to support different packages.