U.S. patent application number 13/934342 was filed with the patent office on 2014-01-09 for electronic commerce network with mobile transactions.
The applicant listed for this patent is Index Systems, Inc.. Invention is credited to Marc FREED-FINNEGAN, Jonathan WALL.
Application Number | 20140012701 13/934342 |
Document ID | / |
Family ID | 49879249 |
Filed Date | 2014-01-09 |
United States Patent
Application |
20140012701 |
Kind Code |
A1 |
WALL; Jonathan ; et
al. |
January 9, 2014 |
ELECTRONIC COMMERCE NETWORK WITH MOBILE TRANSACTIONS
Abstract
A commerce network that processes a mobile transaction detects a
mobile device of a user entering a store, the user having a
corresponding user account that includes one or more tenders. The
network creates a payment token corresponding to the detecting and
registers it with the store. The network receives a personal
identification number ("PIN") from the user and authenticates the
PIN. The network receives a basket of goods of one or more items
selected by the user for purchase, the basket of goods including
line level data for the items. The network then selects one or more
payment tenders from the one or more tenders based at least on the
line level data and validates and authorizes the selected payment
tenders.
Inventors: |
WALL; Jonathan; (San
Francisco, CA) ; FREED-FINNEGAN; Marc; (San
Francisco, CA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Index Systems, Inc. |
San Francisco |
CA |
US |
|
|
Family ID: |
49879249 |
Appl. No.: |
13/934342 |
Filed: |
July 3, 2013 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
61668254 |
Jul 5, 2012 |
|
|
|
61668255 |
Jul 5, 2012 |
|
|
|
61755135 |
Jan 22, 2013 |
|
|
|
Current U.S.
Class: |
705/26.8 |
Current CPC
Class: |
G06Q 20/3224 20130101;
G06Q 20/383 20130101; G06Q 20/20 20130101; G06Q 20/12 20130101;
G06Q 20/322 20130101 |
Class at
Publication: |
705/26.8 |
International
Class: |
G06Q 20/32 20060101
G06Q020/32 |
Claims
1. A computer readable medium having instructions stored thereon
that, when executed by a processor, cause the processor to process
a mobile transaction, the processing comprising: detecting a mobile
device of a user entering a store, wherein the user has a
corresponding user account that comprises one or more tenders;
creating a payment token corresponding to the detecting and
registering it with the store; receiving a personal identification
number (PIN) from the user and authenticating the PIN; receiving a
basket of goods of one or more items selected by the user for
purchase, wherein the basket of goods comprises line level data for
the items; selecting one or more payment tenders from the one or
more tenders based at least on the line level data; and validating
and authorizing the selected payment tenders.
2. The computer readable medium of claim 1, wherein the store has a
corresponding merchant account that comprises an acquirer and a
list of stores corresponding to a merchant.
3. The computer readable medium of claim 1, wherein the one or more
tenders comprises at least one of: a debit card, a credit card, a
gift card, a bank account, a coupon, a loyalty card or loyalty
points.
4. The computer readable medium of claim 1, wherein the line level
data for the items comprises for each item at least one of a brand,
a price, a size, or a stock keeping unit (SKU).
5. The computer readable medium of claim 1, wherein detecting the
mobile device of the user entering the store comprises detecting a
position of the mobile device relative to a geo-fence of the
store.
6. The computer readable medium of claim 1, further comprising
transmitting information to the mobile device after creating the
payment token and registering it with the store.
7. The computer readable medium of claim 1, wherein the user
account comprises a priority of usage of the one or more tenders,
and wherein the selecting is based at least on the priority.
8. The computer readable medium of claim 1, further comprising: for
each selected payment tender, sending a payment request to a
corresponding issuer of the tender.
9. A computer-implemented method of operating an electronic
commerce network, the method comprising: detecting a mobile device
of a user entering a store, wherein the user has a corresponding
user account that comprises one or more tenders; creating a payment
token corresponding to the detecting and registering it with the
store; receiving a personal identification number (PIN) from the
user and authenticating the PIN; receiving a basket of goods of one
or more items selected by the user for purchase, wherein the basket
of goods comprises line level data for the items; selecting one or
more payment tenders from the one or more tenders based at least on
the line level data; and validating and authorizing the selected
payment tenders.
10. The method of claim 9, wherein the store has a corresponding
merchant account that comprises an acquirer and a list of stores
corresponding to a merchant.
11. The method of claim 9, wherein the one or more tenders
comprises at least one of: a debit card, a credit card, a gift
card, a bank account, a coupon, a loyalty card or loyalty
points.
12. The method of claim 9, wherein the line level data for the
items comprises for each item at least one of a brand, a price, a
size, or a stock keeping unit (SKU).
13. The method of claim 9, wherein detecting the mobile device of
the user entering the store comprises detecting a position of the
mobile device relative to a geo-fence of the store.
14. The method of claim 9, further comprising transmitting
information to the mobile device after creating the payment token
and registering it with the store.
15. The method of claim 9, wherein the user account comprises a
priority of usage of the one or more tenders, and wherein the
selecting is based at least on the priority.
16. The method of claim 9, further comprising: for each selected
payment tender, sending a payment request to a corresponding issuer
of the tender.
17. A commerce network comprising: a first level authentication
module that detects a mobile device of a user entering a store,
wherein the user has a corresponding user account that comprises
one or more tenders, and creates a payment token corresponding to
the detecting and registers it with the store; a second level
authentication module that receives a personal identification
number (PIN) from the user and authenticates the PIN; a payment
processor module that receives a basket of goods of one or more
items selected by the user for purchase, wherein the basket of
goods comprises line level data for the items, selects one or more
payment tenders from the one or more tenders based at least on the
line level data, and validates and authorizes the selected payment
tenders.
18. The commerce network of claim 17, wherein the one or more
tenders comprises at least one of: a debit card, a credit card, a
gift card, a bank account, a coupon, a loyalty card or loyalty
points.
19. The commerce network of claim 17, wherein the line level data
for the items comprises for each item at least one of a brand, a
price, a size, or a stock keeping unit (SKU).
20. The commerce network of claim 17, wherein the user account
comprises a priority of usage of the one or more tenders, and
wherein the selecting is based at least on the priority.
Description
CROSS REFERENCE TO RELATED APPLICATIONS
[0001] This application claims priority of Provisional Patent
Application Ser. No. 61/668,254, filed on Jul. 5, 2012, Provisional
Patent Application Ser. No. 61/668,255, filed on Jul. 5, 2012, and
Provisional Patent Application Ser. No. 61/755,135, filed on Jan.
22, 2013, the contents of each of which is hereby incorporated by
reference.
FIELD
[0002] One embodiment is directed generally to a computer system,
and in particular to an electronic commerce network and system.
BACKGROUND INFORMATION
[0003] Electronic commerce, or "e-commerce", is generally
considered the buying and selling of a product or service over
electronic systems or a "commerce network" such as the Internet and
other computer networks. Electronic commerce can include
functionality such as mobile commerce, electronic funds transfer,
supply chain management, Internet marketing, online transaction
processing, electronic data interchange ("EDI"), inventory
management systems, and automated data collection systems.
Electronic commerce and a commerce network as a core function
provides the exchange of data to facilitate the financing and
payment aspects of business transactions.
[0004] The mobile commerce aspect of a commerce network, also
referred to as mobile transactions, mobile payment, and mobile
wallet, generally refers to payment services operated under
financial regulation and performed from or via a mobile device such
as a smartphone. Instead of paying with cash, check, or credit
cards, a user can use a mobile phone to pay for a wide range of
services and digital or hard goods.
[0005] There are many known models that can be used for mobile
commerce. These models include Short Message Service ("SMS") based
transactional payments in which the user sends a payment request
via an SMS text message and a premium charge is applied to the
user's phone bill or online wallet. Another model is direct mobile
billing in which the user uses the mobile billing option during
checkout at an e-commerce site, such as an online gaming site, to
make a payment. After authentication typically involving a personal
identification number ("PIN") and a password, the consumer's mobile
account is charged for the purchase.
[0006] Another known model is mobile web payments in which the user
uses web pages displayed or additional applications downloaded and
installed on the mobile phone to make a payment using Wireless
Application Protocol ("WAP"). Still another model is contactless
Near Field Communication ("NFC") in which a consumer using a
special mobile phone equipped with a smart card waves the phone
near a reader module. Most NFC transactions do not require
authentication, but some require authentication using a PIN before
the transaction is completed. The payment is deducted from a
pre-paid account or charged to a mobile or bank account
directly.
[0007] Each of these known models, and other known mobile commerce
models, have potential disadvantages, including security concerns,
lack of flexibility in that the user may be locked into a specific
vendor or financial institution, and being difficult to use,
especially when multiple or alternative forms of tender are
involved in a transaction. As a result, no single model
predominates the mobile commerce marketplace.
SUMMARY
[0008] One embodiment is a commerce network that processes a mobile
transaction. The network detects a mobile device of a user entering
a store, the user having a corresponding user account that includes
one or more tenders. The network creates a payment token
corresponding to the detecting and registers it with the store. The
network receives a personal identification number ("PIN") from the
user and authenticates the PIN. The network receives a basket of
goods of one or more items selected by the user for purchase, the
basket of goods including line level data for the items. The
network then selects one or more payment tenders from the one or
more tenders based at least on the line level data and validates
and authorizes the selected payment tenders.
BRIEF DESCRIPTION OF THE DRAWINGS
[0009] Further details, advantages, and modifications will become
apparent from the following detailed description of embodiments of
the invention, which is to be taken in conjunction with the
accompanying drawings, in which like numerals denote like
elements.
[0010] FIG. 1 is an overview diagram of an electronic commerce
network and associated peripheral devices in accordance with
embodiments of the present invention.
[0011] FIG. 2 is a block diagram of a computer server/system that
can implement the network of FIG. 1, and well as any of the
associated peripheral devices of FIG. 1, in accordance with an
embodiment of the present invention.
[0012] FIG. 3 is an overview diagram illustrating a user initiating
the functionality of the network of FIG. 1 in accordance with one
embodiment.
[0013] FIG. 4 is an overview diagram illustrating a merchant
initiating the functionality of the network of FIG. 1 in accordance
with one embodiment.
[0014] FIG. 5 illustrates a user being checked into a store with a
store account in accordance with one embodiment.
[0015] FIG. 6 illustrates a POS client at the merchant and using
the merchant account to checkout the user in accordance with one
embodiment.
[0016] FIG. 7 further illustrates the checkout process based on a
basket of goods selected by the user in accordance with one
embodiment.
[0017] FIG. 8 illustrates the functionality of a transaction engine
in accordance with an embodiment of the present invention.
[0018] FIG. 9 illustrates the functionality of the transaction
engine with multiple items and multiple payment/tender options in
accordance with an embodiment of the present invention.
[0019] FIG. 10 is a flow diagram of the functionality of the
commerce network module of FIG. 1 when providing mobile commerce
and conducting a mobile transaction in accordance with one
embodiment.
DETAILED DESCRIPTION
[0020] One embodiment is an electronic commerce network that
facilitates mobile transactions. The commerce network allows a user
with a mobile device to enter a store, and make a purchase of a
basket of goods. The purchase can be made using one or more
different tender instruments, including electronic coupons, gift
certificates, debit cards, credit cards, etc. The commerce network
authenticates the user, and can determine the best mix of tender
instruments to use for the particular basket of goods.
[0021] FIG. 1 is an overview diagram of an electronic commerce
network 100 and associated peripheral devices in accordance with
embodiments of the present invention. Network 100 is implemented by
one or more server computers ("servers") and is connected to the
peripheral devices via the Internet, or other telecommunication
means, to provide the functionality disclosed in detail below.
Network 100 includes and implements at least one user/customer
account 102, at least one merchant/retailer account 104 and at
least one issuer account 106. Network 100 further includes one or
more engines 110, including a transaction engine and a business
optimization engine, as described in more detail below. The
functionality of network 100 in one embodiment is accessible by any
user over the Internet using a browser or any other interface
method. The interface method can include application programming
interfaces ("API"s) 107, 122 and 132.
[0022] Network 100 functions as a fabric that connects accounts for
the principal parties of commerce--users, merchants, and issuers of
tender. Network 100 enables fluid commerce by making accounts
online and accessible. These accounts can be joined to facilitate
rich interactions including purchase transactions, offer
targeting/delivery, and other personalized experiences. The
accounts are made accessible by the associated peripheral devices,
including clients such as user clients 108, 109, and merchant-based
clients such as point of sale ("POS") client 120 and management
client 121, which extend the reach of network 100 to a user's
computer 109, mobile device 108, the merchant's counter via POS
120, and any other device that can interface with network 100.
[0023] FIG. 2 is a block diagram of a computer server/system 10
that can implement network 100 of FIG. 1, and well as any of the
associated peripheral devices of FIG. 1, in accordance with an
embodiment of the present invention. Although shown as a single
system, the functionality of system 10 can be implemented as a
distributed system. Further, the functionality of network 100 can
be implemented by a single system 10, or by multiple systems 10.
Further, any of the devices/functionality shown in FIG. 1 can be
implemented by one or more system 10s. Finally, all elements shown
in FIG. 2 are not required in any implementation of any portion of
network 100.
[0024] System 10 includes a bus 12 or other communication mechanism
for communicating information, and a processor 22 coupled to bus 12
for processing information. Processor 22 may be any type of general
or specific purpose processor. System 10 further includes a memory
14 for storing information and instructions to be executed by
processor 22. Memory 14 can be comprised of any combination of
random access memory ("RAM"), read only memory ("ROM"), static
storage such as a magnetic or optical disk, or any other type of
computer readable media. System 10 further includes a communication
device 20, such as a network interface card, to provide access to a
network. Therefore, a user may interface with system 10 directly,
or remotely through a network or any other known method.
[0025] Computer readable media may be any available media that can
be accessed by processor 22 and includes both volatile and
nonvolatile media, removable and non-removable media, and
communication media. Communication media may include computer
readable instructions, data structures, program modules or other
data in a modulated data signal such as a carrier wave or other
transport mechanism and includes any information delivery
media.
[0026] Processor 22 is further coupled via bus 12 to a display 24,
such as a Liquid Crystal Display ("LCD"). A keyboard 26 and a
cursor control device 28, such as a computer mouse, are further
coupled to bus 12 to enable a user to interface with system 10.
[0027] In one embodiment, memory 14 stores software modules that
provide functionality when executed by processor 22. The modules
include an operating system 15 that provides operating system
functionality for system 10. The modules further include a commerce
network module 16 that provides the functionality of commerce
network 100 of FIG. 1, as disclosed in more detail below. System 10
can be part of a larger system, such as a database management
system or a financial management system. Therefore, system 10 will
typically include one or more additional functional modules 18 to
include the additional functionality. A database 17 is coupled to
bus 12 to provide centralized storage for modules 16 and 18.
[0028] Referring again to FIG. 1, each user of network 100 is
represented by user account 102. User account 102 holds basic
profile information, global and merchant specific payment
preferences, and any number and type of tender instruments
including debit cards, private label cards, gift cards, bank
accounts, coupons, offers, loyalty cards, loyalty points, etc.
Users may access and manage this information through a range of
user clients such as clients 108, 109. The user clients can be any
device that allows access to network 100 over the Internet or other
network, and may include an Internet browser. The clients may
include a web page, mobile applications, and tablet interfaces
which enable users to add/delete tender instruments, view a
transaction history, and perform a range of other account
management functions. User account 102 facilitates the collection
and management of any tender type from any platform (e.g., web
page, mobile, social) by the user. User account 102 also enables
the seamless sharing of these tender instruments with the merchant
at the time of transaction via network 100.
[0029] Each merchant using network 100 creates a merchant account
104 that represents the merchant on network 100. Merchant account
104 holds basic information such as store address/location(s) and
merchant acquiring information that defines how payment should flow
to the merchant. Merchant account 104 also holds detailed user and
store level transaction information and analytics. Finally,
merchant account 104 contains information about merchant clients
such as POS client 120 and management client 121 which may access
and interact with merchant account 104. An authorized merchant POS
client such as client 120 may connect to network 100 via POS or
merchant APIs 122 to facilitate user authentication and transaction
settlement from the POS. Similarly, merchant management client 121
can interact with merchant account 104 via a web page or tablet
interfaces to access real-time analytics, configure account
settings, or interact with engines 110, including the business
optimization engine. The business optimization engine allows
merchants to tailor rich offers, loyalty rewards, and other
promotions to individual users or user segments to assist with
customer acquisition and retention.
[0030] Each issuer 130 of tender using network 100 has a
corresponding issuer account 106. An issuer account 106 may include
an authorization policy, an authorization mechanism and a
settlement mechanism for each tender type the issuer supports. The
authorization and settlement mechanisms specified for each tender
are executed by the transaction engine as it processes a
transaction. While traditional forms of tender use existing
infrastructure for authorization and settlement, newer forms of
tender may use new authorization and settlement mechanisms.
Therefore, in one embodiment the issuer API 132 includes new
authorization and settlement mechanisms, including authorization by
web services and direct settlement.
[0031] As discussed, embodiments interconnect users and
merchants/retailers to enable complex transaction processing and
other functionality. To initiate the functionality of network 100,
in one embodiment a user downloads an application to a mobile
device and sets up a user account 102. An account may be set up
through a website, a mobile application, or any other method.
[0032] FIG. 3 is an overview diagram illustrating a user initiating
the functionality of network 100 of FIG. 1 in accordance with one
embodiment. In one embodiment, the user could use a website via
user client/computer 109 to create a user account 102, set up the
password for the account, and create a personal identification
number ("PIN"). The user could also use the website to populate the
user account 102 with a debit card 303, a loyalty card 304 and a
coupon 305. Other tender instruments are possible. The user can
then download a "mobile commerce" application to the user's
client/mobile phone 108 and sign into account 102. At this point
the user is ready to use network 100. Alternatively, the user can
sign-up in a similar fashion through a retailer-branded web
interface or mobile application.
[0033] Similarly, to initiate the functionality of network 100, in
one embodiment a merchant first creates a merchant account 104
representing the corporate entity and then creates store accounts
for each physical store. FIG. 4 is an overview diagram illustrating
a merchant initiating the functionality of network 100 of FIG. 1 in
accordance with one embodiment. To accomplish this the merchant
would use a web page via merchant client 121 or other method. In
the example of FIG. 4, the merchant has a single store and creates
merchant account 104 and a store account of the single location 404
having store hours 405. The merchant would add information to the
store account describing how payments should be handled for that
store location. Specifically, the merchant will designate which
acquirer 402 and account 403 processed funds should flow into.
Acquirer 402 is the merchant's acquirer, also referred to as a
payment "processor". Examples of payment processors include First
Data Corp. ("FDC"), Fifth Third Processing Solutions, etc. Account
403 is the merchant's corporate level account or the individual
store's account on network 100.
[0034] Once the store account is setup, in one embodiment the
merchant integrates a "Beanstalk Library" into the merchant's POS
system. The Beanstalk Library allows the POS system/client 120 to
initiate transactions on network 100, much the same way that these
systems initiate transactions with a traditional acquirer. In one
embodiment, the Beanstalk library combines the functions of the
following known integration products: [0035] Credit processing
gateways (e.g., First Data Corp, Fifth Third, etc.); [0036]
Processing solutions (e.g., Chase Paymentech, Heartland Processing,
etc.); [0037] Gift card processing hosts (e.g., First Data
Valuelink, Store Value Solutions ("SVS"), ValuTec, Givex, Mercury
Gift Cards, etc.); [0038] Coupon redemption systems (e.g., NCH,
Inmar, etc.); [0039] Loyalty providers (e.g., City Retail Services,
SAP, TSYS, etc.); [0040] Voucher providers (e.g., Groupon, Living
Social, etc.); and [0041] POS hardware platforms (e.g., NCR,
Micros, etc). Once integrated, POS 120 is ready to initiate
payments on network 100. Payments initiated via a beanstalk API are
processed as described by the rules set up in the store account for
the physical store that initiates payment.
[0042] Once at least one user and one merchant and store account,
and one issuer has been set up, transactions can occur on network
100. FIG. 5 illustrates a user being checked into a store with a
store account in accordance with one embodiment. The example
beginning at FIG. 5 is for a transaction with a single item and a
single payment instrument.
[0043] As shown in FIG. 5, network 100 via the mobile commerce
application downloaded on the user's mobile device 108 observes the
user's location and uses this information to determine when the
user enters a store that has a corresponding store account on
network 100. The downloaded mobile commerce application uses GPS
signaling in one embodiment to determine when the user enters the
store by crossing a merchant geo-fence 502. A geo-fence is a
virtual perimeter for a real-world geographic area such as the
store.
[0044] To prepare the user to pay at the store, the user mobile
application sends a check-in request to network 100 indicating that
network 100 should prepare the user to pay at the store. Network
100 receives the check-in request and creates a single-use payment
token or "Bean" 510 for the user. Network 100 registers the token
510 with the store and replies to the user's mobile phone 108. If
desired by the user, the mobile phone 108 can be programmed to buzz
or otherwise alert the user to let the user know that they are
ready to pay at the store. Similarly, if the manager at the store
is looking at POS client 120 or Management Client 121, the manager
will notice that another user has entered the store by an
indication that pops up on client 120 or 121.
[0045] A Bean, such as Bean 510, in general is a session object
that captures the interaction events between a user and a single
store location. In one embodiment, a Bean object lifecycle begins
when a user enters the store location and ends when a user leaves
the store location. Other lifecycle initialization triggers and
ending triggers are possible. For example, a Bean could be
instantiated in an anonymous transaction by the store at the time
of a transaction initiation, and closed when the transaction
processing is complete. Bean 510 can be used for a single
transaction, or it may be applied to a user session in a store that
spans multiple refunds and purchase transactions.
[0046] In the current example where the user purchases a single
item, the user makes the selection of the item and heads to the
checkout. FIG. 6 illustrates POS client 120 at the merchant and
using merchant account 104 to checkout the user in accordance with
one embodiment. POS client 120 displays multiple methods of payment
on display 610, including credit and debit. One of the options is a
"mobile" option indicating payment via network 100. As the cashier
rings the user up, the user selects the "mobile" option and enters
the PIN number in the existing PIN pad.
[0047] At this point POS 120 uses the integrated Beanstalk Library
to authenticate the user via the PIN. To achieve this, the POS
software passes the user's PIN into the Beanstalk Library and
requests an authentication. The Beanstalk Library sends the request
to network 100 where the user's PIN is used to validate the user.
Once validated, the payment token 510 (that was created when the
user entered the store) is returned to POS client 120. POS client
120 is now ready for checkout.
[0048] FIG. 7 further illustrates the checkout process based on a
basket of goods selected by the user in accordance with one
embodiment. The basket of goods 700 is the line level data of the
one or more items that the user has selected for purchase. Basket
of goods 700 includes a full description of each item, including
the brand, price, size, stock keeping unit ("SKU"), etc. In
general, the description includes the core information of SKU,
price, tax and a list of additional key-value descriptors to cover
item or merchant specific characteristics such as color, category,
size, condition, etc. Once the cashier finalizes the transaction at
POS client 120, basket of goods 700 that the user selected is
passed into the Beanstalk Library. Basket of goods 700 (i.e., line
level data) and payment token/Bean 510 are then sent to network 100
for processing.
[0049] When the transaction request reaches network 100 it is
passed into a transaction engine 810. FIG. 8 illustrates the
functionality of transaction engine 810 in accordance with an
embodiment of the present invention. The checkout process is based
on basket of goods 700 selected by the user and the corresponding
line level data in accordance with one embodiment. Transaction
engine 810 reviews the basket of goods 700 being purchased,
compares them to the payment instruments in the user's user account
102, and selects the correct payment instrument(s) to use. If the
user had any item-specific coupons, they would be applied here.
However, in this example the user has no coupons and pays the full
amount with the user's debit card.
[0050] Once transaction engine 810 has selected the payment
instrument (in this example, the user's debit card), it looks up
the store account's processing preferences. In this example, the
store uses First Data Corporation, or other payment processor for
processing. Transaction engine 810 sends a request to FDC, or other
payment processor or partner, to put the full total of the
transaction (e.g., $5.00) on the user's debit card and waits for
the response.
[0051] Assuming the transaction is approved, transaction engine 810
sends a success response to POS 120. It then uses the basket of
goods to create a digital receipt and notify the user of the
purchase and an available receipt. Transaction engine 810 similarly
creates a receipt for the store and updates its real-time analytics
to reflect these sales.
[0052] In a variation of the preceding example, assume the user has
selected multiple items, and has manufacturer coupons in the user
account 102 for two of the items: a $10.00 off coupon for "Item A"
and a $5.00 off coupon for "Item B." In this example, the user's
check-in and PIN authentication proceeds in the same manner as
disclosed in the above example. However, when the transaction
reaches network 100, it is processed differently. FIG. 9
illustrates the functionality of transaction engine 810 with
multiple items and multiple payment/tender options in accordance
with an embodiment of the present invention. When transaction
engine 810 compares the basket of goods 700 to the user's user
account 102, which stores the coupons, it matches Item A to one of
the coupons, and matches Item B to the other coupon. Network 100 is
able to do this because it has received line level data for the
basket of goods from POS 120. It then applies these payment
instruments to the basket alongside the debit card.
[0053] Once the tenders are selected, transaction engine 810 sends
three transaction requests to the acquirer/processor: [0054] A
$10.00 Automated Clearing House ("ACH") payment from the Item A
manufacturer to the store. [0055] A $5.00 ACH payment from the Item
B manufacturer to the store. [0056] The remainder of the
transaction is placed on the user's debit card.
[0057] Transaction engine 810 then waits for the PIN debit
transaction to complete but not the ACH transactions, since they
can take much longer to complete. Receipts are generated and they
include information about the redeemed offers. If these offers were
part of a specific campaign, the campaign analytics would be
updated to reflect this usage.
[0058] As disclosed above, network 100 enables merchants to accept
any and all forms of tender, to complete complex multi-tender
transactions, and to effectively engage with customers across new
channels. Specifically, transaction engine 810 joins user accounts
102, merchant accounts 104 and issuer accounts 106 to enable the
flexible settlement of any type and any number of tenders for a
single transaction. In turn, this flexibility empowers merchants to
reach customers through new channels which require new
incentives/tender types for effective engagement. For example,
mobile web engagement might require the creation and distribution
of mobile advertisements/offers, a "Facebook" engagement might
require Facebook Offers or the distribution of Facebook Credits,
and an e-mail marketing campaign might require the creation and
distribution of e-mail offers/Groupon certificates, etc. By
supporting any tender type, network 100 effectively unlocks these
new channels to merchants and turns them into powerful and
measurable paths to reach customers. The resulting platform
provides a medium for users and merchants to seamlessly engage with
one another and fosters rich multi-channel relationships. Network
100 allows merchants to promote, distribute, accept and analyze
results for new tender types that most directly support their core
business.
[0059] FIG. 10 is a flow diagram of the functionality of commerce
network module 16 of FIG. 1 when providing mobile commerce and
conducting mobile transactions in accordance with one embodiment.
In one embodiment, the functionality of the flow diagram of FIG. 10
is implemented by software stored in memory or other computer
readable or tangible medium, and executed by a processor. In other
embodiments, the functionality may be performed by hardware (e.g.,
through the use of an application specific integrated circuit
("ASIC"), a programmable gate array ("PGA"), a field programmable
gate array ("FPGA"), etc.), or any combination of hardware and
software. The functionality of FIG. 10 can be implement by system
10 as shown in FIG. 2, or distributed over multiple system 10s.
[0060] At 1002, at least one user account, one merchant account and
one issuer account is established. Each user account holds basic
profile information, payment preferences and one or more tender
instruments, including debit cards, private label credit cards,
gift cards, bank accounts, coupons, offers, loyalty cards, loyalty
points, etc. Each merchant account holds basic information such as
store address/location(s) and merchant acquiring information that
defines how payment should flow to the merchant. Each issuer
account may include an authorization policy, an authorization
mechanism and a settlement mechanism for each tender type the
issuer supports.
[0061] At 1004, a user with a mobile client that has downloaded a
mobile commerce application, such as a smartphone, is detected
entering one of the stores of the merchant account. In one
embodiment, the user is detected when the user crosses a geo-fence
of the store using the user's smartphone GPS capability.
[0062] At 1006, a token or Bean is created and registered with the
store. A notification is optionally sent to the user indicating
that the user now can make payments at that store. This is the
completion of a first level of authentication. At this point, the
store is able to communicate with the user via the mobile client,
such as providing store information, advertisements, coupons,
etc.
[0063] At 1008, after the user selects one or more items to
purchase that form a basket of goods, the user approaches the
store's POS, selects the option to pay using the mobile commerce
network, and enters the mobile commerce PIN that was associated
with the user when the user created the user account. The PIN is
received by the commerce network 100 and is then authenticated at
the network, and the token is sent to the POS in the store. This is
the completion of a second level of authentication.
[0064] At 1010, the basket of goods of the user's selections,
including line level data for all items, is received by the network
100 for processing.
[0065] At 1012, the basket of goods is compared with the payment
instruments or tender in the user's user account, and the
appropriate one or more tenders are selected, validated and
authorized to complete the payment (referred to as tender
"extraction"). The tenders can include debit cards, credit cards,
electronic coupons, electronic group buying instruments such as
Groupon "deals"/certificates, electronic gift certificates, etc.
When more than one tender can be used to complete the payment, the
"best" tender is selected. For example, coupons or gift
certificates will be used before debit or credit cards, and the
remaining balance, if not completely satisfied by the coupon or
gift certificates, can be satisfied by the debit/credit cards.
[0066] At 1014, each of the one or more payment requests
corresponding to the tenders are sent to the corresponding issuer
by initiating/calling the appropriate settlement mechanism for each
tender.
Users
[0067] As discussed above, every user of network 100 has a user
account 102. User account 102 holds basic profile information,
global and merchant specific payment preferences, transaction
history, and any number and type of tender instruments including
debit cards, credit cards, private label cards, gift cards, bank
accounts, coupons, offers, loyalty cards, loyalty points, etc. The
tender instruments in the User account 102 are accessible at the
time of transaction and are used to facilitate payment in the
order/fashion prescribed by the user. The desired use of
instruments and the order in which they should be used is
determined by the user in a user account preferences file. In one
embodiment, these preferences may be set once and not modified
again, or the user could manually adjust these preferences before
each transaction.
[0068] Users can create, access and manage their user accounts 102
through a range of user clients (e.g., user clients 108, 109, or
any devices that enable the user to interface with network 100).
These clients include web pages, mobile applications, and tablet
interfaces which enable users to add/delete tender instruments,
view transaction history, and perform a range of other account
management functions. User clients access user account data via
commerce network 100 and present a consistent set of instruments
across interfaces. For example, whether a user looks at the
contents of user account 102 on web client 109 or on mobile client
108, the user will see the same set of instruments.
[0069] In one embodiment, a primary use for the user clients is
adding and managing instruments of tender. When a user adds an
instrument to user account 102, the instrument data is sent to
network 100 for secure storage in user account 102. In one
embodiment, once instrument data is added to user account 102, the
data exists exclusively in user account 102 and is never shared
with or stored in any of the clients. However, in one embodiment
user account 102 shares instrument references with the user clients
so that the clients can actualize a user interface that lets users
examine, delete and configure the instruments in user account 102.
Instrument references contain only enough information about the
instrument in one embodiment to allow it to be meaningfully
displayed in the user interface. Because the user clients do not
store sensitive tender data, they are not a point of attack from
which credentials may be extracted.
[0070] The user clients may also serve as points of user engagement
and tender discovery before and after a transaction. For example, a
merchant might present an offer to a user when the user arrives at
a store to drive sales of an item that is overstocked, or a
merchant might provide an offer attached to a receipt to
incentivize the user to return to the store that same week. In
these examples, the user clients also become channels for
delivering rich personalized experiences and presenting new
instruments of tender.
[0071] The user clients, such as user client 108, 109 are
merchant-centric. Unlike some prior art mobile wallets that are
organized around object types (e.g., payment credentials,
offers/coupons, loyalty/reward cards, receipts, etc.), the user
clients in accordance with one embodiment are organized around
user/merchant relationships. By default, user account data is
organized by merchants and this serves as a user client's
organizing principle. The default view in a user client in one
embodiment is a list of merchants organized by location, favorites
or any other arrangement. Users can pivot data around themselves
(e.g., to view receipts across all merchants) in another view.
[0072] Once a user retrieves a detailed view of a specific
merchant, the user is able to see a view of their entire
relationship with the merchant. This view, referred to as a
"merchant relationship feed" is an intelligent sort of all past,
present and potential future user/merchant interactions. An
intelligent algorithm weighs recency, importance and other factors
to develop a feed of transactions, offers, rewards, news and other
user/merchant engagement opportunities.
[0073] Network 100 enables merchants to reach customers through new
channels which often require new incentive/tender types for
effective engagement (e.g., mobile advertisements/offers for mobile
channels, Facebook Credits/Offers for Facebook "likes", etc.).
Across these new channels, users generally engage while they are
online and logged into a range of third party accounts such as
Pinterest, Facebook, Google, Twitter and Yahoo. Network 100 allows
users to link their user accounts to these third party accounts to
enable seamless discovery, clipping, sharing and engagement with
tender available on these channels. To create this link, in one
embodiment network 100 uses "OAuth" to connect user accounts to
these third party account. OAuth is a known open standard for
authorization and provides a process for end-users to authorize
third-party access to their server resources without sharing their
credentials (typically, a username and password pair), using
user-agent redirections. In other embodiments, other authorization
mechanisms can be used. A user may elect to link user account 102
to any or all third party accounts made available by network
100.
[0074] When a third party account is linked to user account 102, it
is granted a set of capabilities to interact with user account 102,
which might include adding tender instruments into user account
102. For example, a user who is logged into Yahoo might clip an
offer from an email message directly to the user's user account
102. Similarly, when a user account 102 is linked to a third party
account, with user permission a user account 102 may interact with
the third party account. For example, a user account 102 might gain
access to post something to a user's Facebook Wall or Twitter
Stream. This linking of accounts gives users a federated commerce
capability with a broad online presence. The federated commerce
capability actualizes a chain of authentication so that no matter
what the online context, users are able to save to and publish from
their user account 102.
[0075] While the above describes using account federation to add
tender instruments from Twitter and Facebook, for example, this
mechanism extends to any secure online account, including user
accounts with financial institutions, media outlets and merchants.
Therefore, a user logged in to a merchant or issuer website could
similarly push things like offers or payment cards into their user
accounts.
[0076] When a third party account is linked to user account 102, it
is granted a set of permissions which can include the ability to
add tender instruments to user account 102 (including debit cards,
private label cards, gift cards, bank accounts, coupons, offers,
loyalty cards, loyalty points etc.). To add instruments to user
account 102, third parties can interact with a defined set of User
Account APIs. With user permission, these third parties can then
push instrument data to the user account. These APIs can implement
using known web service mechanisms such as Representational State
Transfer ("REST") and data payloads encoded as JavaScript Object
Notation ("JSON").
[0077] If a user is not logged on to network 100 when trying to
save a new instrument to the user account 102, the user will be
prompted to login to network 100 or any third party account.
Similarly, if a user is already logged into a third party account
that is not yet federated to user account 102, the user will be
prompted to link that account to user account 102 or to login using
a valid user account 102.
[0078] For mobile applications where an application may not use the
notion of a "logged in" account (e.g., an advertisement in a video
game), the client application exposes local APIs by which an
application may pass data to the client application to be saved. In
this embodiment, federated authentication is provided by the client
installed on the user client. In one embodiment, an intent or
uniform resource identifier ("URI") exchange is used to pass tender
data into the client application which will receive and save the
instrument data.
[0079] In one embodiment, user account 102 plays a large role in
the settlement of tender at the time of a transaction. When a user
makes a purchase, the merchant passes the user authentication token
510, also referred to as a "Bean", loaded with a basket of goods to
network 100. Network 100 uses token 510 to access user account 102
and passes the basket of goods and user account 102 to transaction
engine 810 for processing.
[0080] Transaction engine 810 examines the basket of goods and full
set of instruments in user account 102 and applies a business
algorithm to determine which tender instruments to use for the
transaction. Transaction engine 810 then initiates the transaction
and updates user account 102 as necessary. For example, offers that
are redeemed to settle the transaction would be marked as used.
Further, if a gift card is used in a transaction, its balance would
be updated in user account 102.
[0081] The online and federated nature of user account 102 enables
it to: (1) gather tender instruments from any online context; (2)
make those instruments available for processing at the time of
transaction; and (3) update user account 102 after transaction
processing so that the user can immediately see the results of the
transaction.
Merchants
[0082] As previously discussed, in one embodiment every merchant
that participates in network 100 has a merchant account 104.
Merchant account 104 holds basic profile information, an arbitrary
number of stores which represent physical locations for the
merchant, geo-fence properties for each store, merchant
acquirers/processors used to finalize settlement of acceptable
forms of tender, etc. In addition, merchant account 104 may hold
any merchant specific business logic that should be applied to
transactions.
[0083] To provide flexibility, embodiments allow merchants to
arrange stores into arbitrary sets/store groups (e.g., regional
groups) to simplify the management tasks. A merchant can then use
these groups to set store policies or publish incentives/offers in
varying granularities. For example, a merchant could publish a
national offer to all stores, a warm weather offer to a group of
warm weather stores, a local offer to a single store or individual
offers to specific customers or customer groups, based on any range
of demographics, historic purchases, online browsing, or other
characteristics or actions.
[0084] Store groups can also be used to delegate administrative
permission for the stores. For example, a regional manager could be
given permission to set offers/store policies for a regional store
group or a local store manager could set policies and promotions
for one store only.
[0085] Merchants can connect to network 100 to authenticate users
and initiate transactions through approved merchant POS clients,
such as POS client 120. These merchant POS clients may include
existing and future POS infrastructure which is connected to
network 100 via merchant APIs 122. In order to authenticate users
and initiate transactions, a POS in one embodiment first
authenticates itself to network 100. This initial authentication
includes an exchange of merchant account 104 username, password,
and predefined POS identifier (e.g., "Lane 17"). In addition, key
material is also exchanged with the POS to more strongly
authenticate it.
[0086] Once authenticated, merchant POS client 120 (via API 122) is
used to authenticate in-store users to network 100. When a user
elects to pay using network 100, the user is prompted to enter the
PIN on the terminal attached to the POS. For example, the terminal
might be a PIN-pad from Verifone Systems Inc., or a touch-screen
PIN-pad when using a tablet/mobile POS. Once the PIN is collected,
it is sent to network 100 where it is compared to the PINs of users
checked into the store. Therefore, the PIN is used both to
authenticate and disambiguate the user. If there are multiple users
with the same or even similar PINs in the store, network 100 in one
embodiment presents a challenge question to the user. For example,
the user may be asked to enter a date of birth, street address
number, phone number or other information into the same terminal.
This information would then be similarly passed to network 100 for
authentication.
[0087] Once a user is authenticated, as described, the POS receives
a token, or Bean, for the transaction at hand. The Bean is an
opaque token that carries no intrinsic value and does not return
any tender instruments to the POS. Accordingly, the Bean does not
require any PCI security standards council or similar level
protection by the merchant.
[0088] Once the user has authenticated to network 100 via the POS,
the cashier/teller at the POS moves forward with the merchant's
standard purchase flow until it is time to complete the
transaction. With a traditional transaction, the POS/cashier would
send a user instrument (for example a Visa card) and a basket total
(for example $100) to a network for authorization and settlement.
However, for network 100, the cashier sends the token/Bean which
includes the complete basket of goods including line level data to
network 100. With the basket of goods as a guide, transaction
engine 810 then joins the user, merchant and issuer accounts to
process the transaction. Once cleared, network 100 returns an
updated receipt to the POS including any price modifications. This
enables the user have a real-time view of the final purchase price
and confirmation of which instruments were applied to clear the
transaction.
[0089] Merchants can create, access and manage their merchant
accounts 104 through a range of merchant clients (e.g., management
client 121). These clients include web pages, mobile applications,
and tablet interfaces which enable designated managers to monitor
their merchant account, add/delete stores, view transaction
history, and perform a range of other account management functions.
A management console provides merchants with a real-time view of
activity in their stores and across channels, such as how many
customers are in their stores segmented by customer type, subject
to user permission, or a customer's individual wish lists or
purchase history. Additionally the management console provides a
real-time view of purchase velocity, the performance of promotional
campaigns, and custom monitoring/alerts based on any information
available on network 100. The management console also provides
access to the business optimization engine, which can be used to
optimize and generate personalized advertising, incentive, and
promotional campaigns across channels to maximize revenue and
customer engagement.
Issuers
[0090] As disclosed above, every issuer of network 100 has a
corresponding issuer account 106. Issuer account 106 details the
issuer's tender types, and the authorization policy, authorization
mechanism, and settlement mechanism for each form of tender. An
authorization policy is a contract that describes how and under
what circumstances authorization for the tender should occur. An
authorization mechanism describes how the tender should be
authorized by the issuer should the authorization policy deem it
necessary. Finally, the settlement mechanism describes how
settlement should be actualized for the tender. In one embodiment,
network 100 splits the authorization and settlement of tender into
separate phases to provide a flexible solution capable of handling
a broad set of tender types.
[0091] For example, if Groupon were to issue an offer that could be
redeemed on network 100, Groupon would first create an issuer
account or an account is created on behalf of Groupon. Groupon
would specify an authorization policy, an authorization mechanism,
and a settlement mechanism for the Groupon tender. Groupon could
specify: (1) an authorization policy that required real time
authorization for any Groupon tender; (2) an authorization
mechanism that used a web services call to perform the
authorization for the tender; and (3) an ACH settlement mechanism
that used ACH to move the money from Groupon to the merchant. In
some transactions, authorization and settlement could be part of
the same action for a specific tender type. For example, the
authorization mechanism could be set to null in the issuer account,
which would shift the responsibility of authorization to the
settlement agent.
[0092] For traditional payment instruments where the issuer (e.g.,
a bank) may not be have a corresponding issuer account on network
100, a delegate issuer account may be automatically configured. For
example, a debit card would use a pre-defined debit Issuer account
delegate that would specify authorization and settlement using a
traditional debit network.
[0093] An issuer can use an issuer management console or other
method to facilitate the setup of issuer accounts 106 and
management of the authorization policy, authorization mechanism,
and settlement mechanism for each tender. The issuer management may
also provide real-time analytics about issuer tender on network
100, the number of transactions inflight, the outstanding balance
due, settlement, etc.
[0094] The authorization and settlement mechanisms specified for
use by the issuer can be implemented in a number of ways.
Embodiments include a set of issuer APIs 132 and reference
implementations that use next generation authorization and
settlement mechanisms. For example, when using Groupon-based
tender, as described above, in one embodiment Groupon would use the
authorization mechanism defined in issuer API 132 to implement
authorization via a web services call.
Validity Score
[0095] In one embodiment, network 100 executes a machine learning
algorithm over data it collects and combines the results with a
prediction algorithm to provide a "validity score" for all
participants and tenders involved in a transaction. The validity
score is used in conjunction with the authorization mechanisms for
tender types that support explicit authorization. If a validity
score is insufficient for any tender or participant in the
transaction, the transaction is either flagged or declined.
[0096] The validity score allows network 100 to enable settlement
using a broad set of instruments. The validity score prediction
algorithm uses machine learning to weigh all aspects of a
transaction. As network 100 sees more and more transactions, the
prediction algorithm improves and the machine learning model
becomes trained resulting in improved accuracy. The quality and
quantity of data combined with a scalable machine learning approach
give network 100 the enhanced ability to predict the validity of
all components of a transaction. In one embodiment, validity
scoring enables network 100 to recognize and flag anything from bad
tender, to a suspect user, a bad retail lane, or cashier that
exhibits fraudulent characteristics. In one embodiment, the
validity scoring includes velocity checks, including frequency of
transactions and failed authentication attempts, location signals
including a device location history, and a total amount charged,
including single high value transactions or high spend per day. The
same characteristics can be used to identify abnormal merchant/POS
behavior.
Authentication
[0097] As described above, embodiments uses a two factor/level
authentication system to verify a user's identity and initiate a
transaction. The first factor of authentication is a user's
geo-location. Specifically, the user's smartphone or other mobile
client must be physically present in the store to initiate a
transaction and the user client (i.e., a mobile commerce
application) must be installed. To make this possible, in one
embodiment a user configures the user client to login to the user's
user account 102.
[0098] Once authenticated, the mobile user client examines all
location information and uses a check-in algorithm that runs on the
mobile device to decide when to send a check-in request to network
100. When the user client sends the check-in request to network
100, it includes all the location information available to the user
client. Network 100 analyzes the request and returns both a
decision (checked-in or not), and new data that will help the user
client make better localized decisions in the future. The dynamic
exchange of information between the user client and network 100
lets the system learn and constantly improve the accuracy of its
geo-fence capability and notice/adjust to any attempts to
fraudulently manipulate location signals.
[0099] The second factor of authentication is typically a PIN that
the user knows and enters into the POS when the user is ready to
initiate a transaction. If for any reason a transaction is
flagged/raises fraud concerns, network 100 can challenge the user
to answer questions/provide additional factors of
authentication.
[0100] Network 100 uses multiple factors of authentication to
verify the identity of the user in-store. This in-store
authentication gates the initiation of any transaction on behalf of
the user. Once a transaction has been initiated, network 100 seeks
to further validate the identity of the user by leveraging machine
learning and the user's location, location history, purchase
history, and recent behavior to generate a validity score for the
user. If for some reason the user validity score is too low,
network 100 can issue challenge questions to the user to confirm
the user's identity.
[0101] Merchant infrastructure is secured using key exchanges and
cashier/teller login to merchant endpoints. For each transaction,
network 100 seeks to validate both the authenticity of the
merchant's endpoint and the legitimacy of the behavior originating
from that endpoint. If a merchant endpoint is being used to
purchase merchandise that the merchant does not stock, or a
merchant endpoint is being used to purchase volumes of goods that
are unusual, the transactions and/or endpoints can be flagged.
Likewise if an invalid or uncommon discount were applied
incorrectly or inappropriately, the transaction, teller and/or
endpoint can be flagged.
[0102] To handle transactions and endpoints that were flagged for
unusual behavior, the merchant can specify a policy in merchant
account 104. For slightly odd situations, the merchant could simply
request the opening of an audit log. For more serious issues, the
merchant could require a manager override for the transaction to
complete. Since merchant APIs 122 provide merchants with the
ability to pass a teller ID along with the basket of goods, these
mechanisms could similarly be used to detect dubious teller
behavior.
Authorization
[0103] Network 100 sits at the intersection of transactions that
span users, merchants and tender types. For each transaction,
network 100 considers a wide cross-section of data including basket
contents, location, time of day, consumer purchase patterns and
merchant signals like checkout lane, teller, etc. Network 100
executes a machine learning and a predictive algorithm across this
data to derive a validity score as described above. The validity
score for all aspects of the transaction including the tender is
combined with the authorization mechanisms described below to
provide robust authorization implementation.
[0104] For a tender like ACH that does not have an explicit
authorization mechanism, network 100 internally evaluates whether
or not to accept the tender. In this scenario network 100 must
decide to accept or decline the transaction based on the validity
scores of the tender and other components of the transaction.
Network 100 supports a configurable policy that lets the bearer of
liability (in the case of ACH, the merchant) configure thresholds
for validity scores and dollar values. For example, a merchant
might tolerate a range of validity scores for small purchases but
demand very high validity scores for large purchases.
[0105] In addition to top down validity scoring, issuer defined
authorization policies and mechanisms are also used to authorize
each tender instrument. For example, to determine if a Groupon
"certificate" can be used for settlement, network 100 would combine
the results of a Groupon authorization web services call with the
tender's validity score.
[0106] Traditional instruments like PIN-debit and private label
networks have built in authorization mechanisms including PIN,
address and/or phone number verification. For these traditional
forms of payment, authorization is performed at the same time as
settlement. When authenticating these forms of tender, network 100
relies on the validity score calculated for the tender and performs
the tender's explicit authorization as part of settlement. When
settling PIN-debit, for example, the PIN would be passed with the
card number to the PIN-debit network as part of the request for
settlement. For a private label card the settlement mechanism may
pass the user's address and phone number to the private label
issuer as additional authorization signals for the private label
network. For newer tender instruments, the authorization and
settlement will likely be more clearly divided and the settlement
mechanism will only perform settlement in one embodiment.
[0107] Embodiments can process multiple different forms of tender
in a single transaction. As the number of tenders per transaction
increases, keeping transaction latency low can become increasingly
difficult, as the transaction will be as slow as the slowest form
of tender. To authorize this mixed bag of tenders and ensure timely
transactions, embodiments include a number of mechanisms that let
network 100 pre-authorize certain tenders before they are used in a
transaction.
[0108] Pre-authorization is the act of authorizing a tender without
the immediate expectation of settlement. Pre-Authorization removes
the tender issuers from the critical processing path while
employing a number of mechanisms to ensure the tender security is
not compromised. The ability to pre-authorize is based on
embodiments that decouple authorization from settlement. The
pre-authorization and transaction history of tenders provides
critical data for the machine learning algorithms.
[0109] Embodiments may include a number of pre-authorization
mechanisms that are not mutually exclusive. Any number of these
mechanisms may be used alone or in combination to validate a single
tender. In addition, these mechanisms may be used repeatedly during
the lifecycle of a tender.
[0110] One pre-authorization mechanism authorizes an instrument
when it is added to user account 102. This could be a
blocking/gating operation by which tender instruments are only
allowed in user account 102 after passing an authorization check.
This is an aggressive form of authorization where network 100
validates the health of tender as it is enters the system.
[0111] For tenders that have second factors of authentication,
another pre-authorization mechanism can be used to verify not just
the validity of the tender but also the user's ownership of the
instrument. For debit cards, network 100 uses the PIN in this
capacity. When a user adds a debit card to user account 102,
network 100 performs an authorization not just to confirm that the
card is valid, but also to confirm that it is the owner entering
the card.
[0112] The pre-authorization on entry to prove validity mechanism
described above ensures that instruments added to user account 102
are valid on entry, but additional validation may be required as
instruments age. Embodiments can scan user accounts and
re-authorize instruments that have not been authorized for some
duration of time. For example, if a Groupon voucher/certificate is
validated on entry, network 100 could choose to re-authorize the
voucher after an initial authorization expires.
[0113] If the user had printed out the Groupon offer and redeemed
it manually, then network 100 would receive a "used/not valid"
response from Groupon and mark the voucher used in user account
102. Periodic re-authorization would be accomplished by rescanning
all tender and sending batches of low priority authorization
requests to Groupon.
[0114] The check-in aspect of the two-factor authentication system
of embodiments of the present invention provide an opportunity to
pre-authorize tender in user account 102. When the user checks-in
to the store, network 100 can kick-off a pre-authorization of all
the tenders in the user's user account 102 that may be applied at
the store the user checked into. In most cases, the user will be in
the store for at least a few minutes before making a purchase,
which provides a window of opportunity for network 100 to
re-authorize and verify the validity of any instruments that may be
used as part of an upcoming transaction.
[0115] While the mechanisms described above can improve the latency
of real-time transaction processing, many of these mechanisms may
be used for any/all tender types in an account or across network
100 to improve the security of the system. For example if a number
of bad Groupon certificates were observed, network 100 can
interpret this as a compromise of Groupon and choose to
re-authenticate all Groupon tenders to assess the situation.
Similarly if a specific user was flagged for unusual behavior,
network 100 could choose to pre/re-authorize all of the user's
tenders to see if the user was potentially a fraudster trying to
utilize bad tenders.
[0116] Regardless of the validity score or level of
pre-authorization, network 100 can choose to fully re-authorize
tenders at the time of transaction. In the event that authorization
cannot be performed in real-time (e.g., the issuer is experiencing
downtime), network 100 can leverage the tender validity score to
make an authorization decision about the tender's legitimacy. For
example, if an offer were pre-authorized a week ago, and the tender
validity score is high, network 100 could proceed with settlement
under the assumption that the tender is good. This mechanism of
falling back to local authorization mechanisms of network 100 when
real-time authorization fails is referred to as "authorization
fallback."
[0117] Embodiments further include a tunable fallback policy that
describes how and when authorization fallbacks should be used. The
bearer of liability configures the fallback policy with acceptable
thresholds for tender validity scores, time since last successful
authorization/pre-authorization, etc. In the case of a low value
coupon, the expectation would be that the manufacturer (i.e.,
issuer) would be liable for the coupons and would set relatively
permissive thresholds since the cost of a bad coupon would be very
low. Conversely if a merchant accepted private label and shoulder
liability, it might set very high validity thresholds for the
private label tender. The merchant could even set validity
thresholds that varied by dollar amount to minimize its risk.
Settlement
[0118] To accept payment, in one embodiment merchants must specify
an acquirer configuration in its merchant account 104. The
configuration can be as simple as an acquirer name and account or
as complex as a set of acquirers and accounts and a policy about
which acquirers should be used for which tender types. This
configuration would likely include a raw merchant account endpoint
to be used for transactions that did not explicitly require an
acquirer.
[0119] For each tender issued, in one embodiment the issuer must
specify a settlement mechanism in the issuer account 106. For
legacy tenders, these mechanisms are interactions with legacy
networks such as the PIN-debit, private label or credit networks.
For newer forms of tender, these mechanisms may be ACH or even
direct settlement where/when supported by issuers. Regardless of
the tender, it is the settlement mechanisms affect settlement by
initiating the movement of money between two endpoints but never
take direct possession of money.
[0120] As described above, when a user client initiates a check-in,
network 100 creates a secure session token or "Bean" that is
registered with merchant account 104. The token contains a
reference to the store and user and the token is referenced within
merchant account 104 by the user's PIN. When the user enters the
PIN at the merchant's POS to initiate a transaction, the PIN is
used to lookup the token for the user. This mechanism therefore
uses the PIN both to authenticate the user and also to disambiguate
the user from other in-store users.
[0121] When the user enters the PIN to authorize a transaction, a
token is returned from network 100 to the POS. The POS adds the
basket of goods to the token and sends it back to network 100 where
the basket is fully constructed and the transaction is ready for
processing. The token is used by network 100 to facilitate
processing. Finally, when the transaction is complete, the token is
turned into a receipt. The token is the transactional entity that
ties the user, merchant, basket of goods and issuers together for
the lifecycle of an individual transaction including post-purchase
actions such as returns.
Transaction Engine
[0122] Transaction engine 810, as described above, uses user
account 102, merchant account 104 and the basket of goods to derive
payment from a set of issuer accounts 106. Transaction engine 810
in one embodiment divides the work of processing a transaction into
three distinct phases: a business logic phase, an authentication
and authorization phase, and a settlement phase.
[0123] The business logic phase is the initial phase of a
transaction in which transaction engine 810 looks at all
instruments in the user's user account 102, the tender types the
merchant accepts, the items in the basket of goods, which include
line level data, and decides how to process the transaction.
[0124] Transaction engine 810 first looks at user account 102 and
gathers all the forms of tender. It then organizes the forms of
tender based on the user's stated preference for tender use at the
specified merchant. Forms of tender that the user does not want to
use are removed from the list of potential tenders.
[0125] The list of potential tenders is then filtered based on any
restrictions the merchant may have. If the merchant for example is
not willing to accept a form of tender it is removed from the list
of tenders to be used for the transaction. Merchants set tender
acceptance policies and users may always manually select tender
preferences (e.g., universal default tender, default tender by
merchant, etc.). However, embodiments can also dynamically and
intelligently select user tender for each transaction without any
required user action.
[0126] Transaction engine 810 then applies the tenders to the
basket of goods seeking to honor the order of tender priority and
best possible tender outcome. This may require relatively complex
determinations as some tender types have complex rules and the
outcomes of these rules must be compared (i.e., is a "2 for the
price of 1" coupon better than a "2 for $5.00 coupon"?). As the
basket is processed and tenders are applied, any tender specific
policy is also preserved. For example most coupons are not eligible
for stacking and some rewards programs may be applied only to
certain products.
[0127] Transaction engine 810 applies all tenders until the basket
of goods is qualified for settlement. This process may take many
iterations and include many tender types as a single basket may be
funded by coupons, loyalty rewards, pre-paid offers, multiple gift
cards and a private label card, debit card, etc. Transaction engine
810 in one embodiment can enable split tender of not just 2 or 3
but an unlimited number of instruments.
[0128] At this point the business logic phase has completed, the
set of tender instruments has been chosen, and transaction engine
810 moves onto the authentication and authorization phase. In this
phase, transaction engine 810 leverages the authentication
mechanisms described above to validate all participants in the
transaction, and the authorization mechanisms described above to
authorize all tenders to be used in the transaction.
[0129] To verify the user and merchant, the user and merchant
authentication mechanisms are used, and in the case of insufficient
validity corrective action is taken. For a weakly authenticated
user, challenge questions are issued, or for a weak merchant
endpoint score, the merchant authentication policy is followed.
[0130] To verify the validity of selected tenders, transaction
engine 810 resolves the issuer account for each tender and performs
the authorization action specified by the authorization policy in
issuer account 106. The authentication and authorization phase
ensures that the user, the merchant, the basket of goods and the
tender instruments have all been validated before moving on to the
settlement phase.
[0131] In the settlement phase, transaction engine 810 settles the
set of tenders that have been specified for the transaction. To
settle tenders, transaction engine 810 resolves the issuer account
106 for each tender, looks up the settlement mechanism and executes
the settlement.
[0132] Network 100 allows merchants to specify a mechanism by which
they should receive payment and issuers to specify an agent that
should be used to settle outstanding balances. Network 100 in one
embodiment does not take control or hold money at any point during
the transaction.
[0133] Transaction engine 810 in one embodiment uses a phased
approach to processing transactions in order to separate business
logic, authentication/authorization and settlement from one
another. As a consequence, the authentication and authorization
phase of the transaction validates more than just the tender as
transaction engine 810 validates all aspects of a transaction
regardless of the tender instrument(s) used to settle the
transaction. Therefore, transaction engine 810 makes it well suited
to support tenders with weak or no authorization mechanism.
Conversely, instruments with stronger authorization mechanisms
(e.g., PIN debit) are made increasingly secure by the added layers
of validation.
[0134] One embodiment allows users to modify tender selection even
after a transaction has been settled. For example, if a user
accidentally applied a 20% off offer to a $10 basket, the user
might prefer to save the offer for the larger transaction.
Embodiments let the user modify the tender selection and re-settle
the transaction by choosing to pay the merchant an extra $2 and to
have the offer marked as unused. Similarly, if a user wanted to
move a purchase from a debit card to a line of credit, or from one
line of credit to another line of credit the same mechanism could
be used. This post-settlement modification mechanism will depend on
merchant and issuer policies
[0135] As disclosed, embodiments provide a system and commerce
network that integrates users, merchants and issuers in allowing a
user to make payments to store using a mobile device. Multiple
forms of tender may be used to process the payment, and embodiments
determine the most suitable forms of payments based on line level
data of the basket of goods that are being purchased. Further,
multiple levels of authentication prevent fraud and mistakes from
occurring.
[0136] Several embodiments are specifically illustrated and/or
described herein. However, it will be appreciated that
modifications and variations of the disclosed embodiments are
covered by the above teachings and within the purview of the
appended claims without departing from the spirit and intended
scope of the invention.
* * * * *