Note: Descriptions are shown in the official language in which they were submitted.
CARDLESS CHALLENGE SYSTEMS AND METHODS
[0001] Blank.
[0002] Blank.
BACKGROUND
[0003] The present application is generally related to payment
transactions,
and more specifically to handling and/or authorizing payment requests by a
consumer for a transaction.
[0004] Many Internet transactions are performed using credit, debit, or
other
type of account number. If an unauthorized person is able to obtain the
account
number or other information used in a transaction, the account may be
compromised. The result may be unauthorized withdrawals or charges made by the
unauthorized person. Most fraud occurs because of compromised merchants and
acquirers who have received the account information during the transaction.
1
CA 3036173 2019-03-08
[0005] Although other systems attempt to prevent the merchant from
obtaining
the account number, such implementations require enrollment and extensive
infrastructure changes. For example, in Google Checkout, a merchant must write
new code to interface with a new entity, i.e. Google. Many additional requests
and
receiving of responses are added to the infrastructure of the merchant web
site, e.g.,
via a plug-in. The merchant also needs to configure settings for the checkout,
or
monitor a merchant page in order to track an order. The merchant also has to
cross-
reference its order number with a unique identification number generated by
Google.
Also, the consumer needs to enroll with Google to obtain the benefit of the
Google
.. Checkout procedure. All of these and other steps require a lot of work by
the
merchant and consumer, and at a minimum frustrate the adoption of Google
Checkout, along with the lack of other features.
[0006] Additionally, additional steps may be performed to protect a
card that is
compromised, stolen, or is being used without proper authorization of the
cardholder.
Prior methods attempt to authenticate the consumer in order to prevent
security
risks, such as fraud. However, such attempts have met with limited success.
With
the burgeoning growth of e-commerce and transactions conducted online,
opportunities for payment card theft have become more readily available. As a
result, online payment card fraud has also accordingly increased over the last
few
years. Despite many prevention efforts, payment card fraud continues to
account for
annual losses in the range of hundreds of millions of dollars. In addition to
losses
incurred due to payment card fraud, transactions lost due to false-positive
declines
(i.e., transactions that are incorrectly identified as fraudulent) also
annually cost
merchants and issuers hundreds of millions of dollars in sales.
[0007] Furthermore, existing industry solutions that combat payment card
fraud tend to be account- and issuer-oriented. In other words, individual
issuers may
employ different solutions to detect fraudulent activities on their respective
accounts
and detection is at a single account level. As a result, payment card fraud
that
occurs across multiple accounts from multiple issuers often goes undetected.
For
example, it would be difficult for an individual issuer to determine that an
usually high
number of payment cards used at a particular merchant have been compromised
and subject of fraud, since the fraud may only involve a small number of
payment
cards issued by that individual issuer.
2
CA 3036173 2019-03-08
[0008] Additionally, a limited time is typically allowed for an
authorization to
occur after a consumer has initiated the transaction, e.g., submitting a
payment
request via button on a web page. Thus, mechanisms that are used to
authenticate
the person, in order to prevent fraudulent activity, have very little time to
run. Thus,
only very simple mechanisms have been achieved thus far.
[0009] Better ways to perform electronic financial transactions and to
authenticate consumers, particularly when the consumer is initiating a
transaction
over the Internet, are desirable. Embodiments of the invention address the
above
problems, and other problems, individually and collectively.
BRIEF SUMMARY
[0010] Embodiments of the present invention provide systems and methods
for handling and/or authorizing payment requests by a consumer for a
transaction.
In one aspect, a challenge question is sent from the non-merchant to the
consumer
subsequent to receiving from the consumer a consumer message including payment
information, which may be done directly. Thereby, additional authentication
information may be obtained. Such additional authentication information can be
advantageously obtained when appropriate, and highly probative questions may
be
utilized, thereby providing greater security than previously available. In one
embodiment, only after the challenge period would the non-merchant authorize
or
send an authorization request to an issuer or send payment information to
another
entity, thus the time limit of the authorization request does not limit the
challenge
period. The result of the authorization may then be sent to the merchant as in
conventional methods, thus not requiring the merchant to alter any other
mechanisms or parts of its infrastructure.
[0011] In another aspect, a non-merchant server initiates a risk analysis
prior
to the consumer submitting payment information and calculates a first risk
score
based on the risk analysis. In this manner, a more efficient and/or complex
risk
analysis procedure may be implemented. In one embodiment, challenge questions
are presented to the consumer depending at least partially on the first risk
score.
[0012] In yet another aspect, the merchant serves an application (e.g. Web)
page to the consumer, where the page includes code that sends device
information
3
CA 3036173 2019-03-08
from the consumer to the non-merchant. The device information may be
advantageously used to begin a risk analysis in anticipation of receiving
payment
information from the consumer.
[0013] As used herein, the term "directly" can mean that the contents
of a
message are not viewed by another entity during the path between the stated
sender
and receiver of the message. A direct transmission via a network, such as the
Internet, will probably be sent through routers on its way to the receiver
from the
sender; however, such a transmission is still direct. Although the message may
be
routed by a routing server that is part of the Internet backbone, such a
server does
not view the contents. Also, as used herein, the term "server" can refer to a
computing system of one or more computers and network inputs and/or outputs
that
act as portals for a local network to a larger (wider) network, such as the
Internet.
Also, as used herein, the term "based on X" can mean that an analysis, result,
or
other determination uses X in a calculation but that other factors may also be
used.
Also, as used herein, the term "application page" may be a web page, a local
page
(e.g. a window) of an application running on a POS terminal, or any other
window,
screen, or page through which an application receives, sends, or displays
information to a consumer, including via text messages.
[0014] Other embodiments of the invention are directed to systems,
portable
consumer devices, and computer readable media associated with the above-
described methods.
[0015] These and other embodiments of the invention are described in
further
detail below with reference to the Figures and the Detailed Description.
BRIEF DESCRIPTION OF THE DRAWINGS
[0016] FIG. 1 shows a block diagram of a system 20 according to an
embodiment of the invention.
[0017] FIG. 2 shows a block diagram of one type of portable consumer
device.
[0018] FIG. 3 shows a plan view of a second type of portable consumer
device.
4
CA 3036173 2019-03-08
[0019] FIG. 4 shows a block diagram for a method 400 illustrating the
flow of
data during a transaction according to an embodiment of the present invention.
[0020] FIG. 5 shows a screen shot of a checkout page 500 according to
an
embodiment of the present invention.
[0021] FIG. 6 shows a block diagram of a method 600 illustrating the flow
of
data during a transaction where transaction information is sent from the
access
device to the payment processing network 26 according to another embodiment of
the present invention.
[0022] FIG. 7 shows a block diagram for a method 700 illustrating the
flow of
data during a transaction where challenges are presented to the consumer
according
to an embodiment of the present invention.
[0023] FIG. 8 shows a screen shot of a checkout page 800 used for
presenting challenge questions to a consumer according to an embodiment of the
present invention.
[0024] FIG. 9 shows a block diagram for a method 900 illustrating the flow
of
data during a transaction where a type of payment information is sent to the
merchant 22 from the payment processing network 26 according to an embodiment
of the present invention.
[0025] FIG. 10 shows a block diagram for a method 1000 illustrating
the flow
of data during a transaction where a type of payment information is sent to an
acquirer 24 from the payment processing network 26 according to an embodiment
of
the present invention.
[0026] FIG. 11 shows a block diagram of an exemplary computer
apparatus
usable with system and methods according to embodiments of the present
invention.
DETAILED DESCRIPTION
[0027] Embodiments of the present invention provide systems and
methods
for handling and/or authorizing payment requests by a consumer for a
transaction.
Challenge questions may be presented from the non-merchant to the consumer
after
receiving the payment information, thereby allowing a judicious determination
of
5
CA 3036173 2019-03-08
when to ask such challenge questions and allowing for the possibility of
asking more
complex and probative questions. The time limit for such challenge questions
may
not be constrained. Also, a risk analysis may be started prior to the consumer
submitting payment information, thus allowing an efficient and complex risk
analysis.
Information about an access device used by the consumer may be obtained at the
non-merchant from the access device with code sent to the access device from
the
merchant, and the device information may be used in the risk analysis.
[0028] I. System and Challenge Overview
[0029] FIG. 1 shows an exemplary system 20 according to an embodiment
of
the invention. Other systems according to other embodiments of the invention
may
include more or less components than are shown in FIG. 1.
[0030] The system 20 shown in FIG. 1 includes a merchant 22 and an
acquirer 24 associated with the merchant 22. In a typical payment transaction,
a
consumer 30 may purchase goods or services at the merchant 22 using a portable
consumer device 32. The merchant 22 could be a physical brick and mortar
merchant or an e-merchant. The acquirer 24 can communicate with an issuer 28
via
a payment processing network 26. The consumer may interact with the payment
processing network 26 and the merchant through an access device 34, such as a
point of sale (POS) terminal, personal computer, and a mobile phone. The
merchant
22 may also have, or may receive communications from, an access device 34 that
can interact with the portable consumer device 32, such as a debit card,
credit card,
smartcard, and a mobile phone.
[0031] In one aspect, communications to/from the merchant 22 are
provided
by one or more servers. A server may be any computer device that is connected
to
the communication channels provided. As used herein, the term merchant may be
used interchangeably with a merchant server. Similar communications involving
the
acquirer and issuer may also use a server.
[0032] As shown in FIG. 1, the payment processing network 26 may
comprise
a server 26(a), which may comprise a challenge question engine 26(a)-1. The
server 26(a) may also be in communication with a transaction history database
26(b)
and a challenge question database 26(c). The challenge question engine 26(a)-1
6
CA 3036173 2019-03-08
may simply extract challenge questions from the challenge question database
26(c).
Alternatively or additionally, the challenge question engine 26(a)-1 may
generate
challenge questions using information in the transaction history database
26(b).
[0033] The challenge questions may be static or dynamic in nature, as is
described in U.S. Patent Publication No. 2008/0005037 A1, entitled "CONSUMER
AUTHENTICATION SYSTEM AND METHOD". For example, the challenge question
engine 26(a)-1 may receive an authorization request message, for example, in
response to a consumer's request to purchase goods. It may thereafter retrieve
suitable
questions from the challenge question database 26(c) or may generate suitable
challenge questions on its own. For instance, in some cases, the challenge
question
engine 26(a)-1 may retrieve the question "What is your mobile phone number?"
from
the challenge question database 26(c) after receiving an authorization request
message
from a particular consumer. Alternatively, the challenge question engine 26(a)-
1 may
generate a dynamic question such as "Did you use this credit card at
McDonald's last
night?" The information pertaining to the particular restaurant that the
consumer 30 was
at the preceding day could be retrieved from the transaction history database
26(b).
[0034] The challenge question database 26(c) may be populated with
questions
of any suitable type. The questions may relate to a past location (e.g., the
consumer's
current home, the city that the consumer recently visited) or current location
(e.g., the
current location of the store that the consumer is currently at), the type or
name of the
merchant that the consumer is presently visiting or has visited in the past,
the
consumer's family or personal data (e.g., name, phone number, social security
number,
etc.), etc. The questions in the challenge question database 26(c) may be
generated by
the challenge question engine 26(a)-1 and subsequently stored in the challenge
question database 26(c). As will be described later, the challenge question
engine
26(a)-1 may determine whether to ask a question and which questions to ask
based on
device information received from the access device 34 and/or the selection of
items to
purchase, or type of transaction involved.
7
Date Recue/Date Received 2020-05-06
[0035] Alternatively, or additionally, the challenge questions may be
generated
from an external source and then subsequently stored in the challenge question
database 26(c). For example, the consumer 30 may use a browser on a personal
computer or the like to supply specific challenge questions to the server
26(a) via a
communication medium (not shown) such as the Internet.
[0036] In some embodiments, a consumer may determine the kinds and/or
quantity of challenge questions to ask himself or herself. For example, the
consumer
may specify that the consumer wants to be asked three challenge questions if
the
consumer visits a jewelry store, but only one question if the consumer visits
a fast food
restaurant. The types of questions posed by the consumer may be based on the
merchant type, frequency of purchasing, etc. Some concepts relating to user-
defined
authorization parameters are described in U.S. Patent Publication No.
2003/0172040
Al.
[0037] In preferred embodiments, the challenge questions are derived
from past
transaction data in the transaction history database 26(b). The consumer 30
may
conduct many, many transactions with the payment processing network 26 (and/or
the
issuer 28) over time. This consumer transaction information may be stored in
the
transaction history database 26(b) over time, and challenge questions may be
generated using the transaction information. The past transaction
information provides a good basis for authenticating the consumer 30, since
the
consumer 30 will know about what transactions that the consumer 30 has
conducted in
the past. For example, the consumer 30 may have used his credit card to pay
for a hotel
room in New York the previous day, and on the next day may be asked a question
such
as "Did you stay at a hotel in New York yesterday?" In another example, the
consumer
may have purchased an item that is more than $2000 the day before, and on the
next day may be asked "Did you make a purchase for more than $2000 yesterday?"
The questions/answers that are presented to the consumer 30 may be free form
in
30 nature and/or may include pre-formatted answers such as multiple choice
or true-false
answers from which the user may select.
[0038] The description below describes a process where the consumer
30 buys
an item over the Internet through a personal computer, e.g. at home or at
work.
8
Date Recue/Date Received 2020-05-06
However, in other embodiments the consumer may use an access device at the
merchant 22 to select the item, much in the same way as on the Internet. For
example, a consumer 30 may obtain items and scan them in to make the
selection.
In one embodiment, the application page (e.g. a web page) would then already
be at
the access device and thus would not need to be sent. The scanning device
could
also communicate with a consumer's phone, where either can communicate with
the
merchant 22, and the payment processing network 26.
[0039] II. Secure and convenient transactions
[0040] Methods according to embodiments of the invention can be
described
with reference to FIGS. 1 and 4. In a typical purchase transaction, the
consumer 30
initiates a purchase of a good or service at a merchant server 22 (e.g.
through a
merchant's website) using a portable consumer device 32 such as a credit card.
[0041] FIG. 4 shows a block diagram for a method 400 illustrating the
flow of
data during a transaction according to an embodiment of the present invention.
In
step 401, the items and the type of payment method are selected by the
consumer
30. As part of a checkout request, this information is sent from the access
device 34
to the merchant server 22, also referred to as the merchant. For example, the
consumer 30 picks the stock-keeping unit (SKU) number of items desired. In
this
example, the access device 34 may be a point of sale (POS) terminal at the
merchant 22.
[0042] In a pure Internet commerce transaction embodiment, the
consumer 30
has selected the items on a merchant's website by placing them in a shopping
basket or similar part of the merchant's website. The consumer 30 is then
offered
various payment options (also termed payment mechanism options herein). Then,
.. once the consumer selects a particular payment option such as a particular
credit
card (e.g. VISA, MasterCard, American Express, or Discover), the above
information
(i.e., shopping basket information, and credit card information) is sent to
the
merchant 22.
[0043] In a POS (point of sale) terminal example, a consumer 30 may
scan in
items at a checkout kiosk. This effectively fills up a virtual shopping
basket. The
consumer 30 can then select a type of payment by making a selection on a
display
9
CA 3036173 2019-03-08
screen associated with the POS terminal. Alternatively, the consumer 30 may
initiate a payment with the portable consumer device 32, for example, by
swiping a
card through an appropriate slot in the POS terminal. In another example, the
POS
terminal may be a contactless reader, and the portable consumer device 32 may
be
a contactless device such as a contactless card. The POS terminal can then
identify
the payment type and send information regarding the type of transaction to the
merchant 22.
[0044] In step 402, the merchant server 22 sends transaction
information to
the payment processing network 26 or other non-merchant entity. The
transaction
information may be sent in a transaction message. In one aspect, a server of
the
payment processing network 26 receives the transaction information, as well as
other messages and receiving other messages mentioned herein.
[0045] The transaction information includes a merchant identification
(ID), an
amount of the transaction, and a correlation ID, which ties together messages
associated with the same transaction. The correlation ID may be the same ID
that
the merchant normally uses internally to track a transaction, which is
advantageous,
since the merchant 22 does not have to create any additional infrastructure.
The
merchant 22 creates a message and sends it (Method="POST") to the payment
processing network 26 in a process via a communication channel that is
different
than the communication channel that exists between the access device 34 and
the
merchant 22. Optionally, information relating to the items (e.g. SKU) selected
may
also be sent as part of the transaction info.
[0046] Note that this step typically involves sending credit card
information
from the merchant 22 to the payment processing network 26. However, it is not
necessary to do this at this point, particularly in embodiments where the
merchant 22
does not receive the credit card information. For example, in some cases, only
information related to the shopping basket is sent. This information may just
be the
amount of the transaction, but also may include information about the items
selected,
which may be used to select challenge questions as described below. For
example,
an item being purchased may be an item that the consumer 30 does not normally
purchase and/or the merchant 22 may have a reputation for being a risky
merchant
(e.g., past fraud has been associated with the merchant).
CA 3036173 2019-03-08
[0047] In step 403, a checkout page, or other type of application
page, with a
mapping to the payment processing network 26 is sent to the access device 34.
The
page may be sent in response to the consumer 30 selecting an option to check
out
with the items selected in the virtual shopping cart. In one embodiment, the
merchant 22 serves a checkout page to the consumer 30, where the checkout page
has a "Submit Payment" button (or other mapping element) that has a
destination
address mapped to the payment processing network 26 The destination address
can be mapped to one or many computer apparatuses in the payment processing
network 26.
[0048] In step 404, payment information is sent from the access device 34
to
the payment processing network 26 or other non-merchant entity. The payment
information may be sent via a consumer message from the access device, which
may be done by any suitable protocol. A consumer message may be any message
sent from the consumer via any device used by the consumer (e.g. access device
34).
[0049] The payment information includes account information (such as
the
account number or other account identifier) of the consumer's account to be
used for
the transaction, and may include other numbers such as the credit card
verification
(CCV) number. In one embodiment of the invention, the payment information is
obtained from the consumer entering data into the checkout page. A purpose of
sending the identified consumer account is so that the account may be used as
a
funding source for the transaction, e.g., to buy selected items or otherwise
send
money to another individual or business.
[0050] In another embodiment of the invention, the payment information
is
obtained from the consumer 30 initiating the transaction with the portable
consumer
device 32, for example, at a POS terminal (acting as the access device 34).
Similarly, for this transaction, the destination of the account information is
the
payment processing network 26. The access device 34 can be programmed to
permanently erase the account information once the transaction is complete.
[0051] As the account information is advantageously not sent to the
merchant
22, there is not a risk of a security breach at the merchant 22, which can
cause a
compromise in consumer's information (e.g., credit card information).
11
CA 3036173 2019-03-08
[0052] In one embodiment, the receiver of the account information
(i.e.
non-merchant, payment processing network 26) already is aware of the account
information. In one aspect, the credit card is created at least partially
through or in
cooperation with the entity that administers or runs the payment processing
network
26 (e.g. a credit card provider). For example, the payment processing network
26
may create a portion of the account identifier as a Bank Identification Number
(BIN)
that is associated with the issuer 28. Accordingly, during the transaction, no
new
entities may become aware of the account information, and the account
information
is held by a minimum number of entities. In another embodiment, the payment
processing network 26 can perform clearing and settlement services. In yet
another
embodiment, the payment processing network 26 is able to send the account
information directly to the issuer 28.
[0053] In step 405, an authorization request message is sent from
payment
processing network 26 to the issuer 28. Note that the merchant 22 does not
provide
an authorization request message in the example shown. In step 406, the issuer
28
responds to the authorization request, which was initiated by the payment
processing network 26.
[0054] In step 407, the payment processing network 26 creates and
sends a
status message, which contains the correlation ID and the status of the
transaction,
e.g., whether or not the transaction is a success (with receipt) or failure.
Accordingly, the merchant server 22 does not see the account information in
this
embodiment. In some embodiments, the status information may also include the
transaction amount and/or items to be purchased, e.g., when the merchant 22
has
not received this information yet. The status message is one type of a funding
message that is sent from the payment processing network 26 to the merchant
server 22. A funding message may be any message sent from a non-merchant
server (such as payment processing network 26) to a merchant server 22.
[0055] Normally, in a conventional transaction, the merchant 22 would
receive
an authorization response from the acquirer 24, which would be in response to
the
merchant 22 sending an authorization request message after receiving the
payment
information. In the embodiment of Figure 4, the merchant 22 still receives an
authorization response message in the form of the status information. The
merchant
12
CA 3036173 2019-03-08
22 has the convenience of still using this same mechanism after it has matched
the
correlation ID with the items selected, thus providing simple mechanisms for
merchants to adopt more secure methods of conducting transactions.
[0056] In step 408, a receipt or confirmation of the transaction may
be sent to
the consumer 30. As shown, the receipt is sent from the merchant 22 to the
consumer 30. In another embodiment, the payment processing network 26 may also
send the consumer 30 the receipt.
[0057] Specific embodiments of how the payment information is directed
to
the payment processing network 26 will now be described.
[0058] III. Adoption of secure transactions
[0059] It is desirable to make it easy for merchants and consumers to
adopt
the secure transaction processes described herein. Unless the parties of the
transaction can perform secure transactions with little or no effort on their
part, the
secure transaction are less likely to be adopted. If the secure transactions
are not
adopted, fraud cannot be reduced. Accordingly, the embodiments described
herein
are easy to use and are likely to be adopted.
[0060] FIG. 5 shows a screen shot of a checkout page 500 according to
an
embodiment of the present invention. The checkout page 500 is served to the
consumer 30 (e.g., via an access device that the consumer is operating) from
the
merchant 22 (e.g., from a merchant's web server). This may occur after the
consumer 30 has selected items and activated a general checkout button
(checkout
request) on the merchant's website or at the merchant's POS terminal. The
information relating to the selected items may then be transferred from a
previous
page to page 500. Thus, page 500 may already have all or some of the items and
quantity information filled in. In another example, the page is presented on a
POS
display and the items are shown once an item is scanned.
[0061] The frame 510 of the window 500 shows the selections made by
the
consumer. For example, the consumer may have chosen 1 set of Golf Clubs, 5
Golf
Tees, and 1 pair of Golf Shorts. The quantity and price (individual and total)
for each
of the items may be displayed. The frame 520 includes options for selecting
the type
13
CA 3036173 2019-03-08
of payment mechanism desired, such as different types of credit/debit cards or
other
payment options. The payment frame 530 includes a place to input payment
information, such as the name and address of the payee, the account (card)
number
and a credit card verification number, if applicable. The Submit Payment
button 535
causes the payment information to be sent to either the merchant 22 or the
payment
processing network 26 depending on which payment option was selected. In one
embodiment, the payment frame 530 does not appear until the payment type is
selected.
[0062] When the consumer clicks on the option A 525, the shopping
basket
information from frame 510 is sent to the merchant 22 as described for step
401.
Option A 525 may be a stand alone button as shown, or it may be chosen from a
drop-down list or from some other list. When option A 525 is selected, the
destination of the payment information when the submit payment button 535 is
pressed is the payment processing network 26. Thus, the payment information
may
be sent directly to the payment processing network 26. The submit payment
button
535 and the payment options 525 and 527 are payment objects of the application
page.
[0063] In one embodiment, the destination of the submit payment button
535
is changed to the payment processing network 26. In another embodiment, the
destination of the submit payment button 535 can start out being the payment
processing network 26, and thus the destination stays the same. In yet another
embodiment, the destination address has no set value and the destination is
set to
be the payment processing network 26.
[0064] Option A 525 may be a single option or it may be a subset of
options,
.. e.g., a subset of four different options. In one embodiment, these four
options
correspond to different payment mechanisms that can be processed by the
payment
processing network 26. For example, a set of credit cards (such as VISA and
MasterCard) may be processed by payment processing network 26.
[0065] In one embodiment, the destination of the submit payment button
535
is changed by a new payment frame 530 being sent from the merchant 22 to the
access device 34. The new payment frame 530 has the "Submit Payment" button
535 with a destination mapped to the network 26. This may be the only change
to
14
CA 3036173 2019-03-08
the frame so that as far as the consumer is concerned, the page has not
changed.
In another embodiment, the new payment frame 530 may have a different
presentation with different fonts, locations to input the payment information,
different
payment information to enter, and different logos or advertising.
[0066] As to changes that are needed to be implemented by the merchant 22,
the option A button can have functionality for sending the shopping basket
information of frame 510 to the merchant 22. Also, the merchant 22 can have
the
destination of submit payment 535 changed. The change may be done by sending
over a new piece of HTML or other code, or having the destination change
dynamically based on code originally sent with the page, when the checkout
process
was initiated by the consumer 30.
[0067] In one embodiment, the new payment frame 530 is sent by the
merchant 22 as an !Frame (an HTML element) that points to a location within
the
payment processing network 26, and the payment frame 530 is served from the
payment processing network 26. In this case, the new payment frame 530 is sent
from payment processing network 26. For example, once the IFrame is received
by
the access device 34, it then submits a request to the payment processing
network
26 for the display information for the lframe.
[0068] Advantageously, the consumer 30 does not have to enroll into a
program or create an account to conduct secure transactions. As noted above,
payment information can be sent automatically to the payment processing
network
26, even though the consumer 30 does not supply a username and/or password. A
secure checkout is automatically performed when the payment option 525 is
chosen.
Accordingly, it is likely that consumers will adopt embodiments of the
invention, since
it is easy and convenient to use.
[0069] In one embodiment of the invention, as far as the consumer 30
knows,
the payment information is still sent to the merchant 22. Thus, this step can
be
transparent to the consumer. For example, the URL in the browser that is used
by
the consumer would not change and the rest of the page also would not change.
In
other words, the change in the destination of the submit payment button 535
can be
hidden from the consumer 30, so that the consumer's shopping experience is the
same as it has been in the past.
CA 3036173 2019-03-08
[0070] When the consumer 30 selects other options 527, then the
transaction
may proceed as normal. For example, the destination of the submit payment
button
535 would still be directed to the merchant 22. An authorization request
message
would be sent from the merchant 22, to the payment processing network 26, and
back to the issuer 28 in some embodiments. Also, the virtual shopping basket
information may not be sent to the merchant 22 when the button 527 is
activated, but
the virtual shopping basket information may be sent when the submit payment
button
535 is pressed.
[0071] As mentioned above, the change or selection of the destination
of the
"submit payment" button 535 may be performed with code sent to the access
device
34 operated by the consumer 30 in the initial serving of the page 500. Also,
the
transmission of the transaction information may be different from method 400.
[0072] FIG. 6 shows a block diagram of a method 600 illustrating the
flow of
data during a transaction where transaction information is sent from the
access
device 34 to the non-merchant, payment processing network 26 according to
another
embodiment of the present invention. Method 600 shows other embodiments where
the initial checkout page 500 includes code for sending payment information to
the
network 26 when the option A 525 is chosen and/or where the transaction
information is sent from the access device 34 to the payment processing
network 26,
as opposed to being sent from the merchant 22 to the payment processing
network
26.
[0073] In step 601, a checkout page (e.g. page 500) is served from the
merchant 22 to the access device 34 operated by the consumer 30. The checkout
page 500 may have a place for the consumer 30 to select the items or may
already
have all or some of the item and quantity information filled in, which may be
transferred from a previous page. In one embodiment, this checkout page 500
includes logic to select among a plurality of destinations for the payment
information
to be sent once a submit payment element (e.g. 535) is activated. The
selection is
based on the payment type selected. This may be done with IF statements, a
CASE
statement, or similar logic.
[0074] In one embodiment of the invention, the payment option A 525
has a
destination mapped to the payment processing network 26. Thus, in step 602 at
16
CA 3036173 2019-03-08
least some of the transaction information is sent to the payment processing
network
26 (without first being sent to the merchant 22) when payment option 525 is
selected
(e.g., clicked). This transaction information includes at least the amount of
the
transaction, and a merchant ID or merchant identifier. The transaction
information
may also include a transaction or correlation ID, which was sent by the
merchant 22
in page 500 or that was created at the access device 34, e.g., by code
embedded in
page 500. If the correlation ID is created at the access device 34, then the
correlation ID may be sent from the access device 34 to the merchant 22, e.g.
in
step 603 or in another step.
[0075] The payment option A 525 may also have a destination mapped to the
merchant server 22 so that the same transaction information is also sent to
the
merchant server 22 in an optional step 603. If this information is sent to the
merchant 525, the payment frame may be served from the merchant 22 as
described
in FIG. 4. The payment frame may be of a universal type or the merchant can
specify one that is designed to it (e.g. includes branding that it desires).
Alternatively, the payment processing network 26 can provide its own branding.
[0076] In the embodiment shown in FIG. 6, the web page 500 already
includes
the !Frame to retrieve the payment page 530 from the network 26. Once the
option
525 is chosen, the code in the checkout page 500 automatically knows to obtain
a
new payment frame 530 from the payment processing network 26.
[0077] Thus, in step 604, the payment frame is sent from the payment
processing network 26 to the access device 34. This payment frame has a
"Submit
Payment" element (e.g. 535) directed to the network 26.
[0078] Accordingly, in one embodiment, information regarding the
payment
type is not received by the merchant 22. The page sent to the consumer via the
access device 34 when a general checkout is requested may already have a
mapping of the submit payment element to payment processing network 22 even
though the consumer has not selected the form of payment yet. Once the
consumer
has selected the payment option A, the link to the payment processing network
30 26 is established using the mapping that has already been sent. In one
aspect,
information indicating that the payment network 26 was chosen is sent to the
merchant 22.
17
CA 3036173 2019-03-08
[0079] The rest of the steps of method 600 may be performed as the
comparable steps in method 400, or as described herein. For example, step 606
can send an authorization request to issuer 28; step 607 can send back the
authorization response from the issuer 28; and step 608 can send the status
information to merchant 22.
In one embodiment, the status information sent in step 608 can include the
amount
of the transaction and the items selected as the merchant 22 may not be aware
of
this information if step 603 is not performed. In step 609, a receipt or
confirmation of
the transaction may be sent to the consumer 30.
[0080] In one embodiment, an entity associated with the payment processing
network 26 can incentivize the use of embodiments of the invention by
providing a
discount in a fee charged to the merchant 22 if the merchant 22 uses
embodiments
of the invention.
[0081] IV. Complex challenges and risk analysis
[0082] The ability of payment processing network 26 to obtain payment
information from the access device 34 and not from the merchant 22 allows
challenges to be presented from the payment processing network 26 to the
consumer and the types of challenges can be more complex than those previously
available. For instance, more time can be made available for challenges, thus
allowing more challenges and more specific and complex questions.
[0083] FIG. 7 shows a block diagram for a method 700 illustrating the
flow of
data during a transaction where challenges are presented to the consumer
according
to an embodiment of the present invention. Method 700 presents a process flow
similar to method 400 for the first few steps. However, in other embodiments,
the
first few steps may be similar to that of method 600 or other methods
described
herein.
[0084] In step 701, the items selected by the consumer 30 and the type
of
payment method are sent from the access device 34 to the merchant server 22.
In
step 702, the merchant server 22 sends the transaction information to the
payment
processing network 26 or other non-merchant entity. In one embodiment, the
18
CA 3036173 2019-03-08
transaction information includes a merchant identification (ID), an amount of
the
transaction, and a correlation ID, which ties together messages associated
with the
same transaction. As mentioned above, the payment information may also be sent
from the access device 34 directly to the payment processing network 26.
[0085] In step 703, a checkout page with a mapping to the payment
processing network 26 is sent to the access device 34. This page may be sent
in
response to the consumer 30 selecting an option to checkout (e.g. a checkout
request) with the items selected in the shopping cart. In one embodiment, the
merchant 22 serves a checkout page to the consumer, where the checkout page
has
a "Submit Payment" button that has a destination address mapped to one or more
computer apparatuses (e.g. servers) in the payment processing network 26.
[0086] In step 704, device information may be obtained. In one
embodiment,
this occurs before the account information is sent. Device information may
include
an IP address for the access device 34, an operating system of the access
device
.. 34, a private value (such as a hash or other encrypted value) resulting
from code
running on the access device 34, or any other type of information correlated
to a
computing device. In one embodiment, the merchant 22 serves a checkout page to
the consumer 30, where the checkout page has a "Submit Payment" button mapped
to the payment processing network 26,and renders an lframe for device
information
collection, with a correlation ID reference. This is discussed in more detail
below. In
one aspect, when the payment processing network 26 is chosen, the device
information is sent and also then the items and amount are sent, either by the
merchant 22 or the consumer 30.
[0087] In one embodiment, the device information is saved in a
database or
.. other storage device accessible to the payment processing network 26. The
device
information can be stored associated with a particular consumer and/or a
particular
consumer account. In this manner, the device information for a current
transaction
can be compared to the device information for previous transaction, which can
be
used in calculating a risk score as described herein. The database of device
information may also include information based on the items that the person
has
purchased. The information in the database may then be used to deliver an
offer to
the consumer. For example, if a computer (access device) is known to be of a
19
CA 3036173 2019-03-08
certain age and the location of the computer is known to be near a particular
store, a
coupon for that store (possibly targeted specifically for computers) may be
sent to
the consumer via post mail, e-mail, or mobile application (such as SMS or
MMS).
[0088] In one embodiment, a merchant ID and the correlation ID are
sent
when the device information is sent. In one aspect, a specific device server
is used
in the collection that is different from the server used to verify the
transaction.
[0089] The device information may also include a user unique ID
(UUID),
which is not the account number. The device server may also request
DNA/pebbles
through the user's browser based on the UUID. The device server can then push
results to the application tier. The device information may be filed in a
local flat
activity in, e.g., an XML format.
[0090] The use of IFrames allows the device collection to work
transparently
and to not be compromised by browser controls, such as pop up blockers. In one
embodiment, if the device server is not available then a 'function not
available"
message is sent to the application server so that the transaction is not
disrupted,
thus allowing the user's experience to always be seamless.
[0091] In step 705, payment information is sent from the access device
34 to
the payment processing network 26 or other non-merchant entity. The payment
information includes the account number of the consumer, and may include other
numbers such as the credit card verification (CCV) number. As mentioned above,
the access device 34 may be a personal computing device (e.g. computer, phone,
PDA, etc.) of the consumer 30, or the access device 34 may be associated with
a
retail establishment, such as a POS terminal.
[0092] The payment processing network 26 may use the device
information or
the transaction information to initiate a risk analysis of the transaction.
For example,
if the IP address is not in the country, then the transaction would be
riskier, or if it is
an IP address never used before, e.g., not your home or work computer.
Mechanisms may also determine whether an IP address is being spoofed.
[0093] Initiating a risk analysis can refer to the start of a risk
analysis, parts of
which may be partially performed by another entity, or actual performance of
the risk
analysis.
CA 3036173 2019-03-08
[0094] Also, if an item, the items taken as a whole, or the amount
are unusual for
the consumer 30 to purchase, then the transaction may be characterized as
risky. Past
transaction information may be used to determine whether or not an item is an
unusual
purchase for the consumer 30. Other information may also be used, such as the
person's age, location of residence, or other information. For example, if the
consumer
30 is 75 years old and purchased a hang glider, then the transaction might be
characterized as risky.
[0095] A risk score that represents an account level risk associated
with the
corresponding transaction may be calculated from any of the information above.
Additional discussion for the calculation of a risk score can be found in U.S.
Patent No.
6,658,393 and U.S. Patent Publication No. 2005/0149455 Al. A transaction with
a high
initial risk score compared to a threshold criteria may be supplemented via
challenge
questions submitted to the consumer.
[0096] In step 706, a challenge message is sent to the consumer 30.
For
example, when the device, item, consumer info, or other information suggests
that the
transaction being conducted is risky, then challenge questions may be
presented in
order to increase the security. The messages may be in the form of challenge
questions. Examples of challenge questions may include questions about the
consumer's zip code, mother's maiden name, or more specific questions such as
past
purchases, etc.
[0097] The challenges may be sent to the access device 34 from which
the
account information was received, or it may be another device associated with
the
consumer, e.g., the consumer's mobile phone when it is not used as the access
device
34. In one embodiment, a code is sent to the consumer's mobile phone, and the
challenge question requests an input of the code. In one aspect, the code may
be
redeemable for a discount on the current transaction or a future transaction.
This code
may be sent before the payment mechanism is shown, thus incentivizing use of a
payment mechanism that is compatible (processable) by the network 26 (e.g.
option A 525).
21
Date Recue/Date Received 2020-05-06
[0098] In step 707, the consumer responds to the challenge question,
e.g.
providing a challenge answer. The process of sending challenge questions and
receiving challenge answers may be repeated.
[0099] After the challenge response has been validated as being
correct or
incorrect, a risk score may be provided to the issuer 28 for use in
determining
whether to authorize the transaction. The risk score may account for
correctness of
the challenge response, the place of purchase, the history of the card, the
amount of
the purchase, or any combination of the other criteria mentioned herein. Thus,
if an
incorrect response is provided, the transaction is not necessarily denied.
Also, more
than one challenge can be used. If two challenges are used and the response to
both are wrong, then there would be a greater chance that person would be
turned
down, i.e. a greater risk score. If one is wrong and the other right, then the
total
contribution to the risk score from the challenges may be zero or dependent on
the
confidence score (see below) of each challenge. One skilled in the art will
appreciate the different contributions arising from multiple challenge
questions.
[0100] Some challenge questions may be more reliable (confidence
score)
than other ones. The more reliable challenge questions may affect the risk
score
more. Thus, a more accurate and efficient risk score may be achieved. In one
aspect, the confidence score may be used as a weighting in determining the
overall
risk score, or similarly whether the user is considered to be authenticated.
[0101] In one embodiment, the limited time for the authorization to
occur after
a consumer has initiated the transaction, e.g., submitting a payment request
via
button on a web page, does not begin until the authorization request is sent
to the
issuer 28. Thus, as many challenge questions may be presented as desired.
Thus,
more complicated mechanisms may be achieved.
[0102] In step 708, the authorization request message is sent from the
payment processing network 26 to the issuer 28. Additional steps may be
performed
as in methods 400 or 600, or other methods described herein. The presentation
of
the challenge questions can be made to integrate with the checkout page
presented
to the consumer 30, as described in the embodiment below.
[0103] FIG. 8 shows a screen shot of a checkout page 800 used for
presenting challenge questions to a consumer according to an embodiment of the
22
CA 3036173 2019-03-08
present invention. In one embodiment, checkout page 800, or other type of
application page, has a similar layout compared to the checkout page 500. The
items 810-827 may have the same functionality as the corresponding items of
checkout page 500. Option A 825 may also have enhanced functionality.
[0104] In one embodiment, embedded software, such as a hidden frame, is
included in the checkout page 800 when it is sent to the consumer. This code
may
be used to initiate the device information collection process. The code may be
directly included in the page 800 or a link to the code may be included. An
exemplary line of a link to the code sent from the merchant 22 to the access
device
34 is <iframe src='http://www.ivisa.com/zfp_visa/php? Merchid=2000$corrid=123'
height=1 width=1 frameborder=0 scrolling=no></iframe>. The device information
may be sent at anytime after the page 800 is served to the consumer. For
example,
it may be immediately after the page is served, i.e. before the Option A 825
is
activated. In another embodiment, the device information is sent to the
network 26
after the option A 825 is activated, which selects the preferred payment
processing
network 26, or payment processing organization (e.g., Visa).
[0105] Also, after the option A 825 is chosen, the network-specific
frame 830,
which may use an !Frame, is presented to the consumer 30. The submit payment
button 835 has a destination address linked to the payment processing network
26.
After the submit payment button 835 is activated, a challenge question 840 may
appear, along with a text box 845 for entering an answer to the challenge
question
840. After any of these buttons or boxes are activated, they may disappear, as
signified by the dotted lines. The challenge questions and answers may be used
to
determine or alter a risk score as defined above. In one embodiment, the
incorrect
answers may be used to immediately deny the transaction.
[0106] The frame 830 may also be used to provide the feedback of
whether
the transaction is approved or not, e.g., via a box 850.
[0107] The device information may also include information as to the
type of
browser being used. This information may be used to determine how to provide
the
frame 830 and the challenge questions. For example, by knowing the browser
capabilities, the code may be served in a manner that is easily displayable
and
functional with the browser of the consumer. For example, different code may
be
23
CA 3036173 2019-03-08
used based on whether or not the access device is using a browser of a mobile
phone.
[0108] V. ADDITIONAL PROCESS FLOWS
[0109] In some embodiments, the organization and processing of the
authorization may differ from the embodiments presented above. The payment
processing network 26 does not always send an authorization request message to
the issuer 28. For example, after the payment processing network 26 has
received
the payment information, e.g. in step 404, or after the payment processing
network
26 has finishes the challenge process, e.g. after step 707, the payment
processing
network 26 can send some type of payment information to the merchant, a
merchant
acquirer, or a general use acquirer.
[0110] FIG. 9 shows a block diagram for a method 900 illustrating the
flow of
data during a transaction where a type of payment information is sent to the
merchant 22 from the payment processing network 26 according to an embodiment
of the present invention. Steps before step 904 may occur as described herein.
[0111] In step 904, payment information is sent from the access device
34 to
the payment processing network 26 or other non-merchant entity. The payment
processing network 26 may initiate a challenge process with the consumer 30,
continue with a risk analysis, or perform other steps as described herein or
known to
one skilled in the art. In one embodiment, the payment information includes an
account identifier for the account to be used for the transaction.
[0112] In step 905, payment information is sent from the payment
processing
network 26 (e.g. a server of a non-merchant entity) to the merchant 22. The
payment information may be sent as one type of a funding message that is sent
from
the payment processing network 26 to the merchant 22.
[0113] In one embodiment, the information sent in this step may
include a
same account identifier as received in step 904 or it may include a different
payment
identifier. For example, the payment processing network 26 can create a new or
artificial PAN (primary account number) or code from any symbols (possibly at
random) and can associate that number with the credit card number received in
step
24
CA 3036173 2019-03-08
904. The new number may be of the same size (e.g. # of characters) as the
actual
PAN.
[0114] In this manner, the merchant 22 still does not receive the
actual credit
card number of the consumer. The new number may also only be associated with
the credit card number for a limited time (i.e. temporary), thus preventing
that
number to be used again. In one embodiment, the new number can have a prefix
or
other part that signifies that it is not a real card number but an artificial
one created
for the purpose above.
[0115] In step 906, the merchant 22 sends a first authorization
request
message to the acquirer 24. In step 907, after the acquirer 24 receives the
first
authorization request message, the first authorization request message is then
sent
to the payment processing network 26. At this point, the payment processing
network 26 can match the new number with the actual account number of the
customer.
[0116] In step 907, the payment processing network 26 then, if necessary,
forwards the authorization request message with the account number and amount
to
the issuer 28 (step 908). This step is not necessary, e.g., when the payment
processing network 26 is also the issuer of the consumer account.
[0117] In step 909, the issuer 28 responds to the authorization
request
message. For example, the issuer 28 may accept the transaction or decline the
transaction, or may refer the transaction. In step 910, the payment processing
network 26 forwards the authorization response to the acquirer 24, which then
forwards the authorization results (step 911). Finally a receipt may be sent
to the
consumer (step 912).
[0118] FIG. 10 shows a block diagram for a method 1000 illustrating the
flow
of data during a transaction where a type of payment information is sent to an
acquirer 24 from the payment processing network 26 according to an embodiment
of
the present invention. Steps before step 1004 may occur as described herein.
[0119] In step 1004, payment information is sent from the access
device 34 to
the payment processing network 26 or other non-merchant entity. The payment
processing network 26 may then perform a challenge process with the consumer
30,
CA 3036173 2019-03-08
continue with a risk analysis, or perform other steps as described herein or
known to
one skilled in the art.
[0120] In step 1005, payment information is sent from the payment
processing
network 26 (e.g. a server of a non-merchant entity) to an acquirer 24. In one
embodiment, the information sent in this step may include a same account
identifier
as received in step 904 or it may include a different payment identifier as
described
above. In one embodiment, acquirer 24 may be an acquirer chosen or associated
with the merchant 22, and thus each merchant may have a different acquirer. In
another embodiment, the payment processing network 26 may use the same
acquirer 24 for all transactions, or at least the same acquirer for a group of
merchants.
[0121] In step 1006, the acquirer 24 sends a first authorization
request
message to the network 26. At this point, a server computer in the payment
processing network 26 can match the new number with the actual account number
of
the customer.
[0122] In step 1007, the payment processing network 26 then, if
necessary,
forwards the authorization request message with the account number and amount
to
the issuer 28 (step 908). This step is not necessary, e.g., when the payment
processing network 26 is also the issuer of the consumer account.
[0123] In step 1008, the issuer 28 responds to the authorization request
message. For example, the issuer 28 may accept the transaction or decline the
transaction, or may refer the transaction. In step 1009, the payment
processing
network 26 forwards the authorization response message to the acquirer 24,
which
then responds with the authorization results to the network 26(step 1010). In
step
1011, the payment processing network 26 can then send status information to
the
merchant 22 as in step 407. Finally a receipt may be sent to the consumer from
the
merchant 22 (step 1012). Alternatively, the payment processing network 26 can
send the receipt to the consumer 30, e.g., in parallel with status information
sent to
the merchant 22.
26
CA 3036173 2019-03-08
[0124] VI. VARIOUS EMBODIMENTS
[0125] As used herein, an "acquirer" is typically a business entity,
e.g., a
commercial bank that has a business relationship with a particular merchant or
an
ATM. An "issuer" is typically a business entity (e.g., a bank) which issues a
portable
consumer device such as a credit or debit card to a consumer. Some entities
can
perform both issuer and acquirer functions. Embodiments of the invention
encompass such single entity issuer-acquirers.
[0126] The consumer 30 may be an individual, or an organization such
as a
business that is capable of purchasing goods or services. In other
embodiments, the
consumer 30 may simply be a person who wants to conduct some other type of
transaction such as a money transfer transaction or a transaction at an ATM.
[0127] The portable consumer device 32 may be in any suitable form.
For
example, suitable portable consumer devices can be hand-held and compact so
that
they can fit into a consumer's wallet and/or pocket (e.g., pocket-sized). They
may
include smart cards, ordinary credit or debit cards (with a magnetic strip and
without
a microprocessor), keychain devices (such as the Speedpass TM commercially
available from Exxon-Mobil Corp.), etc. Other examples of portable consumer
devices include cellular phones, personal digital assistants (PDAs), pagers,
payment
cards, security cards, access cards, smart media, transponders, and the like.
The
portable consumer devices can also be debit devices (e.g., a debit card),
credit
devices (e.g., a credit card), or stored value devices (e.g., a stored value
card).
[0128] The access devices 34 according to embodiments of the invention
can
be in any suitable form. Examples of access devices include point of sale
(POS)
devices, cellular phones, PDAs, personal computers (PCs), tablet PCs, handheld
specialized readers, set-top boxes, electronic cash registers (ECRs),
automated
teller machines (ATMs), virtual cash registers (VCRs), kiosks, security
systems,
access systems, and the like.
[0129] If the access device 34 is a point of sale terminal, any
suitable point of
sale terminal may be used including card readers. The card readers may include
any suitable contact or contactless mode of operation. For example, exemplary
card
27
CA 3036173 2019-03-08
readers can include RF (radio frequency) antennas, magnetic stripe readers,
etc. to
interact with the portable consumer devices 32.
[0130] The access device 34 may also be a wireless phone. In one
embodiment, the portable consumer device 32 and the access device are the same
device. For example, a consumer may use a wireless to phone to select items to
buy through a browser.
[0131] When the access device 34 is a personal computer, the
interaction of
the portable consumer devices 32 may be achieved via the consumer 30 or
another
person entering the credit card information into an application (e.g. a
browser) that
was opened to purchase goods or services and that connects to a server of the
merchant, e.g. through a web site. In one embodiment, the personal computer
may
be at a checkout stand of a retail store of the merchant, and the application
may
already be connected to the merchant server.
[0132] An exemplary portable consumer device 32' in the form of a
phone may
comprise a computer readable medium and a body as shown in FIG. 2. (FIG. 2
shows a number of components, and the portable consumer devices according to
embodiments of the invention may comprise any suitable combination or subset
of
such components.) The computer readable medium 32(b) may be present within the
body 32(h), or may be detachable from it. The body 32(h) may be in the form a
plastic substrate, housing, or other structure. The computer readable medium
32(b)
may be a memory that stores data and may be in any suitable form including a
magnetic stripe, a memory chip, etc. The memory preferably stores information
such
as financial information, transit information (e.g., as in a subway or train
pass),
access information (e.g., as in access badges), etc. Financial information may
include information such as bank account information, bank identification
number
(BIN), credit or debit card number information, account balance information,
expiration date, consumer information such as name, date of birth, etc. Any of
this
information may be transmitted by the portable consumer device 32.
[0133] Information in the memory may also be in the form of data
tracks that
are traditionally associated with credits cards. Such tracks include Track 1
and
Track 2. Track 1 ("International Air Transport Association") stores more
information
than Track 2, and contains the cardholder's name as well as account number and
28
CA 3036173 2019-03-08
other discretionary data. This track is sometimes used by the airlines when
securing
reservations with a credit card. Track 2 ("American Banking Association") is
currently most commonly used. This is the track that is read by ATMs and
credit
card checkers. The ABA (American Banking Association) designed the
specifications of this track and all world banks must abide by it. It contains
the
cardholder's account, encrypted PIN data, plus other discretionary data.
[0134] The portable consumer device 32 may further include a
contactless
element 32(g), which is typically implemented in the form of a semiconductor
chip (or
other data storage element) with an associated wireless transfer (e.g., data
transmission) element, such as an antenna. Contactless element 32(g) is
associated with (e.g., embedded within) portable consumer device 32 and data
or
control instructions transmitted via a cellular network may be applied to
contactless
element 32(g) by means of a contactless element interface (not shown). The
contactless element interface functions to permit the exchange of data and/or
control
instructions between the mobile device circuitry (and hence the cellular
network) and
an optional contactless element 32(g).
[0135] Contactless element 32(g) is capable of transferring and
receiving data
using a near field communications ("NEC") capability (or near field
communications
medium) typically in accordance with a standardized protocol or data transfer
mechanism (e.g., ISO 14443/NFC). Near field communications capability is a
short-
range communications capability, such as RFID, BluetoothTM, infra-red, or
other data
transfer capability that can be used to exchange data between the portable
consumer device 32 and an interrogation device. Thus, the portable consumer
device 32 is capable of communicating and transferring data and/or control
instructions via both cellular network and near field communications
capability.
[0136] The portable consumer device 32 may also include a processor
32(c)
(e.g., a microprocessor) for processing the functions of the portable consumer
device
32 and a display 32(d) to allow a consumer to see phone numbers and other
information and messages. The portable consumer device 32 may further include
input elements 32(e) to allow a consumer to input information into the device,
a
speaker 32(f) to allow the consumer to hear voice communication, music, etc.,
and a
microphone 32(i) to allow the consumer to transmit her voice through the
portable
29
CA 3036173 2019-03-08
consumer device 32. The portable consumer device 32 may also include an
antenna 32(a) for wireless data transfer (e.g., data transmission).
[0137] If the portable consumer device is in the form of a debit,
credit, or
smartcard, the portable consumer device may also optionally have features such
as
magnetic strips. Such devices can operate in either a contact or contactless
mode.
[0138] An example of a portable consumer device 32" in the form of a
card is
shown in FIG. 3. FIG. 3 shows a plastic substrate 32(m). A contactless element
32(o) for interfacing with an access device 34 may be present on or embedded
within the plastic substrate 32(m). Consumer information 32(p) such as an
account
number, expiration date, and consumer name may be printed or embossed on the
card. Also, a magnetic stripe 32(n) may also be on the plastic substrate
32(m).
[0139] As shown in FIG. 3, the portable consumer device 32" may
include
both a magnetic stripe 32(n) and a contactless element 32(o). In other
embodiments, both the magnetic stripe 32(n) and the contactless element 32(o)
may
be in the portable consumer device 32". In other embodiments, either the
magnetic
stripe 32(n) or the contactless element 32(o) may be present in the portable
consumer device 32".
[0140] The payment processing network 26 may include data processing
subsystems, networks, and operations used to support and deliver authorization
services, exception file services, and clearing and settlement services. An
exemplary payment processing network may include VisaNetTm. Payment
processing networks such as VisaNetTM are able to process credit card
transactions,
debit card transactions, and other types of commercial transactions.
VisaNetTM, in
particular, includes a VIP system (Visa Integrated Payments system) which
processes authorization requests and a Base II system which performs clearing
and
settlement services.
[0141] The payment processing network 26 may include a server
computer. A
server computer is typically a powerful computer or cluster of computers. For
example, the server computer can be a large mainframe, a minicomputer cluster,
or
a group of servers functioning as a unit. In one example, the server computer
may
be a database server coupled to a Web server. The payment processing network
26
may use any suitable wired or wireless network, including the Internet.
CA 3036173 2019-03-08
[0142] The issuer 28 may be a bank or other organization that may have
an
account associated with the consumer 30. The issuer 28 may operate a server
which may have a challenge question engine. A transaction history database and
a
challenge question database may be in communication with a server of issuer
28.
The issuer server, challenge question engine, transaction history database,
and
challenge question database may operate in the same way or a different way
than
the payment processing network server 26(a), challenge question engine 26(a)-
1,
transaction history database 26(b), and challenge question database 26(c).
[0143] Embodiments of the invention are not limited to the above-
described
embodiments. For example, although separate functional blocks are shown for an
issuer, payment processing network, and acquirer, some entities perform all or
any
suitable combination of these functions and may be included in embodiments of
invention. Additional components may also be included in embodiments of the
invention.
[0144] VII. COMPUTER APPARATUS
[0145] FIG. 11 shows typical components or subsystems of a computer
apparatus. Such components or any subset of such components may be present in
various components shown in FIG. 1, including the access device 34, server
computers 26(a), 28(a), etc. The subsystems shown in FIG. 11 are
interconnected
via a system bus 1175. Additional subsystems such as a printer 1174, keyboard
1178, fixed disk 1179, monitor 1176, which is coupled to display adapter 1182,
and
others are shown. Peripherals and input/output (I/O) devices, which couple to
I/O
controller 1171, can be connected to the computer system by any number of
means
known in the art, such as serial port 1177. For example, serial port 1177 or
external
interface 1181 can be used to connect the computer apparatus to a wide area
network such as the Internet, a mouse input device, or a scanner. The
interconnection via system bus 1175 allows the central processor 1173 to
communicate with each subsystem and to control the execution of instructions
from
system memory 1172 or the fixed disk 1179, as well as the exchange of
information
between subsystems. The system memory 1172 and/or the fixed disk 1179 may
embody a computer readable medium.
31
CA 3036173 2019-03-08
[0146] Embodiments of the invention provide for a number of
advantages. For
example, the number of entities that know a credit card number can be kept at
a
minimum. Also, the amount of changes that a merchant needs to perform are
minimal, such as simply placing one or more IFrames into a checkout page.
Also,
transaction information, such as device info, amount of the transaction, and
the
subject items of the transaction can be provided to the network 26, so that
the
network 26 can, for example, get a head start on a risk analysis and also to
determine whether or not to present challenge questions. The challenge
questions
can also be more complex since an authorization request need not sent until
after
the challenge questions have been answered and no more questions are deemed
necessary.
[0147] The specific details of the specific aspects of the present
invention may
be combined in any suitable manner without departing from the spirit and scope
of
embodiments of the invention. However, other embodiments of the invention may
be
directed to specific embodiments relating to each individual aspects, or
specific
combinations of these individual aspects.
[0148] It should be understood that the present invention as described
above
can be implemented in the form of control logic using computer software in a
modular or integrated manner. Based on the disclosure and teachings provided
herein, a person of ordinary skill in the art will know and appreciate other
ways
and/or methods to implement the present invention using hardware and a
combination of hardware and software
[0149] Any of the software components or functions described in this
application, may be implemented as software code to be executed by a processor
using any suitable computer language such as, for example, Java, C++ or Perl
using, for example, conventional or object-oriented techniques. Computer
programs
incorporating features of the present invention may be encoded on various
computer
readable media for storage and/or transmission; suitable media include
magnetic
disk or tape, optical storage media such as compact disk (CD) or DVD (digital
versatile disk), flash memory, and the like. The computer readable medium may
be
any combination of such storage or transmission devices.
32
CA 3036173 2019-03-08
[0150] Such programs may also be encoded and transmitted using
carrier signals
adapted for transmission via wired, optical, and/or wireless networks
conforming to a
variety of protocols, including the Internet. As such, a computer readable
medium
according to an embodiment of the present invention may be created using a
data
.. signal encoded with such programs. Computer readable media encoded with the
program code may be packaged with a compatible device or provided separately
from
other devices (e.g., via Internet download). Any such computer readable medium
may
reside on or within a single computer program product (e.g. a hard drive or an
entire
computer system), and may be present on or within different computer program
products within a system or network.
[0151] The above description is illustrative and is not restrictive.
Many variations
of the invention will become apparent to those skilled in the art upon review
of the
disclosure. The scope of the invention should, therefore, be
.. determined not with reference to the above description, but instead should
be
determined with reference to the pending claims along with their full scope or
equivalents.
[0152] A recitation of "a", "an" or "the" is intended to mean "one or
more" unless
specifically indicated to the contrary.
33
Date Recue/Date Received 2020-05-06
