U.S. patent application number 14/176570 was filed with the patent office on 2014-06-05 for universal merchant platform for payment authentication.
This patent application is currently assigned to CARDINALCOMMERCE CORPORATION. The applicant listed for this patent is Chandra S. Balasubramanian, Michael A. Keresman, III, Francis M. Sherwin. Invention is credited to Chandra S. Balasubramanian, Michael A. Keresman, III, Francis M. Sherwin.
Application Number | 20140156532 14/176570 |
Document ID | / |
Family ID | 46150487 |
Filed Date | 2014-06-05 |
United States Patent
Application |
20140156532 |
Kind Code |
A1 |
Balasubramanian; Chandra S. ;
et al. |
June 5, 2014 |
UNIVERSAL MERCHANT PLATFORM FOR PAYMENT AUTHENTICATION
Abstract
A method of processing of a transaction between a first and
second party is provided. The method includes: receiving payment
information at a server operatively connected to a communications
network, the payment information identifying a particular payment
option used by the second party for the transaction, and the server
being equipped to format and route messages over the communications
network in different manners to accommodate a plurality of
different authentication protocols; determining which of the
different authentication protocols is prescribed for the type of
payment option identified in the payment information; selecting a
particular authentication protocol from the plurality of different
authentication protocols supported by the server; obtaining an
authentication determination for the transaction, including
formatting messages and routing the formatted messages over the
communications network in accordance with one or more mandates of
the selected authentication protocol.
Inventors: |
Balasubramanian; Chandra S.;
(University Heights, OH) ; Sherwin; Francis M.;
(Shaker Heights, OH) ; Keresman, III; Michael A.;
(Kirtland Hills, OH) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Balasubramanian; Chandra S.
Sherwin; Francis M.
Keresman, III; Michael A. |
University Heights
Shaker Heights
Kirtland Hills |
OH
OH
OH |
US
US
US |
|
|
Assignee: |
CARDINALCOMMERCE
CORPORATION
Mentor
OH
|
Family ID: |
46150487 |
Appl. No.: |
14/176570 |
Filed: |
February 10, 2014 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
13423557 |
Mar 19, 2012 |
8650118 |
|
|
14176570 |
|
|
|
|
12720857 |
Mar 10, 2010 |
8140429 |
|
|
13423557 |
|
|
|
|
11419829 |
May 23, 2006 |
7693783 |
|
|
12720857 |
|
|
|
|
10459849 |
Jun 12, 2003 |
7051002 |
|
|
11419829 |
|
|
|
|
60388094 |
Jun 12, 2002 |
|
|
|
Current U.S.
Class: |
705/44 |
Current CPC
Class: |
G06Q 20/10 20130101;
G06Q 20/12 20130101; G06Q 20/02 20130101; G06Q 20/04 20130101; G06Q
20/4014 20130101; G06Q 30/0613 20130101; G06Q 20/105 20130101; G06Q
40/06 20130101; G06Q 20/1085 20130101; G06Q 40/025 20130101; G06Q
20/102 20130101; G06Q 40/04 20130101; G06Q 20/042 20130101; G06Q
20/403 20130101; G06Q 20/108 20130101; G06Q 40/00 20130101; G06Q
20/40 20130101 |
Class at
Publication: |
705/44 |
International
Class: |
G06Q 20/40 20060101
G06Q020/40 |
Claims
1. A method that supports processing of a transaction conducted
between a first party and a second party, wherein the first party
accepts payment via a plurality of different payment options
selectable by the second party, said plurality of different payment
options being associated with a plurality of different
authentication protocols prescribed therefor, said method
comprising: receiving payment information over the Internet at a
server operatively connected to the Internet, wherein a particular
payment option used by the second party for the transaction said is
determinable from said payment information, and said server is
equipped to format and route messages over the Internet in
different manners to accommodate the plurality of different
authentication protocols; determining from the payment information
received at the server which of the different authentication
protocols is prescribed for the type of payment option identified
in the payment information; selecting, in accordance with the
determination made, a particular authentication protocol from the
plurality of different authentication protocols supported by the
server; and, obtaining an authentication determination for the
transaction, said authentication determination being produced in
accordance with the selected authentication protocol.
Description
[0001] This application is a continuation of U.S. patent
application Ser. No. 13/423,557, filed Mar. 19, 2012, which is a
continuation of U.S. patent application Ser. No. 12/720,857, filed
Mar. 10, 2010, which is a continuation of U.S. patent application
Ser. No. 11/419,829, filed May 23, 2006, which is a
continuation-in-part of U.S. patent application Ser. No.
10/459,849, filed Jun. 12, 2003, which claims the benefit of U.S.
Provisional Application No. 60/388,094, filed Jun. 12, 2002, all of
which are incorporated herein by reference in their entirety.
FIELD
[0002] The present inventive subject matter relates to the art of
authentication. It finds particular application in conjunction with
facilitating the authentication of an individual to conduct a
secure transaction with a credit or debit card or other payment
instrument or payment means over a communications network, e.g.,
the Internet, and it will be described with particular reference
thereto. It is to be appreciated, however, that the present
inventive subject matter is also amenable to other like
applications.
BACKGROUND
[0003] Internet commerce, or e-commerce as it is otherwise known,
relates to the buying and selling of products and services between
consumers and merchants over the Internet or other like
transactional exchanges of information. The convenience of shopping
over the Internet has sparked considerable interest in e-commerce
on behalf of both consumers and merchants. Internet sales, or like
transactions, have been typically carried out using standard credit
cards such as Visa.RTM., MasterCard.RTM., Discover.RTM., American
Express.RTM., or the like, or standard debit cards, i.e., check
cards or automated teller machine (ATM) cards which directly access
funds from an associated deposit account or other bank account.
Other payment methods have also been developed for making payments
in connection with e-commerce transactions. For example, these
include PayPal.RTM., Bill Me Later.RTM., Secure eBill, Western
Union, and the like.
[0004] While widely used for more traditional face-to-face
transactions, use of standard cards in connection with e-commerce
presents certain difficulties, including difficulties concerning
authentication or positive identification of the cardholder. For
example, maintaining consumer confidence in security has become
difficult with increased reports of fraud. The resulting
apprehension is also fueled by consumer uncertainty of the
reputation or integrity of a merchant with whom the consumer is
dealing. Questionable security of the consumer's card information
or other personal information typically submitted along with a
traditional e-commerce transaction (e.g., address, card number,
phone number, etc.) serves to increase apprehension even more.
Additionally, cardholders, merchants and financial institutions are
all concerned about safeguarding against fraudulent or otherwise
unauthorized transactions. Similarly, other payments methods are
concerned with security.
[0005] Accordingly, various payment networks have implemented
initiatives or programs aimed at safeguarding against fraud. For
example, Visa.RTM. and MasterCard.RTM. both support authentication
initiatives whereby a cardholder is authenticated by the bank or
financial institution issuing the card, i.e., the issuing bank.
FIG. 1, illustrates one such exemplary authentication initiative.
As shown in this example, a consumer/cardholder 10, e.g., employing
a suitable web browser or the like, is making an on-line purchase,
e.g., over the Internet, from a merchant 20. As is known in the
art, the illustrated back-end payment processing chain includes an
optional payment gateway 30, the merchant's financial institution
or acquiring bank 32, the credit card network 34 and the issuing
bank 36.
[0006] At a point of checkout, the consumer 10 selects an
appropriate payment method based on the initiatives supported by
the merchant 20. At this point, the consumer fills out the on-line
checkout form including a payment option, card number, expiration
date, etc. Based on the payment information, the merchant 20, via a
plug-in 22 installed on their server, passes a verify enrollment
request (VEReq) message to a directory 38 on a server, e.g.,
suitably operated by the credit card network 34. The directory 38
includes a database associating participating merchants with their
acquiring banks and a database associating card number ranges with
locations or addresses, e.g., universal resource locator (URL)
addresses, of issuing banks' authentication servers, e.g., the
authentication server 40 for issuing bank 36. The VEReq message is
a request to verify the enrollment of the card in the
authentication program, and it contains the card number provided by
the consumer 10.
[0007] Based on the card number range stored within the directory,
the VEReq message will be sent to the appropriate URL address for
the server 40 which returns to the merchant 20 via the directory 38
a response thereto, i.e., a verify enrollment response (VERes).
That is to say, the server 40 will verify the enrollment status of
the card and respond with a VERes message to the directory 38 which
is then passed back to the merchant's plug-in component 22.
[0008] Based on the VERes message (i.e., if positive), the merchant
plug-in component 22 will redirect the cardholder's browser to the
server 40 by passing it a payer authentication request (PAReq)
message generated by the merchant's plug-in component 22. The
consumer 10 then completes an authentication process directly with
the server 40. The authentication server 40 authenticates the
consumer/cardholder 10 and responds to the merchant 20 with a payer
authentication response (PARes) message including a digital
signature. The merchant's plug-in component 22 validates the
digital signature of the PARes and extracts the authentication
status and other specified data that is to be used by the merchant
20 during the payment authorization process carried out via the
back-end payment processing chain. For example, the merchant 20
sends an authorization/sale transaction to their payment gateway 30
along with the data elements received from the PARes. The payment
gateway 30 routes the data to the acquiring bank 32 based on the
acquirer's specification. The acquiring bank 32 then sends the data
via the appropriate credit card network 34 to the issuing bank 36
for settlement.
[0009] When using authentication initiatives such as the
aforementioned example, the credit card network often ensures
participating merchants that fraudulent transactions and other
charge backs, as they are known in the art, will not be the
merchants' responsibility provided the specified protocols have
been followed. However, there are considerable burdens placed upon
the merchants to participate in the authentication initiatives. For
example, typical installation of the merchant plug-in can be overly
burdensome using up resources, i.e., computing power, memory, data
storage capacity, etc., the merchant would otherwise prefer to
devote to other tasks. Often, the plug-in component can be
extremely large and/or cumbersome to implement on the merchant's
server. Moreover, for a merchant that participates in a plurality
of such authentication programs for multiple credit card networks,
the burden can be that much more, i.e., requiring a separate
plug-in component for each individual authentication initiative
they wish to support, especially considering that each credit card
network may have its own particular protocols, data fields that are
employed in the respective messages, specific data format
requirements, etc.
[0010] Further, the merchants are responsible for remaining current
with initiative protocols that can change periodically. That is to
say, as the authentication protocols are updated and/or changed by
the respective credit card networks, the merchants are likewise
responsible for updating and/or changing their plug-in components
to reflect those update and/or changes being mandated by the credit
card networks.
[0011] The present inventive subject matter contemplates a new and
improved system and/or method which overcomes the above-referenced
problems and others.
SUMMARY
[0012] In accordance with one aspect of the present invention, a
method is provided for supporting processing of a transaction
conducted between a first party and a second party. The first party
accepts payment via a plurality of different payment options
selectable by the second party, and the plurality of different
payment options are associated with a plurality of different
authentication protocols prescribed therefor. The method includes:
receiving payment information over a communications network at a
server operatively connected to the communications network, the
payment information identifying a particular payment option used by
the second party for the transaction, and the server being equipped
to format and route messages over the communications network in
different manners to accommodate the plurality of different
authentication protocols; determining from the payment information
received at the server which of the different authentication
protocols is prescribed for the type of payment option identified
in the payment information; selecting, in accordance with the
determination, a particular authentication protocol from the
plurality of different authentication protocols supported by the
server; and, obtaining an authentication determination for the
transaction in accordance with the selected authentication
protocol, including formatting messages and routing the formatted
messages over the communications network in accordance with one or
more mandates of the selected authentication protocol.
[0013] In accordance with another aspect of the present invention,
a system is provided for supporting processing of a transaction
conducted between a first party and a second party. The first party
accepts payment via a plurality of different payment options
selectable by the second party, and the plurality of different
payment options are associated with a plurality of different
authentication protocols prescribed therefor. The system includes:
means for receiving payment information over a communications
network at a server operatively connected to the communications
network, the payment information identifying a particular payment
option used by the second party for the transaction, and the server
being equipped to format and route messages over the communications
network in different manners to accommodate the plurality of
different authentication protocols; means for determining from the
payment information received at the server which of the different
authentication protocols is prescribed for the type of payment
option identified in the payment information; means for selecting,
in accordance with the determination made by the means for
determining, a particular authentication protocol from the
plurality of different authentication protocols supported by the
server; and, means for obtaining an authentication determination
for the transaction in accordance with the selected authentication
protocol, including means for formatting messages and routing the
formatted messages over the communications network in accordance
with one or more mandates of the selected authentication
protocol.
[0014] Numerous advantages and benefits of the present inventive
subject matter will become apparent to those of ordinary skill in
the art upon reading and understanding the present
specification.
BRIEF DESCRIPTION OF THE DRAWINGS
[0015] The present inventive subject matter may take form in
various components and arrangements of components, and/or in
various steps and arrangements of steps. The drawings are only for
purposes of illustrating preferred embodiments and are not to be
construed as limiting.
[0016] FIG. 1 is a block diagram illustrating a typical e-commerce
transaction carried out in accordance with an exemplary
authentication initiative/program of a credit card network.
[0017] FIG. 2 is a diagrammatic illustration showing a high level
overview of an exemplary processing of an authenticated commercial
transaction in accordance with aspects of the present inventive
subject matter.
[0018] FIG. 3 is a block diagram illustrating an exemplary merchant
server and exemplary merchant authentication processing system in
accordance with aspects of the present inventive subject
matter.
DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS
[0019] For clarity and simplicity, the present specification shall
refer to structural and/or functional network elements, entities
and/or facilities, relevant standards, protocols and/or services,
and other components that are commonly known in the art without
further detailed explanation as to their configuration or operation
except to the extent the same has been modified or altered in
accordance with and/or to accommodate aspects of the present
inventive subject matter.
[0020] In accordance with a preferred embodiment, the present
inventive subject matter serves as a centralized merchant
processing system for authenticated payments, allowing a merchant
or their proxy to securely and easily accommodate authentication of
consumers and/or cardholders in accordance with a variety of
authentication initiatives implemented by credit card networks or
other payment networks, and to process electronic transactions
through any payment network using a single platform. It also
enables merchants or their proxies to process these payments,
regardless of which payment network they are to be routed through,
with a single implementation. In one version, this is accomplished
using "thin-client" communication software which links information
with a centralized merchant authentication processing system (MAPS)
upon demand. Moreover, it allows them or a funding source to use
the established underlying payment processing infrastructure to
process their credit/debit or other payment instruments at
participating merchant sites.
[0021] The advantages to funding sources are: the ability to
authenticate users and process all electronic transactions through
a single platform; the ability to seamlessly process payments using
any given payment network; a reduction in processing costs;
increased use of their credit/debit or other payment instrument;
increased acceptance of their credit/debit or other payment
instrument; the ability to send authenticated payment and
authorization requests to any network; the ability to receive
detailed consumer purchasing behavior statistics. Likewise, there
are advantages to the merchant, including, but not limited to: the
ability to comply with, participate in, and enjoy the benefits of a
variety of different authentication initiatives; the ability to
authenticate consumers using different payment vehicles or credit
cards, thereby avoiding lost sales; and, protection from fraud.
[0022] The approach detailed in the present specification provides
a secure, scalable and modular solution for merchants to
participate in and support various payment authentication
initiatives, such as, e.g., Visa's 3-D Secure Verified by Visa
(VbV) and MasterCard's SecureCode and/or Secure Payment Application
(SPA). It provides payment gateways, acquirers, merchant service
providers (MSP) and independent sales organizations (ISO) an easy
and effective way to provide their merchants with the means for
cardholder or account holder authentication, as defined by various
authenticating programs, e.g., VbV, SecureCode, SPA, etc.
[0023] With reference to FIG. 2, a high level overview of an
exemplary commercial transaction carried out in accordance with
aspect of the present inventive subject matter is diagrammatically
illustrated. Via a computer, a consumer 50 shops at an on-line
merchant 60 using a selected payment instrument. When the
transaction is completed, transaction details are sent from the
merchant 60 to a transaction processing service provider (TPSP) 70
that formats and routes various messages and takes other defined
actions on behalf of the merchant 60 in accordance with
authentication protocols prescribed by the payment processing
network to which the payment instrument being used for the
transaction belongs. For example, as shown, there is an ATM card
payment processing network 70, a first credit card payment
processing network 72 for a first type or brand of credit card, a
second credit card payment processing network 74 for a second type
or brand of credit card, a check card payment processing network
76, and a private label credit card processing network 78, all of
which optionally support different authentication protocols. Of
course, optionally, other types of payment processing networks may
also be included. As shown, the TPSP 70 optionally obtains
transactions from the merchant and distributes them to the proper
payment processing networks, e.g., for direct authentication by the
entity issuing the payment instrument used in the transaction.
Having obtain an authentication determination, the authentication
service provider 70 then returns this determination to the merchant
60 so that it may be included when the transaction is submitted by
the merchant 60 to the established underlying payment processing
infrastructure, e.g., via an optional payment gateway 80.
[0024] More specifically, with reference to FIG. 3, an exemplary
server 100 operated by an on-line merchant and an exemplary
merchant authentication processing system (MAPS) 200 are shown. The
merchant server 100 includes a checkout processing function 102, a
payment processing function 104 and a thin-client 106 operative to
provide interworking between the server 100 and the MAPS 200. The
server 100 suitably hosts a website accessible over a
communications network (e.g., the Internet) by
consumers/cardholders to conduct commercial transactions, i.e., to
purchase good and/or services. That is to say, a
consumer/cardholder using an appropriate web browser or like
application may connect to the server 100 over the Internet to shop
on the hosted website.
[0025] Suitably, when a consumer/cardholder is done shopping, the
checkout processing function 102 is invoked thereby providing the
consumer's web browser with a checkout webpage whereby the
transaction amount (i.e., the total amount of payment due) is
established and/or presented and payment information collected. The
checkout processing function 102 supports payment with a plurality
of different types of payment instruments, e.g., credit and/or
debit cards, belonging to different payment processing networks,
e.g., Visa.RTM., MasterCard.RTM., etc. Alternately, other payment
options may include PayPal.RTM., Bill Me Later.RTM., Western Union,
Secure eBill, etc. That is to say, the consumer/cardholder
optionally selects the particular type of payment instrument or
payment method being used for the commercial transaction from a
plurality of supported payment types. Additionally, the checkout
processing function 102 is also used to collect the card number,
expiration date, and other relevant payment data from the
consumer/cardholder.
[0026] The payment processing function 104 submits completed
transactions to the established underlying payment processing
infrastructure (i.e., payment gateway, acquiring bank, payment
processing network, issuing bank, etc.) in the usual manner as
prescribed by the various payment processing networks.
[0027] The merchant's thin-client 106 is used for communicating
transaction data elements such as card number, account number or
name, transaction amount, etc. between the merchant's website and
the MAPS 200. The thin-client is not aware of the specific
processing logic or protocols prescribed for each payment
authentication initiative. Suitably, the thin-client 106 is a small
software component installed on the merchant's server 100, e.g.,
approximately 50 kilobytes in size. Alternately, the following
options for connecting to the MAPS 200 are also available in order
to cater to different merchants depending upon the merchant's
transaction processing volume, technical expertise, resource
availability and software standards: (i) an "easy connection"
implementation, as it is termed herein, i.e., a software-less
merchant client; and (ii) a "direct connection" implementation, as
it is termed herein, i.e., a direct integration within the MAPS
200. Nevertheless, the thin-client approach provides the merchant
with a thin (i.e., small) software object (e.g., approximately 50
kilobytes) that is used by the merchant to communicate with the
MAPS 200. Using the thin-client 106, the merchant can participate
within the various payment authentication initiatives, e.g., VbV,
SPA, etc., without any significant reprogramming of the server 100
or their website. Suitably, the thin-client 106 is available as a
COM object or a Java component that is integrated with the
merchant's established transaction handling process.
[0028] The thin-client software is used by the merchants to
securely communicate with the MAPS. The thin-client software is
used to format name/value pairs to the designated MAPS message
format and securely communicate the message to the MAPS system.
Suitably, the thin-client does not hold any payment authentication
specific business process logic. The thin-client supports the
following features: secure communication to the MAPS 200,
formatting data to the MAPS specific message format, and allowing
merchants to access response data.
[0029] Suitably, the architecture of the thin-client 106 includes a
request layer 110 and a response layer 112 that sit on top of a
message formatting layer 114 that sits on top of a communication
layer 116. The request layer 110 provides an interface that can be
accessed by the merchant's web site to provide data to the
thin-client 106 in the form of name/value pairs. The request layer
110 also exposes functions for the merchant to send messages to a
specific MAPS 200. The response layer 112 provides an interface for
returning responses to the website, e.g., returned as a function
call response to a send message instruction. The message formatting
layer 114 formats and translates traffic between the request and
response layers 110 and 112 which employ a name/value pairs format
and the communication layer 116 which suitably employs an XML
format to communicate with the MAPS 200. Of course optionally,
other formats may also be used to communicate with the MAPS 200,
e.g., Simple Object Access Protocol (SOAP), Short Message Service
(SMS), a Comma Separated Value (CSV) or other like format (using
flat files or batch files), etc. The communication layer 116
provides connectivity with the MAPS 200, e.g., via HTTPS (i.e.,
hypertext transfer protocol over secure socket layer (SSL)).
[0030] The MAPS 200 is a core component within the system. The MAPS
200 provides the functionality to merchants for participation in
the various different authentication programs and initiatives
supported by the payment processing networks. Suitable, the MAPS
200 architecture is extensible to support existing and new releases
of existing payment initiatives without requiring a total software
rewrite, and likewise accommodates addition of new authentication
initiatives. This approach leads to an easy implementation at the
merchant website level, i.e., where the processing logic and
message handling prescribed by the initiatives are controlled at a
central location rather than at an individual merchant level. That
is to say, any changes or additions implemented do not affect
individual merchants.
[0031] The MAPS 200 provides a secure infrastructure for processing
transactions based on payment authentication initiative
specifications. The MAPS 200 provides extensible software than can
seamlessly support future revisions of the existing payment
authentication initiatives and new payment authentication
initiatives. Preferably, the MAPS 200 provides complete abstraction
as to how each payment authentication initiative is implemented,
thereby providing one central location for any changes. Suitably,
the MAPS 200 is programmed with Java software to provide the
described functionality. The MAPS software architecture includes
the following layers: a connectivity layer 210 that sit on top of a
message distribution layer 220 that sit on top of a plug-in layer
230, and external connection layer 240. The external connection
layer 240 provides a generic interface that is used by the MAPS 200
to communicate with outside resources, e.g., the directory or the
like as prescribed by various authentication protocols.
[0032] The connectivity layer 210 provides a generic layer for
external entities such as merchants to connect to and process a
specific payment authentication transaction. The connectivity layer
210 supports the following connectors: an HTTPS server 212; a
"direct connector" 214, as it is termed herein; and, an "easy
connector" 216, as it is termed herein; and an optional "other
connector" 218, as it is termed herein.
[0033] The HTTPS server 212 receives and/or sends HTTP messages and
communicates them to and/or from the message distribution layer
220. This connecter is used by the thin-client 106 to communicate
with the MAPS 200. The direct connector 214 provides a Java
interface than can be used by a merchant integrating with the MAPS
200 using the direct connection approach. This connector exposes
the appropriate Java interfaces than can be used by the merchant
during integration. Messages received/sent using this connector are
also communicated to/from the message distribution layer 220. The
easy connector 216 provides a web server that is used to
communicate with the message distributor and also to communicate
with the cardholder. This connector interfaces with the cardholder
to perform the merchant functionality and interfaces with the
message distributor to communicate the relevant messages. Suitably,
the other connector 218 allows the connectivity layer 210 to be
expanded to support other communication and custom integration
options.
[0034] Implementing multiple connector types provides multiple ways
for merchants to integrate and participate within the various
authentication initiatives. By providing multiple integration
approaches, a wide variety of merchants can be supported depending
upon the merchant's technical expertise, resource availability and
transaction processing volume. That is to say, in addition to the
thin-client approach, a "direct connection" and "easy connection"
approach are also optionally available to merchants.
[0035] The direct connection approach is provided for merchants
which insist on or otherwise want to host and manage the product,
e.g., such merchants may be high transaction volume merchants
and/or merchants who have the technical resources to host and
manage the product. The merchant can use direct Java calls or the
like to interface with the MAPS 200 and communicate the appropriate
XML or other like messages. The direct connect interface is also
available via a local socket server provided as part of the MAPS
200. Merchants utilizing a software platform other than Java can
use the local socket server. Under the direct connection approach
the merchants provide their own hardware and/or software. On the
opposite end of the spectrum, the easy connection approach is
provided as a software-less integration approach for merchants that
do not wish to install the thin-client 106. Using the easy connect
approach, the merchant redirects the cardholder to the MAPS easy
connect web server. The web server acts on behalf of the merchant's
website and communicates with the MAPS 200 to provide the
appropriate processing for the appropriate authentication
initiative. Under this approach, the merchant redirects the
cardholder using HTTPS posts and receives the responses at a
specified response URL. HTTP redirections are performed via the
cardholder's browser. Using the easy connection approach the
merchant may place an appropriate script after the
cardholder/consumer has provided the merchant with appropriate
payment data, such as credit card number, expiration date, etc. The
merchant receives the authentication response at the URL specified
within a response URL field designated in the script.
[0036] The message distribution layer 220 is a component within the
software architecture that facilitates scalability, redundancy,
high availability and transaction processing speed. Suitably, the
message distribution layer 220 is developed using Java 2 Enterprise
Edition (J2EE) specifications related to transaction processing. It
is preferably a low footprint message distribution application
configured to route XML or other like messages to specific plug-in
components in the plug-in layer 230 for appropriate transaction
processing.
[0037] The plug-in layer 230 includes a plurality of individual
authentication initiative plug-in components 232 that listen to the
message distribution layer 220 for a specific message type. The
respective plug-in component 232 is activated by the message
distribution layer 220 that sends messages to the specified plug-in
component 232 based upon the type of payment instrument or method
being used for the transaction being processed. For example, as
shown, the MAPS 200 optionally includes plug-in components 232 for
Visa.RTM., MasterCard.RTM. and other payment instruments or
methods. Notably, the plug-in components 232 are freely and easily
updated, exchanged or otherwise manipulated as desired to comply
with new version of existing authentication initiatives, or
additional plug-in components are freely and easily added to
accommodate new initiatives, without any additional alterations to
the MAPS 200 or on the merchant side. In this manner, the merchants
are automatically kept in compliance with the latest authentication
initiatives without having to rework authentication processing
protocols on their server 100. Further, as other payment processing
enhancements are introduced and/or desired, e.g., currency
conversion, compliant plug-in components therefor may likewise be
developed and simply added to the plug-in layer 230 of the MAPS 200
thereby providing the merchant with the particular payment
processing functionality.
[0038] Additionally, the plug-in layer 230 optionally also supports
various management and/or administrative applications (not shown).
For example, a merchant registration application module may be made
available to merchant service providers (MSPs) for registering
their merchants within the appropriate payment authentication
initiatives. Suitably, the merchant registration application offers
a web-based application, where the merchants, based on
communications received from their MSPs, can register themselves
and download appropriate software and related integration
documentation. The merchant registration application also provides
registration/license key-based control to the MSP, where the MSP
can communicate a license key to the merchant that will be used to
authenticate the merchant during registration and download.
Optionally, the data elements collected from the merchants can be
customized as desired by the MSP.
[0039] An optional MSP administration application provides the MSP
with a web-based application that is used to administer merchants.
The MSP administration application may, e.g., provides the
following features: enabling/disabling merchants for use of the
MAPS 200; maintaining merchant profile information; etc. The MSP
administration application is optionally accessed directly via
XML/HTTP based application program interfaces (APIs) that may also
be used to integrate with other systems. Additionally, a merchant
self-service application allows the merchant to access their
profile information via the web. For example, the merchant
self-service application optionally offers the following features:
self profile management; access to transaction history; access to
raw message logs related to authentication processes; etc. The
merchant self-service application may be similarly accessed
directly via XML/HTTP based APIs that are optionally also used to
integrate with other systems.
[0040] As another option, a MSP reporting application provides a
web-based application for MSPs to view consolidated and individual
transaction listings. For example, the following reports may
optionally be provided as part of the MSP reporting application:
consolidated transaction count/dollar volume reports; individual
transaction reports; raw message logs; merchant registration
reports; and/or other customized reports.
[0041] As will be appreciated by those of ordinary skill in the
art, the MAPS 200 provides a method for authenticating a consumer
using one of a plurality of different types of payment instruments
(e.g., credit/debit cards) or payment methods to conduct a
commercial transaction over a communications network with a
merchant employing the MAPS 200. The payment instrument or method
may be either enrolled in or not enrolled in an authentication
program conforming to one of a plurality of authentication
protocols prescribed for the respective plurality of different
types of payment instruments by payment networks supporting the
same.
[0042] Suitably, via the thin-client approach (or alternately the
direct or easy connection approaches) the MAPS 200 obtains payment
information for the transaction from the merchant's server 100.
Suitably, the payment information includes a number or name
identifying the particular payment instrument or account being used
(i.e., the card number or account number or account name), an
expiration date, transaction details (i.e., the transaction amount,
etc), and other pertinent payment data. In the case of the
thin-client approach, the payment information is obtained from the
merchant's website or page via the request layer 110 in the form of
name/value pairs. The request layer 110 passes the payment
information to the message formatting layer 114 that translates it
into an XML or otherwise appropriately formatted message and passes
it to the communication layer 116. The communication layer 116 then
passes the message in the XML format or other suitable format to
the MAPS 200 via the HTTPS server 212 in the connectivity layer
210.
[0043] Upon receiving the payment information, the MAPS 200
determines the type of payment instrument or method being used from
the payment information. Notably, the payment processing network to
which a credit/debit card belongs can be determined from the card
number as is known in the art.
[0044] Optionally, the MAPS 200 determines from the enrollment
status of the particular payment instrument or account being used
for the transaction. For example, the MAPS 200 may maintain a local
cache or database of card numbers that identifies those payment
instruments enrolled for participation in various authentication
programs and/or initiatives. If the particular payment instrument
being used is not enrolled in a particular authentication program
for the determined type of payment instrument or method, then the
process may be ended at this point with the MAPS 200 retuning a
"not enrolled" message or data back to the thin-client 106
installed on the merchant's server 100. Accordingly, the
thin-client 106 passes this information to the payment processing
function 104 to be bundled with the transaction data for submission
of the completed transaction to the established underlying payment
processing infrastructure. It is to be appreciated, that the
returned "not enrolled" message or data, as with all such
information returned to the merchant, is provided by the MAPS 200
through the thin-client 106 (i.e., through the communication layer
116, the message formatting layer 114 and the response layer 112)
such that it emerges already formatted and/or otherwise in
compliance with the appropriate authentication protocols prescribed
so that the merchant does not have to manipulate the data further
prior to submission to the established underlying payment
processing infrastructure.
[0045] Alternately, if the particular payment instrument being used
is enrolled in an authentication program, then the payment
information is passed to the message distribution layer 220 that
routes it to the proper plug-in component 232 in the plug-in layer
230. The plug-in component 232 then handles, administers and/or
otherwise executes set procedures prescribed for the respective
authentication program employing the appropriate protocols and/or
logic to obtain an authentication determination for the
transaction. For example, the plug-in component 232 formats and
routes messages in accordance with the authentication protocols
prescribed for the determined type of payment instrument or method
being used. Having obtained the authentication determination, the
MAPS 200 returns the same to the merchant's server 100.
[0046] Suitably, the plug-in components 232 are programmed to
administer any of a variety of authentication protocols as may be
prescribed for different types of payment instruments or methods
support be various payment processing networks. For example, to
accommodate a particular authentication initiative, a particular
plug-in component 232 optionally formats and routes a messages to
an issuing entity, e.g., an issuing bank having issued the
particular payment instrument being used for the transaction,
requesting that the issuing entity confirm the enrollment status of
the particular payment instrument being used for the transaction.
Upon obtaining a response to the enrollment request message from
the issuing entity, the information may be returned to the
merchant's server 100 in the same manner as if the MAPS 200
performed the enrollment check itself.
[0047] Additionally, once the enrollment status is determined to be
positive, the operative plug-in component 232 optionally formats
and routes a second message to the merchant such that the
consumer/cardholder is redirected to the issuing entity for
completing authentication directly therewith, whereupon the
authentication determination is made. A response containing the
authentication determination made by the issuing entity is then
returned in accordance with routing instructions contained in the
second message so that it is obtained by the MAPS 200. Suitably,
the routing instructions include a universal resource locator (URL)
directing the response back to the MAPS 200. Optionally, the
plug-in component 232 verifies that the response to the second
message was obtained from the issuing entity, e.g., by checking a
digital signature incorporated with the response. The MAPS 200 is
also optionally equipped to detect and/or qualitatively evaluate
the level and/or type of authentication employed to arrive at the
authentication determination, and this information may be
communicated to the merchant or others.
[0048] To further comply with another selected authentication
initiative, a particular plug-in component 232 is optionally
programmed such that the MAPS 200 is equipped to dynamically add
one or more data fields to the merchant's webpage so as to bring
the merchant's webpage into conformity with prescribed
authentication protocols for the determined type of payment
instrument. Additionally, other data elements and/or fields may
optionally be dynamically added, e.g., to provide currency
conversion, etc.
[0049] Suitably, the MAPS 200 further includes a database (not
shown) in which historical records of transactions processed by the
MAPS 200 are maintained. The historical records can then be
optionally accessed by the merchants or MSPs to perform audit trail
and/or reconciliation operations.
[0050] It is to be appreciated that the foregoing description and
the accompanying figures are merely exemplary in nature. In
particular, other hardware and/or software configurations
recognizable to one of ordinary skill in the art may be employed to
implement the present invention, and other similar payment
authentication initiatives, i.e., other than the exemplary VbV and
SPA, may likewise be supported without departing from the scope of
the present invention. Nevertheless, the architecture described in
the present specification achieves certain benefits. For example,
the availability of multiple implementation approaches (i.e.,
thin-client, direction connection and easy connection) allows a
customized fit to a variety of differently equipped merchants based
upon their transaction processing volume, technical expertise,
software and/or hardware resources, etc. Further, the centralized
MAPS 200 removes the burden otherwise placed on the merchant's
server 100 having to support multiple payment processing
initiatives providing substantially complete abstraction related to
individual payment authentication initiative processing rules and
logic, and with its extensible plug-in layer 230, provides
availability to multiple payment authentication initiatives with
one implementation on the merchant side.
[0051] Additionally, where the merchant employs a MSP to perform
payment processing and/or related tasks on the merchant's behalf,
it is to be appreciated that the MSP may effectively step into the
position of the merchant relative to the MAPS 200. For example,
rather than the thin-client 106 being installed on the individual
merchant's server 100, it may be installed on the MSP's server
which may use it on behalf of a single merchant or multiple
merchants serviced by the MSP. That is to say, information and/or
data to and/or from respective merchants would first be routed
through the MSP's server where it is exposed to and/or interacts
with the thin-client 106 installed thereon in essentially the same
manner as described above. Of course, any other suitable proxy may
similarly take the position of the merchant. Moreover, rather than
returning authentication determinations and/or other transaction
processing results back to the merchant, it is to be appreciated
that optionally the information or results may be sent or directly
forwarded from the MAPS 200 to any other selected or designated
entity within the chain completing back-end processing of the
completed transaction, e.g., a merchant's payment gateway,
acquiring bank, payment or credit card network, issuing bank,
etc.
[0052] The invention has been described with reference to the
preferred embodiments. Obviously, modifications and alterations
will occur to others upon a reading and understanding of this
specification. It is intended that the invention be construed as
including all such modifications and alterations insofar as they
come within the scope of the appended claims or the equivalents
thereof.
* * * * *