U.S. patent application number 15/189693 was filed with the patent office on 2016-12-29 for securing sensitive user data associated with electronic transactions.
The applicant listed for this patent is III Holdings 1, LLC. Invention is credited to Scott K. Chow, Charlie L. Kimes, Douglas B. Nielson.
Application Number | 20160379191 15/189693 |
Document ID | / |
Family ID | 40259972 |
Filed Date | 2016-12-29 |
![](/patent/app/20160379191/US20160379191A1-20161229-D00000.png)
![](/patent/app/20160379191/US20160379191A1-20161229-D00001.png)
![](/patent/app/20160379191/US20160379191A1-20161229-D00002.png)
![](/patent/app/20160379191/US20160379191A1-20161229-D00003.png)
![](/patent/app/20160379191/US20160379191A1-20161229-D00004.png)
![](/patent/app/20160379191/US20160379191A1-20161229-D00005.png)
United States Patent
Application |
20160379191 |
Kind Code |
A1 |
Nielson; Douglas B. ; et
al. |
December 29, 2016 |
SECURING SENSITIVE USER DATA ASSOCIATED WITH ELECTRONIC
TRANSACTIONS
Abstract
A payment processor for providing a payment service includes a
transaction processor to process a transaction request. An
application programming interface links a merchant to the
transaction processor based on an identifier. A merchant center,
located between a gateway and a point of sale device of the
merchant, queries a database for information associated with a
buyer and the merchant based on information received from the point
of sale device, to generate the transaction request based from
merchant transaction data received from the point of sale device
and the information associated with the buyer and the merchant
received from the database, and to communicate the transaction
request to the transaction processor. The transaction processor
also communicates information associated with the transaction
request with the merchant based on the identifier.
Inventors: |
Nielson; Douglas B.;
(Cranbury, NJ) ; Kimes; Charlie L.; (Scottsdale,
AZ) ; Chow; Scott K.; (New York, NY) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
III Holdings 1, LLC |
Wilmington |
DE |
US |
|
|
Family ID: |
40259972 |
Appl. No.: |
15/189693 |
Filed: |
June 22, 2016 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
13481543 |
May 25, 2012 |
|
|
|
15189693 |
|
|
|
|
11865789 |
Oct 2, 2007 |
8204825 |
|
|
13481543 |
|
|
|
|
60949928 |
Jul 16, 2007 |
|
|
|
Current U.S.
Class: |
705/40 |
Current CPC
Class: |
G06Q 30/06 20130101;
G06Q 30/0268 20130101; G06Q 20/202 20130101; G06Q 30/0256 20130101;
G06Q 20/40 20130101; G06Q 20/20 20130101; G06Q 20/385 20130101;
G06Q 20/3821 20130101; G06Q 20/102 20130101; G06Q 20/367 20130101;
G06Q 20/3829 20130101; G06Q 20/10 20130101 |
International
Class: |
G06Q 20/10 20060101
G06Q020/10; G06Q 20/40 20060101 G06Q020/40; G06Q 20/20 20060101
G06Q020/20 |
Claims
1-20. (canceled)
21. A computing system, comprising: communication circuitry; and
one or more processing elements configured to: receive, from a
first entity via the communication circuitry, a transaction request
that includes first information identifying a user, wherein the
first information is entered via a virtual point-of-sale device
that is integrated into a website of the first entity; retrieve,
from an electronic database, second information that identifies an
account of the user that is to be used for the transaction, wherein
the transaction request does not include the second information and
wherein the electronic database is not accessible to the first
entity; transmit a request, via a gateway component, wherein the
request includes both the first and second information, wherein the
gateway component is configured to route transactions to a
processor network based on the second information; receive an
authorization response via the gateway component; and transmit the
authorization response to the first entity.
22. The computing system of claim 21, wherein the one or more
processing elements are further configured to register the user and
store the second information in the electronic database prior to
receiving the transaction request.
23. The computing system of claim 21, wherein the one or more
processing elements are further configured to retrieve third
information for the first entity from the electronic database and
include the third information in the request.
24. The computing system of claim 23, wherein the third information
is not accessible to the user.
25. The computing system of claim 21, wherein the one or more
processing elements execute instructions of an application
programming interface (API) to include the second information in
the request.
26. The computing system of claim 21, wherein the one or more
processing elements are further configured to transmit, to the
first entity, digital information that encodes the virtual
point-of-sale device.
27. The computing system of claim 21, wherein the one or more
processing elements are configured to transmit an identifier for
the request to both the first entity and the processor network.
28. A method, comprising: receiving, by a merchant center system
from a first entity, a transaction request that includes first
information identifying a user, wherein the first information is
entered via a virtual point-of-sale device that is integrated into
a website of the first entity; retrieving, by the merchant center
system from an electronic database, second information that
identifies an account of the user that is to be used for the
transaction, wherein the transaction request does not include the
second information and wherein the electronic database is not
accessible to the first entity; transmitting a request from the
merchant center system via a gateway component, wherein the request
includes both the first and second information, wherein the gateway
component is configured to route transactions to an processor
network based on the second information; receiving, by the merchant
center system, an authorization response via the gateway component;
and transmitting, by the merchant center system, the authorization
response to the first entity.
29. The method of claim 28, wherein the transaction request is
routed to the merchant center system based on registration of the
first entity with the merchant center system.
30. The method of claim 28, further comprising: prior to receiving
the transaction request: registering the user; receiving the second
information from the user; and storing the second information in
the electronic database.
31. The method of claim 28, further comprising: retrieving third
information for the first entity from the electronic database and
including the third information in the request.
32. The method of claim 31, wherein the third information is not
accessible to the user.
33. The method of claim 28, wherein the second information is
included in the request according to an application programming
interface (API).
34. The method of claim 28, further comprising: transmitting
digital information that encodes the virtual point-of-sale device
to the first entity for integration with the website of the first
entity.
35. The method of claim 28, further comprising: including an
identifier in the request and transmitting the identifier to the
first entity.
36. A non-transitory computer-readable medium having instructions
stored thereon that are executable by a computing device to perform
operations comprising: receiving, from a first entity, a
transaction request that includes first information identifying a
user, wherein the first information is entered via a virtual
point-of-sale device that is integrated into a website of the first
entity; retrieving, from a database, second information that
identifies an account of the user that is to be used for the
transaction, wherein the transaction request does not include the
second information and wherein the database is not accessible to
the first entity; transmitting a request via a gateway component,
wherein the request includes both the first and second information,
wherein the gateway component is configured to route transactions
to an processor network based on the second information; receiving
an authorization response via the gateway component; and
transmitting the authorization response to the first entity.
37. The non-transitory computer-readable medium of claim 36,
wherein the operations further comprise registering the user and
storing the second information in the database.
38. The non-transitory computer-readable medium of claim 36,
wherein the operations further comprise retrieving third
information for the first entity from the database and including
the third information in the request.
39. The non-transitory computer-readable medium of claim 36,
wherein the operations further comprise transmitting digital
information that encodes the virtual point-of-sale device to the
first entity for integration with the website of the first
entity.
40. The non-transitory computer-readable medium of claim 36,
wherein the operations further comprise including an identifier in
the request and transmitting the identifier to the first entity.
Description
CROSS REFERENCE TO RELATED APPLICATION
[0001] This application is a continuation of claims priority to and
the benefit of, U.S. Ser. No. 11/865,789 entitled "SYSTEM, METHOD
AND COMPUTER PROGRAM PRODUCT FOR PROCESSING PAYMENTS" filed Oct. 2,
2007. The '789 application claims priority to, and the benefit of,
U.S. Provisional Patent Application Ser. No. 60/949,928, filed Jul.
16, 2007. All of which are hereby incorporated by reference in
their entirety.
BACKGROUND OF THE INVENTION
[0002] Field Of The Invention
[0003] The present invention generally relates to alternative
payment systems, and more particularly to a system, method and
computer program product for providing registration, integration,
payment processing and data capture.
[0004] Related Art
[0005] The primary way consumers pay for items online is with the
use of financial transaction instruments (e.g., credit or debit
cards or "plastic"), where a user enters card and shipping
information after having selected one or more items.
Alternative-payment systems have been developed to provide
alternative means of transaction processing, both for the buyer and
the merchant. Examples include payment services such as Google
Checkout, Bill Me Later, and eBay's PayPal.
[0006] One common aspect of many alternative payment systems is the
registry function, which requires customers to preload information
such as personal information and transaction account information
into registry databases. Consumers opt-in and provide these systems
with their personal information as well as transaction account
information.
[0007] The payment form accepted by various alternative payment
systems may differ, however. For example, some allow the buyer to
pay with a credit or debit card versus paying with a checking
account.
[0008] From the buyer's perspective, one advantage of alternative
payment systems is that only one set of buyer credentials is
necessary to use multiple commerce sites. If, for example, a
buyer's credit card expires or needs to be reissued because of
fraud or some other reason, with alternative payment systems the
buyer is not required to go to all of the commerce sites with which
the buyer transacts and change any saved card info. Instead, at
worst, the buyer need only make one change.
[0009] On the merchant side, conventional alternative payment
systems require a merchant to create new processes and technology
each time a new payment form is added to a merchant's
infrastructure. This involves building entirely new linkages to
accommodate the new payment solutions. Reconfiguring such an
infrastructure can be costly and therefore not practical for some
businesses.
[0010] Notwithstanding the benefits provided by existing
alternative payment systems, there is a need for a payment solution
which maintains customer privacy, provides fast, secure and
convenient payment functionality while reducing the integration
requirements for merchants. There also is a need to maintain buyer
privacy while collecting aggregate data about purchases made
through such payment solutions and providing consumer approved
services.
[0011] Given the foregoing, what is needed is a system, method and
computer program product for processing payments.
BRIEF DESCRIPTION OF THE INVENTION
[0012] The present invention meets the above-identified needs by
providing a system, method and computer program product for
processing payments. In one embodiment, a system for providing a
payment service includes a transaction processor configured to
process a transaction request. The system further includes an
application programming interface operable to link a merchant to
the transaction processor based on an identifier. Also included in
the system is a merchant center, located between a gateway and a
point of sale device of the merchant, configured to query a
database for information associated with a buyer and the merchant
based on information received from the point of sale device, to
generate the transaction request based from merchant transaction
data received from the point of sale device and the information
associated with the buyer and the merchant received from the
database, and to communicate the transaction request to the
transaction processor. The transaction processor is further
configured to communicate information associated with the
transaction request with the merchant based on the identifier.
[0013] Further features and advantages of the present invention as
well as the structure and operation of various embodiments of the
present invention are described in detail below with reference to
the accompanying drawings.
BRIEF DESCRIPTION OF THE DRAWINGS
[0014] The features and advantages of the present invention will
become more apparent from the detailed description set forth below
when taken in conjunction with the drawings in which like reference
numbers indicate identical or functionally similar elements.
Additionally, the left-most digit of a reference number identifies
the drawing in which the reference number first appears.
[0015] FIG. 1 is a system diagram of an exemplary payment
processing system 100 in accordance with an embodiment of the
present invention.
[0016] FIG. 2 is a flowchart illustrating buyer and merchant
registration processes in more detail, in accordance with an
embodiment of the present invention.
[0017] FIG. 3 is a flowchart depicting an integration solution and
process 300 in accordance with an embodiment of the present
invention.
[0018] FIG. 4 is a block diagram showing the linkage and API
configuration in accordance with an embodiment of the present
invention.
[0019] FIG. 5 is a block diagram of an exemplary computer system
useful for implementing the present invention.
DETAILED DESCRIPTION
[0020] The present invention, which is directed to a system, method
and computer program product for processing payments, is now
described in more detail herein in terms of the above exemplary
credit or debit card and banking payment processing system. This is
for convenience only and is not intended to limit the application
of the present invention. In fact, after reading the following
description, it will be apparent to one skilled in the relevant
art(s) how to implement the following invention in alternative
embodiments involving different types of payment methods (e.g.
electronic checking, money order, wire transfer, electronic cash,
etc.)
[0021] The terms "buyer," "user," "end user," "consumer,"
"customer," "participant," and/or the plural form of these terms
may be used interchangeably to refer to those persons or entities
capable of accessing, using, being affected by and/or benefiting
from the tool that the present invention provides for processing
payments.
[0022] Furthermore, the terms "service establishment" ("SE"),
"business," "merchant," "seller" and/or the plural form of these
terms may be used interchangeably and shall mean any person,
entity, distributor system, software and/or hardware that is a
provider, broker and/or any other entity in the distribution chain
of goods or services. For example, a merchant may be a grocery
store, a retail store, a travel agency, a service provider, an
online merchant or the like.
[0023] A "transaction account" as used herein refers to an account
associated with an open account or a closed account system. The
transaction account may exist in a physical or non-physical
embodiment. For example, a transaction account may be distributed
in non-physical embodiments such as an account number,
frequent-flyer account, telephone calling account or the like.
Furthermore, a physical embodiment of a transaction account may be
distributed as a financial instrument.
[0024] A financial transaction instrument may be traditional
plastic transaction cards, titanium-containing, or other
metal-containing, transaction cards, clear and/or translucent
transaction cards, foldable or otherwise unconventionally-sized
transaction cards, radio-frequency enabled transaction cards, or
other types of transaction cards, such as credit, charge, debit,
pre-paid or stored-value cards, or any other like financial
transaction instrument. A financial transaction instrument may also
have electronic functionality provided by a network of electronic
circuitry that is printed or otherwise incorporated onto or within
the transaction instrument (and typically referred to as a "smart
card"), or be a fob having a transponder and an RFID reader.
[0025] FIG. 1 is a system diagram of an exemplary payment
processing system 100 in accordance with an embodiment of the
present invention. Generally, system 100 includes four components:
registration (A), integration (B), gateway (C), and data capture
(D). These components arc arranged so as to maintain a buyer's
privacy at a point-of-sale while providing convenient purchasing
and payment functionality. This arrangement further provides
merchants with an alternative payment solution supported by gateway
linkages to multiple types of transaction processors used to
receive payments and leveraging any existing infrastructure.
[0026] The registration component (A) of system 100 includes a
buyer interface 101, such as a home computer, a mobile phone, or
other device connected to a network such as an e-commerce network
on the Internet. Prior to completing a transaction, a buyer
registers with the provider of the system 100 by entering
registration information as depicted in block 104. This process can
take place, for example, on a merchant's website just before the
buyer checks out. Alternatively, the buyer can preregister directly
with the provider. Block 104 represents an exemplary buyer
registration process for registering buyers and merchants with
either an alternate payment solution ("APS") and/or checkout ("CO")
website provider to execute transactions with merchants. This
registration information is stored in a database referred to as
data warehouse 105. Alternatively, as described below with respect
FIG. 5, registration information may be stored in a separate
database (not shown).
[0027] Before being provided access to system 100, a merchant must
be registered. Particularly, a merchant registers with the provider
of the APS or CO as shown in block 106.
[0028] A merchant that is not registered with a provider or does
not have a merchant acquiring account with a transaction processor
124 provides information such as federal tax identifier, merchant
name, address, and the like, through an online merchant sign up
engine 110. An example of a sign up registration process is
American Express's Want-to-Honor ("WTH") registration processing
system. A merchant can also apply for additional transaction plans
(i.e., banking options, credit card issuers, and the like) through
the online merchant sign up engine 110.
[0029] Once registered with a transaction processor 124, such as a
credit or debit card company, bank or other merchant financial
transaction instrument acquirer (e.g., a credit or debit card
company), the merchant is provided with a virtual point-of-sale
("POS") terminal and a merchant and terminal ID ("MID"). When
transacting, the merchant provides the alternative payment system
provider with its MID information which, in turn, is received and
validated by a MID validation engine 108.
[0030] The integration component (B) of system 100 takes the
virtual POS and integrates it into the processing components of a
merchant's website. This can be implemented by installing
application programming interfaces ("APIs") into the merchant's
website infrastructure. These APIs allow the relevant financial
transaction instrument information of the buyer and transaction
information from the merchant (e.g., from the merchant's point of
sale device) to be routed to the transaction processor 124 via a
merchant center 120 and gateway 122 without the merchant obtaining
access during a transaction to the buyer's information such as
personal or financial transaction account information.
[0031] More particularly, after merchant 102 registers, integration
engine 112 installs the APIs to provide links (also referred to
sometimes as "feeds") to one or more transaction processors 124
(e.g., acquirer systems). Each link supplies the information
necessary to supply a transaction processor 124 with a full set of
transaction information necessary to complete a transaction.
[0032] Application engine 114 provides online application forms to
be filled out by merchants to integrate them with new transaction
payment services. Other types of information collecting methods can
be used. For example, industry wide standard data files can be
imported into forms (e.g., using Extensible Markup Language or
"XML"), or downloaded or uploaded, as the case may be, directly
into data warehouse 105. In either case, the merchant registration
data is stored in data warehouse 105, which is a secure database
inaccessible from the transaction processor 124. As shown in FIG.
1, data warehouse 105 is also in communication with an aggregator
107a. Aggregator 107a may be a third-party which submits
transactions for payment to a transaction processor 124 on behalf
of other merchants who may or may not have direct relationships
with merchant acquirers on the network.
[0033] The gateway component (C) is a front-end software
application that enables financial data to be routed to the
respective transaction processors. More particularly, gateway 122
is a server based infrastructure containing software which inserts
the buyer and seller details into a payment processing network's
authorization infrastructure, such as credit/debit or bank acquirer
transaction processor(s) 124.
[0034] As the new transaction processors are added to system 100,
additional connections are added to system 100 to connect the
transaction processors to gateway 122. This is accomplished by
configuring the software of the gateway to handle the data
structures of the new transaction processor and by adding
additional links (sometimes referred to as "pipes") using
conventional leased telecommunications lines or internet-based
telecommunication protocols.
[0035] Once the merchant has registered and been integrated into
system 100, a buyer can then shop at a merchant website through its
interface 116. This is accomplished, for example, by connecting to
the merchant's website and logging in with a login and password if
pre-registered. If not pre-registered the buyer may shop and
proceed to registration when ready to complete the transaction, it
should be understood that other authentication techniques may be
utilized instead of a login and password, such as smartcard,
biometric, RFID or other form of authentication device or method.
Once authenticated, the buyer is transferred to merchant's website
118 which has been enabled to accept the payment solution described
herein.
[0036] After shopping, the buyer finalizes the transaction by
selecting, for example, a "checkout" button (not shown). The
checkout page is hosted off of the merchant's website hosted by
enabled engine 118. In other words, when the buyer initiates a
checkout process, the buyer is then passed from the merchant's
website to another, secure website. Alternatively, the checkout
page can be hosted by the provider of system 100.
[0037] Upon submission of a transaction, the merchant transmits an
authorization request to the transaction processor 124 via the
enabled merchant engine 118. Logic within merchant center 120
queries the data warehouse 105 for buyer and merchant details and
then generates the required authorization request and submission
message (for simplicity collectively called "a transaction
request") for insertion into gateway 122. The details merchant
center 120 obtains from data warehouse 105 include informatinon
associated with the buyer such as buyer transaction account
information, name, address and the like, and information associated
with the merchant such as acquirer identifier and other information
required by a particular transaction processor.
[0038] The gateway 122, in turn, submits the message to transaction
processor 124. In response, the transaction processor 124 provides
a response to the authorization request (e.g., approval or decline)
to the merchant. The merchant is provided a reference number
corresponding to a transaction so that it can track and further
process the transaction, but the merchant is not provided the
buyer's transaction account information, thereby keeping the
buyer's financial transaction account information private during
the transaction processing.
[0039] The particular codes that are exchanged between the enabled
merchant engine 118 and merchant center 120 are messages used
between conventional transaction processing systems and merchants.
Other new forms of transaction processing messages may be developed
and used in addition to, or in place of the convention transaction
messages since the payment solution described herein moves the
servicing responsibility to the transaction processor 124.
Similarly, reconciliation may be made between transaction processor
124 and the merchant 102 without additional configuration by the
merchant.
[0040] Data warehouse 105 stores the purchase information (i.e.,
line item data), such as SKU data, quantity, the buyer's
transaction account number, shipping information, and the like,
received from merchant center 120. In addition, data warehouse may
store buyer information, such as profiles, transaction account
information, ship to information, and the like. Other information,
such as websites visited, and the like, may also be stored in data
warehouse 105.
[0041] Data capture component (D) 107 is an optional component
which provides the ability for third parties (or the provider of
system 100 itself) to collect information about transactions and
buyers. The data can be used to enhance the customer's search and
shopping experience and other applications per the permission
granted by, for example, a user opt-in.
[0042] As explained above, data capture component (P) 107 may
include an aggregator engine 107a which can submit transactions for
payment to a transaction processor on behalf of other merchants who
may or may not have direct relationships with merchant acquirers on
the network. Aggregator 107a can also compile and distill the
information it receives. Particularly, aggregator engine 107a
allows a provider or third party to use transaction information for
statistical or marketing purposes. Aggregator 107a also can be
configured to feed information to an advertising search engine
107b, which may further analyze the data to provide custom
advertising or marketing.
[0043] As described above, from the data warehouse 105, the buyer's
data is moved to the merchant center 120. Merchant center 120
combines the merchant and buyer data to create a full transaction
data set and in turn communicates the financial transaction data to
a gateway 1220. Thus, the transaction is isolated from the
merchant's website and is instead concatenated at the merchant
center 120. Similarly, the personal information of the buyer can be
isolated from the data capture component 107.
[0044] As explained above, gateway 122 routes the transaction data
to the appropriate transaction processor 124, such as a bankcard
processor or credit card (e.g. American Express or "AXP") issuer.
Since the merchant is not provided the buyer's transaction account
information during a transaction, the buyer's transaction account
information is kept private.
[0045] FIG. 2 is a flowchart illustrating buyer and seller
registration processes 200 in more detail. In one embodiment, the
buyer registration process operates in a conventional
business-as-usual ("BAU") manner such that the user transaction
experience is similar to past transaction experiences. Buyer
registration is performed by an operator entering buyer
registration information through a buyer interface 101. As the
buyer inputs data through buyer interface 101, the data is fed to
registration engine 104. Registration engine 104, in turn, performs
the steps necessary to register the buyer. Once registration engine
104 has completed registering the buyer, the buyer's spending limit
is determined by a buyer validation engine 202. Buyer validation
engine 202 performs an authorization process with the transaction
processor (i.e., bank or credit card issuer) in order to determine
an amount the buyer is authorized to spend. Once registered and
validated the buyer is tagged as an enabled buyer as shown in block
204.
[0046] Merchant registration is performed by an operator entering
seller registration information through establishment (i.e.,
seller) interface 102. In one embodiment, the seller registration
process requires merchants to input additional information
initially by using conventional service establishment or merchant
identifier numbers to vet plastic-accepting merchants and
facilitate registration. By registering up front, service
establishments which are not registered to accept plastic can sign
up for plastic acceptance through sign-up channels such as American
Expresses want-to-honor ("WTH") or bankcard applications. As
registration information is entered, it is fed to registration
engine 106 which feeds the data to either plastic (e.g.,
credit/debit card) acceptance engine 206 or non plastic (i.e., non
credit card) acceptance. If the merchant wishes to accept plastic,
then the service establishment is validated using service
establishment or merchant identifier validation engine 210. Once
the service establishment validation engine 210 has completed
validating the service establishment, the service establishment's
website is integrated using site integration engine 212. Once the
service establishment is validated and its website integrated using
application program interfaces ("APIs"), then the service
establishment is an enabled seller as shown in block 214.
[0047] If the merchant does not accept plastic (block 208), then
the service establishment can choose between various payment types
to apply for using acceptance application engine 216. The
transaction processor 218 (e.g., credit, debit card, or bankcard
acquirer) determines whether the service establishment can
establish a transaction account. If the service establishment is
not accepted by the transaction processor 218, then the application
is rejected, as shown in block 222. If the service establishment is
accepted, then at block 220 the service establishment is considered
registered and the process continues at block 210, as describe
above.
[0048] Advantageously, the above described registration processes
maintain user privacy at a point of sale. The service establishment
is not provided with the buyer or sellers personal profile data
since that data is stored in data warehouse 105.
[0049] FIG. 3 is a flowchart depicting an integration process 300
in accordance with an embodiment of the present invention. Process
300 begins after a service establishment has been registered as
shown in block 302. Once registered, the service establishment has
one of three alternative integration procedures to follow. In the
embodiment depicted in FIG. 3, the integration procedure followed
by the service establishment depends on the size of the service
establishment. For small sellers with basic payment needs, the
service establishment can be integrated with a conventional click
and buy engine 304, which links to a hosted payment website 306. A
hosted payment website allows a third party to process payments on
its payment page as shown in block 308. For small to medium sized
sellers having a conventional shopping cart, the service
establishment integrates using a standard shopping card
pre-integration engine 310, which involves downloading
pre-integrated application programming interfaces (APIs), as shown
in block 312. Once integrated, at block 314, the registered service
establishment provides a link from the checkout to the web front
end. For large sellers with custom e-commerce infrastructures, a
custom integration can be performed as shown in block 316. Once the
service establishment is integrated, then an alternative payment
solution is deployed using a software development kit ("SDK") and
associated libraries as shown at block 318. Once the payment
solution has been deployed, a service establishment can join,
integrate and test their systems, as shown in block 320.
[0050] FIG. 4 is a block diagram showing the linkages and API
configuration in accordance with an embodiment of the present
invention. As shown in FIG. 4, transaction processors 124 (e.g.,
acquirer processors) are linked to merchant systems 404 by
acquirer/processor links 402. As described above, Gateway 122 is a
front-end software application that enables financial data to be
routed to the respective transaction processors 124. As shown, each
merchant system 404 maintains its own transaction processor links
402.
[0051] A payment solution engine 410 integrates with the web front
end of the enabled merchant website 406 using payment solution
tools and APIs 408. Payment solution tools and APIs 408 also supply
the software and links used to leverage gateway 122 to route
transactions to the merchants. By incorporating tools and APIs 408
between the gateway and payment solution (blocks 122, 410,
respectively) and merchant systems and websites (blocks 404, 408,
respectively), the gateway 122 is leveraged to route transactions
to the merchants existing transaction processor 124 rather than
require the merchants to create new links. A registry engine 410
feeds the payment solution engine 410 buyer and merchant
registration information. In addition, as explained above, data
warehouse 105, which may be one or more databases, captures
transaction details.
[0052] The present invention (i.e., systems and processes 100, 200,
300 and 400) or any part(s) or function(s) thereof) may be
implemented using hardware, software or a combination thereof and
may be implemented in one or more computer systems or other
processing systems. However, the manipulations performed by the
present invention were often referred to in terms, such as logging
in or filling out a form, which are commonly associated with mental
operations performed by a human operator. No such capability of a
human operator is necessary, or desirable in most cases, in any of
the operations described herein which form part of the present
invention. Rather, the operations are machine operations. Useful
machines for performing the operation of the present invention
include general purpose digital computers or similar devices.
[0053] In fact, in one embodiment, the invention is directed toward
one or more computer systems capable of carrying out the
functionality described herein. An example of a computer system 500
is shown in FIG. 5.
[0054] The computer system 500 includes one or more processors,
such as processor 504. The processor 504 is connected to a
communication infrastructure 506 (e.g., a communications bus,
cross-over bar, or network). Various software embodiments are
described in terms of this exemplary computer system. After reading
this description, it will become apparent to a person skilled in
the relevant art(s) how to implement the invention using other
computer systems and/or architectures.
[0055] Computer system 500 can include a display interface 502 that
forwards graphics, text, and other data from the communication
infrastructure 506 (or from a frame buffer not shown) for display
on the display unit 530.
[0056] Computer system 500 also includes a main memory 508,
preferably random access memory (RAM), and may also include a
secondary memory 510. The secondary memory 510 may include, for
example, a hard disk drive 512 and/or a removable storage drive
514, representing a floppy disk drive, a magnetic tape drive, an
optical disk drive, etc. The removable storage drive 514 reads from
and/or writes to a removable storage unit 518 in a well known
manner. Removable storage unit 518 represents a floppy disk,
magnetic tape, optical disk, etc., which is read by and written to
by removable storage drive 514. As will be appreciated, the
removable storage unit 518 includes a computer usable storage
medium having stored therein computer software and/or data.
[0057] In alternative embodiments, secondary memory 510 may include
other similar devices for allowing computer programs or other
instructions to be loaded into computer system 500. Such devices
may include, for example, a removable storage unit 522 and an
interface 520. Examples of such may include a program cartridge and
cartridge interface (such as that found in video game devices), a
removable memory chip (such as an erasable programmable read only
memory (EPROM), or programmable read only memory (PROM)) and
associated socket, and other removable storage units 522 and
interfaces 520, which allow software and data to be transferred
from the removable storage unit 522 to computer system 500.
[0058] Computer system 500 may also include a communications
interface 524. Communications interface 524 allows software and
data to be transferred between computer system 500 and external
devices. Examples of communications interface 524 may include a
modem, a network interface (such as an Ethernet card), a
communications port, a Personal Computer Memory Card International
Association (PCMCIA) slot and card, etc. Software and data
transferred via communications interface 524 are in the form of
signals 528 which may be electronic, electromagnetic, optical or
other signals capable of being received by communications interface
524. These signals 528 are provided to communications interface 524
via a communications path (e.g., channel) 526. This channel 526
carries signals 528 and may be implemented using wire or cable,
fiber optics, a telephone line, a cellular link, a radio frequency
(RF) link and other communications channels.
[0059] In this document, the terms "computer program medium" and
"computer usable medium" are used to generally refer to media such
as removable storage drive 514, a hard disk installed in hard disk
drive 512, and signals 528. These computer program products provide
software to computer system 500. The invention is directed to such
computer program products.
[0060] Computer programs (also referred to as computer control
logic) are stored in main memory 508 and/or secondary memory 510.
Computer programs may also be received via communications interface
524. Such computer programs, when executed, enable the computer
system 500 to perform the features of the present invention, as
discussed herein. In particular, the computer programs, when
executed, enable the processor 504 to perform the features of the
present invention. Accordingly, such computer programs represent
controllers of the computer system 500.
[0061] In an embodiment where the invention is implemented using
software, the software may be stored in a computer program product
and loaded into computer system 500 using removable storage drive
514, hard drive 512 or communications interface 524. The control
logic (software), when executed by the processor 504, causes the
processor 504 to perform the functions of the invention as
described herein.
[0062] In another embodiment, the invention is implemented
primarily in hardware using, for example, hardware components such
as application specific integrated circuits (ASICs). Implementation
of the hardware state machine so as to perform the functions
described herein will be apparent to persons skilled in the
relevant art(s).
[0063] In yet another embodiment, the invention is implemented
using a combination of both hardware and software.
[0064] While various embodiments of the present invention have been
described above, it should be understood that they have been
presented by way of example, and not limitation. It will be
apparent to persons skilled in the relevant art(s) that various
changes in form and detail can be made therein without departing
from the spirit and scope of the present invention. Thus, the
present invention should not be limited by any of the above
described exemplary embodiments, but should be defined only in
accordance with the following claims and their equivalents,
[0065] In addition, it should be understood that the figures and
screen shots illustrated in the attachments, which highlight the
functionality and advantages of the present invention, are
presented for example purposes only. The architecture of the
present invention is sufficiently flexible and configurable, such
that it may be utilized (and navigated) in ways other than that
shown in the accompanying figures.
[0066] Further, the purpose of the foregoing Abstract is to enable
the U.S. Patent and Trademark Office and the public generally, and
especially the scientists, engineers and practitioners in the art
who are not familiar with patent or legal terms or phraseology, to
determine quickly from a cursory inspection the nature and essence
of the technical disclosure of the application. The Abstract is not
intended to be limiting as to the scope of the present invention in
any way. It is also to be understood that the steps and processes
recited in the claims need not be performed in the order
presented.
* * * * *