DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

[0023] Referring to FIG. 1, there is illustrated in a functional block diagram an on-line direct debit payment system in accordance with an embodiment of the present invention.

[0024] FIG. 1 illustrates in a functional block diagram the on-line direct debit payment system in accordance with an embodiment of the present invention. The system 10 includes a Service Layer 12, Process Layer 14 and Business Components Layer 16 that communicate with a database 18.

[0025] The service layer 12 includes a presentation view 20 having a merchant administration module 22, a service provider administration module 24, a consumer wallet 26 and a forms module 28. The service layer 12 also includes a merchant interface 30 having a merchant integration API module 32, a business-to-business (B2B) interface 34. The service layer also includes a payment interface 36.

[0026] The process layer 14 includes business logic and data conversion and shares persistent objects 40 and 42 with the service layer 12 and business component layer 16, respectively. Business logic layer acts as a messenger between the service layer and business component layer. It takes requests from service layer, performs first level validations on inputs, does data conversion on the inputs and passes it on to the business component layer for further validations and data storage functions. This layer takes responses from the business component layer and passes it to the Services layer in the appropriate formats

[0027] The business component layer includes a user authentication module 44, a transaction processing module 46, a payment manager module 48, a B2B interface 50 and a sales tool module 52. The payment manager 48 includes a debit manager module 54, an account settlement module 56, a messaging manager module 58 and a billing manager 60. The B2B interface 50 includes a configuration manager 62, a scheduler 64 and a secure transfer module 66.

[0028] Referring to FIG. 2, there is illustrated the modules of the system of FIG. 1 used to process a purchase transaction;

[0029] The modules of the system that interact to process a purchase transaction are shown in FIG. 2. The modules include the merchant integration API module 32, the user authentication module 44, the transaction processing module 46, the debit manager module 54, the account settlement module 56, and the messaging manager module 58.

