U.S. patent application number 10/697984 was filed with the patent office on 2004-07-15 for internet payment systerm and method.
This patent application is currently assigned to ModaSolutions Corporation. Invention is credited to Forzley, Marwan.
Application Number | 20040139016 10/697984 |
Document ID | / |
Family ID | 46205008 |
Filed Date | 2004-07-15 |
United States Patent
Application |
20040139016 |
Kind Code |
A1 |
Forzley, Marwan |
July 15, 2004 |
Internet payment systerm and method
Abstract
A payment method and system use 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 system also referred to as
the Internet Debit Manager (IDM) provides 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 to shop online and at the time of checkout to
select direct payment from account as the payment option.
Inventors: |
Forzley, Marwan; (Ottawa,
CA) |
Correspondence
Address: |
GOWLING LAFLEUR HENDERSON, LLP
Suite 2600
160 Elgin Street
Ottawa
K1P 1C3
CA
|
Assignee: |
ModaSolutions Corporation
|
Family ID: |
46205008 |
Appl. No.: |
10/697984 |
Filed: |
October 31, 2003 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
60422640 |
Nov 1, 2002 |
|
|
|
60506873 |
Sep 30, 2003 |
|
|
|
Current U.S.
Class: |
705/40 ;
705/39 |
Current CPC
Class: |
G06Q 20/10 20130101;
G06Q 30/04 20130101; G06Q 20/02 20130101; G06Q 20/102 20130101;
G06Q 30/0222 20130101; G06Q 30/0635 20130101; G06Q 30/0236
20130101; G06Q 20/26 20130101; G06Q 30/0239 20130101; G06Q 30/06
20130101; G06Q 20/00 20130101 |
Class at
Publication: |
705/040 ;
705/039 |
International
Class: |
G06F 017/60 |
Claims
What is claimed is:
1. A system for Internet payment comprising: a service layer
including a presentation view, a merchant interface, and a payment
interface; a process layer including business logic and data
conversion modules; and a business component layer including user
authentication, transaction processing, payment manager,
business-to-business interface and sales tools modules.
2. A system as claimed in claim 1 wherein the presentation view
includes a connection for a graphical user interface.
3. A system as claimed in claim 2 wherein the presentation view
includes merchant and service provider administration modules.
4. A system as claimed in claim 2 wherein the presentation view
includes a customer wallet module for monitoring a customer
account.
5. A system as claimed in claim 4 wherein the customer wallet
module includes an interface for allocating funds to outstanding
bills
6. A system as claimed in claim 3 wherein the presentation view
includes merchant settlement.
7. A system as claimed in claim 1 wherein the merchant interface
includes a merchant interface API.
8. A system as claimed in claim 1 wherein the merchant interface
includes a business-to-business (b2b) interface.
9. A system as claimed in claim 1 wherein the payment manager
includes a debit manager.
10. A system as claimed in claim 1 wherein the payment manager
includes a account settlement module.
11. A system as claimed in claim 10 wherein the account settlement
module includes means for allocating payment to bills on a
first-in-first-out (FIFO) basis.
12. A system as claimed in claim 1 wherein the payment manager
includes a messaging manager.
13. A system as claimed in claim 1 wherein the payment manager
includes a billing manager.
14. A system as claimed in claim 1 wherein business-to-business
interface includes a configuration manager.
15. A system as claimed in claim 1 wherein business-to-business
interface includes a scheduler.
16. A system as claimed in claim 1 wherein business-to-business
interface includes a secure transfer module.
17. A system as claimed in claim 1 wherein the payment interface
includes means for accepting an electronic feed in various
formats.
18. A system as claimed in claim 3 wherein the presentation view
includes an interface for creating accounts.
19. A system as claimed in claim 3 wherein the presentation view
includes an interface for importing accounts.
20. A system as claimed in claim 3 wherein the presentation view
includes an interface for creating coupons.
21. A system as claimed in claim 10 wherein the account settlement
includes means for processing of coupons.
22. An Internet payment method comprising the steps of: a. Creating
user and merchant accounts; b. Receiving from a user a selection of
web banking as a payment option; c. Creating and sending an
electronic bill for the user representing a user account and a
merchant account; d. Receiving a transfer of electronic data from a
banking institution, in response to a payment request by the user;
e. Parsing of electronic data received; f. Updating a database
using the parsed data; g. Settling the user account; h. Settling
the merchant account; and i. Sending confirmations of payments to
both user and merchant.
23. A method as claimed in claim 22 further comprising the step of
setting up an Internet payment service provider as a payment
receiver with banking institutions.
24. A method as claimed in claim 23 wherein the step of creating a
merchant account includes the step of setting up a merchant account
within the payment service provider.
25. A method as claimed in claim 24 wherein the step of creating
accounts includes assigning unique identification numbers for each
account.
26. A method as claimed in claim 24 wherein the step of creating
merchant accounts includes providing dynamic submit forms for each
merchant used for selling goods and services.
27. A method as claimed in claim 24 wherein the step of creating
merchant accounts include providing a reporting tool for each
organization to allow them to oversee their accounts.
28. A method as claimed in claim 24 wherein the step of creating
user accounts includes setting up user accounts.
29. A method as claimed in claim 24 wherein the step of creating
user accounts includes creating unique user id to log into the
Internet payment service provider site.
30. A method as claimed in claim 24 wherein the step of creating
user accounts includes setting up user accounts.
31. A method as claimed in claim 22 further comprising the steps of
tracking issuance of a coupon, mapping the coupon to the invoice
and wherein the steps of settling merchant and user accounts in
dependence upon a value assigned to the coupon.
32. A method as claimed in claim 22 wherein the step of creating an
electronic bill includes the steps of defining a schedule for
recurring billing, creating and sending an electronic bill in
accordance with the schedule.
33. A method as claimed in claim 22 further comprising the steps of
determining if a user account is overdue, determining any terms of
sale applied to overdue accounts and apply the terms of sale to the
overdue account to generate a reminder bill.
34. A method as claimed in claim 22 wherein any one of the steps of
sending and receiving employ wireless communication.
35. A method as claimed in claim 22 further comprising the step of
setting up a service provider as a payment receiver.
36. A method as claimed in claim 22 further comprising the step of
setting up a merchant as a payment receiver.
37. A method as claimed in claim 22 further comprising the step of
receiving payment for a pre-approved account.
38. A method as claimed in claim 37 further comprising the step of
embedding the pre-populated account in electronic media.
39. A method as claimed in claim 22 further comprising the step of
accepting purchase information from a wireless device.
40. A method as claimed in claim 22 further comprising the step of
a consumer completing payment from wireless device.
41. A method as claimed in claim 22 further comprising the step of
accessing the consumer wallet from a wireless device.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application is related to a first provisional patent
application filed with the U.S. patent office under application No.
60/422,640 with filing date Nov. 1, 2002 and a second provisional
patent application filed with the U.S. patent office under
application No. 60/506,873 with filing date Sep. 30, 2003.
FIELD OF THE INVENTION
[0002] The present invention relates to an Internet payment system
and method.
BACKGROUND OF THE INVENTION
[0003] Currently users who have purchased goods and services over
the Internet are faced with few payment options. The credit card
companies dominate the market, while the users pay high processing
fees and shy away from making online payments for trust and
security reasons. Digital cash has lower rates than credit card
companies, but the adoption has been slow and the solutions in
place are still not turnkey. Following is a list of few problems
that are imposed by the current methods:
[0004] a) Credit Card fraud deters users from using their credit
card numbers on the web;
[0005] b) High cost of processing deters merchants from setting up
eCommerce sites; and
[0006] c) Inability to buy items from multiple merchants with one
payment transaction makes the process cumbersome.
SUMMARY OF THE INVENTION
[0007] An object of the present invention is to provide an improved
Internet payment system and method.
[0008] A payment method and system using electronic media and in
particular the Internet to allow a secure and trusted exchange of
money, to broaden the choices of users and allow merchants to
receive payment using means other than credit cards and digital
cash, to reduce the cost of electronic transactions for both user
and merchant and to allow users to make payment for multiple
merchants using a single account.
[0009] The Internet Debit Manager (IDM) functions as a payment
processing infrastructure, that processes online purchases
completed by buyers via web banking, telebanking and mobile
banking. The present invention supports purchase processing,
payment processing, as well as service provider and merchant tools.
The system is able to clear and settle funds for both the buyers as
well as merchants participating in transactions.
[0010] The system enables secure confidential debit payment for
goods and services purchased over the Internet. The system has
flexible payment handling and supports payment flow from the bank
to the service provider to the merchant or directly from the bank
to the merchant.
[0011] The system allows consumers to shop online and at the time
of checkout select direct payment from an account as the payment
option. A bill is automatically displayed and emailed to the
customer. The customer pays the bill at their bank the same way
they pay their utility bill, which then results in a payment
confirmation sent from the bank to the payee. Payment information
from the bank is sent to the system manually by the service
provider administrator using the Debit Manager interface or by
running an automated batch process to update the purchase
transactions. Once the payment information is processed the
customer and merchant accounts are balanced and both receive
automatic notification of the payment. The system also advises if
underpayment or overpayment has been made. The system handles
errors scenarios during the processing of the transaction and
notifies customer, merchant or service providers with the necessary
error codes and appropriate action that needs to be taken.
[0012] In accordance with an aspect of the present invention there
is provided an apparatus for Internet payment comprising: a service
layer including a presentation view and a merchant interface; a
process layer including business logic and data conversion modules;
and a business component layer including user authentication,
transaction processing, payment manager, business-to-business
interface and sales tools modules.
[0013] In accordance with another aspect of the present invention
there is provided an Internet payment method comprising the steps
of: creating user and merchant accounts; receiving from a user a
selection of web banking as a payment option; creating and sending
an electronic bill for the user representing a user account and a
merchant account; receiving a transfer of electronic data from a
banking institution, in response to a payment request by the user;
parsing of electronic data received; updating a database using the
parsed data; settling the user account; settling the merchant
account; and sending confirmations of payments to both user and
merchant.
BRIEF DESCRIPTION OF THE DRAWINGS
[0014] The present invention will be further understood from the
following detailed description with reference to the drawings in
which:
[0015] FIG. 1 illustrates in a functional block diagram an on-line
direct debit payment system in accordance with an embodiment of the
present invention;
[0016] FIG. 2 illustrates the modules of the system of FIG. 1 used
to process a purchase transaction;
[0017] FIG. 3 illustrates the modules of the system of FIG. 1 used
to process a payment transaction;
[0018] FIG. 4 illustrates the modules of the system of FIG. 1 used
to send a message;
[0019] FIG. 5 illustrates the modules of the system of FIG. 1 used
to provide business-to-business transactions;
[0020] FIG. 6 illustrates communication with the system of FIG. 1
for a typical end user purchase;
[0021] FIGS. 7a, 7b, and 7c illustrate in flow charts set up,
purchase and payment processes for the system of FIG. 1; and
[0022] FIG. 8 illustrates communication with the system of FIG. 1
for Internet card loading.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
[0023] Referring to FIG. 1, there is illustrated in a functional
block diagram an on-line direct debit payment system in accordance
with an embodiment of the present invention.
[0024] FIG. 1 illustrates in a functional block diagram the on-line
direct debit payment system in accordance with an embodiment of the
present invention. The system 10 includes a Service Layer 12,
Process Layer 14 and Business Components Layer 16 that communicate
with a database 18.
[0025] The service layer 12 includes a presentation view 20 having
a merchant administration module 22, a service provider
administration module 24, a consumer wallet 26 and a forms module
28. The service layer 12 also includes a merchant interface 30
having a merchant integration API module 32, a business-to-business
(B2B) interface 34. The service layer also includes a payment
interface 36.
[0026] The process layer 14 includes business logic and data
conversion and shares persistent objects 40 and 42 with the service
layer 12 and business component layer 16, respectively. Business
logic layer acts as a messenger between the service layer and
business component layer. It takes requests from service layer,
performs first level validations on inputs, does data conversion on
the inputs and passes it on to the business component layer for
further validations and data storage functions. This layer takes
responses from the business component layer and passes it to the
Services layer in the appropriate formats
[0027] The business component layer includes a user authentication
module 44, a transaction processing module 46, a payment manager
module 48, a B2B interface 50 and a sales tool module 52. The
payment manager 48 includes a debit manager module 54, an account
settlement module 56, a messaging manager module 58 and a billing
manager 60. The B2B interface 50 includes a configuration manager
62, a scheduler 64 and a secure transfer module 66.
[0028] Referring to FIG. 2, there is illustrated the modules of the
system of FIG. 1 used to process a purchase transaction;
[0029] The modules of the system that interact to process a
purchase transaction are shown in FIG. 2. The modules include the
merchant integration API module 32, the user authentication module
44, the transaction processing module 46, the debit manager module
54, the account settlement module 56, and the messaging manager
module 58.
[0030] The Merchant API receives information in an html post, XML
or client server secure interface. The information must include the
merchant identification and at least one purchase item. Each
purchase item must have a positive dollar value attached to it. The
transaction must also include all mandatory fields and correct
field formats as defined by the Merchant Integration API.
[0031] The general format of the purchase information passed to the
IDM system in the HTML post is shown below:
1 <form action=https://www.modasolutions.com/MODAPay/
ProcessPayment " method="POST"> <input type=hidden
name=merchant_id value="MP0001"> <input type=hidden
name=item_name_1 value="computer"> <input type=hidden
name=item_desc_1 value="DELL Dimension"> <input type=hidden
name=item_amount_1 value="1400"> <input type=hidden
name=item_quantity_1 value="1"> <input type=hidden
name=item_name_2 value="Monitor"> <input type=hidden
name=item_desc_2 value="Samsung 14" LCD"> <input type=hidden
name=item_amount_2 value="1400"> <input type=hidden
name=item_quantity_2 value="1"> <input type=hidden
name=item_count value="2"> <input type=hidden name=currency
value="CAD"> <input type=hidden name=cmd value="_mTrans">
not to be changed </form>
[0032] The system 10 is capable of processing single or recurring
payment. For recurring payments the frequency of the payments must
also be passed to the system. The payment schedule is stored in the
database. The billing manager is invoked periodically and searches
due bills and sends the information to the messaging manager to
prepare and deliver the necessary bills. For single billing, the
transaction process invokes the billing manager real-time.
[0033] The system 10 is capable of managing overdue accounts. To
enable this feature the information passed must include overdue
account information indicating the terms of sales to be applied to
overdue accounts. The billing manager 60 applies this information
to any reminder bills generated. For example a merchant may pass
net "30, 1.5%, overdue reminder=yes". After thirty days if the
account remains unpaid an ebill reminder will be sent including the
1.5% interest charges against the transaction.
[0034] System generated errors are returned to the system or
presented to the user. Either the user or the merchant's system
administrator must correct the error in order to proceed with the
purchase.
[0035] The system 10 includes a user Authentication Module 44.
Prior to the system committing a sales transaction to the database
the customer information is passed to the authentication module 44.
The user authentication module 44 is passed the customer
information. If the customer is a new user the user authentication
module 44 of the system creates an account, the system returns the
account and password information for the customer to accept.
[0036] Referring to FIG. 3, there is illustrated the modules of the
system of FIG. 1 used to process a payment transaction;
[0037] The system is also capable of receiving bulk purchase
information in a batch process. This information is passed through
the Merchant Interface 32 to the system via html or xml. The system
processes batch purchases the same way it processes individual
requests made to the Merchant Interface API.
[0038] The modules of the system that interact to process a payment
transaction are shown in FIG. 3 blue. These modules include the
merchant administration module 22, the payment interface 36, the
process layer 14, the debit manager module 54, the account
settlement module 56, the messaging manager module 58 and the
database 18.
[0039] In one embodiment, the payment information is received
electronically and is processed by the system. The Payment
Interface 36 receives payment information in an electronic feed
from the banks. The Payment Interface 36 may be configured to
receive the files and information in different formats to
accommodate different banks. The payment interface 36 parses the
information to ensure that it is in the pre-defined bank format.
The parsing of the information may be triggered manually through
the merchant administration view 22 or scheduled to run at
different intervals.
[0040] All generated errors are written to a log file. The errors
must be corrected in order to proceed with the processing of the
payment file.
[0041] The Account Settlement module 56 processes all valid payment
transactions by extracting the data and populating the database 18.
The system is capable of managing correct payments, overpayment and
underpayment. The transactions are processed as follows:
[0042] When the amount received equals the amount owing in the
customers account all transactions are processed, and marked as
Paid.
[0043] When the amount received is larger than the amount owing on
the customer account all transactions are credited and their status
is changed to Paid. The account balance will reflect the
unused.
[0044] When the amount received is less than the total amount owing
on all transactions the Account Settlement module processes the
transactions starting with the transaction that was purchased
first, money is credited to each transaction and marked as Paid.
Unpaid transactions retain their status as payment pending. The
customer account carries a balance if the were insufficient funds
to cover the bill.
[0045] The payment process triggers the Messaging Manager module 58
to notify the user that a payment has been received, the status of
the account and if further action is required on their part to
complete the transaction.
[0046] In a second embodiment, the payment information is received
by fax and entered into the system manually. The transactions are
manually typed into the Debit Manager 54 by entering the account
number and amount received from the bank. The system then processes
the transactions the same way it processes the electronic
feeds.
[0047] Referring to FIG. 4, there is illustrated the modules of the
system of FIG. 1 used to send a message.
[0048] The system includes a module known as the Messaging Manager
58. As shown in FIG. 4 the messaging manager 58 receives system
calls from the Merchant Interface 22, Account Settlement module 56
and Billing Scheduler 60 to trigger the sending of a message.
[0049] The system call includes parameters such as message type,
message format, preconfigured account number and transaction
reference number. Based on these parameters the message manager 58
queries the database 18 for the content of the message.
[0050] The type of messages generated by the messaging manager 58
are eBill, Payment Reminder, Payment Received, Over Payment,
Insufficient Payment, and Coupons, Order Cancellation or Amendment.
The content of each of the messages may be system default or
composed using the merchant interface and stored in the database.
The automatic sending of a message may be suppressed. The messaging
manager 58 sends email, SMS and MMS formats.
[0051] An embodiment of the invention further includes a method of
facilitating customers to manage their account funds using the
Consumer Wallet 26 in an internet browser. The Consumer Wallet 26
queries the database 18 to present a history of transactions, a
list of outstanding transactions and the account balance. Available
funds can be allocated to unpaid bills and the Account Settlement
module 56 updates the database. Bills that have been completed
successfully are marked as Paid. The remaining balance is credited
to the customers account; outstanding transactions remain as
payment pending.
[0052] Using the GUI interface a customer can choose to allocate
funds manually or configure the Account Settlement module to
allocate money on their behalf using a First in first out (FIFO)
system. When the "Allocate Funds Manually" option is enabled, then
each time a payment transaction is processed the Messaging Manager
sends the customer an email instructing the customer to log on to
the system to complete the transaction by allocating the funds
appropriately.
[0053] The system includes a module known as the Service Provider
Administration Tool 24. The Service Provider admin is an
application accessed through an internet browser that allows
authorized administrators to view and manage the information stored
in the database.
[0054] The Service Provider Administration provides the following
functionality:
[0055] 1. View, search, sort, and edit merchant account information
belonging to that Service Provider, setup and tear down merchant
accounts.
[0056] 2. View, search, sort transaction information generated by
their merchants
[0057] 3. View, search, sort customer account information.
[0058] 4. Generate merchant statements
[0059] 5. Reconcile settlement with merchants:
[0060] a. Retrieve records of all payments received for a specified
period of time
[0061] b. Flag transaction records as "reimbursed" when payments of
funds have been reimbursed to the merchants.
[0062] The system includes a module known as the Merchant
Administration Tool 22. The Merchant admin is an application
accessed through an internet browser that allows authorized
administrators to view and manage the information stored in the
database.
[0063] The Merchant Administration provides the following
functionality:
[0064] 1. View, search, sort, and edit customer account information
belonging to that Merchant, setup and tear down merchant
accounts
[0065] 2. View, search, sort transaction information generated by
their customer
[0066] 3. Perform bill adjustments
[0067] 4. View, search, sort customer account information
[0068] 5. Generate customer statements
[0069] 6. Generate and configure message manager
[0070] 7. Reconcile settlement with payees:
[0071] a. Retrieve records of all payments received for a specified
period of time
[0072] b. Retrieve records of all payments reimbursed by the payee
for a specified period of time.
[0073] In an embodiment of the system the merchant administration
enables merchants to make adjustments to existing bills. The bill
adjustment includes bill presentment to the administrator and the
functions to perform order cancellations, item cancellation, and
item modifications. Adjustments to orders can trigger the account
settlement module to make the required changes to the customer
account when billing is affected. The message manager can be
automatically or manually invoked to send notification of the
change to the customer.
[0074] Another embodiment of the invention includes a system for
generating and settling coupons. The system comprises of an
interface to create and manage the coupons, a database to store
coupon details and the method that enables merchants to send
coupons once the eBill has been received by the buyer. A coupon
contains the customer account and the discount amount that is
applied to a purchased or left in the account for future purchases.
The interface accepts individual coupons or batch loading of
coupons into the system. When a payment is processed the Account
Settlement module searches the database for coupons that are linked
to the customer account and applies the discount to settle the
account balance.
[0075] Referring to FIG. 5, there is illustrated the modules of the
system of FIG. 1 used to provide business-to-business
transactions.
[0076] The system includes a module known as the B2B Interface 50
that interfaces on the backend with third party applications such
as sales order processing and accounting systems residing in the
merchants' premises. The order processing information is exported
off the system over and HTML or XML interface 34. As shown in FIG.
5 below the B2B Interface includes three components as follows:
[0077] 1 Configuration Module 62
[0078] 2 Scheduler Module 64
[0079] 3 Secure Transfer Module 66
[0080] The configuration module 62 is used to record in the
database the batch processing triggers, information to be
transmitted, interface destination, output formats and error
handling destination.
[0081] The scheduler 64 runs to invoke the secure transfer of the
order information on a scheduled basis. The secure transfer module
66 establishes a secure link with the host destination. A file is
created and the information is transferred to the host
destination.
[0082] Referring to FIG. 6, there is illustrated communication with
the system of FIG. 1 for a typical end user purchase.
[0083] Purchase processing supports an API to accept user
authentication information and purchase transaction details from a
shopping cart or other web application such as an invoicing or
event management application. Purchase processing also enables
posting of transaction information to the IDM database, and
triggers electronic bill delivery and electronic receipt
delivery.
[0084] Payment processing allows processing by batch or
individually of bank payment logs. Payment processing also allows
customers to allocate funds to purchases as desired when multiple
pending payments exist. Processed payments can trigger automatic
notification of incomplete payment, over payment and full payment
received.
[0085] Merchant tools allow merchants to view, search and sort
transactions, manage sales transactions, export data from the IDM
system, generate notification and marketing messages over SMS,
email, NMS or instant messaging, generate coupons, and create
pre-assigned customer accounts.
[0086] Service Provider tools allows administrators to view, create
and maintain merchant and user accounts and settle merchant
reimbursements.
[0087] Referring to FIGS. 7a, 7b, 7c, there are illustrated in flow
charts set up, purchase and payment processes for the system of
FIG. 1 respectively. A method that enables a payee to be configured
on the system and setup as a payee at the bank is illustrated in
FIG. 7a, 100 as follows: Configure service provider as a payment
receiver--IDM Service Provider registers itself as a payment
receiver with all major banks. This process is only performed once
before the system is deployed. At the completion of this step any
person can visit their banks web page, mobile banking or
telebanking and search for the payee name. Once the company
information is displayed a user adds payee to their bill list.
[0088] Alternatively, Merchant as payee--The Merchant registers
itself as a payment receiver with all major banks. This process is
only performed once before IDM is deployed. At the completion of
this step any person can visit their banks web page, mobile banking
or telebanking and search for the merchant. Once the company
information is displayed a user adds the merchant to their bill
list
[0089] Currently all transaction processing software components are
only capable of processing payments based on one account--one
merchant basis. For example each Utility company creates an account
number for each client, which limits the client to only pay that
particular utility. The system leverages the existing banking
infrastructure and improves it by allowing users to pay multiple
merchants using one account.
[0090] A method that enables a merchant to be configured on the
system is illustrated in FIG. 7a, as follows: A merchant that
wishes to offer web banking as a payment option for online
purchases of goods or services contacts the service provider to
receive integration information. Once the registration form is
completed the information is setup on the system database and a
unique account id and number identifying the merchant is assigned
102.
[0091] 2. Each merchant may assign one or more administrators to
maintain support of the system and to track and manage
transactions. All administrators are given access to a
sophisticated reporting and management tool.
[0092] 3. A merchant has two system interface options based on
their level of sophistication and size of business:
[0093] a. Use wed banking with IDM Service Provider online order
form 28
[0094] b. Integrate web banking with shopping cart software using
the Merchant Integration API, 104
[0095] 4. The merchant must choose the payee:
[0096] a. The Service provider will be the payee. The customer will
make their bill payments to Service Provider, the bank will pay the
Service Provider, which will then reimburse the merchants.
[0097] b. The merchant will be the payee. The customers will make
their bill payments directly to the merchant and the bank will pay
the merchant.
[0098] FIG. 7b, illustrates in a flow chart the purchase process.
The method provided enables merchants to accept debit payments for
online purchases as follows:
[0099] 1. A user visits the merchant website 110 and selects the
goods or services they wish to purchase. Once the user decides to
proceed to checkout and selects direct payment from account as the
payment option the transaction information is posted 112 to the IDM
system via the Merchant Integration API.
[0100] 2. The Merchant Integration API allows external parties
(customers, suppliers or partners) to use the IDM for processing of
payment. The API can be made public and offered as open source or
it can be sold for a fee. The API will have calls to the IDM and
will serve as a way to hide the inner details of the engine from
the outside world.
[0101] 3. Each Transaction must include the merchant identification
and at least one purchase item. Each purchase item must have a
positive dollar value attached to it. The transaction must also
include all mandatory fields and correct field formats as defined
in by the Merchant Integration API.
[0102] 4. The information passed may include the payment occurrence
indicating whether the transaction is a single payment or
re-occurring payment and the type of the transaction Test or Live.
For re-occurring payment the frequency of the payments must also be
passed to the IDM system.
[0103] 5. The information passed may include overdue account
information indicating the terms of sales to be applied to overdue
accounts. This information will be applied to any reminder bills
generated. For example a merchant may pass net "30, 1.5%, overdue
reminder=yes". After thirty days if the account remains unpaid an
ebill reminder will be sent including the 1.5% interest charges
against the transaction.
[0104] 6. Errors 114, 116 are returned to the system or presented
to the user. Either the user or the merchant's system administrator
must correct the error in order to proceed with the purchase.
[0105] 7. The customer is then authenticated as a user of the
payment system 118. If the customer is a new user an account is
created 120 and the customer is display their account information
and password.
[0106] 8. The customer is displayed a confirmation page 122 to
accept the purchase order and consent to the web banking payment
method.
[0107] 9. An electronic bill is emailed 126 to the customer showing
the order details, amount due, due date and instructing them to
make payment to the payee using their assigned account number at
their own bank.
[0108] 10. All transaction information 124 is tracked in the system
database.
[0109] FIG. 7c illustrates in a flow chart the payment process.
This method enables merchants to process bank payment notifications
as follows:
[0110] 1. Customers visit their banks online, and pay their bills,
using the account number and amount specified in the email 130.
Note: The first time the user makes an online payment; they must
add the payment receiver to the list of vendors in their bill
list.
[0111] 2. On a scheduled basis 132, the banks send The payment
receiver an electronic feed for the transactions completed.
[0112] Options 1--Automatic: The system receives 134 the files,
parses them, extracts the data and populates the system database
making the appropriate entries in the customer account tables. The
process also notifies the user that the payee received a payment
and that further action is required on their part if they chose the
manual payment processing option to complete the transaction.
[0113] Option 2--Manual: For smaller operations the bank feed can
be received via fax and the database manually updated by an
authorized administrator. The admin will use the debit manager
interface to enter account number and amount received from the
bank. The system will then update the database records. The process
also notifies the user that the payee received a payment and that
further action is required on their part if they chose the manual
payment processing option to complete the transaction.
[0114] 3. Each customer can choose to allocate finds manually or
let the account settlement module allocate money on their behalf
using a First in first out (FIFO) system.
[0115] 4. If the customer chooses to allocate funds manually, then
each time a payment is made at the bank, and the processing is
completed by the system as outlined above, the customer is sent an
email and is asked to revisit system and complete the transaction
by allocating the funds appropriately. When the customer logs into
their Wallet, they will see a list of their outstanding
transactions and account balance. The customer manually allocates
funds to each transaction. Transactions that have been completed
successfully are marked as payment complete. The remaining balance
is credited to the customers account; outstanding transactions
remain as payment pending. The customer can only allocate full
payment against any specific transactions, partial payment are not
accepted.
[0116] 5. If the customer makes a decision to allocate the funds
automatically using FIFO, the Account Settlement module will
process the payments daily using the following three scenarios.
[0117] 6. The amount deposited equals the amount owing 136 in the
customers account. In such a case all transactions are processed,
and marked as payment completed 138.
[0118] 7. The amount paid is larger than the amount owing on the
customer account. In such a case all transactions are credited and
their status is changed to payment competed. The remaining funds
will remain in the customers account 140 and can be refunded or
used at a later time to complete other payments against future
transactions.
[0119] 8. If the money paid is less than the total amount owing on
all transactions, then Account Settlement processes the
transactions starting with the service that was purchased first,
money is credited to each transaction and marked payment completed.
Once the system determines that cash on hand is not sufficient to
complete a transaction, the process stops. The remaining
transactions retain their status as payment pending. The remaining
funds stay in the users account. A transaction summary and account
status is then emailed to the customer 142.
[0120] 9. The merchant has the option of sending reminder bills to
customers with over due accounts. The bill sent to the customer
will reflect the outstanding balance, and interest incurred and a
total owing.
[0121] The system also includes a default or configurable
"Checkout" button. This graphic and text can be inserted in html
webpages, emails or electronic documents to enable buyers to select
the direct pay at my bank option. A default button is provided by
MODASolutions however this is a configurable option for both The
Checkout button is The presentation and the wording on the checkout
can be either supplied by MODASolutions or preconfigured by the
merchant or provider. The preconfiguration includes presentation
and text.
[0122] Service Provider Tools 24 enable service providers to offer
the system as a service to their merchant base. The Service Provide
tools 24 allow an authorized system administrator to access and
maintain information pertaining to their merchants, transactions
billing, and merchant reimbursements.
[0123] Using the Service Provider tool enables Service
Providers:
[0124] 1. to view, search, sort, and edit merchant account
information, setup and tear down merchants belonging to that
Service Provider;
[0125] 2. to view, search sort transaction information generated by
their merchants;
[0126] 3. to view search sort customer account information;
[0127] 4. to generate merchant statements; and
[0128] 5. to reconcile settlement with merchants.
[0129] The tools also allow Service Providers to:
[0130] a. Retrieve records of all payments received for a specified
period of time;
[0131] b. Flag transaction records as "reimbursed" when payments of
funds have been reimbursed to the merchants; and
[0132] c. Generate a merchant statement
[0133] Merchant Tools such as sales closing tools enable merchants
to send notifications as follows:
[0134] 1. Systems notifications--enable merchants to select default
system generated emails to be sent to buyers. As an example. The
merchant can select a "Thank you for buying" email that is sent to
consumers who paid directly. Another example is when merchant can
send a "reminder to pay" email for those with payment pending
status
[0135] 2. Merchant defined notifications--enables merchants to
compose and send emails to buyers who completed their payments or
people who did not pay yet. These emails are not predefined and are
written by the merchant and may include the opportunity for
cross-selling or up selling. The system will support text-based
emails and formatted based ones.
[0136] 3. Wireless SMS/MMS Systems notifications--enables merchants
to select predefined system generated SMS or MMS messages to be
sent to buyers on their mobile phones. As an example. The merchant
can select a "Thank you for buying" SMS that is sent to consumers
who paid directly. Another example is when merchant can send a
"reminder to pay" SMS/MMS for those with payment pending status
[0137] 4. Wireless merchant defined notifications--enables
merchants to compose and send SMS or MMS messages to buyers who
completed their payments or people who did not pay yet. These
emails are not predefined and are written by the merchant and may
include the opportunity for cross-selling or up selling.
[0138] Coupon issuing enables merchants to send coupons once the
buyer has received the eBill. The coupon can include discounts that
can be used to reduce payments or a credit that can be left in
account for future purchases. Below is a walkthrough of how coupon
issuing can work
[0139] 1. Buyer fills a shopping cart, checks out and selects
direct payment from bank account.
[0140] 2. Buyer receives eBill by email with the amount specified
in the email.
[0141] 3. Merchant uses the couponing tools to issue a $100
discount coupon. The coupon can be issues at the same time the
eBill is emailed or sent by the merchant at a later time to
motivate the buyer to complete payment.
[0142] 4. Buyer receives coupon and decides to pay. Buyer pays for
entire amount less than the $100 coupon
[0143] 5. System processes transaction and matches the transaction
with the account and settles the account
[0144] Coupon creation and distribution module enables:
[0145] 1. a coupon to be created via the web manually and sent via
email to the buyer;
[0146] 2. a coupon to be created via the web manually and sent via
SMS to the buyer;
[0147] 3. a batch of coupons to be uploaded to the system and sent
to buyers by email;
[0148] 4. a batch of coupons to be uploaded to the system and sent
to buyers by SMS; and
[0149] 5. the merchant to define a credit coupon or a discount
coupon.
[0150] Discount coupons can be applied against an outstanding bill.
Credit coupons can be applied any time after the coupon is
issued.
[0151] A Coupon Processing module enables the system to store,
track, and process coupons sent to the buyer. The module maps
coupon numbers to an account number held by the buyer. The module
that enables discounts coupons to be matched against outstanding
bills. On processing of transactions the number of coupons are
matched against the eBill amount. The module enables credit coupons
to be added to the buyer's account. The system processes the credit
coupons and updates the balance in the buyer's account
[0152] Embedded payments in direct marketing campaigns can also be
supported by system 10. The system enables merchants to
preauthorize prospective buyers and send them marketing campaigns
that include pre-assigned account numbers that enable the buyer to
pay for the items enclosed in the campaign. The following is a
walkthrough of the method:
[0153] 1. Merchant compiles list of potential prospects
[0154] 2. Merchant sends campaign to list with details of
product/service in the body of the email
[0155] 3. System assigns a predefined account number and assigns to
the buyer
[0156] 4. Buyer receives email, reads information and then decides
to pay
[0157] 5. Buyer uses pre-defined account to pay for merchant's
product/service
[0158] 6. Buyer can click on a button that routs to a pre-filled
form in which the user reviews information and then confirms a
request for an eBill. The user then carries on with the payment
process as defined throughout this document.
[0159] 7. Buyer has the opportunity to proceed and pay from their
bank account without requesting an eBill.
[0160] Recurring Payments enable merchants to define the payment
schedule for recurring payments. The payment schedule can be
defined on a weekly, monthly, or quarterly basis. The method
enables merchants to track the number of recurring payments
completed by the buyer. Example, merchant can view the admin
reports and determine that customer x has completed 3 out of 7
payments. The merchant can also have the option to utilized any of
the resources available by the system such as notifications and
coupons.
[0161] Leasing tools enable merchants to break down the amount of a
transaction into multiple smaller amounts. An example of this
scenario is as follows:
[0162] 1. Merchant sells $1000 dollars computers
[0163] 2. Buyer wants to buy computer but cannot afford full
amount
[0164] 3. Buyer agrees for the merchant's leasing program
[0165] 4. Buyer selects leasing terms
[0166] 5. System sets up transaction as a recurring payment
transaction and manage the eBills, the interest on the leasing as
well as the conditions and policies in the event of a
non-payment.
[0167] Enterprise Deployment the system 10 can be supported as a
software license that can be hosted on the web or deployed at the
customer premise behind a firewall. A software license with
installable tools to be deployed on standalone redundant servers
and has all the modules to support direct payment from bank
account.
[0168] Backend Interfaces:
[0169] 1. enable merchants to pull data from IDM system via a set
of interfaces as follows:
[0170] a. XML interface
[0171] b. Proprietary interface
[0172] c. Email
[0173] 2. enable IDM to push the data via a set of tools as
follows:
[0174] a. XML interface
[0175] b. Installable software at merchant premise that retrieves
data from the system and presents it on the screen.
[0176] 3. A back end interface that include data from IDM
containing information deposited in the database and passed to the
system through the front end interface. The data includes the
following:
[0177] a. Transaction details
[0178] b. Payment status
[0179] c. Sales closing information
[0180] d. Coupon usage information
[0181] Another embodiment extends the system to mobile phones,
wireless devices, and PDAs that enables the purchase loop and the
payment loop to be executed on a mobile device. In the form of an
installable software module on a mobile device with menus and
functionality that enables buyer to complete purchase and or
payment loop on their mobile device and to manage their account
status, payments and profiles.
[0182] Wireless adaptation enables merchants to offer web-banking
payments for purchases completed from a wireless device.
[0183] 1. The IDM engine can be built using any CGI Web enabled
programming language, along with any data storage facilities. For
the initial release of the engine JAVA, JSP, xHTML, Oracle are used
to build the engine. There are several classes and database tables
required to implement this engine. Also there are shell scripts and
EDI used to transfer and extract the data between the banks and
IDM.
[0184] 2. The IDM interface is also available for immediate use by
clients with access to an IP enabled mobile phones. Since IDM wired
interface is written using xHTML the translation to a wireless
devise is instantaneous and requires minimal code modifications
[0185] 3. The IDM interface can also be developed to accommodate
mobile devices that require a mobile interface. For this purpose
IDM can be supported using different technologies such as J2ME Web
services, ASP.NET, Python and other technologies.
[0186] 4. The mobile device can use navigation where a user can
easily allocate funds using their mobile towards their IDM account.
Once the payment is received by the IDM the data is processed in
the same manner as before. An email is sent out as well as an SMS
message (if client is set up with the service) instructing the
client to allocate payments towards the transactions. The Wireless
banking module is then invoked from the main menu, where a user is
then displayed the balance in their account and a list of
transactions that are pending. The user can then select each item
and hit the enter button on their phone. Once the button is
selected, the appropriate tables are updated and the corresponding
emails and SMS messages are sent.
[0187] Referring to FIG. 8, there is illustrated communication with
the system of FIG. 1 for Internet card loading. Internet Card
Loading is a method that enables merchants and consumer acquirers
to load prepaid value cards using the IDM system. The stored value
cards could be one of the following:
[0188] 1. prepaid credit cards
[0189] 2. prepaid phone cards used for land line/mobile
telephony
[0190] 3. prepaid value cards run and owned by the provider of the
IDM system
[0191] The following steps highlight the functionality for the
system are illustrated in the FIG. 8:
[0192] 1. user 80 visits merchant site 82 that is selling prepaid
cards
[0193] 2. user selects card, and the amount of money to be
loaded
[0194] 3. user receives an eBill
[0195] 4. user pays the eBill at their bank account using the
pre-assigned account number
[0196] 5. Funds are now allocated in the user's account
[0197] 6. System 10 maps the account number to the prepaid card
number
[0198] 7. mapping enables prepaid card to be used as desired by the
user 80
[0199] The internet loading can happen in multiple possible
configurations:
[0200] 1. The merchant acquirer 82 assigns an account to the
consumer 80 and maps the IDM account to the prepaid cards.
[0201] 2. The merchant acquirer 82 configures the system 10 to
issue accounts that are equivalent to the prepaid cars. Once the
account is loaded, there is no need for mapping between multiple
accounts to be made
[0202] The IDM system enables the system operator, merchant
acquirers, to execute on novel methods to acquire merchants. These
methods are detailed as follows:
[0203] 1. inverted value based pricing--merchant is charged on a
per transaction value where the discount rate assigned is inverted
to the value of the transaction. The higher the value of the
transaction the lower the discount rate. For example, if a
merchant's average business transaction is $1000 dollars, then the
discount rate is 0.5%. If the merchant's average business
transaction is $2000, then the discount rate is 0.25%
[0204] 2. flat based pricing--merchant is charged a flat fee per
month or on a yearly basis regardless of the volume or value of the
transaction. Example a large merchant is charged 100,000 dollars
per year for unlimited number of transactions. A small merchant
could be charged 5,000 per year for unlimited number of
transactions. Different packages can be assembled based on the
size, and type of merchant.
[0205] 3. Free internet loading--merchant is not charged for
loading stored value cards. The revenue could then be derived from
float, and breakage or other supporting revenue streams
[0206] The IDM system enables the system operator to implement
different business models by enabling the charging to be configured
on a per merchant and per transaction basis. The following
parameters can be configured by the merchant acquirer or the system
administrator on a per merchant and per transaction basis.
[0207] 1. merchant setup fee
[0208] 2. monthly service charge
[0209] 3. per transaction processing fee
[0210] 4. per transaction discount fee
[0211] Each of these fees can be set to nullified to support
different packages.
* * * * *
References