US20080114657A1 - Internet payment system and method - Google Patents
Internet payment system and method Download PDFInfo
- Publication number
- US20080114657A1 US20080114657A1 US12/016,647 US1664708A US2008114657A1 US 20080114657 A1 US20080114657 A1 US 20080114657A1 US 1664708 A US1664708 A US 1664708A US 2008114657 A1 US2008114657 A1 US 2008114657A1
- Authority
- US
- United States
- Prior art keywords
- payment
- consumer
- online
- merchant
- information
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
- G06Q20/102—Bill distribution or payments
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/22—Payment schemes or models
- G06Q20/26—Debit schemes, e.g. "pay now"
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/02—Marketing; Price estimation or determination; Fundraising
- G06Q30/0207—Discounts or incentives, e.g. coupons or rebates
- G06Q30/0222—During e-commerce, i.e. online transactions
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/02—Marketing; Price estimation or determination; Fundraising
- G06Q30/0207—Discounts or incentives, e.g. coupons or rebates
- G06Q30/0236—Incentive or reward received by requiring registration or ID from user
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/02—Marketing; Price estimation or determination; Fundraising
- G06Q30/0207—Discounts or incentives, e.g. coupons or rebates
- G06Q30/0239—Online discounts or incentives
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/04—Billing or invoicing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/06—Buying, selling or leasing transactions
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/06—Buying, selling or leasing transactions
- G06Q30/0601—Electronic shopping [e-shopping]
- G06Q30/0633—Lists, e.g. purchase orders, compilation or processing
- G06Q30/0635—Processing of requisition or of purchase orders
Definitions
- the present invention relates to an Internet payment system and method.
- 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.
- 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 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.
- 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.
- 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.
- FIG. 1 illustrates a payment processing system in accordance with an embodiment of the present invention
- FIGS. 2 a , 2 b , and 2 c are flow charts illustrating processes for set up, purchase and payment, respectively, for the system of FIG. 1 in accordance with an embodiment of the present invention
- FIG. 3 illustrates a functional block diagram the modules of the system of FIG. 1 in accordance with an embodiment of the present invention
- FIG. 4 illustrates, in bold, the modules of the system of FIG. 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 of FIG. 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 of FIG. 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 of FIG. 1 used to provide business to business transactions in accordance with an embodiment of the present invention.
- FIG. 8 illustrates an alternate embodiment of the system of FIG. 1 for Internet card loading.
- 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.
- the payment processing system or IDM service provider 10 facilitates payments for online purchases made by a user or consumer 80 at an online merchant 82 .
- the IDM service provider 10 supports the online transaction during the purchase loop and the payment loop, as shown in FIG. 1 and described below.
- a consumer 80 accesses merchant web sites 82 via the Internet.
- the consumer 80 selects the goods and services they wish to purchase by filling a shopping cart (step 1 ).
- the merchant 82 displays a payment web page to the consumer 80 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 the consumer 80 selects the debit payment option, the merchant 82 sends purchase details of the consumer's order to the IDM service provider 10 (step 2 ).
- the IDM service provider 10 then generates and provides an ebill to the consumer 80 showing, among other information, the order details, amount due, and due date along with instructions to the consumer 80 to make payment to the indicated payee using the payee's assigned account number at a financial institution 84 of the consumer's choice (step 3 ).
- the ebill is independent of any confidential financial information pertaining to the consumer.
- the consumer 80 Upon receipt of the ebill, the consumer 80 completes payment of the ebill at the chosen financial institution 84 (step 4 ). Once the financial institution 84 processes the payment, payment logs or information is sent to the IDM service provider 10 (step 5 ). The IDM service provider 10 processes the payment information and provides notification (receipt) of the payment to the merchant 82 and the consumer 80 (step 6 ). Shipment and fulfillment of the order occurs after receipt of notification of payment by the merchant 82 (step 7 ). The merchant 82 receives payment directly from the financial institution 84 or through the IDM service provider 10 (step 8 ).
- the financial institution 84 (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. 2 a , 2 b , and 2 c are flow charts illustrating processes for set up, purchase and payment for the system of FIG. 1 in accordance with an embodiment of the present invention.
- An online merchant 82 that wishes to offer web banking as a payment option (debit payment option) for online purchases of goods or services contacts the IDM service provider 10 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 the merchant 82 .
- the IDM service provider 10 and/or the online merchant 82 is set up as a payee with financial institutions, in accordance with an embodiment of the present invention, as shown in FIG. 2 a .
- the IDM Service Provider 10 registers itself as a payment receiver with all major banks 84 (step 100 ).
- an online merchant account is created with the IDM service provider 10 and either the IDM service provider 10 or the online merchant 82 is registered as a payment receiver (payee) with the financial institutions 84 (step 102 ).
- This process is only performed once before the system is deployed.
- any person or consumer 80 can visit their banks web page, mobile banking or telebanking and search for the payee name.
- the online merchant 82 integrates their shopping cart (direct payment as check out option) with the IDM service provider 10 (step 104 ).
- 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. 2 b illustrates, 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 (step 110 ).
- 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) (Step 112 ).
- 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.
- the frequency of the payments is also passed to the IDM service provider system.
- the transaction information is checked for errors (step 114 ). Any errors detected are returned to the IDM service provider system or presented to the user (step 116 ). 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 (step 118 ). If the consumer is a new user, an account is created and the consumer is provided their account information and password (step 120 ).
- the consumer is displayed a confirmation page to accept the purchase order and consent to the direct (web banking) payment method (step 122 ).
- a transaction is created in the IDM service provider database and flagged as payment pending (step 124 ). 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 (step 126 ).
- the process now enters the payment loop (step 128 ) as illustrated in detail in FIG. 2 c .
- the ebill is independent of any confidential financial information pertaining to the consumer.
- FIG. 2 c 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 (step 130 ). 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.
- the banks send the payment receiver, i.e., the IDM service provider or the merchant, an electronic feed for the transactions completed (step 132 ).
- the IDM service provider process the information either automatically or manually.
- 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.
- 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.
- 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.
- 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 (Step 136 ). 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 (step 138 ).
- 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 (step 140 ).
- 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 (step 142 ).
- the merchant has the option of sending reminder bills to consumers with over due accounts.
- the bill sent to the consumer may reflect the outstanding balance, and interest incurred and a total owing.
- FIG. 3 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 .
- 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 service layer business-to-business (B2B) interface 34 .
- the service layer also includes a payment interface 36 .
- 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.
- the process layer 14 acts as a messenger between the service layer 12 and business component layer 16 . It takes requests from service layer 12 , performs first level validations on inputs, does data conversion on the inputs and passes it on to the business component layer 16 for further validations and data storage functions.
- the process layer 14 takes responses from the business component layer 16 and passes it to the service layer 12 in the appropriate formats.
- the business component layer 16 includes a user authentication module 44 , a transaction processing module 46 , a payment manager module 48 , a business component 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 business component B2B interface 50 includes a configuration manager 62 , a scheduler 64 and a secure transfer module 66 .
- FIG. 4 there is illustrated, in bold, the modules of the system 10 of FIG. 3 used to process a purchase transaction in accordance with an embodiment of the present invention.
- the modules of the system 10 that interact to process a purchase transaction are shown in FIG. 4 .
- 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 .
- the Merchant Integration API 32 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 the Merchant Integration API 32 .
- the system 10 is capable of processing single or recurring payment. For recurring payments the frequency of the payments is also passed to the system 10 .
- the payment schedule is stored in the database 18 .
- the billing manager 60 is invoked periodically and searches due bills and sends the information to the messaging manager 58 to prepare and deliver the necessary bills to the user or consumer 80 .
- the transaction process invokes the billing manager 60 in real-time.
- the system 10 is capable of managing overdue accounts.
- the information passed includes overdue account information indicating the terms of sales to be applied to overdue accounts.
- 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.
- the system 10 includes a User Authentication or Verification Module 44 . Prior to the system 10 committing a sales transaction to the database 18 , the consumer information is passed to the user authentication module 44 . If the consumer is a new user the user authentication module 44 of the system 10 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 the Merchant Interface 30 to the system via HTML or XML. The system processes batch purchases the same way it processes individual requests made to the Merchant Integration API 32 .
- FIG. 5 there is illustrated, in bold, the modules of the system 10 of FIG. 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 in FIG. 5 , in bold. 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 .
- the payment information is received electronically and is processed by the system 10 .
- 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. For example, ACH format on the RPPS network. The parsing of the information may be triggered manually through the merchant administration view 22 or scheduled to run at different intervals.
- the Account Settlement module 56 processes all valid payment transactions by extracting the data and populating the database 18 .
- the account settlement module 56 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:
- the Account Settlement module 56 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 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.
- 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 10 then processes the transactions the same way it processes the electronic feeds.
- FIG. 6 there is illustrated, in bold, the modules of the system 10 of FIG. 3 used to send a message in accordance with an embodiment of the present invention.
- the messaging manager 58 receives system calls from the Merchant Interface 30 , Account Settlement module 56 and Billing Scheduler/Manager 60 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 the message manager 58 queries the database 18 for the content of the message.
- the type of messages generated by the messaging manager 58 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 the merchant interface 30 and stored in the database 18 .
- the automatic sending of a message may be suppressed.
- the messaging manager 58 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 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 18 . 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.
- a consumer can choose to allocate funds manually or configure the Account Settlement 56 module to allocate money on their behalf using a payment matching algorithm, such as First in first out (FIFO) system.
- a payment matching algorithm such as First in first out (FIFO) system.
- FIFO First in first out
- the Messaging Manager 58 sends the consumer an email instructing the consumer to log on to the system to complete the transaction by allocating the funds appropriately.
- the system 10 includes a module known as the Service Provider Administration Tool 24 .
- Service Provider Tools 24 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 the database 18 .
- the Service Provider Administration Tools 24 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 Service Provider Administration Tools 24 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.
- the system 10 includes a module known as the Merchant Administration Tools 22 .
- the Merchant Administration Tools 22 is an application accessed through an Internet browser that allows authorized administrators to view and manage the information stored in the database 18 .
- the Merchant Administration Tools 22 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.
- the Merchant Administration Tools 22 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.
- Merchant Tools such as sales closing tools enable merchants to send various notifications as follows.
- 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.
- 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 56 to make the required changes to the consumer account when billing is affected.
- the message manager 58 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.
- the Account Settlement module 56 searches the database 18 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.
- 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.
- 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.
- FIG. 7 there is illustrated, in bold, the modules of the system 10 of FIG. 3 used to provide business-to-business transactions in accordance with an embodiment of the present invention.
- the system 10 includes a module known as the business component 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 an HTML or XML service layer B2B interface 34 .
- the business component B2B Interface includes three components viz., Configuration Module 62 ; Scheduler Module 64 ; and Secure Transfer Module 66 .
- the configuration module 62 is used to record in the database 18 the batch processing triggers, information to be transmitted, interface destination, output formats and error handling destination.
- 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.
- 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.
- the following steps highlight the functionality of the Internet Card Loading operation.
- a user 80 visits merchant site 82 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.
- the system 10 maps the account number to the prepaid card number. The mapping enables prepaid card to be used as desired by the user 80 .
- the Internet loading can happen in multiple possible configurations. For example, the merchant 82 assigns an account to the consumer 80 and maps the IDM account to the prepaid cards. Alternatively, the merchant 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.
- 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.
- 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 Provider online order form 28 or integrate web banking with shopping cart software using the Merchant Integration API, as shown in Step 104 of FIG. 2 a.
- the merchant can choose to be the payee or chose the service provider to be the payee.
- the merchant 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.
- 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.
- the system 10 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.
- 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.
- the buyer has the opportunity to proceed and pay from their bank account to the pre-defined account number without requesting an ebill.
- system 10 can be supported as a software license that can be hosted on the web or deployed at the consumer premise behind a firewall.
- 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.
- 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.
- JAVA, JSP, xHTML, Oracle can be used to build the engine.
- 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.
- 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.
- 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.
Abstract
Description
- This application is continuation-in-part of U.S. patent application Ser. No. 10/697,984, filed on Oct. 31, 2003, which is related to U.S. Provisional Patent Application No. 60/422,640 filed on Nov. 1, 2002 and U.S. Provisional Patent Application No. 60/506,873 filed on Sep. 30, 2003.
- The present invention relates to an Internet payment system and method.
- 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.
- 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.
- 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. 2 a, 2 b, and 2 c are 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. - 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 to
FIG. 1 , there is illustrated a payment processing system in accordance with an embodiment of the present invention. The payment processing system orIDM service provider 10 facilitates payments for online purchases made by a user orconsumer 80 at anonline merchant 82. The IDMservice provider 10 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, a
consumer 80 accessesmerchant web sites 82 via the Internet. Theconsumer 80 selects the goods and services they wish to purchase by filling a shopping cart (step 1). Themerchant 82 displays a payment web page to theconsumer 80 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 theconsumer 80 selects the debit payment option, themerchant 82 sends purchase details of the consumer's order to the IDM service provider 10 (step 2). TheIDM service provider 10 then generates and provides an ebill to theconsumer 80 showing, among other information, the order details, amount due, and due date along with instructions to theconsumer 80 to make payment to the indicated payee using the payee's assigned account number at afinancial institution 84 of the consumer's choice (step 3). The ebill is independent of any confidential financial information pertaining to the consumer. - Upon receipt of the ebill, the
consumer 80 completes payment of the ebill at the chosen financial institution 84 (step 4). Once thefinancial institution 84 processes the payment, payment logs or information is sent to the IDM service provider 10 (step 5). TheIDM service provider 10 processes the payment information and provides notification (receipt) of the payment to themerchant 82 and the consumer 80 (step 6). Shipment and fulfillment of the order occurs after receipt of notification of payment by the merchant 82 (step 7). Themerchant 82 receives payment directly from thefinancial institution 84 or through the IDM service provider 10 (step 8). - The financial institution 84 (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. 2 a, 2 b, and 2 c are 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 merchant 82 that wishes to offer web banking as a payment option (debit payment option) for online purchases of goods or services contacts theIDM service provider 10 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 themerchant 82. - Prior to the purchase and payment process, the
IDM service provider 10 and/or theonline merchant 82 is set up as a payee with financial institutions, in accordance with an embodiment of the present invention, as shown inFIG. 2 a. TheIDM Service Provider 10 registers itself as a payment receiver with all major banks 84 (step 100). Alternatively, an online merchant account is created with theIDM service provider 10 and either theIDM service provider 10 or theonline merchant 82 is registered as a payment receiver (payee) with the financial institutions 84 (step 102). This process is only performed once before the system is deployed. At the completion of this step any person orconsumer 80 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 merchant 82 integrates their shopping cart (direct payment as check out option) with the IDM service provider 10 (step 104). - 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. 2 b illustrates, 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 (step 110). 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) (Step 112). - 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 (step 114). Any errors detected are returned to the IDM service provider system or presented to the user (step 116). 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 (step 118). If the consumer is a new user, an account is created and the consumer is provided their account information and password (step 120).
- The consumer is displayed a confirmation page to accept the purchase order and consent to the direct (web banking) payment method (step 122). A transaction is created in the IDM service provider database and flagged as payment pending (step 124). 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 (step 126). The process now enters the payment loop (step 128) as illustrated in detail in
FIG. 2 c. As described earlier, the ebill is independent of any confidential financial information pertaining to the consumer. -
FIG. 2 c 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 (step 130). 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 (step 132). 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 (Step 136). 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 (step 138).
- 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 (step 140).
- 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 (step 142).
- The merchant has the option of sending reminder bills to consumers with over due 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 to
FIG. 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. Thesystem 10 includes aService Layer 12,Process Layer 14 andBusiness Components Layer 16 that communicate with adatabase 18. - The
service layer 12 includes apresentation view 20 having amerchant administration module 22, a serviceprovider administration module 24, aconsumer wallet 26 and aforms module 28. Theservice layer 12 also includes amerchant interface 30 having a merchantintegration API module 32, a service layer business-to-business (B2B)interface 34. The service layer also includes apayment interface 36. - The
process layer 14 includes business logic and data conversion and sharespersistent objects service layer 12 andbusiness component layer 16, respectively. Theprocess layer 14 acts as a messenger between theservice layer 12 andbusiness component layer 16. It takes requests fromservice layer 12, performs first level validations on inputs, does data conversion on the inputs and passes it on to thebusiness component layer 16 for further validations and data storage functions. Theprocess layer 14 takes responses from thebusiness component layer 16 and passes it to theservice layer 12 in the appropriate formats. - The
business component layer 16 includes auser authentication module 44, atransaction processing module 46, apayment manager module 48, a businesscomponent B2B interface 50 and asales tool module 52. Thepayment manager 48 includes adebit manager module 54, anaccount settlement module 56, amessaging manager module 58 and abilling manager 60. The businesscomponent B2B interface 50 includes aconfiguration manager 62, ascheduler 64 and asecure transfer module 66. - Referring to
FIG. 4 , there is illustrated, in bold, the modules of thesystem 10 ofFIG. 3 used to process a purchase transaction in accordance with an embodiment of the present invention. - The modules of the
system 10 that interact to process a purchase transaction are shown inFIG. 4 . The modules include the merchantintegration API module 32, theuser authentication module 44, thetransaction processing module 46, thedebit manager module 54, theaccount settlement module 56, and themessaging manager module 58. - The
Merchant Integration API 32 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 API 32. - 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> - The
system 10 is capable of processing single or recurring payment. For recurring payments the frequency of the payments is also passed to thesystem 10. The payment schedule is stored in thedatabase 18. Thebilling manager 60 is invoked periodically and searches due bills and sends the information to themessaging manager 58 to prepare and deliver the necessary bills to the user orconsumer 80. For single billing, the transaction process invokes thebilling manager 60 in real-time. - The
system 10 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 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. - 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.
- The
system 10 includes a User Authentication orVerification Module 44. Prior to thesystem 10 committing a sales transaction to thedatabase 18, the consumer information is passed to theuser authentication module 44. If the consumer is a new user theuser authentication module 44 of thesystem 10 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 the
Merchant Interface 30 to the system via HTML or XML. The system processes batch purchases the same way it processes individual requests made to theMerchant Integration API 32. - Referring to
FIG. 5 , there is illustrated, in bold, the modules of thesystem 10 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 in
FIG. 5 , in bold. These modules include themerchant administration module 22, thepayment interface 36, theprocess layer 14, thedebit manager module 54, theaccount settlement module 56, themessaging manager module 58 and thedatabase 18. - In one embodiment, the payment information is received electronically and is processed by the
system 10. ThePayment Interface 36 receives payment information in an electronic feed from the banks. ThePayment Interface 36 may be configured to receive the files and information in different formats to accommodate different banks. Thepayment interface 36 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 view 22 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.
- The
Account Settlement module 56 processes all valid payment transactions by extracting the data and populating thedatabase 18. Theaccount settlement module 56 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, the
Account Settlement module 56 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 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. - 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. Thesystem 10 then processes the transactions the same way it processes the electronic feeds. - Referring to
FIG. 6 , there is illustrated, in bold, the modules of thesystem 10 ofFIG. 3 used to send a message in accordance with an embodiment of the present invention. - As shown in
FIG. 6 themessaging manager 58 receives system calls from theMerchant Interface 30,Account Settlement module 56 and Billing Scheduler/Manager 60 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 the
message manager 58 queries thedatabase 18 for the content of the message. - The type of messages generated by the
messaging manager 58 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 interface 30 and stored in thedatabase 18. The automatic sending of a message may be suppressed. Themessaging manager 58 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 the
Consumer Wallet 26 in an Internet browser. TheConsumer Wallet 26 queries thedatabase 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 theAccount Settlement module 56 updates thedatabase 18. 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 the
Account Settlement 56 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 Manager 58 sends the consumer an email instructing the consumer to log on to the system to complete the transaction by allocating the funds appropriately. - The
system 10 includes a module known as the ServiceProvider Administration Tool 24.Service Provider Tools 24 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 thedatabase 18. - The Service
Provider Administration Tools 24 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 Service
Provider Administration Tools 24 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. - The
system 10 includes a module known as theMerchant Administration Tools 22. TheMerchant Administration Tools 22 is an application accessed through an Internet browser that allows authorized administrators to view and manage the information stored in thedatabase 18. - The
Merchant Administration Tools 22 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. - The
Merchant Administration Tools 22 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 the
system 10, 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 module 56 to make the required changes to the consumer account when billing is affected. Themessage manager 58 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 the
Account Settlement module 56 searches thedatabase 18 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 to
FIG. 7 , there is illustrated, in bold, the modules of thesystem 10 ofFIG. 3 used to provide business-to-business transactions in accordance with an embodiment of the present invention. - The
system 10 includes a module known as the businesscomponent 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 an HTML or XML servicelayer B2B interface 34. As shown inFIG. 7 the business component B2B Interface includes three components viz.,Configuration Module 62;Scheduler Module 64; and SecureTransfer Module 66. - The
configuration module 62 is used to record in thedatabase 18 the batch processing triggers, information to be transmitted, interface destination, output formats and error handling destination. - The
scheduler 64 runs to invoke the secure transfer of the order information on a scheduled basis. Thesecure transfer module 66 establishes a secure link with the host destination. A file is created and the information is transferred to the host destination. - Referring to
FIG. 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 the
FIG. 8 , the following steps highlight the functionality of the Internet Card Loading operation. Auser 80visits merchant site 82 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. Thesystem 10 maps the account number to the prepaid card number. The mapping enables prepaid card to be used as desired by theuser 80. - The Internet loading can happen in multiple possible configurations. For example, the
merchant 82 assigns an account to theconsumer 80 and maps the IDM account to the prepaid cards. Alternatively, themerchant 82 configures thesystem 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. - 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 Provider
online order form 28 or integrate web banking with shopping cart software using the Merchant Integration API, as shown inStep 104 ofFIG. 2 a. - 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 the
system 10 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 the
system 10 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 (28)
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US12/016,647 US8566237B2 (en) | 2002-11-01 | 2008-01-18 | Internet payment system and method |
US14/040,314 US9275410B2 (en) | 2002-11-01 | 2013-09-27 | Internet payment system and method |
US15/006,399 US20160267449A1 (en) | 2002-11-01 | 2016-01-26 | Internet payment system and method |
Applications Claiming Priority (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US42264002P | 2002-11-01 | 2002-11-01 | |
US50687303P | 2003-09-30 | 2003-09-30 | |
US10/697,984 US20040139016A1 (en) | 2002-11-01 | 2003-10-31 | Internet payment systerm and method |
US12/016,647 US8566237B2 (en) | 2002-11-01 | 2008-01-18 | Internet payment system and method |
Related Parent Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/697,984 Continuation US20040139016A1 (en) | 2002-11-01 | 2003-10-31 | Internet payment systerm and method |
US10/697,984 Continuation-In-Part US20040139016A1 (en) | 2002-11-01 | 2003-10-31 | Internet payment systerm and method |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/040,314 Continuation US9275410B2 (en) | 2002-11-01 | 2013-09-27 | Internet payment system and method |
Publications (2)
Publication Number | Publication Date |
---|---|
US20080114657A1 true US20080114657A1 (en) | 2008-05-15 |
US8566237B2 US8566237B2 (en) | 2013-10-22 |
Family
ID=46205008
Family Applications (4)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/697,984 Abandoned US20040139016A1 (en) | 2002-11-01 | 2003-10-31 | Internet payment systerm and method |
US12/016,647 Expired - Fee Related US8566237B2 (en) | 2002-11-01 | 2008-01-18 | Internet payment system and method |
US14/040,314 Expired - Fee Related US9275410B2 (en) | 2002-11-01 | 2013-09-27 | Internet payment system and method |
US15/006,399 Abandoned US20160267449A1 (en) | 2002-11-01 | 2016-01-26 | Internet payment system and method |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/697,984 Abandoned US20040139016A1 (en) | 2002-11-01 | 2003-10-31 | Internet payment systerm and method |
Family Applications After (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/040,314 Expired - Fee Related US9275410B2 (en) | 2002-11-01 | 2013-09-27 | Internet payment system and method |
US15/006,399 Abandoned US20160267449A1 (en) | 2002-11-01 | 2016-01-26 | Internet payment system and method |
Country Status (1)
Country | Link |
---|---|
US (4) | US20040139016A1 (en) |
Cited By (33)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20080059303A1 (en) * | 2006-08-31 | 2008-03-06 | Fordyce Edward W | Transaction evaluation for providing rewards |
US20080059302A1 (en) * | 2006-08-31 | 2008-03-06 | Fordyce Iii Edward W | Loyalty program service |
US20080059307A1 (en) * | 2006-08-31 | 2008-03-06 | Fordyce Iii Edward W | Loyalty program parameter collaboration |
US20080059306A1 (en) * | 2006-08-31 | 2008-03-06 | Fordyce Edward W | Loyalty program incentive determination |
US20080228582A1 (en) * | 2007-03-15 | 2008-09-18 | Fordyce Edward W | Loyalty program for merchant inventory |
US20090006203A1 (en) * | 2007-04-30 | 2009-01-01 | Fordyce Iii Edward W | Payment account processing which conveys financial transaction data and non financial transaction data |
US7725818B1 (en) * | 2005-01-06 | 2010-05-25 | International Business Machines Corporation | Parallel composition of electronic responses to electronic requests |
US20100169170A1 (en) * | 2007-08-30 | 2010-07-01 | Fordyce Iii Edward W | Merchant offer program |
US20100174595A1 (en) * | 2007-06-12 | 2010-07-08 | Cvon Innovations Ltd. | Method and system for managing credits via a mobile device |
US20110207250A1 (en) * | 2007-06-14 | 2011-08-25 | Shinji Uya | Back-illuminated type imaging device and fabrication method thereof |
US20110313831A1 (en) * | 2009-03-02 | 2011-12-22 | Ebay Gmarket Co., Ltd. | Method for providing electronic coupon service using communication network, and computer-readable recording medium for storing program for executing the method |
US8170527B2 (en) | 2007-09-26 | 2012-05-01 | Visa U.S.A. Inc. | Real-time balance on a mobile phone |
WO2012061067A1 (en) * | 2010-10-25 | 2012-05-10 | Internet Kreations, Llc | Method and system for secure online payments |
US20130018794A1 (en) * | 2011-07-13 | 2013-01-17 | NetQash LLC | Mobile communication device based monetary transfer system |
US8543508B2 (en) | 2010-07-09 | 2013-09-24 | Visa International Service Association | Gateway abstraction layer |
US8615426B2 (en) | 2006-12-26 | 2013-12-24 | Visa U.S.A. Inc. | Coupon offers from multiple entities |
US8639846B2 (en) | 2005-06-29 | 2014-01-28 | Visa U.S.A. Inc. | Adaptive gateway for switching transactions and data on unreliable networks using context-based rules |
US8645971B2 (en) | 2006-12-26 | 2014-02-04 | Visa U.S.A. Inc. | Real-time balance updates |
US20140337207A1 (en) * | 2013-04-28 | 2014-11-13 | Tencent Technology (Shenzhen) Company Limited | Method, device, server, and system for making payment with a messaging application on a mobile device |
US20150006561A1 (en) * | 2007-06-04 | 2015-01-01 | Bce Inc. | Methods and systems for handling online requests based on information known to a service provider |
US8977567B2 (en) | 2008-09-22 | 2015-03-10 | Visa International Service Association | Recordation of electronic payment transaction information |
US9443268B1 (en) | 2013-08-16 | 2016-09-13 | Consumerinfo.Com, Inc. | Bill payment and reporting |
US9542687B2 (en) | 2008-06-26 | 2017-01-10 | Visa International Service Association | Systems and methods for visual representation of offers |
US9672508B2 (en) | 2008-09-22 | 2017-06-06 | Visa International Service Association | Over the air update of payment transaction data stored in secure memory |
US9715709B2 (en) | 2008-05-09 | 2017-07-25 | Visa International Services Association | Communication device including multi-part alias identifier |
US9824355B2 (en) | 2008-09-22 | 2017-11-21 | Visa International Service Association | Method of performing transactions with contactless payment devices using pre-tap and two-tap operations |
US9836743B2 (en) | 2014-06-04 | 2017-12-05 | Visa International Service Association | Systems and methods to register merchants for data processing in an electronic transaction system |
US9940627B2 (en) * | 2006-12-26 | 2018-04-10 | Visa U.S.A. Inc. | Mobile coupon method and system |
US10325314B1 (en) | 2013-11-15 | 2019-06-18 | Consumerinfo.Com, Inc. | Payment reporting systems |
US10489754B2 (en) | 2013-11-11 | 2019-11-26 | Visa International Service Association | Systems and methods to facilitate the redemption of offer benefits in a form of third party statement credits |
US10671749B2 (en) | 2018-09-05 | 2020-06-02 | Consumerinfo.Com, Inc. | Authenticated access and aggregation database platform |
US11270279B1 (en) * | 2018-09-20 | 2022-03-08 | Wells Fargo Bank, N.A. | Systems and methods for real-time biller posting services |
IT202100005714A1 (en) * | 2021-03-11 | 2022-09-11 | Corner Banca Sa | METHOD AND SYSTEM FOR PROVIDING PURCHASE PROPOSALS AND PERSONALIZED AND/OR AUTOMATED PAYMENT SERVICES |
Families Citing this family (47)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20040139016A1 (en) | 2002-11-01 | 2004-07-15 | Modasolutions Corporation | Internet payment systerm and method |
US7613656B2 (en) * | 2003-08-11 | 2009-11-03 | Jp Morgan Chase Bank | Coupon payment system |
US8016185B2 (en) * | 2004-07-06 | 2011-09-13 | Visa International Service Association | Money transfer service with authentication |
US20070179883A1 (en) * | 2006-01-18 | 2007-08-02 | Verdicash Inc. | System and method and computer readable code for visualizing and managing digital cash |
WO2007142486A1 (en) * | 2006-06-08 | 2007-12-13 | Cheolhyoun Park | Business-to-business electronic payment method |
US20080228566A1 (en) * | 2007-03-15 | 2008-09-18 | Microsoft Corporation | Processing coupons with payments |
US7904354B2 (en) * | 2007-05-04 | 2011-03-08 | Validas, Llc | Web based auto bill analysis method |
US8666849B2 (en) * | 2007-05-04 | 2014-03-04 | Validas, Llc | Computer implemented method for bill analysis over the internet |
CA2689072C (en) * | 2007-12-05 | 2018-01-09 | Bce Inc. | Methods and computer-readable media for facilitating forensic investigations of online transactions |
US8380625B2 (en) * | 2007-12-28 | 2013-02-19 | International Business Machines Corporation | Use of constraints to enforce complex payment policies |
US10586277B2 (en) * | 2008-05-15 | 2020-03-10 | Wells Fargo Bank, N.A. | Graphical user interface system and method |
GB2464133A (en) * | 2008-10-04 | 2010-04-07 | Ibm | Using constrained payments to enforce complex payment policies in electronic commerce systems |
US20110093387A1 (en) * | 2009-10-16 | 2011-04-21 | Zack Fuerstenberg | System and method for non-credit card billers to accept credit card payments |
US20120016696A1 (en) * | 2010-07-14 | 2012-01-19 | Huckjin Lee | Home-based Money Transaction Method |
US10402795B2 (en) | 2012-01-05 | 2019-09-03 | Moneygram International, Inc. | Prefunding for money transfer send transactions |
US9704145B2 (en) * | 2012-12-11 | 2017-07-11 | Semaconnect, Inc. | System and method for remote payment for an electric vehicle charging station |
US10755245B2 (en) | 2013-02-25 | 2020-08-25 | Moneygram International, Inc. | Money transfer system having location based language and dynamic receipt capabilities |
US10192204B2 (en) * | 2013-08-01 | 2019-01-29 | Moneygram International, Inc. | System and method for staging money transfers between users having profiles |
US11748736B1 (en) | 2014-04-30 | 2023-09-05 | Wells Fargo Bank, N.A. | Mobile wallet integration within mobile banking |
US9652770B1 (en) | 2014-04-30 | 2017-05-16 | Wells Fargo Bank, N.A. | Mobile wallet using tokenized card systems and methods |
US11461766B1 (en) | 2014-04-30 | 2022-10-04 | Wells Fargo Bank, N.A. | Mobile wallet using tokenized card systems and methods |
US11288660B1 (en) | 2014-04-30 | 2022-03-29 | Wells Fargo Bank, N.A. | Mobile wallet account balance systems and methods |
US10997592B1 (en) | 2014-04-30 | 2021-05-04 | Wells Fargo Bank, N.A. | Mobile wallet account balance systems and methods |
US11610197B1 (en) | 2014-04-30 | 2023-03-21 | Wells Fargo Bank, N.A. | Mobile wallet rewards redemption systems and methods |
US11615401B1 (en) | 2014-04-30 | 2023-03-28 | Wells Fargo Bank, N.A. | Mobile wallet authentication systems and methods |
US10445739B1 (en) | 2014-08-14 | 2019-10-15 | Wells Fargo Bank, N.A. | Use limitations for secondary users of financial accounts |
US10373134B1 (en) | 2014-12-15 | 2019-08-06 | Wells Fargo Bank, N.A. | Scrub and match and payee account match |
US10621658B1 (en) | 2015-01-15 | 2020-04-14 | Wells Fargo Bank, N.A. | Identity verification services with identity score through external entities via application programming interface |
US10990974B1 (en) | 2015-01-15 | 2021-04-27 | Wells Fargo Bank, N.A. | Identity verification services and user information provision via application programming interface |
US10997654B1 (en) | 2015-01-15 | 2021-05-04 | Wells Fargo Bank, N.A. | Identity verification services through external entities via application programming interface |
US10937025B1 (en) | 2015-01-15 | 2021-03-02 | Wells Fargo Bank, N.A. | Payment services via application programming interface |
US11853919B1 (en) | 2015-03-04 | 2023-12-26 | Wells Fargo Bank, N.A. | Systems and methods for peer-to-peer funds requests |
US10628893B1 (en) * | 2015-06-19 | 2020-04-21 | Intuit Inc. | Staged transactions in financial management application |
US10453156B1 (en) | 2015-12-04 | 2019-10-22 | Wells Fargo Bank, N.A. | Customer incapacity management |
US20170193485A1 (en) * | 2015-12-31 | 2017-07-06 | Paypal, Inc. | Systems and methods for providing smart payment options |
US11468414B1 (en) | 2016-10-03 | 2022-10-11 | Wells Fargo Bank, N.A. | Systems and methods for establishing a pull payment relationship |
WO2018222171A1 (en) | 2017-05-30 | 2018-12-06 | Visa International Service Association | System, method, and computer program product for maintaining transaction integrity over public networks |
US11676126B1 (en) | 2017-12-28 | 2023-06-13 | Wells Fargo Bank, N.A. | Account open interfaces |
US11106515B1 (en) | 2017-12-28 | 2021-08-31 | Wells Fargo Bank, N.A. | Systems and methods for multi-platform product integration |
US11295297B1 (en) | 2018-02-26 | 2022-04-05 | Wells Fargo Bank, N.A. | Systems and methods for pushing usable objects and third-party provisioning to a mobile wallet |
US11074577B1 (en) | 2018-05-10 | 2021-07-27 | Wells Fargo Bank, N.A. | Systems and methods for making person-to-person payments via mobile client application |
US11775955B1 (en) | 2018-05-10 | 2023-10-03 | Wells Fargo Bank, N.A. | Systems and methods for making person-to-person payments via mobile client application |
US10725798B2 (en) * | 2018-12-05 | 2020-07-28 | Visa International Service Association | Method, system, and computer program product for dynamic development of an application programming interface |
US11093912B1 (en) * | 2018-12-10 | 2021-08-17 | Wells Fargo Bank, N.A. | Third-party payment interfaces |
US11551190B1 (en) | 2019-06-03 | 2023-01-10 | Wells Fargo Bank, N.A. | Instant network cash transfer at point of sale |
US11044246B1 (en) | 2019-06-21 | 2021-06-22 | Wells Fargo Bank, N.A. | Secure communications via third-party systems through frames |
US11121989B1 (en) | 2020-05-29 | 2021-09-14 | Bank Of America Corporation | Centralized repository and communication system for cross-network interactions |
Citations (39)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5420606A (en) * | 1993-09-20 | 1995-05-30 | Begum; Paul G. | Instant electronic coupon verification system |
US20010019604A1 (en) * | 1998-09-15 | 2001-09-06 | In Touch Technologies Limited, British Virgin Islands | Enhanced communication platform and related communication method using the platform |
US20020029269A1 (en) * | 2000-06-29 | 2002-03-07 | Campus Pipeline, Inc. | Methods and systems for coordinating the termination of sessions on one or more systems |
US20020029248A1 (en) * | 2000-03-17 | 2002-03-07 | Cook Jon L. | Method and systems for providing a secure electronic mailbox |
US20020035489A1 (en) * | 2000-06-02 | 2002-03-21 | Rosalind Herman | Foundation funds generation system and method |
US20020049670A1 (en) * | 2000-10-06 | 2002-04-25 | Hitachi, Ltd. | Electronic payment method and system |
US6381582B1 (en) * | 1997-09-29 | 2002-04-30 | Walker Digital, Llc | Method and system for processing payments for remotely purchased goods |
US20020099618A1 (en) * | 2000-08-30 | 2002-07-25 | Sergio Stiberman | Vehicle lease exchange method & system |
US20020161707A1 (en) * | 2001-03-30 | 2002-10-31 | Alan Cole | Method and system for multi-currency escrow service for web-based transactions |
US20030004834A1 (en) * | 2001-06-28 | 2003-01-02 | Nec Corporation | Online shopping method, online shopping system and computer program product for realizing the same |
US6502747B1 (en) * | 1999-10-26 | 2003-01-07 | First Data Corporation | System and method for performing money transfer transaction using TCP/IP |
US20030046237A1 (en) * | 2000-05-09 | 2003-03-06 | James Uberti | Method and system for enabling the issuance of biometrically secured online credit or other online payment transactions without tokens |
US20030126094A1 (en) * | 2001-07-11 | 2003-07-03 | Fisher Douglas C. | Persistent dynamic payment service |
US20030140004A1 (en) * | 1999-05-03 | 2003-07-24 | Chase Manhattan Bank | Method and system for processing internet payments using the electronic funds transfer network |
US20030145205A1 (en) * | 2000-04-14 | 2003-07-31 | Branko Sarcanin | Method and system for a virtual safe |
US6629081B1 (en) * | 1999-12-22 | 2003-09-30 | Accenture Llp | Account settlement and financing in an e-commerce environment |
US20030220835A1 (en) * | 2002-05-23 | 2003-11-27 | Barnes Melvin L. | System, method, and computer program product for providing location based services and mobile e-commerce |
US20040059688A1 (en) * | 2002-09-10 | 2004-03-25 | Visa International Service Association | Data authentication and provisioning method and system |
US20040064407A1 (en) * | 1991-07-25 | 2004-04-01 | Kight Peter J. | Integrated electronic bill presentment and universal payment |
US20040107146A1 (en) * | 2002-11-29 | 2004-06-03 | Alfano Nicholas P. | System and method for conducting an electronic commercial transaction |
US20040172552A1 (en) * | 1999-12-15 | 2004-09-02 | Boyles Stephen L. | Smart card controlled internet access |
US20040254849A1 (en) * | 2002-07-25 | 2004-12-16 | Merck Patent Gmbh | Method and system for the processing of order transactions |
US20040260657A1 (en) * | 2000-07-18 | 2004-12-23 | John Cockerham | System and method for user-controlled on-line transactions |
US20050038738A1 (en) * | 2002-02-04 | 2005-02-17 | Matthew Peck | System for a account authorisation |
US20050038707A1 (en) * | 2002-08-30 | 2005-02-17 | Navio Systems, Inc. | Methods and apparatus for enabling transactions in networks |
US20050065883A1 (en) * | 1997-09-09 | 2005-03-24 | Microsoft Corporation | Consumer-based system and method for managing and paying electronic billing statements |
US20050097320A1 (en) * | 2003-09-12 | 2005-05-05 | Lior Golan | System and method for risk based authentication |
US20050187878A1 (en) * | 2000-08-08 | 2005-08-25 | Squaretrade, Inc. | Managing an electronic seal of certification |
US7051002B2 (en) * | 2002-06-12 | 2006-05-23 | Cardinalcommerce Corporation | Universal merchant platform for payment authentication |
US20060282382A1 (en) * | 2002-06-12 | 2006-12-14 | Cardinalcommerce Corporation | Universal merchant platform for payment authentication |
US7249069B2 (en) * | 2001-08-27 | 2007-07-24 | United Parcel Service Of America, Inc. | International cash-on-delivery system and method |
US20070174189A1 (en) * | 1999-11-05 | 2007-07-26 | American Express Travel Related Services Company, Inc. | Systems and methods for facilitating commercial transactions between parties residing at remote locations |
US20080021803A1 (en) * | 2002-01-07 | 2008-01-24 | First Data Corporation | Systems and methods for selectively delaying financial transactions |
US20080140568A1 (en) * | 2006-12-07 | 2008-06-12 | Moneygram International, Inc. | Method and apparatus for distribution of money transfers |
US20080281726A1 (en) * | 2007-03-22 | 2008-11-13 | Pankaj Gupta | Credit and transaction systems |
US7499875B1 (en) * | 2000-03-17 | 2009-03-03 | Ebay Inc. | Method and apparatus for facilitating online payment transactions in a network-based transaction facility using multiple payment instruments |
US20090150299A1 (en) * | 2006-08-22 | 2009-06-11 | Mark Moscal | Transaction system |
US7593893B1 (en) * | 2000-06-13 | 2009-09-22 | Fannie Mae | Computerized systems and methods for facilitating the flow of capital through the housing finance industry |
US20100274723A1 (en) * | 2001-01-16 | 2010-10-28 | Raymond Anthony Joao | Apparatus and method for providing transaction history information, account history information, and/or charge-back information |
Family Cites Families (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
HUP0103385A2 (en) | 1998-06-19 | 2002-01-28 | Protx Limited | Verified payment system |
BR0013326A (en) | 1999-07-30 | 2002-05-28 | Safewww Inc | System and method for secure purchases through a network |
US6361582B1 (en) | 2000-05-19 | 2002-03-26 | Membrane Technology And Research, Inc. | Gas separation using C3+ hydrocarbon-resistant membranes |
US20040139016A1 (en) | 2002-11-01 | 2004-07-15 | Modasolutions Corporation | Internet payment systerm and method |
-
2003
- 2003-10-31 US US10/697,984 patent/US20040139016A1/en not_active Abandoned
-
2008
- 2008-01-18 US US12/016,647 patent/US8566237B2/en not_active Expired - Fee Related
-
2013
- 2013-09-27 US US14/040,314 patent/US9275410B2/en not_active Expired - Fee Related
-
2016
- 2016-01-26 US US15/006,399 patent/US20160267449A1/en not_active Abandoned
Patent Citations (40)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20040064407A1 (en) * | 1991-07-25 | 2004-04-01 | Kight Peter J. | Integrated electronic bill presentment and universal payment |
US5420606A (en) * | 1993-09-20 | 1995-05-30 | Begum; Paul G. | Instant electronic coupon verification system |
US20050065883A1 (en) * | 1997-09-09 | 2005-03-24 | Microsoft Corporation | Consumer-based system and method for managing and paying electronic billing statements |
US6381582B1 (en) * | 1997-09-29 | 2002-04-30 | Walker Digital, Llc | Method and system for processing payments for remotely purchased goods |
US20010019604A1 (en) * | 1998-09-15 | 2001-09-06 | In Touch Technologies Limited, British Virgin Islands | Enhanced communication platform and related communication method using the platform |
US20030140004A1 (en) * | 1999-05-03 | 2003-07-24 | Chase Manhattan Bank | Method and system for processing internet payments using the electronic funds transfer network |
US6502747B1 (en) * | 1999-10-26 | 2003-01-07 | First Data Corporation | System and method for performing money transfer transaction using TCP/IP |
US20070174189A1 (en) * | 1999-11-05 | 2007-07-26 | American Express Travel Related Services Company, Inc. | Systems and methods for facilitating commercial transactions between parties residing at remote locations |
US20040172552A1 (en) * | 1999-12-15 | 2004-09-02 | Boyles Stephen L. | Smart card controlled internet access |
US6629081B1 (en) * | 1999-12-22 | 2003-09-30 | Accenture Llp | Account settlement and financing in an e-commerce environment |
US20020059430A1 (en) * | 2000-03-17 | 2002-05-16 | Orbke Wayne H. | Methods and systems for establishing an electronic account for a customer |
US20020029248A1 (en) * | 2000-03-17 | 2002-03-07 | Cook Jon L. | Method and systems for providing a secure electronic mailbox |
US7499875B1 (en) * | 2000-03-17 | 2009-03-03 | Ebay Inc. | Method and apparatus for facilitating online payment transactions in a network-based transaction facility using multiple payment instruments |
US20030145205A1 (en) * | 2000-04-14 | 2003-07-31 | Branko Sarcanin | Method and system for a virtual safe |
US20030046237A1 (en) * | 2000-05-09 | 2003-03-06 | James Uberti | Method and system for enabling the issuance of biometrically secured online credit or other online payment transactions without tokens |
US20020035489A1 (en) * | 2000-06-02 | 2002-03-21 | Rosalind Herman | Foundation funds generation system and method |
US7593893B1 (en) * | 2000-06-13 | 2009-09-22 | Fannie Mae | Computerized systems and methods for facilitating the flow of capital through the housing finance industry |
US20020029269A1 (en) * | 2000-06-29 | 2002-03-07 | Campus Pipeline, Inc. | Methods and systems for coordinating the termination of sessions on one or more systems |
US20040260657A1 (en) * | 2000-07-18 | 2004-12-23 | John Cockerham | System and method for user-controlled on-line transactions |
US20050187878A1 (en) * | 2000-08-08 | 2005-08-25 | Squaretrade, Inc. | Managing an electronic seal of certification |
US20020099618A1 (en) * | 2000-08-30 | 2002-07-25 | Sergio Stiberman | Vehicle lease exchange method & system |
US20020049670A1 (en) * | 2000-10-06 | 2002-04-25 | Hitachi, Ltd. | Electronic payment method and system |
US20100274723A1 (en) * | 2001-01-16 | 2010-10-28 | Raymond Anthony Joao | Apparatus and method for providing transaction history information, account history information, and/or charge-back information |
US20020161707A1 (en) * | 2001-03-30 | 2002-10-31 | Alan Cole | Method and system for multi-currency escrow service for web-based transactions |
US20030004834A1 (en) * | 2001-06-28 | 2003-01-02 | Nec Corporation | Online shopping method, online shopping system and computer program product for realizing the same |
US20030126094A1 (en) * | 2001-07-11 | 2003-07-03 | Fisher Douglas C. | Persistent dynamic payment service |
US7249069B2 (en) * | 2001-08-27 | 2007-07-24 | United Parcel Service Of America, Inc. | International cash-on-delivery system and method |
US20080021803A1 (en) * | 2002-01-07 | 2008-01-24 | First Data Corporation | Systems and methods for selectively delaying financial transactions |
US20050038738A1 (en) * | 2002-02-04 | 2005-02-17 | Matthew Peck | System for a account authorisation |
US20030220835A1 (en) * | 2002-05-23 | 2003-11-27 | Barnes Melvin L. | System, method, and computer program product for providing location based services and mobile e-commerce |
US20060282382A1 (en) * | 2002-06-12 | 2006-12-14 | Cardinalcommerce Corporation | Universal merchant platform for payment authentication |
US7051002B2 (en) * | 2002-06-12 | 2006-05-23 | Cardinalcommerce Corporation | Universal merchant platform for payment authentication |
US20040254849A1 (en) * | 2002-07-25 | 2004-12-16 | Merck Patent Gmbh | Method and system for the processing of order transactions |
US20050038707A1 (en) * | 2002-08-30 | 2005-02-17 | Navio Systems, Inc. | Methods and apparatus for enabling transactions in networks |
US20040059688A1 (en) * | 2002-09-10 | 2004-03-25 | Visa International Service Association | Data authentication and provisioning method and system |
US20040107146A1 (en) * | 2002-11-29 | 2004-06-03 | Alfano Nicholas P. | System and method for conducting an electronic commercial transaction |
US20050097320A1 (en) * | 2003-09-12 | 2005-05-05 | Lior Golan | System and method for risk based authentication |
US20090150299A1 (en) * | 2006-08-22 | 2009-06-11 | Mark Moscal | Transaction system |
US20080140568A1 (en) * | 2006-12-07 | 2008-06-12 | Moneygram International, Inc. | Method and apparatus for distribution of money transfers |
US20080281726A1 (en) * | 2007-03-22 | 2008-11-13 | Pankaj Gupta | Credit and transaction systems |
Cited By (63)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7725818B1 (en) * | 2005-01-06 | 2010-05-25 | International Business Machines Corporation | Parallel composition of electronic responses to electronic requests |
US8639846B2 (en) | 2005-06-29 | 2014-01-28 | Visa U.S.A. Inc. | Adaptive gateway for switching transactions and data on unreliable networks using context-based rules |
US8620738B2 (en) * | 2006-08-31 | 2013-12-31 | Visa U.S.A. Inc | Loyalty program incentive determination |
US10037535B2 (en) | 2006-08-31 | 2018-07-31 | Visa U.S.A. Inc. | Loyalty program parameter collaboration |
US11276070B2 (en) | 2006-08-31 | 2022-03-15 | Visa U.S.A. Inc. | Transaction evaluation for providing rewards |
US20080059307A1 (en) * | 2006-08-31 | 2008-03-06 | Fordyce Iii Edward W | Loyalty program parameter collaboration |
US20080059302A1 (en) * | 2006-08-31 | 2008-03-06 | Fordyce Iii Edward W | Loyalty program service |
US20080059306A1 (en) * | 2006-08-31 | 2008-03-06 | Fordyce Edward W | Loyalty program incentive determination |
US10115112B2 (en) | 2006-08-31 | 2018-10-30 | Visa U.S.A. Inc. | Transaction evaluation for providing rewards |
US20080059303A1 (en) * | 2006-08-31 | 2008-03-06 | Fordyce Edward W | Transaction evaluation for providing rewards |
US8903734B2 (en) | 2006-12-26 | 2014-12-02 | Visa U.S.A. Inc. | Coupon offers from multiple entities |
US8645971B2 (en) | 2006-12-26 | 2014-02-04 | Visa U.S.A. Inc. | Real-time balance updates |
US8615426B2 (en) | 2006-12-26 | 2013-12-24 | Visa U.S.A. Inc. | Coupon offers from multiple entities |
US9940627B2 (en) * | 2006-12-26 | 2018-04-10 | Visa U.S.A. Inc. | Mobile coupon method and system |
US20080228582A1 (en) * | 2007-03-15 | 2008-09-18 | Fordyce Edward W | Loyalty program for merchant inventory |
US11049125B2 (en) | 2007-04-30 | 2021-06-29 | Visa U.S.A. Inc. | Payment account processing which conveys financial transaction data and non-financial transaction data |
US10395264B2 (en) | 2007-04-30 | 2019-08-27 | Visa U.S.A. Inc. | Payment account processing which conveys financial transaction data and non financial transaction data |
US20090006203A1 (en) * | 2007-04-30 | 2009-01-01 | Fordyce Iii Edward W | Payment account processing which conveys financial transaction data and non financial transaction data |
US10831840B2 (en) * | 2007-06-04 | 2020-11-10 | Bce Inc. | Methods and systems for handling online requests based on information known to a service provider |
US11687605B2 (en) * | 2007-06-04 | 2023-06-27 | Bce Inc. | Methods and systems for handling online requests based on information known to a service provider |
US20150006561A1 (en) * | 2007-06-04 | 2015-01-01 | Bce Inc. | Methods and systems for handling online requests based on information known to a service provider |
US20210056152A1 (en) * | 2007-06-04 | 2021-02-25 | Bce Inc. | Methods and systems for handling online requests based on information known to a service provider |
US20100174595A1 (en) * | 2007-06-12 | 2010-07-08 | Cvon Innovations Ltd. | Method and system for managing credits via a mobile device |
US20110207250A1 (en) * | 2007-06-14 | 2011-08-25 | Shinji Uya | Back-illuminated type imaging device and fabrication method thereof |
US20100169170A1 (en) * | 2007-08-30 | 2010-07-01 | Fordyce Iii Edward W | Merchant offer program |
US8170527B2 (en) | 2007-09-26 | 2012-05-01 | Visa U.S.A. Inc. | Real-time balance on a mobile phone |
US8452257B2 (en) | 2007-09-26 | 2013-05-28 | Visa U.S.A., Inc | Real-time balance on a mobile phone |
US9715709B2 (en) | 2008-05-09 | 2017-07-25 | Visa International Services Association | Communication device including multi-part alias identifier |
US10304127B2 (en) | 2008-05-09 | 2019-05-28 | Visa International Service Association | Communication device including multi-part alias identifier |
US9542687B2 (en) | 2008-06-26 | 2017-01-10 | Visa International Service Association | Systems and methods for visual representation of offers |
US10430818B2 (en) | 2008-06-26 | 2019-10-01 | Visa International Service Association | Systems and methods for visual representation of offers |
US10943248B2 (en) | 2008-06-26 | 2021-03-09 | Visa International Service Association | Systems and methods for providing offers |
US11315099B2 (en) | 2008-09-22 | 2022-04-26 | Visa International Service Association | Over the air update of payment transaction data stored in secure memory |
US10037523B2 (en) | 2008-09-22 | 2018-07-31 | Visa International Service Association | Over the air update of payment transaction data stored in secure memory |
US8977567B2 (en) | 2008-09-22 | 2015-03-10 | Visa International Service Association | Recordation of electronic payment transaction information |
US11030608B2 (en) | 2008-09-22 | 2021-06-08 | Visa International Service Association | Recordation of electronic payment transaction information |
US11232427B2 (en) | 2008-09-22 | 2022-01-25 | Visa International Service Association | Method of performing transactions with contactless payment devices using pre-tap and two-tap operations |
US9824355B2 (en) | 2008-09-22 | 2017-11-21 | Visa International Service Association | Method of performing transactions with contactless payment devices using pre-tap and two-tap operations |
US11501274B2 (en) | 2008-09-22 | 2022-11-15 | Visa International Service Association | Over the air update of payment transaction data stored in secure memory |
US10332094B2 (en) | 2008-09-22 | 2019-06-25 | Visa International Service Association | Recordation of electronic payment transaction information |
US10706402B2 (en) | 2008-09-22 | 2020-07-07 | Visa International Service Association | Over the air update of payment transaction data stored in secure memory |
US9672508B2 (en) | 2008-09-22 | 2017-06-06 | Visa International Service Association | Over the air update of payment transaction data stored in secure memory |
US10769614B2 (en) | 2008-09-22 | 2020-09-08 | Visa International Service Association | Over the air update of payment transaction data stored in secure memory |
US20110313831A1 (en) * | 2009-03-02 | 2011-12-22 | Ebay Gmarket Co., Ltd. | Method for providing electronic coupon service using communication network, and computer-readable recording medium for storing program for executing the method |
US8543508B2 (en) | 2010-07-09 | 2013-09-24 | Visa International Service Association | Gateway abstraction layer |
US9846905B2 (en) | 2010-07-09 | 2017-12-19 | Visa International Service Association | Gateway abstraction layer |
WO2012061067A1 (en) * | 2010-10-25 | 2012-05-10 | Internet Kreations, Llc | Method and system for secure online payments |
GB2499530A (en) * | 2010-10-25 | 2013-08-21 | Internet Kreations Inc | Method and system for secure online payments |
US20130018794A1 (en) * | 2011-07-13 | 2013-01-17 | NetQash LLC | Mobile communication device based monetary transfer system |
US20220036338A1 (en) * | 2011-07-13 | 2022-02-03 | NetQash LLC | Mobile communication device based monetary transfer system |
US20140337207A1 (en) * | 2013-04-28 | 2014-11-13 | Tencent Technology (Shenzhen) Company Limited | Method, device, server, and system for making payment with a messaging application on a mobile device |
US9443268B1 (en) | 2013-08-16 | 2016-09-13 | Consumerinfo.Com, Inc. | Bill payment and reporting |
US10909508B2 (en) | 2013-11-11 | 2021-02-02 | Visa International Service Association | Systems and methods to facilitate the redemption of offer benefits in a form of third party statement credits |
US10489754B2 (en) | 2013-11-11 | 2019-11-26 | Visa International Service Association | Systems and methods to facilitate the redemption of offer benefits in a form of third party statement credits |
US10269065B1 (en) | 2013-11-15 | 2019-04-23 | Consumerinfo.Com, Inc. | Bill payment and reporting |
US10325314B1 (en) | 2013-11-15 | 2019-06-18 | Consumerinfo.Com, Inc. | Payment reporting systems |
US9836743B2 (en) | 2014-06-04 | 2017-12-05 | Visa International Service Association | Systems and methods to register merchants for data processing in an electronic transaction system |
US10671749B2 (en) | 2018-09-05 | 2020-06-02 | Consumerinfo.Com, Inc. | Authenticated access and aggregation database platform |
US11265324B2 (en) | 2018-09-05 | 2022-03-01 | Consumerinfo.Com, Inc. | User permissions for access to secure data at third-party |
US11399029B2 (en) | 2018-09-05 | 2022-07-26 | Consumerinfo.Com, Inc. | Database platform for realtime updating of user data from third party sources |
US10880313B2 (en) | 2018-09-05 | 2020-12-29 | Consumerinfo.Com, Inc. | Database platform for realtime updating of user data from third party sources |
US11270279B1 (en) * | 2018-09-20 | 2022-03-08 | Wells Fargo Bank, N.A. | Systems and methods for real-time biller posting services |
IT202100005714A1 (en) * | 2021-03-11 | 2022-09-11 | Corner Banca Sa | METHOD AND SYSTEM FOR PROVIDING PURCHASE PROPOSALS AND PERSONALIZED AND/OR AUTOMATED PAYMENT SERVICES |
Also Published As
Publication number | Publication date |
---|---|
US8566237B2 (en) | 2013-10-22 |
US20140172645A1 (en) | 2014-06-19 |
US20040139016A1 (en) | 2004-07-15 |
US9275410B2 (en) | 2016-03-01 |
US20160267449A1 (en) | 2016-09-15 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9275410B2 (en) | Internet payment system and method | |
US8874480B2 (en) | Centralized payment method and system for online and offline transactions | |
US6993502B1 (en) | Transaction tax collection system and method | |
US7412418B2 (en) | Expense tracking, electronic ordering, invoice presentment, and payment system and method | |
US7437327B2 (en) | Method and system for buyer centric dispute resolution in electronic payment system | |
US20120095873A1 (en) | Escrow management system for marketplaces | |
US8468092B2 (en) | Method and system for processing internet payments using the electronic funds transfer network | |
JP4926404B2 (en) | Method and software application for electronic bill presentation and payment | |
CA2748254C (en) | System and method for providing dispute resolution for electronic payment transactions | |
US7805365B1 (en) | Automated statement presentation, adjustment and payment system and method therefor | |
US20080172304A1 (en) | System and method for enabling cash gifts in an online gift registry | |
US20030105710A1 (en) | Method and system for on-line payments | |
US20140222669A1 (en) | Integrated Electronic Cash Flow Management System and Method | |
WO2001013216A1 (en) | Improved business systems | |
JP2007507800A (en) | System and method for merchant-assisted automatic payment processing and exception management | |
JP2008511085A (en) | Method and system for automated payment authentication and settlement | |
JP2002543542A (en) | Virtual private lockbox | |
CA2483348A1 (en) | System and method for varying electronic settlements between buyers and suppliers with dynamic discount terms | |
JP2006500696A (en) | Systems and methods for calculating transaction-based taxes | |
US20090307102A1 (en) | System and method for providing donations | |
US20080097879A1 (en) | System and Method of Interfacing Web Services to Express Creation and Initialization of Merchant Accounts | |
US10127558B2 (en) | Expense tracking, electronic ordering, invoice presentment, and payment system and method | |
KR20070048747A (en) | Method and system for purchase card utilization and data reconciliation with enterprise resource planning/financial sofware | |
US20080097810A1 (en) | System and Method of Managing Workflow for Express Creation and Initialization of Merchant Accounts | |
US20080097897A1 (en) | System and Method of Express Creation and Initialization of Merchant Accounts |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: MODASOLUTIONS CORPORATION, CANADA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:FORZLEY, MARWAN;REEL/FRAME:021466/0767 Effective date: 20080728 |
|
AS | Assignment |
Owner name: WESTERN UNION FINANCIAL SERVICES, INC., COLORADO Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:MODASOLUTIONS CORPORATION;REEL/FRAME:027072/0479 Effective date: 20110929 |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |
|
FPAY | Fee payment |
Year of fee payment: 4 |
|
FEPP | Fee payment procedure |
Free format text: MAINTENANCE FEE REMINDER MAILED (ORIGINAL EVENT CODE: REM.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
LAPS | Lapse for failure to pay maintenance fees |
Free format text: PATENT EXPIRED FOR FAILURE TO PAY MAINTENANCE FEES (ORIGINAL EVENT CODE: EXP.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
STCH | Information on status: patent discontinuation |
Free format text: PATENT EXPIRED DUE TO NONPAYMENT OF MAINTENANCE FEES UNDER 37 CFR 1.362 |
|
FP | Lapsed due to failure to pay maintenance fee |
Effective date: 20211022 |