U.S. patent application number 14/207401 was filed with the patent office on 2014-07-10 for method and system to process credit card payment transactions initiated by a merchant.
This patent application is currently assigned to EBAY INC.. The applicant listed for this patent is EBAY INC.. Invention is credited to Joerg Schleicher.
Application Number | 20140195436 14/207401 |
Document ID | / |
Family ID | 35801160 |
Filed Date | 2014-07-10 |
United States Patent
Application |
20140195436 |
Kind Code |
A1 |
Schleicher; Joerg |
July 10, 2014 |
METHOD AND SYSTEM TO PROCESS CREDIT CARD PAYMENT TRANSACTIONS
INITIATED BY A MERCHANT
Abstract
A system, to process credit card payment transactions initiated
by a merchant, includes an interface to receive a
merchant-initiated request for a transfer of funds from a buyer
credit card account. A credit card processing application initiates
the transfer of funds from the buyer credit card account to a
third-party merchant bank account, held by a third-party payment
service. The third-party merchant bank account receives funds from
the buyer credit card account on behalf of the merchant. A funds
allocation application allocates the received funds to a receiving
account of the merchant, the receiving account being maintained by
the third-party payment service. The credit card processing
application may be virtual point of sale (POS) terminal
application, hosted at a server computer system operated by the
third-party payment service, and accordingly may be accessible by
the merchant via a network.
Inventors: |
Schleicher; Joerg; (San
Francisco, CA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
EBAY INC. |
San Jose |
CA |
US |
|
|
Assignee: |
EBAY INC.
SAN JOSE
CA
|
Family ID: |
35801160 |
Appl. No.: |
14/207401 |
Filed: |
March 12, 2014 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
10941510 |
Sep 14, 2004 |
8682784 |
|
|
14207401 |
|
|
|
|
PCT/US04/22742 |
Jul 16, 2004 |
|
|
|
10941510 |
|
|
|
|
Current U.S.
Class: |
705/44 |
Current CPC
Class: |
G06Q 20/02 20130101;
G06Q 20/202 20130101; G06Q 20/10 20130101; G06Q 20/24 20130101;
G06Q 20/40 20130101 |
Class at
Publication: |
705/44 |
International
Class: |
G06Q 20/40 20060101
G06Q020/40 |
Claims
1. A system to process credit card payment transactions initiated
by a merchant, the system including: an interface to receive a
merchant-initiated request for a transfer of funds from a buyer
credit card account; a credit card processing application to
initiate the transfer of funds from the buyer credit card account
to a third-party merchant bank account, held by a third-party
payment service, the third-party merchant bank account to receive
funds from the buyer credit card account on behalf of the merchant;
and a funds allocation application to allocate the received funds
to a receiving account of the merchant, the receiving account being
maintained by the third-party payment service.
Description
CLAIM OF PRIORITY
[0001] This application is a continuation of U.S. patent
application Ser. No. 10/941,510 filed Sep. 14, 2004, which is a
continuation of PCT Application PCT/US 04/22742 filed Jul. 16,
2004, the benefit of priority of each of which is claimed hereby,
and each of which are incorporated by reference herein in its
entirety.
FIELD OF THE INVENTION
[0002] An embodiment relates generally to the field of funds
transfer automation, and more specifically, to a method and system
to process credit card payment transactions initiated by
merchant.
BACKGROUND OF THE INVENTION
[0003] Credit cards (and debit cards that leverage credit card
processing networks) are a widely used financial instrument.
Accordingly, in order to appeal to a broad base of potential
buyers, it is advantageous for merchants to be able to receive
payment for goods or services utilizing a buyer's credit card. In
order to receive credit card payments, merchants are typically
required to establish so-called merchant bank accounts with
acquiring banks, into which a credit card fund transfer can credit
funds received in payment of goods or services. The establishment
of a merchant bank account is not a trivial undertaking. Approval
of a merchant bank account from an acquiring bank may take weeks to
receive. Further, there are numerous charges associated with the
maintenance and utilization of such merchant bank accounts. For
example, an acquiring financial institution (e.g., a bank), with
which the merchant bank account is established, typically charges
discount rates (e.g., 2%-3% of a transaction total) to settle
transactions. There are further reserve costs that the acquiring
financial institution may hold back to cover contested charges and
charge back fees.
[0004] Credit card payments to a merchant bank account may
furthermore be merchant-initiated, as is the typical case in a
"bricks-and-mortar" purchase scenario, or may be buyer-initiated
where the transaction occurs in an online environment. A brief
discussion is provided below regarding the processing of credit
card transactions that are both merchant-initiated and
buyer-initiated, within different environmental contexts.
[0005] FIG. 1 is a diagrammatic representation of a prior art
credit card transaction processing scheme in the traditional
"bricks-and-mortar" environment, where a buyer 10 is physically
present at a seller location 12, and accordingly able to present a
credit card to the seller 14. In this scenario, in order to
communicate the buyer's credit card information to a credit card
processing system, the seller 14 typically maintains an on-site
Point Of Sale (POS) terminal 16. The seller 14 swipes the buyer's
credit card through the POS terminal 16, which then provides the
relevant credit card information via a dialup connection,
established over a Plain Old Telephone Service (POTS) network 18,
to a payment gateway 20. The payment gateway 2.0 acts as interface
between external networks (e.g., the POTS network 18 or the
Internet) and a proprietary and secure network over which the
various components of a credit card processing system may
communicate.
[0006] The funds transfer request that is issued from the POS
terminal 16, in addition to including the credit card information
of the buyer, also includes (1) a merchant identification number,
identifying the seller's merchant bank account at an acquiring
financial institution, and (2) a terminal identification number
identifying the specific POS terminal 16. The terminal
identification number is utilized to distinguish between multiple
POS terminals 16 that may be operated by the seller 14, for example
at various locations.
[0007] From the payment gateway 20, the funds transfer request is
communicated to an authorization system 22 for the authorization
phase. The authorization system 22 communicates pertinent details
of the funds transfer request to an issuing bank 24, at which the
buyer's credit card account 26 is maintained. The issuing bank 24
will then make a determination as to whether the buyer's credit
card is valid and whether the buyer's credit card has the capacity
to absorb the relevant charge. The authorization system 22 may
also, in certain circumstances, communicate pertinent details of
the funds transferred to an authorization agent 28 (e.g. VISA,
MASTERCARD, AMERICAN EXPRESS, etc.), which is distinct at the
issuing bank 24, to determine whether the relevant credit card has
been reported stolen or the authorization agent is aware of any
other deficiencies. Having received. affirmative authorizations
from the issuing bank 24 and/or the authorization agent 28, the
authorization system 22 will, via the payment gateway 20 and the
POTS network 18, communicate the authorization back to the POS
terminal 16, this authorization then being displayed to the seller.
Responsive to the authorization, the POS terminal 16 will also
typically print a receipt for signature by the buyer 10.
[0008] Having now completed the authorization phase of a payment
processing operation, a settlement phase is then initiated.
Specifically, the funds transfer request, and the relevant
authorization, are communicated to a settlement system 30. The
settlement system 30 operates to transfer authorized funds for a
transaction from the buyer's credit card account 26 to the seller's
merchant bank account 34. A settlement may be performed in
real-time, but is more typically performed as part of a batch
operation once a day. The settlement process requires the
settlement system 30 to communicate details of the funds transfer,
including the amount, and merchant identification information to
both the issuing bank and the acquiring bank. At the issuing bank
24, the buyer's credit card account 26 is debited with the relevant
charge, and a record created in the buyer's credit card account
indicating, inter alia, so-called "merchant of record" information,
this information identifying the seller. At an acquiring bank 32,
the seller's merchant bank account 34 is credited with the relevant
amount. The seller's merchant bank account 34 is identified
utilizing the merchant identifier number communicated from the POS
terminal 16. At the acquiring bank 32, the relevant funds may then
be transferred from the seller's merchant bank account 34 to a
seller's check account 36.
[0009] It will be noted that the seller's merchant bank account 34
is indicated in FIG. 1 as being "present" merchant bank account,
indicating that the merchant bank account 34 is associated with a
physical POS terminal. Acquiring banks 32 may differentiate between
a "present" merchant bank account, which receives payments where
the buyer is "present" at a seller location and accordingly able to
physically present a credit card, and a so-called "not-present"
merchant bank account, for which the credit card information of the
buyer is not received by the physical presentation of a credit card
to the seller. The reason for the differentiation between "present"
and "not-present" merchant bank accounts is that the likelihood of
fraud against "not-present" merchant bank accounts is higher, and
accordingly the charges levied by the acquiring bank 32 for a
"not-present" merchant bank accounts are typically higher than
those levied for "present" merchant bank accounts.
[0010] Continuing with merchant-initiated credit card payment
transactions, FIG. 2 illustrates a credit card processing system to
enable merchant-initiated credit card payment transactions when the
buyer 10 is "not-present" at a seller location, and accordingly
unable to physically present a credit card to the seller 14 to
swipe through a POS terminal 16. FIG. 2 illustrates that the buyer
communicates order and credit card information 40 to the seller 14
verbally during a telephone call established between the buyer 10
and the seller 14. Of course, the order and credit card information
40 can be communicated utilizing any one of a number of other
mediums (e.g., fax, mail, email, web, phone etc.) to the seller 14.
In any event, the seller 14 receives the buyers 10 credit card
information without being physically presented the credit card, and
accordingly is unable to verify the signature on the credit card
against the buyer's 10 signature. In this case, as the seller 14
does not have the physical card, an alternative mechanism is
required in order to enable the merchant to initiate a credit card
payment transaction, utilizing the received credit card
information.
[0011] Accordingly, a seller computer system 42, to which the
seller 14 has access, is shown to host and execute a virtual POS
terminal application 44, into which the seller 14 can input the
buyer's 10 credit card information. The seller computer system 42
is coupled by a network 46 (e.g., the Internet) to a virtual POS
terminal service provider 48, which in turn processes and forwards
the credit card information to a payment gateway 20. From the
payment gateway 20, payment processing (i.e., the authorization and
settlement phases) is substantially similar to that described above
with reference to FIG. 1. One difference will be that the seller
merchant bank account 34, maintained by the acquiring bank 32,
would be flagged as a "not-present" merchant bank account in this
scenario.
[0012] FIG. 3 illustrates a typical prior art credit card
processing system that enables such buyer-initiated payment
transactions (as opposed to the merchant-initiated transactions
described above). In FIG. 3, the seller 14 operates a seller
website (or marketplace) 50 that hosts a payment application 52
accessible, via a network 54 (e.g., the Internet) by a browser 56
executing on a client machine 58. The seller website 50 may provide
a catalogue of items for user purchase, and the payment application
52 may provide a "check out" process to complete payment for items
selected for purchase by a buyer 10. Accordingly, the payment
application 52 may solicit credit card, and other personal
information, from the buyer 10, via the browser 56, and communicate
this information, again via the network 54, to the payment gateway
20. In certain applications, the payment application 52 may be
hosted on a server external to the seller website 50, in which case
the browser 56 may be redirected to a website of a payment service,
which itself hosts the payment application 52, in order to process
payment for purchases made via the seller website 50.
[0013] Once the payment gateway 20 receives the buyer's 10 credit
card information, the downstream processing of the transaction is
substantially similar to that described above with reference to
FIG. 1. Again, it will be noted that, for this scenario, the seller
merchant bank account 34 is designated as a "not-present" merchant
bank account.
SUMMARY OF THE INVENTION
[0014] A method to process credit card payment transactions,
initiated by a merchant, includes receiving a merchant-initiated
request for a transfer of funds from a buyer credit card account.
The transfer of funds from the buyer credit card account to a
third-party merchant bank account is initiated, the third-party
merchant bank account being held by a third-party payment service.
The third-party merchant bank account is to receive funds from the
buyer credit card account on behalf of the merchant. The received
funds are allocated to a receiving account of the merchant, the
receiving account being maintained by the third-party payment
service.
[0015] Other features of the present invention will be apparent
from the accompanying drawings and from the detailed description
that follows.
BRIEF DESCRIPTION OF THE DRAWINGS
[0016] The present invention is illustrated by way of example and
not limitation in the figures of the accompanying drawings, in
which like references indicate similar elements and in which:
[0017] FIG. 1 is a diagrammatic representation of a prior art
credit card transaction processing system that includes a physical
POS terminal at a seller location to enable merchant-initiated
credit card payment transactions.
[0018] FIG. 2 is a diagrammatic representation of a prior art
credit card transaction processing system that includes a virtual
POS terminal, hosted on a seller computer system, so as to enable
merchant-initiated credit card payment transactions.
[0019] FIG. 3 is a diagrammatic representation of a prior art
credit card transaction processing system that enables
buyer-initiated credit card transaction processing by providing a
buyer with access to a payment application utilizing which the
buyer can initiate a payment to a seller.
[0020] FIG. 4 is a block diagram illustrating an architecture of a
system to process a credit card payment transaction, according to
an exemplary embodiment of the present invention.
[0021] FIG. 5 is a diagrammatic representation of a system to
process credit card payment transactions, according to an exemplary
embodiment of the present invention, where credit card payment
transactions are merchant-initiated, and cause a transfer of funds
from a buyer credit card account to a "master" merchant bank
account owned by a third-party payment service.
[0022] FIGS. 6 and 7 present a flow chart illustrating a method,
according to an exemplary embodiment of the present invention, to
process credit card payment transactions initiated by a
merchant.
[0023] FIG. 8 is a user interface diagram, illustrating an order
entry user interface, according to an exemplary embodiment of the
present invention, that may be utilized by a seller to provide
credit card and other personal information to a virtual POS
terminal application hosted by a third-party payment service.
[0024] FIG. 9 is a user interface diagram illustrating an exemplary
transaction failed user interface that may be communicated to a
user, in one embodiment of the present invention, by a virtual POS
responsive to a declining of a credit card payment transaction.
[0025] FIG. 10 is a user interface diagram illustrating an
exemplary transaction success user interface that may, in one
embodiment of the present invention, be presented to a seller user
by a virtual POS terminal application hosted by a third-party
payment service.
[0026] FIG. 11 is a diagrammatic representation of a machine, in
the exemplary form of a computer system, within which a set of
instructions, for causing the machine to perform any one of the
methodologies discussed herein, may be executed.
DETAILED DESCRIPTION
[0027] A method and system to process credit card payment
transactions, initiated by a merchant, are described. In the
following description, for purposes of explanation, numerous
specific details are set forth in order to provide a thorough
understanding of the present invention. It will be evident,
however, to one skilled in the art that the present invention may
be practiced without these specific details.
[0028] FIG. 4 is a diagrammatic representation of a system 59 to
process credit card payment transactions, according to an exemplary
embodiment of the present invention. The exemplary embodiment
employs a client-server architecture, and a payment service 64,
operating in a server role, is accessible via a network 54 (e.g.,
the Internet) by a number of client machines. Exemplary client
machine 60 hosts a web client 61, in the form of a browser
application, to enable a user of the client machine 60 access to
various applications hosted by, and forming part of, the payment
service 64. A further exemplary client machine 62 hosts a virtual
POS programmatic access client 63, which facilitates programmatic
access to applications of the payment service 64. White the web
client 61 may be regarded as a "thin" client, the virtual POS
programmatic access client 63 may be regarded as a "fat" client,
and provides enhanced functions, and/or performs a greater variety
of operations on the client machine 62 than can be performed by the
web client 61.
[0029] Turning to the payment service 64, an interface to the
service 64 is provided, in an exemplary embodiment, by an
Application Program Interface (API) server 66, which provides a
programmatic interface, and a web server 68 (e.g., the MICROSOFT
IIS WEB SERVER), which provides a web interface to the payment
service 64. One or more application servers 70 host a number of
payment applications 72, including a virtual POS terminal
application 74, a funds allocation application 76, and an invoicing
application 78. The operations performed by these various
applications are described in further detail below. Client
applications are able to access the various payment applications
72, via the API server 66 and/or the web server 68, each of which
is shown to be coupled to the application server 70.
[0030] The application servers 70 are coupled to one or more
database servers 80, which facilitate access by the payment
applications 72 to one or more databases 82. The databases 82, in
the exemplary embodiment, are shown to store a user identification
table 84 and a funded accounts table 86, in addition to a large
number of other tables.
[0031] The virtual POS terminal application 74 is also able to
establish a connection, for the purposes of communicating data,
with a payment gateway 88, via the network 54.
[0032] FIG. 5 is a diagrammatic representation illustrating
interaction of the system 59, described above with reference to
FIG. 4, with elements of a credit card payment transaction
processing system. The various operations performed by the
components illustrated FIG. 4 are described below with reference to
the flow chart illustrated in FIGS. 6 and 7. Before commencing with
the operational description, it should be noted from FIG. 5 that
the payment service 64 has established a "master" third-party
payment merchant bank account (MA) 100, optionally of the "not
present" type, and a third-party payment service check account 102
with an acquiring bank 98. The merchant bank account 100 is
associated with the virtual POS terminal application 74, which is
hosted on the application servers 70 of the payment service 64.
[0033] Also to be noted is that the funded accounts table 86 may
contain records for a receiving account, in the exemplary form of a
seller funded account 87. The seller funded account 87 is
associated with the seller 14, and includes a record of funds,
maintained within the third-party payment service check account
102, that belong to the seller 14. The funded accounts table 86 is
also shown to maintain records for funded accounts for multiple
registered users of the payment service 64.
[0034] FIGS. 6 and 7 illustrate a flow chart depicting a method
110, according to an exemplary embodiment of the present invention,
to process credit card payment transactions, where a merchant
initiates the processing of transactions. The method 110 commences
at block 112, with the buyer 10 placing an order for goods or
services with the seller 14. In order to enable the seller 14 to
receive payment for the goods or services, the buyer 10 also
provides the seller 14 with personal information including credit
card information (e.g., a credit card number, buyer name, issuing
authority, expiration date etc.), and buyer identification
information (e.g., an email address). The provision of the personal
information may, for example, occur telephonically, as illustrated
in FIG. 5, or may be achieved using any one of a number of other
communication media (e.g., email, web form, fax, mail, etc.).
Accordingly, this scenario is what is traditionally regarded as a
"not-present" presentation of credit card information.
[0035] At block 114, now having the provided personal information
in hand, the seller 14 accesses a virtual POS terminal application
for the purposes of providing the buyer credit card information and
email address to the virtual POS terminal application. In one
exemplary embodiment, where the virtual POS terminal application 74
is hosted by the third-party payment service 64, this access may be
provided via a browser application 75, hosted on a seller computer
system 42. In an alternative embodiment, the virtual POS
application may comprise a client application that is hosted on the
seller computer system 42. In other embodiments, the virtual POS
application may be distributed, with certain components residing on
the seller computer system 42, with other components residing on
application servers 70 of the third-party payment service 64. In
any event, the seller 14 inputs the personal information of the
buyer into the virtual POS terminal application at block 1114.
[0036] Considering an exemplary embodiment in which the virtual POS
terminal application 74 is a fully hosted application, FIG. 8
illustrates an exemplary order entry interface 150 that may be
generated by the virtual POS terminal application 74, and
communicated to the seller computer system 42 via the network 54,
for display by the browser application 75. The order entry
interface 150 is shown to prompt the seller 14 for customer
information 152, including an email address 154, order details 156,
and the buyer's credit card information. The order entry interface
150 also includes notification information 160, prompting the
seller 14 to make the buyer 10 aware that the merchant of record
information, as will eventually appear on the buyer's credit card
statement, will identify both the third-party payment service 64
(e.g., ABC Corporation 162), as well as the seller 14 (e.g.
"JGOULDTESTO" 164).
[0037] At decision block 116 of the method 110, the virtual POS
terminal application 74 makes a determination whether the buyer 10
is a registered user of the third-party payment service 64. This
determination is made by comparing the personal information,
provided by the seller with personal information, regarding
registered users, stored within the user identification table 84.
For example, the email address 154 of the buyer 10 may be utilized
to determine whether the buyer 10 is a registered user.
[0038] In the event that the virtual POS terminal application 74
determines that the buyer 10 is in fact a registered user, the
invoicing application 78 is invoked to initiate a flow to enable
the seller to issue an invoice to the buyer 10, via the third-party
payment service 64. In this case, the credit card information
received at block 114 is discarded, and the processing of a credit
card payment transaction is terminated at block 120. The invoicing
application 78 may, for example, be an invoicing application such
as that offered by PAYPAL INC., an EBAY COMPANY.
[0039] Returning to decision block 116, should it be determined
that the buyer 10 is in fact not a registered user of the
third-party payment service 64 at block 112, the virtual POS
terminal application 74 performs a look-up in the user
identification table 84 to retrieve seller identification
information (e.g., a seller name) to be included in the transaction
of information to be provided to a payment gateway 88.
[0040] At block 124, the virtual POS terminal application 74
communicates a funds transfer request, via the network 54, to the
payment gateway 88. The funds transfer request includes, inter
alia, a merchant identification number, identifying the third-party
payment service merchant bank account 100, a terminal
identification number, identifying the virtual POS terminal
application 74, and the seller identification information retrieved
at block 122.
[0041] At block 126, the payment gateway 88 communicates the funds
transfer request to an authorization system 90, for authorization.
The authorization system 90, in turn communicates pertinent
information to an issuing bank 94, at which the buyer's credit card
account 96 is maintained.
[0042] At decision block 128, the authorization system 90
determines whether the funds transfer has been authorized or not.
If not, at block 130, a transfer decline is communicated back from
the authorization system 90, via the network 54, to the virtual POS
terminal application 74, which in turn provides an appropriate
communication back to the seller 114. In one exemplary embodiment,
this communication may take the form of a transaction failed user
interface 166, an exemplary embodiment of which is depicted in FIG.
9. The funds transfer request having been declined, the processing
of the credit card payment transaction then again terminates at
block 120.
[0043] On the other hand, should the funds transfer be authorized
at decision block 128, the method 110 progresses to block 132,
shown in FIG. 7. At block 132, the payment gateway 88 communicates
the funds transfer request to a settlement system 92 for
settlement.
[0044] At block 132, the authorization system 90 will additionally
communicate the transfer approval back to the virtual POS terminal
application 74, which may in turn again provide a communication to
the seller 14 that the transaction has been approved. In one
exemplary embodiment, this communication may take the form of a
transaction success user interface, in the exemplary form of a
transaction success web page 170, an example of which is provided
in FIG. 10.
[0045] At block 134, the settlement system 92 proceeds to debit the
buyer credit card account 96, maintained at the issuing bank 94.
The settlement system 92 further provides a merchant identifier
(e.g., the name of the third-party payment service, ABC.COM),
identifying the third-party payment service 64, and the seller
identification information (e.g., the name of the seller 14,
JGOULDTESTO) to the issuing bank 94 for inclusion within merchant
of record information to be associated with the buyer credit card
account. This information will be reflected on a credit card
statement issued by the issuing bank 94 to the buyer 10.
[0046] At block 136, the settlement system 92 then credits the
merchant bank account 100 of the third-party payment service 64,
which is maintained at the acquiring bank 98. The settlement system
92 further communicates the seller identification information for
association with an appropriate transaction record in the merchant
bank account 100.
[0047] At block 138, the acquiring bank 98 transfers the received
funds from the merchant bank account 100 to the check account 102
of the third-party payment service 6.4 maintained at the acquiring
bank 98.
[0048] At block 140, the funds allocation application 76, of the
third-party payment service 64, allocates funds to a receiving
account (e.g., the funded account 87) of the seller 14. The seller
identification information, provided at block 136, is utilized to
determine what funds received via the merchant bank account 100 and
the check account 102 are properly allocatable to the funded
account 87 of the seller 14. In one exemplary embodiment, the
actual funds attributed (or allocated) to the seller 14 may be
retained within the check account 102 of the third-party payment
service 64, with the funded account 87 maintaining a record of a
portion of the balance of the check account 102 that belongs to the
seller 14. In another embodiment, the third-party payment service
64 may in fact be a registered bank, and the allocation of funds
performed at block 140 may involve an actual transfer of value from
the check account 102 into a bank account (e.g., a check account)
maintained by the third-party payment service 64.
[0049] Accordingly, it will be appreciated that a "master"
third-party merchant bank account 100 is enabled, via the
third-party payment service 64, to receive merchant-initiated
credit card payments on behalf of multiple sellers 14, and then to
distribute payments so received to receiving accounts that are
maintained by, or are accessible via, the third-party payment
service 64. This may be advantageous in that it allows multiple
sellers 14 to leverage a merchant bank account 100 that has been
established, and is owned, by the third-party payment service 64.
Accordingly, sellers 14 are spared the inconvenience and costs
associated with establishing individual merchants accounts with one
or more acquiring banks. Further, as the merchant bank account 100
may receive payments on behalf of a large volume of sellers 14, the
size of the merchant bank account 100 may allow the third-party
payment service 64 to obtain certain cost efficiencies, which can
optionally be passed on to the sellers 14. Additionally, the
establishment of the third-party merchant bank account 100 enables
the third-party payment service 64 to optionally provide the
convenience of a virtual POS terminal application 74 to any number
of sellers 14, again without the inconvenience to the sellers 14 of
having to establish individual merchant bank accounts.
[0050] FIG. 11 shows a diagrammatic representation of machine in
the exemplary form of a computer system 200 within which a set of
instructions, for causing the machine to perform any one or more of
the methodologies discussed herein, may be executed. In various
embodiments, the machine operates as a standalone device or may be
connected (e.g., networked) to other machines. In a networked
deployment, the machine may operate in the capacity of a server or
a client machine in server-client network environment, or as a peer
machine in a peer-to-peer (or distributed) network environment. The
machine may be a personal computer (PC), a tablet PC, a set-top box
(STB), a Personal Digital Assistant (PDA), a cellular telephone, a
web appliance, a network router, switch or bridge, or any machine
capable of executing a set of instructions (sequential or
otherwise) that specify actions to be taken by that machine.
Further, white only a single machine is illustrated, the term
"machine" shall also be taken to include any collection of machines
that individually or jointly execute a set (.or multiple sets)of
instructions to perform any one or more of the methodologies
discussed herein.
[0051] The exemplary computer system 200 includes a processor 202
(e.g., a central processing unit (CPU), a graphics processing unit
(GPU) or both), a main memory 204 and a static memory 206, which
communicate with each other via a bus 208. The computer system 200
may further include a video display unit 210 (e.g., a liquid
crystal display (LCD) or a cathode ray tithe ((CRT). The computer
system 200 also includes an alphanumeric input device 212 (e.g., a
keyboard), a cursor control device 214 (e.g., a mouse), a disk
drive unit 216, a signal generation device 218 (e.g., a speaker)
and a network interface device 220.
[0052] The disk drive unit 216 includes a machine-readable medium
222 on which is stored one or more sets of instructions (e.g.,
software 224) embodying any one or more of the methodologies or
functions described herein. The software 224 may also reside,
completely or at least partially, within the main memory 204 and/or
within the processor 202 during execution thereof by the computer
system 200, the main memory 204 and the processor 202 also
constituting machine-readable media.
[0053] The software 224 may further be transmitted or received over
a network 226 via the network interface device 220.
[0054] While the machine-readable medium 222 is shown in an
exemplary embodiment to be a single medium, the term
"machine-readable medium" should be taken to include a single
medium or multiple media (e.g., a centralized or distributed
database, and/or associated caches and servers) that store the one
or more sets of instructions. The term "machine-readable medium"
shall also be taken to include any medium that is capable of
storing, encoding or carrying a set of instructions for execution
by the machine and that cause the machine to perform any one or
more of the methodologies of the present invention. The term
"machine-readable medium" shall accordingly be taken to included,
but not be limited to, solid-state memories, optical and magnetic
media, and carrier wave signals.
[0055] Thus, a method and a system to process credit card payment
transactions, initiated by a merchant, have been described.
Although the present invention has been described with reference to
specific exemplary embodiments, it will be evident that various
modifications and changes may be made to these embodiments without
departing from the broader spirit and scope of the invention.
Accordingly, the specification and drawings are to be regarded in
an illustrative rather than a restrictive sense.
* * * * *