[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: 1

[0032] The system 10 is capable of processing single or recurring payment. For recurring payments the frequency of the payments must also be passed to the system. The payment schedule is stored in the database. The billing manager is invoked periodically and searches due bills and sends the information to the messaging manager to prepare and deliver the necessary bills. For single billing, the transaction process invokes the billing manager real-time.

[0033] The system 10 is capable of managing overdue accounts. To enable this feature the information passed must include overdue account information indicating the terms of sales to be applied to overdue accounts. The billing manager 60 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.

[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 10 includes a user Authentication Module 44. Prior to the system committing a sales transaction to the database the customer information is passed to the authentication module 44. The user authentication module 44 is passed the customer information. If the customer is a new user the user authentication module 44 of the system creates an account, the system returns the account and password information for the customer to accept.

[0036] Referring to FIG. 3, there is illustrated the modules of the system of FIG. 1 used to process a payment transaction;

[0037] The system is also capable of receiving bulk purchase information in a batch process. This information is passed through the Merchant Interface 32 to the system via html or xml. The system processes batch purchases the same way it processes individual requests made to the Merchant Interface API.

[0038] The modules of the system that interact to process a payment transaction are shown in FIG. 3 blue. These modules include the merchant administration module 22, the payment interface 36, the process layer 14, the debit manager module 54, the account settlement module 56, the messaging manager module 58 and the database 18.

[0039] In one embodiment, the payment information is received electronically and is processed by the system. The Payment Interface 36 receives payment information in an electronic feed from the banks. The Payment Interface 36 may be configured to receive the files and information in different formats to accommodate different banks. The payment interface 36 parses the information to ensure that it is in the pre-defined bank format. The parsing of the information may be triggered manually through the merchant administration view 22 or scheduled to run at different intervals.

[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 56 processes all valid payment transactions by extracting the data and populating the database 18. The system is capable of managing correct payments, overpayment and underpayment. The transactions are processed as follows:

[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 58 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.

[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 54 by entering the account number and amount received from the bank. The system then processes the transactions the same way it processes the electronic feeds.

[0047] Referring to FIG. 4, there is illustrated the modules of the system of FIG. 1 used to send a message.

[0048] The system includes a module known as the Messaging Manager 58. As shown in FIG. 4 the messaging manager 58 receives system calls from the Merchant Interface 22, Account Settlement module 56 and Billing Scheduler 60 to trigger the sending of a message.

[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 58 queries the database 18 for the content of the message.

[0050] The type of messages generated by the messaging manager 58 are eBill, Payment Reminder, Payment Received, Over Payment, Insufficient Payment, and Coupons, Order Cancellation or Amendment. The content of each of the messages may be system default or composed using the merchant interface and stored in the database. The automatic sending of a message may be suppressed. The messaging manager 58 sends email, SMS and MMS formats.

[0051] An embodiment of the invention further includes a method of facilitating customers to manage their account funds using the Consumer Wallet 26 in an internet browser. The Consumer Wallet 26 queries the database 18 to present a history of transactions, a list of outstanding transactions and the account balance. Available funds can be allocated to unpaid bills and the Account Settlement module 56 updates the database. Bills that have been completed successfully are marked as Paid. The remaining balance is credited to the customers account; outstanding transactions remain as payment pending.

[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 24. The Service Provider admin is an application accessed through an internet browser that allows authorized administrators to view and manage the information stored in the database.

[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 22. The Merchant admin is an application accessed through an internet browser that allows authorized administrators to view and manage the information stored in the database.

[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 FIG. 5, there is illustrated the modules of the system of FIG. 1 used to provide business-to-business transactions.

[0076] The system includes a module known as the B2B Interface 50 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 and HTML or XML interface 34. As shown in FIG. 5 below the B2B Interface includes three components as follows:

[0077] 1 Configuration Module 62

[0078] 2 Scheduler Module 64

[0079] 3 Secure Transfer Module 66

[0080] The configuration module 62 is used to record in the database the batch processing triggers, information to be transmitted, interface destination, output formats and error handling destination.

[0081] The scheduler 64 runs to invoke the secure transfer of the order information on a scheduled basis. The secure transfer module 66 establishes a secure link with the host destination. A file is created and the information is transferred to the host destination.

[0082] Referring to FIG. 6, there is illustrated communication with the system of FIG. 1 for a typical end user purchase.

[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 FIGS. 7a, 7b, 7c, there are illustrated in flow charts set up, purchase and payment processes for the system of FIG. 1 respectively. A method that enables a payee to be configured on the system and setup as a payee at the bank is illustrated in FIG. 7a, 100 as follows: Configure service provider as a payment receiver—IDM Service Provider registers itself as a payment receiver with all major banks. This process is only performed once before the system is deployed. At the completion of this step any person 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.

[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 FIG. 7a, as follows: A merchant that wishes to offer web banking as a payment option for online purchases of goods or services contacts the service provider to receive integration information. Once the registration form is completed the information is setup on the system database and a unique account id and number identifying the merchant is assigned 102.

[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 28

[0094] b. Integrate web banking with shopping cart software using the Merchant Integration API, 104

[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] FIG. 7b, illustrates in a flow chart the purchase process. The method provided enables merchants to accept debit payments for online purchases as follows:

[0099] 1. A user visits the merchant website 110 and selects the goods or services they wish to purchase. Once the user decides to proceed to checkout and selects direct payment from account as the payment option the transaction information is posted 112 to the IDM system via the Merchant Integration API.

[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 114, 116 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.

[0105] 7. The customer is then authenticated as a user of the payment system 118. If the customer is a new user an account is created 120 and the customer is display their account information and password.

[0106] 8. The customer is displayed a confirmation page 122 to accept the purchase order and consent to the web banking payment method.

[0107] 9. An electronic bill is emailed 126 to the customer showing the order details, amount due, due date and instructing them to make payment to the payee using their assigned account number at their own bank.

[0108] 10. All transaction information 124 is tracked in the system database.

[0109] FIG. 7c illustrates in a flow chart the payment process. This method enables merchants to process bank payment notifications as follows:

[0110] 1. Customers visit their banks online, and pay their bills, using the account number and amount specified in the email 130. Note: The first time the user makes an online payment; they must add the payment receiver to the list of vendors in their bill list.

[0111] 2. On a scheduled basis 132, the banks send The payment receiver an electronic feed for the transactions completed.

[0112] Options 1—Automatic: The system receives 134 the files, parses them, extracts the data and populates the system database making the appropriate entries in the customer 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.

[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 136 in the customers account. In such a case all transactions are processed, and marked as payment completed 138.

[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 140 and can be refunded or used at a later time to complete other payments against future transactions.

[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 142.

[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 24 enable service providers to offer the system as a service to their merchant base. The Service Provide tools 24 allow an authorized system administrator to access and maintain information pertaining to their merchants, transactions billing, and merchant reimbursements.

[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 10. 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. The following is a walkthrough of the method:

[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 3 out of 7 payments. The merchant can also have the option to utilized any of the resources available by the system such as notifications and coupons.

[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 10 can be supported as a software license that can be hosted on the web or deployed at the customer 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.

[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 FIG. 8, there is illustrated communication with the system of FIG. 1 for Internet card loading. 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:

[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 FIG. 8:

[0192] 1. user 80 visits merchant site 82 that is selling prepaid cards

[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 10 maps the account number to the prepaid card number

[0198] 7. mapping enables prepaid card to be used as desired by the user 80

[0199] The internet loading can happen in multiple possible configurations:

[0200] 1. The merchant acquirer 82 assigns an account to the consumer 80 and maps the IDM account to the prepaid cards.

[0201] 2. The merchant acquirer 82 configures the system 10 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

[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.