U.S. patent application number 14/837471 was filed with the patent office on 2015-12-24 for merchant identification of payer via payment path.
The applicant listed for this patent is GOOGLE INC.. Invention is credited to Osama Bedier, Angela Chun Wah Lai, Prasenjit Phukan, Pavel Simakov.
Application Number | 20150371233 14/837471 |
Document ID | / |
Family ID | 47844810 |
Filed Date | 2015-12-24 |
United States Patent
Application |
20150371233 |
Kind Code |
A1 |
Simakov; Pavel ; et
al. |
December 24, 2015 |
MERCHANT IDENTIFICATION OF PAYER VIA PAYMENT PATH
Abstract
Novel features to be used in a proxy card payment system include
a real-time request to override a declined transaction or to select
a different financial account and the insertion of user
identification information into the transaction approval message
sent to the merchant. A payment request is forwarded to the payment
system, which maintains the proxy card account and determines
whether the transaction violates a user-defined rule. If the
transaction is declined by the issuer that maintains the financial
account, or the payment system for violation of a user-defined
rule, the payment system sends a real-time message to the user. The
user is prompted to override the rule causing the transaction to be
declined or to select a new account to process the transaction.
Once the payment system receives authorization for the transaction,
it inserts the user identification information in an approval
message before transmitting the approval to the merchant.
Inventors: |
Simakov; Pavel; (San Mateo,
CA) ; Bedier; Osama; (San Jose, CA) ; Lai;
Angela Chun Wah; (Los Altos Hills, CA) ; Phukan;
Prasenjit; (Los Altos, CA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
GOOGLE INC. |
Mountain View |
CA |
US |
|
|
Family ID: |
47844810 |
Appl. No.: |
14/837471 |
Filed: |
August 27, 2015 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
13481341 |
May 25, 2012 |
9135619 |
|
|
14837471 |
|
|
|
|
61559136 |
Nov 13, 2011 |
|
|
|
Current U.S.
Class: |
705/44 |
Current CPC
Class: |
G06Q 20/3572 20130101;
G06Q 20/405 20130101; G06Q 20/4037 20130101; G06Q 20/40 20130101;
G06Q 20/409 20130101; G06Q 20/401 20130101 |
International
Class: |
G06Q 20/40 20060101
G06Q020/40 |
Claims
1. A computer-implemented method for providing a merchant with user
information using a single proxy account to access multiple
financial accounts, comprising: receiving, by a computer, a payment
request from a merchant for a purchase by a user from the merchant,
the first payment request comprising information identifying a
payment account maintained by a payment system and an amount of the
purchase; authorizing, by the computer, the payment request;
inserting, by the computer, a user identification into a payment
authorization for the first payment request; notifying, by the
computer, the merchant of the authorization of the payment request,
the authorization of the payment request comprising an
authorization for the payment account maintained by the payment
system and the user identification; and initiating, by the
computer, a payment to the merchant for the at least the portion of
the amount of the purchase.
2. The computer-implemented method of claim 1, wherein the user
identification comprises an electronic mail address for the
user.
3. The computer-implemented method of claim 1, wherein the user
identification comprises a telephone number for the user.
4. The computer-implemented method of claim 1, wherein the user
identification comprises a mailing address for the user.
5. The computer-implemented method of claim 1, further comprising
the merchant collecting the user identification.
6. A computer program product, comprising: a computer-readable
medium having computer-readable program code embodied therein for
providing a merchant with user information using single proxy
account to access multiple financial accounts, the
computer-readable medium comprising: computer-readable program code
for receiving a payment request from a merchant for a purchase by a
user from the merchant, the first payment request comprising
information identifying a payment account maintained by a payment
system and an amount of the purchase; computer-readable program
code for authorizing the payment request; computer-readable program
code for inserting a user identification into a payment
authorization for the first payment request; and computer-readable
program code for notifying the merchant of the authorization of the
payment request, the authorization of the first payment request
comprising an authorization for the payment account maintained by
the payment system and the user identification.
7. The computer program product of claim 6, further comprising
computer-readable program code for initiating a payment to the
merchant for the at least the portion of the amount of the
purchase.
8. The computer program product of claim 6, wherein the user
identification comprises an electronic mail address for the
user.
9. The computer program product of claim 6, wherein the user
identification comprises a telephone number for the user.
10. The computer program product of claim 6, wherein the user
identification comprises a mailing address for the user.
11. A system for providing a merchant with user information using
single proxy account to access multiple financial accounts, the
system comprising: one or more information processing units for
executing programs; and an engine executable on the one or more
information processing units, the engine comprising: instructions
for receiving a payment request from a merchant for a purchase by a
user from the merchant, the first payment request comprising
information identifying a payment account maintained by a payment
system and an amount of the purchase; instructions for authorizing
the payment request; instructions for inserting a user
identification into a payment authorization for the first payment
request; and instructions for notifying the merchant of the
authorization of the first payment request, the authorization of
the payment request comprising an authorization for the payment
account maintained by the payment system and the user
identification.
12. The system of claim 11, wherein the engine further comprises
instructions for receiving a payment authorization from the issuer
authorizing the new payment request to charge the at least a
portion of the amount of the purchase to the determined financial
account.
13. The system of claim 11, wherein the engine further comprises
instructions for initiating a payment to the merchant for the at
least the portion of the amount of the purchase.
14. The system of claim 11, wherein the user identification
comprises an electronic mail address for the user.
15. The system of claim 11, wherein the user identification
comprises a telephone number for the user.
16. The system of claim 11, wherein the user identification
comprises a mailing address for the user.
Description
RELATED APPLICATIONS
[0001] This application claims priority to U.S. Provisional Patent
Application No. 61/559,136, filed Nov. 13, 2011 and entitled
"Virtual Payment Path." The entire contents of the above-identified
priority application are hereby fully incorporated herein by
reference.
TECHNICAL FIELD
[0002] The present disclosure relates generally to proxy cards,
and, more particularly, to novel features to be used in proxy card
payment systems.
BACKGROUND
[0003] In a conventional merchant-consumer financial transaction,
the merchant's point of sale terminal or online payment process
engine submits a payment request to the acquirer (for example Chase
PaymentTech, or other third party payment processing companies) for
payment for the transaction. The acquirer then submits the request
to authorize the transaction to the issuer (for example Citibank,
CapitalOne, Bank of America, and other financial institutions to
authorize payment) through the card network (for example VISA,
MasterCard, American Express, Discover or other card processing
networks). If funds are available, the issuer sends an
authorization code to the acquirer through the card network, and
the acquirer notifies the merchant of the approval for the payment
transaction. The payment process involves a single payment request
generated and submitted by the merchant. The request contains
generalized information, such as the total payment amount and
consumer account-identifying information encoded on the card's
magnetic stripe, but the request does not contain item-specific
information, such as the stock-keeping unit ("SKU") number, or user
identification information, such as an electronic mail address.
[0004] Conventional merchant-consumer financial transactions also
have involved payment via a consumer's financial account, such as a
debit card, credit card, or stored value card. The consumer card
typically accesses only one type of account, which is maintained by
only one issuer. For instance, an "issuer1" credit card accesses
only the consumer's financial account from "issuer1," and payment
is approved/denied by a single issuer ("issuer1"). Approval or
denial of the transaction is dependent upon rules set by the
particular issuer, for example, credit limits and geographical
limitations. Notification of a violation of these rules results in
a declined transaction, and the consumer must contact the issuer to
alter the rules or to address a declined transaction.
[0005] More recently, proxy card payment systems enable users to
utilize a single card to access multiple financial accounts
maintained by multiple issuers. The user receives a proxy card from
the payment system and either creates a new payment system account
or associates the proxy card with the user's digital wallet account
already maintained by the payment system. The user then associates
one or more financial card accounts with the proxy account. For
example, the user can associate with the user's proxy card account
multiple debit/credit cards maintained by multiple issuers
(including the payment system operating as an issuer), stored value
cards (for example, gift cards, prepaid cards, re-loadable
transaction cards, exchange cards, and other forms of non-credit
based value cards), loyalty cards or store rewards cards, value
added service accounts (for example, coupons, vouchers for prepaid
offers, redemption offers, and other forms of offers), and/or other
forms of financial card accounts. The user applies the proxy card
to a transaction with the merchant in a manner similar to the
application of any financial card to a transaction. The merchant
forwards the payment request to the acquirer, which forwards the
payment request to the card network. The card network forwards the
proxy card payment request to the payment system, which functions
as the issuer for the payment request. The payment system can read
proxy card account information from the payment request and can
access the user's account associated with the proxy card. If the
payment system is the issuer of the financial account, the payment
system will approve or decline the transaction. If another issuer
maintains the financial account, the payment system will generate
and send a new payment request to the issuer via the card network.
The payment system will receive the authorization message from the
issuer via the card network if the transaction is approved. The
payment system forwards an authorization to the acquirer through
the card network, which forwards the authorization to the merchant.
The merchant then approves the transaction.
SUMMARY
[0006] In certain exemplary aspects, novel features to be used in a
proxy card payment system include a real-time request to override a
declined transaction or a real-time request to select a different
financial account to proceed with the transaction and the insertion
of user identification information into the transaction approval
message sent to the merchant. A payment system includes specified
information for multiple financial accounts, including, but not
limited to debit cards, credit cards, stored value cards,
loyalty/rewards cards, and coupons (including purchased offers and
other offers), each accessible by the proxy account. The user sets
rules specifying which financial account will be accessed when the
proxy card is used and specifying limits or circumstances during
which the proxy card will be declined. A payment request is
forwarded to the payment system, which maintains the proxy card
account. The payment system reads the user account information
before using the rules to determine the order in which the
financial accounts are to be applied and whether the transaction
violates a user-defined rule. If the payment system does not
maintain the financial account, the payment system sends a new
payment request to the issuer of the referenced account. If the
transaction is to be declined by the issuer or the payment system,
the payment system can send a real-time message to the user via the
user's mobile device. The user may be prompted to override a rule
causing the transaction to be declined or to select a new account
to process the transaction. Once the payment system receives
authorization for the transaction, it can insert user
identification information in an approval message before
transmitting the approval to the merchant, through the card network
and acquirer. User identification information also can be provided
in the proxy card account information stored on the magnetic stripe
of the proxy card or otherwise associated with the proxy card
account identifier.
[0007] These and other aspects, objects, features and advantages of
the exemplary embodiments will become apparent to those having
ordinary skill in the art upon consideration of the following
detailed description of illustrated exemplary embodiments, which
include the best mode of carrying out the invention as presently
presented.
BRIEF DESCRIPTION OF THE DRAWINGS
[0008] FIG. 1 is a block diagram depicting an operating environment
for a single proxy account capable of accessing multiple accounts
maintained by multiple issuers according to an exemplary
embodiment.
[0009] FIG. 2 is a block flow diagram depicting a method for
registering a user proxy card according to an exemplary
embodiment.
[0010] FIG. 3 is a block flow diagram depicting a method for
defining proxy card static rules according to an exemplary
embodiment.
[0011] FIG. 4, comprising FIGS. 4a and 4b, is a block flow diagram
depicting a method for processing a proxy card payment according to
an exemplary embodiment.
[0012] FIG. 5 is a block flow diagram depicting a method for
accessing a user's proxy card account according to an exemplary
embodiment.
[0013] FIG. 6 is a block flow diagram depicting a method for
processing value added services according to an exemplary
embodiment.
[0014] FIG. 7 is a block flow diagram depicting a method for
sending offers according to an exemplary embodiment.
[0015] FIG. 8, comprising FIGS. 8a and 8b, is a block flow diagram
depicting a method for authorizing a declined transaction according
to an exemplary embodiment.
DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS
Overview
[0016] A payment system includes specified information for multiple
financial accounts, including, but not limited to debit cards,
credit cards, stored value cards, loyalty/rewards cards, and
coupons (including purchased offers and other offers), each
accessible by the proxy account. The user sets rules specifying
which financial account will be accessed when the proxy card is
used and specifying limits or circumstances during which the proxy
card will be declined. The user can then add, delete, or change the
default payment rules associated with the proxy card. The user can
change these default static rules, create new rules, or delete a
rule. In an exemplary embodiment, the user can access the payment
system account and modify the rules at any time, including a time
immediately before a payment transaction is initiated using the
proxy card. In an exemplary embodiment, the user can access the
payment system account using a mobile device application.
[0017] If the user has defined static payment rules or
added/deleted/modified the rules prior to the transaction, the
payment system applies the user-defined rules to the transaction
first. Otherwise, the payment system applies the default static
payment rules to the transaction. If the transaction is to be
declined, the payment system notifies the user of the declined
transaction via a message communicated to the user's mobile device.
If the violation of a rule caused the transaction to be declined,
the user may be prompted to override the rule. If the financial
account has insufficient funds, the user may be prompted to select
a new financial account. Instead of declining the payment request,
the payment system can authorize and/or process the payment request
based on the user's response to the message. Alternatively, the
payment system can decline the original payment request,
communicate the notice message to the user, receive the user's
response, and revise the stored rules for payment. Then, the user
may immediately initiate a new payment transaction with the
merchant using the proxy card. The payment system will then approve
the payment transaction after receipt of a new payment request.
[0018] The payment system generates a new payment request if the
financial account is maintained by a non-payment system issuer or
authorizes the original payment request if the payment system
maintains the financial account. In either case, the payment system
can add user identification information to the authorization
message received from the issuer or generated by the payment system
acting as issuer for the financial account. The payment system also
can forward offers to the user or inject offers directly into the
payment transaction based on the product identification information
received in the payment message and/or the merchant identification
information.
[0019] Users may be allowed to limit or otherwise affect the
operation of the features disclosed herein. For example, users may
be given opportunities to opt-in or opt-out of the collection or
use of certain data or the activation of certain features. In
addition, users may be given the opportunity to change the manner
in which the features are employed, including for situations in
which users may have concerns regarding privacy. Instructions also
may be provided to users to notify them regarding policies about
the use of information, including personally identifiable
information, and manners in which each user may affect such use of
information. Thus, information can be used to benefit a user, if
desired, through receipt of relevant advertisements or other
information, without risking disclosure of personal information or
the user's identity.
[0020] The functionality of the exemplary embodiments will be
explained in more detail in the following description, read in
conjunction with the figures illustrating the program flow.
System Architecture
[0021] Turning now to the drawings, in which like numerals indicate
like (but not necessarily identical) elements throughout the
figures and exemplary embodiments are described in detail.
[0022] FIG. 1 is a block diagram depicting an operating environment
100 for a proxy card 105 capable of accessing multiple accounts
maintained by multiple issuers 160, 170 according to an exemplary
embodiment. As depicted in FIG. 1, the exemplary operating
environment 100 includes a proxy card 105, merchant system 110, a
user 101 mobile device system 120, an acquirer system 140, a card
network system 150, an issuer/payment system 160, and one or more
issuer system 170 that are configured to communicate with one
another via one or more communication networks (not shown).
[0023] Each communication network includes a wired or wireless
telecommunication means by which network devices (including devices
105, 110, 120, 140, 150, 160 and 170) can exchange data. For
example, each network can include a local area network ("LAN"), a
wide area network ("WAN"), an intranet, an Internet, a mobile
telephone network, a card network or any combination thereof.
Throughout this specification, it should be understood that the
terms "data" and "information" are used interchangeably herein to
refer to text, images, audio, video, or any other form of
information that can exist in a computer-based environment.
[0024] The secure communication channel 130 includes a
telecommunication means by which network devices (including devices
110 and 120) can exchange data. For example, each connection can
include a local area network (LAN), a wide area network (WAN), an
intranet, an Internet, a mobile telephone network, a personal area
network (PAN) or any combination thereof. In exemplary embodiments,
the secure communication channel 130 comprises a proximity
communication connection, such as Bluetooth. Bluetooth can enable
the exchange of data over short distances through the creation of
PANs with high levels of security. Wi-Fi is yet another proximity
communication type wherein contactless devices can communicate via
a wireless ad hoc network. In an alternative exemplary embodiment,
the secure communication channel 130 comprises a near field
communication (NFC) communication method.
[0025] The point of sale (POS) terminal system 110 includes a
terminal reader 113 that is capable of reading the proxy card 105
and communicating with the mobile device system 120 and the
merchant POS terminal 118 via an application 115.
[0026] In an exemplary embodiment, the terminal reader 113
comprises a magnetic stripe reader, which reads a magnetic stripe
on the proxy card 105 when the proxy card 105 is swiped in the
reader. In other exemplary embodiments, the terminal reader 113
comprises a bar code, QR code, or other machine-readable scanner
that captures information from the proxy card.
[0027] In another exemplary embodiment, the terminal reader 113
comprises a communication component that communicates with the
mobile device 120 using a Bluetooth communication method. In an
alternative exemplary embodiment, the terminal reader 113
communicates with the mobile device 120 using a Wi-Fi communication
method. In yet another exemplary embodiment, the terminal reader
113 communicates with the mobile device 120 using a NFC
communication method. While the terminal reader 113 is depicted as
standalone hardware device, the terminal reader 113 also may be an
integrated part of the POS terminal 118, in accordance with
alternative exemplary embodiments.
[0028] In an exemplary embodiment, the mobile device system 120 can
refer to a smart device that can communicate via an electronic,
magnetic, or radio frequency field between the device and another
device, such as a terminal reader 113. In an exemplary embodiment,
the mobile device 120 has processing capabilities, such as storage
capacity/memory and one or more application 122 that can perform a
particular function. In an exemplary embodiment, the mobile device
120 contains an operating system (not illustrated) and user
interface 123. Exemplary mobile devices 120 include smart phones;
mobile phones; PDAs; mobile computing devices, such as netbooks and
iPads; other electronically enabled key fobs; electronically
enabled credit card type cards; and other devices, in each case
having processing and user interface functionality. Certain mobile
devices 120 can be used for multiple purposes, including financial
transactions, coupons, ticketing, secure authentication, and other
related applications.
[0029] The secure element 126 can exist within a removable smart
chip or a secure digital (SD) card, or can be embedded within a
fixed chip on the mobile device 120. In certain exemplary
embodiments, Subscribed Identity Module (SIM) cards may be capable
of hosting a secure element 126, for example, an NFC SIM Card. The
secure element allows a wallet software application or other
application (122 or 127) resident on the device 120 and accessible
by the user 101 to interact securely with certain functions within
the secure element 126, while protecting information stored within
the secure element. The secure element 126 comprises applications
127 running thereon that perform the functionality described
herein.
[0030] The secure element 126 includes components typical of a
smart card such as crypto processors and random generators. In an
exemplary embodiment, the secure element 126 comprises a Smart MX
type NFC controller 124 in a highly secure system on a chip
controlled by a smart card operating system, such as a JavaCard
Open Platform (JCOP) operating system. In another exemplary
embodiment, the secure element 126 is configured to include a
non-EMV type contactless smart card, such as an optional
implementation.
[0031] The secure element 126 communicates with the controller 124
and the application 122 in the mobile device 120. In an exemplary
embodiment, the secure element 126 is capable of storing encrypted
user information and only allowing trusted applications to access
the stored information. The controller 124 interacts with a secure
key encrypted application 122 for decryption and installation in
the secure element 126. In an exemplary embodiment, the controller
124 is a Bluetooth link controller. The Bluetooth link controller
may be capable of sending and receiving data, identifying the
terminal reader 113, performing authentication and ciphering
functions, and directing how the mobile device 120 will listen for
transmissions from the terminal reader 115 or configure the mobile
device 120 into various power-save modes according to the
Bluetooth-specified procedures. In another exemplary embodiment,
the controller 124 is a Wi-Fi controller or an NFC controller
capable of performing similar functions.
[0032] The application 122 is a program, function, routine, applet
or similar entity that exists on and performs its operations on a
mobile device 120. For example, the application 122 may be one or
more of a digital wallet application, a coupon application, a
loyalty card application, another value-added application, a user
interface application, or other suitable application operating on
the mobile device 120. Additionally, the secure element 126 also
may comprise secure contactless software applications, such as
payment applications, secure forms of the applications 122,
authentication applications, payment provisioning applications, or
other suitable application using the secure functionality of the
secure element.
[0033] An exemplary digital wallet application 122 enables storage
of one or more financial card accounts registered by user 101. In
an exemplary embodiment, the registered accounts can be maintained
by the user's 101 digital wallet application 122 and stored in the
data storage unit 167. In yet another embodiment, the registered
accounts can be maintained by the payment system's 160 processing
module 163 and stored in the data storage unit 167.
[0034] The mobile device 120 communicates with the terminal reader
113 via an antenna 128. In an exemplary embodiment, once the mobile
device application 122 has been activated and prioritized, the
controller 124 is notified of the state of readiness of the mobile
device 120 for a transaction. The controller 124 outputs through
the antenna 128 a radio signal, or listens for radio signals from
the device reader 115. On establishing a secure communication
channel 130 between the mobile device 120 and the terminal reader
113, the terminal reader 113 requests the list of available
applications 127 from the secure element 126. A directory is first
displayed, after which, based on the set priority or the type of
device reader 115, an application 127 is chosen and initiated for
the transaction.
[0035] In certain exemplary embodiments, the network devices
(including devices 110, 120, 140, 150, 160, and 170) include an
HTML5 compliant or other web server. HTML5 compliant web servers
include a cross-document messaging application programming
interface ("API") and a local storage API that previous HTML
versions did not have. The cross-document messaging API of HTML5
compliant web servers enable documents, such as websites, to
communicate with each other. For example, a first document can send
a message to a second document requesting information. In response,
the second document can send a message including the requested
information to the first document. The local storage API of HTML5
compliant web browsers enables the web browser to store information
on a client device upon which the web browser is installed or is
executing. Websites can employ the local storage API to store
information on a client device. Other web browsers have
cross-document messaging and/or local storage capabilities also may
be used in certain exemplary embodiments.
[0036] In an exemplary embodiment, the proxy card 105 looks and/or
functions in the same manner as a standard credit or debit card.
For example, the proxy card 105 may have the user's 101 name and/or
account number listed on the front of the card 105. An exemplary
proxy card 105 can include a magnetic stripe encoding the user's
101 payment system 160 account information. In an exemplary
embodiment, the account information encoded in the magnetic stripe
routes payment requests to the payment system 160 for
processing.
[0037] In an alternative exemplary embodiment, the proxy card 105
is not a physical card. Instead, the proxy card 105 is an account
accessible by a wireless tap of a mobile device 120, an account
identification number, a bar code or QR code, a token, or other
form of account identification or access, which may be entered
manually into the term POS terminal 118 or terminal reader 113 or
which may be captured by the terminal reader 113. The proxy card
105 as discussed throughout the specification refers to a physical
card as well as the proxy account.
[0038] The user 101 may use the mobile device 120 or other network
device to register the proxy card 105 and/or access the user's 101
payment system 160 account. The mobile device 120 may comprise
appropriate technology that includes or is coupled to a web server
(for example, Google Chrome, Microsoft Internet Explorer, Netscape,
Safari, Firefox, or other suitable application for interacting with
web page files).
[0039] The payment system 160 includes a data storage unit 167
accessible by the processing module 163. The exemplary data storage
unit 167 can include one or more tangible computer-readable storage
devices.
[0040] The user 101 can use the web server to view, register,
download, upload, or otherwise access the payment system 160 via a
website (not illustrated) and a communication network (not
illustrated). The user 101 associates one or more registered
financial card accounts, including bank account debit cards, credit
cards, gift cards, loyalty cards, coupons, offers, prepaid offers,
store rewards cards, or other type of financial account that can be
used to make a purchase or redeem value-added services with the
proxy card 105. The registered financial card accounts may have
multiple issuers 160, 170 that maintain each financial account. The
payment system 160 also may function as the issuer for the
associated financial account. The user's 101 registration
information is saved in the payment system's 160 data storage unit
167 and is accessible the by the processing module 163. The
registration of a user 101 proxy card 105 is discussed in more
detail hereinafter with reference to the methods described in FIG.
2.
[0041] The user 101 also may use the web server to define proxy
card 105 payment rules. The creation of proxy card 105 payment
rules is discussed in more detail hereinafter with reference to the
methods described in FIG. 3.
[0042] The merchant 110 may use a web server (not illustrated) to
view, download, upload, create offers, or otherwise access the
payment system 160 via a website (not illustrated) and a
communication network (not illustrated).
[0043] The user 101 may request a purchase from the merchant 110.
In an exemplary embodiment, the purchase is initiated by swiping
the proxy card 105 at the POS terminal 118. In an alternative
exemplary embodiment, the purchase is initiated by a wireless "tap"
of the mobile device 120 with the terminal reader 113. In an
alternative exemplary embodiment, the purchase is initiated when
the user 101 enters an account identification number at the POS
terminal 118 or in the mobile device 120. The account
identification number may be the proxy card 105 account number or a
different number that links the payment transaction to the proxy
card 105 account. In yet another alternative exemplary embodiment,
the purchase is initiated by use of a permanent/temporary
virtual/physical token, QR code, bar code, or other suitable
machine-readable medium captured by the terminal reader 113. The
merchant's POS terminal 118 interacts with the acquirer 140 (for
example Chase PaymentTech, or other third party payment processing
companies), the card network 150 (for example VISA, MasterCard,
American Express, Discover or other card processing networks), the
payment system 160, and the issuer 170 (for example Citibank,
CapitalOne, Bank of America, and other financial institutions to
authorize payment). The processing of proxy card 105 payments is
discussed in more detail hereinafter with reference to the methods
described in FIGS. 4-8. System Process
[0044] FIG. 2 is a block flow diagram depicting a method for
registering a user proxy card according to an exemplary embodiment.
The method 200 is described with reference to the components
illustrated in FIG. 1.
[0045] In block 210, the payment system 160 issues a proxy card 105
to the user 101. In an exemplary embodiment, the user 101 creates
requests a proxy card 105 using a web server, and the proxy card
105 is mailed to the user 101. The user 101 may be issued an
account number to be used for transactions via the Internet before
a physical card is received. In an alternative exemplary
embodiment, the payment system 160 mails an inactivated proxy card
105 to the user 101. The proxy card 105 is then activated by the
user 101 before use. In an alternative exemplary embodiment, a
physical proxy card 105 is not issued. The proxy card 105 account
information is stored in the mobile device 120 and is used to make
a payment via a NFC, Bluetooth, Wi-Fi, or other form of wireless
tap of the mobile device 120 with the terminal reader 113. In an
alternative exemplary embodiment, the purchase is initiated when
the user 101 enters an account identification number at the POS
terminal 118 or in the mobile device 120. The account
identification number may be the proxy card 105 account number or a
different number that links the payment transaction to the proxy
card 105 account. In yet another alternative exemplary embodiment,
the purchase is initiated by use of a permanent/temporary
virtual/physical token QR code, bar code, or other suitable
machine-readable medium that is read by the POS terminal 118. In
these cases, the POS terminal 118 may comprise a scanner, camera,
or other reading device that captures the proxy account
information, such as a bar code or QR reader or other suitable
reading device. The proxy account information may be printed in
paper or other form.
[0046] In block 220, the user 101 creates a new payment system 160
account or links the proxy card 105 to an existing payment system
160 account. The payment system 160 also may create or update a
digital wallet application 122 account on the mobile device
120.
[0047] In block 230, the user 101 activates the proxy card 105 and
associates one or more financial card accounts (for example, debit
cards, credit cards, gift cards/stored value cards, loyalty
cards/reward cards, coupons, prepaid or other offers, and other
accounts used to make a purchase or redeem value added services)
with the proxy card 105 account. In an exemplary embodiment, the
user associates multiple financial card accounts with the proxy
card 105 account. The user 101 may perform this block by inputting
identifying information for each financial card account.
[0048] In an exemplary embodiment, one or more financial card
account(s) are maintained by the payment system 160 and other
issuers 170a. In an alternative exemplary embodiment, the payment
system 160 maintains one or more of the financial card accounts and
acts as the issuer for that financial card account. In another
exemplary embodiment, the financial card accounts are maintained by
more than one issuer 170, including the payment system 160.
[0049] The user 101 may define payment rules to be followed when
processing a payment using the proxy card 105, in block 240. The
method for defining the proxy card 105 rules is described in more
detail hereinafter with reference to the methods described in FIG.
3.
[0050] FIG. 3 is a block flow diagram depicting a method for
defining proxy card static rules according to an exemplary
embodiment. The method 240 is described with reference to the
components illustrated in FIG. 1.
[0051] In block 310, the payment system 160 sets forth the default
payment rules associated with the proxy card 105 account. Blocks
320 through 365 describe the exemplary default payment rules. In an
alternative exemplary embodiment, the exemplary default rules may
appear in any order. In another exemplary embodiment, one or more
of the exemplary default rules may not be used if additional funds
are not required. For example, if after the application of a stored
value account, further funds are not required to complete the
purchase, the payment transaction will be fully authorized without
following further rules.
[0052] Blocks 320-365 depict an exemplary rule flow. In an
exemplary embodiment, offers and value added services are applied
first. In block 320, the payment system 160 will determine if the
user 101 has any coupons, vouchers, prepaid or other redemption
offers, or other forms of value added services associated with the
proxy card 105 first.
[0053] If the payment system 160 determines that the user 101 has a
value added service available, it will apply those financial
accounts first, in block 325. In an exemplary embodiment, the
payment system 160 will have a pre-defined order in which it looks
for and applies the various forms of value added services. For
example, the payment system 160 may apply vouchers first, then
coupons, then redemption offers, and finally any other form of
registered value added service.
[0054] If the payment system 160 determines that the user 101 does
not have a value added service available, it will proceed to block
340.
[0055] In an exemplary embodiment, loyalty cards are applied
second. In block 340, the payment system 160 will determine if the
user 101 has a loyalty card, reward card, or other form of store
value card associated with the proxy card 105. In an alternative
exemplary embodiment, the payment system 105 may apply loyalty
cards before other forms of value added services.
[0056] If the payment system 160 determines that the user 101 has a
loyalty card available, it will apply that financial account. In an
exemplary embodiment, the payment system 160 will determine if
multiple loyalty cards are available and apply each financial
account.
[0057] If the payment system 160 determines that the user 101 does
not have a loyalty card available, it will proceed to block
350.
[0058] In an exemplary embodiment, stored value accounts are
applied third. In block 350, the payment system 160 will determine
if the user 101 has a stored value account, including gift cards,
prepaid cards, re-loadable transaction cards, exchange cards and
other forms of non-credit based value cards associated with the
proxy card 105.
[0059] If the payment system 160 determines that the user 101 has a
stored value card available, it will apply that financial account.
In an exemplary embodiment, the payment system 160 will determine
if multiple stored value accounts are available and apply each
financial account.
[0060] If the payment system 160 determines that the user 101 does
not have a stored value card available, it will proceed to block
360.
[0061] In an exemplary embodiment, debit and credit cards are
applied last. In block 360, the payment system 160 will determine
if the user 101 has a debit card, credit card or other form of
credit-based account associated with the proxy card 105.
[0062] If the payment system 160 determines that the user 101 has a
debit/credit card available, it will apply that financial
account.
[0063] If the payment system 160 determines that the user 101 does
not have a debit/credit card available, the transaction will
end.
[0064] In an exemplary embodiment, the default static payment rules
may be presented in any order. In an alternative exemplary
embodiment, the payment system 160 may add, delete, or otherwise
change any of the default static payment rules.
[0065] The user 101 also may configure payment rules. In block 370,
the user 101 may add, delete, or otherwise change any of the
default static payment rules. In an exemplary embodiment, the user
101 also may change the order of the rules.
[0066] In an exemplary embodiment, the user 101 may define or
select additional static payment rules. The user 101 may define
payment rules based on the type of or name of the merchant (for
example, if the merchant is a restaurant, use the A credit cards
first, or use the frequent flyer credit card if the merchant is an
airline), the time of day or day of the week (for example, use the
restaurant loyalty card first for lunches over $5, or use the
business credit card for weekday expenses between the hours of 9 am
and 5 pm), or the location or currency used by the merchant (for
example, use credit card X for all European transactions, or use
credit card Z for all online transactions). The user may define
conditional rules. For example, if the transaction is under $5 at B
coffee shop, use the Y gift card.
[0067] In addition to the rules discussed with reference to FIG. 3,
the payment system 160 also can learn rules for application of a
financial account. For example, if the user applies a particular
financial account to a particular merchant or type of merchant, and
the user repeats that process for a predetermined number of times
or time period, then the payment system 160 can create a rule to
apply that particular financial account whenever the proxy card is
used at the particular merchant or type of merchant. The payment
system 160 can log the user's 101 past use of particular financial
accounts with regard to particular merchants or types of merchants.
Then, when such logging determines that the user consistently
applies the same financial account with the same merchant or type
of merchant, the payment system 160 establishes a new rule for such
use. In an exemplary embodiment, the payment system 160 can
identify the user's past application of a particular financial
account based on the user's rule setting in the payment system 160
within a predetermined time of application of the user's proxy card
at the particular merchant or type of merchant. The payment system
160 may insert the learned rules into the appropriate order of
payment rules. For example, if the learned payment rule applies to
a credit or debit card, then the learned payment rule is inserted
prior to the standard rule for applying credit or debit cards. A
similar insertion process applies to offers, loyalty cards, and
stored value cards.
[0068] In an exemplary embodiment, the user 101 can access the
payment system 160 account via the mobile device 120 and can add,
delete, or modify the static rules at any time. In an exemplary
embodiment, the user 101 can access the payment system 160 account
and override the static rules on a one-time or multiple-time basis,
without permanently changing the static rules. In an alternative
exemplary embodiment, the user 101 can use a mobile device 120
application 122 to add, delete, or modify the static rules using
the user interface 123 at the time payment is made.
[0069] From block 370, the method 240 proceeds to block 250 (FIG.
2).
[0070] Returning to FIG. 2, in block 250, the payment system 160
sends the user proxy card 105 account identification information to
the network 150.
[0071] In block 260, the network 150 stores the proxy card account
identification information. In an alternative exemplary embodiment,
the account number identifies the payment system 160 as the issuer
and payments are automatically routed from the network 150 to the
payment system 160 for approval.
[0072] FIG. 4 is a block flow diagram depicting a method for
processing a proxy card payment according to an exemplary
embodiment. The method 400 is described with reference to the
components illustrated in FIG. 1.
[0073] In block 403, the user 101 optionally modifies the static
rules defined in block 240. In an exemplary embodiment, the mobile
device 120 is used to temporarily add/modify/delete one or more
static rules before a purchase is made using the proxy card 105. In
an alternative exemplary embodiment, the terminal reader 113 and/or
POS terminal 118 is used to temporarily add/modify/delete one or
more static rules before a purchase is made using the proxy card
105.
[0074] The user 101 applies the proxy card 105 to a transaction
with the merchant 110, in block 405. In an exemplary embodiment,
the user 101 swipes the proxy card 105 at the POS terminal 118 to
pay for a transaction with the merchant 110. Alternatively, the
user may present a printed bar code, QR code, or other
machine-readable indicia of the proxy card information for capture
by the terminal reader 113.
[0075] In an alternative exemplary embodiment, the user 101 using
the mobile device 120 to initiate a contactless "tap" with the
terminal reader 113. In operation of an NFC transaction, a user 101
"taps" a mobile device 120, such as an NFC-enabled mobile phone
120, to a terminal reader 113 of a point of sale system. The
terminal reader 113 recognizes the NFC-enabled device 120 when the
device is moved within range of the reader 113, establishes a
secure communication channel with the device 120, and initiates a
payment transaction between the reader 113 and the device 120.
[0076] In alternative exemplary embodiment, the user 101 completes
an online purchase via the Internet. The user 101 can browse the
merchant's 110 website for products using a web server and indicate
a desire to purchase one or more products. After the user 101 has
indicated a desire to purchase the product(s) (for example, by
actuating a "checkout" link), the merchant's 110 website can
present a user interface in the form of a webpage to receive
payment information from the user 101. The user 101 enters the
proxy card 105 information to complete the purchase upon
checkout.
[0077] In another alternative exemplary embodiment, the digital
wallet application 122 can interact with a website of the merchant
110 and with the user 101. The merchant's 110 website can detect
whether the mobile device 120 includes a digital wallet application
122 and attach to user's digital wallet. Once attached, the
merchant's 110 website can send a purchase request message to the
digital wallet application 122 requesting payment information. In
response to receiving a purchase request message from the
merchant's 110 website, the digital wallet application 122 can
present the user 101 with a user interface 123 for the user 101 to
confirm the purchase using proxy card 105 information saved in the
digital wallet application 122.
[0078] In block 407, the POS terminal generates a payment request
message to request payment using the proxy account, and the
merchant system 110 optionally adds product identification
information to the payment request message generated by application
of the proxy card 105 to the transaction. In an exemplary
embodiment, the product identification information comprises the
SKU number(s) of the products sought in the user-merchant
transaction. In alternative exemplary embodiments, the product
identification information can comprise any suitable information
that uniquely identifies a product. For example, the product
identification information can include Global Trade Item Numbers
("GTINs"), such as International Standard Book Numbers ("ISBNs"),
Universal Product Codes ("UPCs"), European Article Numbers
("EANs"), Japanese Article Numbers ("JANs"), brand name and model
number combinations, and other standard identifiers. In an
alternative exemplary embodiment, the product identification
information includes a broad grouping of product/service
identification (for example, the category of goods/services
sought).
[0079] In an exemplary embodiment, the product identification
information is inserted in an empty track of the magnetic stripe
information obtained from the proxy card 105. Traditionally, at
least one track on the magnetic stripe of a financial card remains
unused. Since the payment system 160 functions as the issuer of the
proxy card 105, the magnetic stripe can be formatted to contain
variable information, in addition to the account information
traditionally stored on tracks 1 and 2 of the magnetic stripe. The
proxy card may be formatted to have one or more additional tracks
wherein information can be transmitted between the merchant 110 and
the payment system 160. In an exemplary embodiment, the merchant
110 adds product identification information to an empty track in
the payment request message to enable the application of
product-specific value added services to the current transaction,
such as coupons, prepaid and other offers, and loyalty/rewards
programs. In an alternative exemplary embodiment, the product level
identification information can be used to provide the user 101 with
product-specific coupons and offers to be used in a later
transaction.
[0080] In block 410, the merchant 110 submits the payment request
to the acquirer 140. In an exemplary embodiment, the merchant's POS
terminal 118 submits the request to the acquirer 140 via a network
(not illustrated). In an alternative exemplary embodiment, the
merchant's 110 website submits a request to the acquirer 140.
[0081] The acquirer 140 submits the payment request to the card
network 150, in block 415.
[0082] In block 420, the card network 150 determines whether the
account number used to pay for the transaction is a classic card
number. In an exemplary embodiment, the card network 150
automatically makes this determination using a series of numbers or
routing information in the proxy card 105 account information. In
an alternative exemplary embodiment, the card network 150 reviews a
list of saved account identification information provided to the
card network 150 by the payment system 160 above.
[0083] If the card number is a classic card number, the payment is
processed according to traditional payment processing methods, in
block 423.
[0084] If the card number is not a classic card number, the issuer
170 is the payment system 160 (for example, if the proxy card 105
was used for the transaction). The card network 150 then forwards
the payment request to the payment system 160, in block 425.
[0085] In an alternative exemplary embodiment, the card number can
comprise an identifier that corresponds to the list of saved
account identification information, such as a block of numbers or
other indicia, which identifies the issuer or the payment system.
Based on this identifier, the payment is processed according to
traditional payment processing methods, in block 423, if the
identifier corresponds to a conventional issuer, or the payment is
forwarded to the payment system 160, in block 425, if the
identifier corresponds to the payment system 160.
[0086] In block 427, the payment system 160 optionally reads the
product identification inserted into the payment request. In an
exemplary embodiment, the product identification information was
inserted by the merchant above. In an exemplary embodiment, the
product identification information is used to determine which value
added services can be applied to the current transaction. In an
alternative exemplary embodiment, the product identification
information is used to determine which offers can be provided to
the user 101 for future transactions.
[0087] In block 430, the payment system 160 accesses the user's
proxy card 105 account. The method for accessing a user's proxy
card 105 account is described in more detail hereinafter with
reference to the methods described in FIG. 5.
[0088] FIG. 5 is a block flow diagram depicting a method for
accessing a user's proxy card account according to an exemplary
embodiment. The method 430 is described with reference to the
components illustrated in FIG. 1.
[0089] In block 510, the payment system 160 receives the proxy card
105 payment request from the card network 150.
[0090] The payment system 160 identifies the user 101 account
associated with the proxy card, in block 520. In an exemplary
embodiment, the user's 101 account contains the static rules
defined by the user 101 (or the default rules if the user 101 has
not modified the default rules), any modifications made to the
static rules prior to the transaction, and the associated financial
accounts. In an exemplary embodiment, the payment system 160 uses
the account information to determine how to proceed with the
transaction.
[0091] In block 530, the payment system 160 determines if the user
101 has defined payment rules. In an exemplary embodiment, the user
101 has defined static rules and/or modified the rules prior to the
transaction.
[0092] If the user has defined payment rules, the payment system
160 applies the user-defined rules first to determine the order to
apply the financial accounts to the transaction, in block 540. In
an exemplary embodiment, the payment system 160 applies the rules
modified by the user 101 prior to the transaction first and the
user-defined static rules second. In an alternative exemplary
embodiment, the user 101 did not modify the rules prior to the
transaction. In this embodiment, the payment system 160 applies the
user-defined static rules first.
[0093] In block 545, the payment system 160 determines whether the
transaction will be declined based on a user-defined rule. For
example, if the user 101 defined a rule wherein no more than five
transactions may occur in a single day, and this is the user's six
transaction, the payment system 160 will determine that the
transaction will be declined. If the transaction will be declined,
the method 430 continues to block 815 (FIG. 8). Other rules that
can cause a request to be declined include fraud protection rules.
For example, the payment system 160 may decline a payment request
if the transaction occurs outside of the user's 101 typical
geographic area or if activity on the user's 101 account has
exceeded a payment system 160 defined amount or number of
transactions. Such fraud protection rules can be included in the
default, static rules or the user-defined rules, or a combination
thereof.
[0094] If the transaction will not be declined, the method 430
continues to block 434 (FIG. 4).
[0095] If the user has not defined payment rules, the payment
system 160 proceeds to block 550. In block 550, the payment system
160 applies the default static payment rules to the
transaction.
[0096] In block 555, the payment system 160 determines whether the
transaction will be declined based on a default static rule. For
example, if the user registered only gift cards with the payment
system 160 and additional funds are required, the payment system
160 will determine that the transaction will be declined. If the
transaction will be declined the method 430 continues to block 815
(FIG. 8).
[0097] If the transaction will not be declined, the method 430
continues to block 434 (FIG. 4).
[0098] From block 555, the method 430 proceeds to block 435 (FIG.
4).
[0099] Returning to FIG. 4, in block 435, the payment system 160
determines if the user 101 has any coupons, vouchers, prepaid
offers, redemption offers, loyalty/rewards cards, or other forms of
value added services associated with the proxy card 105.
[0100] If the payment system 160 determines that the user 101 has a
value added service available, it will apply those financial
accounts first, in block 437. In an exemplary embodiment, the
payment system 160 will have a pre-defined order in which it looks
for and applies the various forms of value added services. For
example, the payment system 160 may apply vouchers first, then
coupons, then redemption offers, and finally any other form of
registered value added service. The method for processing value
added services is described in more detail hereinafter with
reference to the methods described in FIG. 6.
[0101] FIG. 6 is a block flow diagram depicting a method for
processing value added services according to an exemplary
embodiment. The method 437 is described with reference to the
components illustrated in FIG. 1.
[0102] In block 610, the user 101 associates value added service
accounts with the proxy card 105. In an exemplary embodiment, this
step is completed during the registration process described in FIG.
2. In an alternative exemplary embodiment, the user 101 adds value
added service accounts, including coupons, loyalty cards, reward
cards, offers (including prepaid offers), discounts, and other
forms of value added services to the proxy card account at any time
before the transaction.
[0103] The merchant 110 optionally submits value added service
discounts to the payment system 160, in block 615. In an exemplary
embodiment, the merchant Alternatively, or additionally,
manufacturers can notify the payment system 160 of discounts,
coupons, and other forms of value added services for particular
products prior to the payment request. The payment system can
search the data storage unit 167 for stored or received merchant
and/or manufacturer value added services in connection with block
645, discussed hereinafter.
[0104] In block 620, the payment system 160 reads the user
identification information form the payment request. In an
exemplary embodiment, the user identification information is
contained in or encoded by the proxy card 105 account
identifier.
[0105] The payment system 160 reads the merchant 110 identification
information from the payment request, in block 625. In an exemplary
embodiment, the merchant 110 identification information is
contained in or encoded by the payment request.
[0106] In block 630, the payment system 160 reads the product
identification information from the payment request. In an
exemplary embodiment, the product identification information is the
SKU information inserted into the payment request by the merchant
110. In an alternative exemplary embodiment, the product
identification information is a description of the type of
goods/services sought.
[0107] The payment system 160 accesses the user's 101 value added
services associated with the proxy card 105, in block 635.
[0108] In block 640, the payment system 160 determines which value
added services to apply and/or the order to apply the value added
services. In an exemplary embodiment, the order is defined by the
user-defined static rules, the user-defined modified rules or the
default static rules. In an alternative exemplary embodiment, the
user 101 can define rules to be applied to specific value added
services. For example, the user 101 can specify when to use a
coupon or redeem an offer. These rule include, but are not limited
to a purchase threshold (for example, receive $10 off a single
purchase of more than $50 from merchant 110), an aggregate purchase
threshold (for example, receive $10 off next purchase from merchant
110 after the accumulated purchase at merchant 110 has reached
$1000), a minimum number of purchases from the merchant 110 (for
example, receive $10 off your tenth purchase from the merchant
110), a time restriction (for example, receive $10 off a lunch-time
purchase), and/or a location restriction (for example, receive $10
off a purchase at a specified merchant 110 location.
[0109] In block 645, the payment system 160 determines whether the
user 101 has a saved offer for the transaction. In an exemplary
embodiment, a saved offer can include, but is not limited to, a
coupon, a voucher, a store reward, a redemption, or other form of
saved offer.
[0110] If the user 101 has a saved offer for the transaction that
meets the rules specified by the user 101 and rules specified for
the offer, the payment system 160 applies the offer, in block 650.
In an exemplary embodiment, the payment system 160 functions as the
issuer 170 for the offer and can adjust the purchase price of the
transaction after the offer(s) is applied.
[0111] In an exemplary embodiment, blocks 645 and 650 also comprise
searching for value added services provided by the merchant or a
manufacturer that can be applied to the purchase transaction based
on the identity of the merchant or specific products in the
purchase transaction.
[0112] If the user 101 does not have a saved offer for the
transaction, the method 437, proceeds to block 655.
[0113] In block 655, the payment system 160 determines whether the
user 101 has a loyalty card for the transaction.
[0114] If the user 101 has a loyalty card for the transaction, the
payment system 160 applies the loyalty card, in block 665. In an
exemplary embodiment, the payment system 160 functions as the
issuer 170 for the loyalty card and can adjust the purchase price
of the transaction after the loyalty card is applied. In an
alternative exemplary embodiment, the loyalty card is applied
before the offer(s) is applied.
[0115] If the user does not have a loyalty card for the transaction
in block 655, the method 437 proceeds to block 440 (FIG. 4).
[0116] From block 655, the method 437 proceeds to block 440 (FIG.
4).
[0117] Returning to FIG. 4, in block 440, the payment system 160
will determine if the user 101 has a stored value account,
including gift cards, prepaid cards, re-loadable transaction cards,
exchange cards and other forms of non-credit based value cards
associated with the proxy card 105.
[0118] If the payment system 160 determines in block 435 that the
user 101 does not have a value added service available, the method
400 will proceed directly to block 440.
[0119] If the payment system 160 determines that the user 101 has a
stored value card available, it will apply that financial account,
in block 443. In an exemplary embodiment, the payment system 160
will determine if multiple stored value accounts are available and
apply each financial account. In an exemplary embodiment, the
payment system 160 functions as the issuer 170 for the stored value
account and can adjust the purchase price of the transaction after
the stored value account is applied. In an alternative exemplary
embodiment, the payment system 160 will forward a new payment
request to the issuer 170 that maintains the stored value account
and receive the authorization from the issuer if the transaction is
approved.
[0120] In block 445, the payment system 160 will determine if
additional funds are required for the transaction. In an exemplary
embodiment, the payment system 160 will adjust the purchase price
of the transaction after the value added services and stored value
accounts are applied to determine if additional funds are required.
In an alternative exemplary embodiment, the payment system 160 will
determine if additional funds are required after applying only the
value added services or stored value account, as defined by the
rules. In another alternative exemplary embodiment, value added
services and stored value accounts are not applied to the
transaction and the payment system 160 will automatically proceed
to block 445.
[0121] If the payment system 160 determines in block 440 that the
user 101 does not have a stored value card available, the method
400 will proceed to block 445.
[0122] If additional funds are not required in block 445 for the
transaction, the payment system 160 will authorize the transaction,
in block 447. The method 400 will then proceed to block 460.
[0123] If additional funds are required in block 445 for the
transaction, the payment system 160 will determine in block 450 the
issuer 160, 170 of the account(s) to be used to finance the
remainder of the transaction. In an exemplary embodiment, the
payment system 160 will determine if the user 101 has a debit card,
credit card or other form of credit-based account associated with
the proxy card 105, in block 450. The payment system 160 will apply
the rules to select one or more credit/debit card to the
transaction. In an exemplary embodiment, the payment system 160
will determine a single account to be used for the remainder of the
transaction. In an alternative exemplary embodiment, the payment
system 160 will determine that multiple accounts will be used for
the remainder of the transaction.
[0124] If the payment system 160 is the issuer of the account, in
block 453, the payment system 160 will approve or deny the account
transaction. In an exemplary embodiment, the payment system 160
will determine whether sufficient funds are available and/or
whether the transaction meets the rules for the financial
account(s) used to complete the transaction.
[0125] If the transaction is declined, the method 400 proceeds to
block 815 (FIG. 8).
[0126] If the transaction is approved, the method 400 proceeds to
block 465 (FIG. 4).
[0127] If the payment system 160 is not the issuer 170 of the
financial account(s), the payment system sends a new payment
request to each issuer (170a, 170b, etc.) via the card network 150,
in block 455. In an exemplary embodiment, the new payment request
is for the remaining transaction balance after applying the value
added services, stored value account, and/or any other financial
account maintained by a different issuer 170.
[0128] In block 457, the issuer 170 approves or declines the
transaction.
[0129] If the transaction is declined, the method 400 proceeds to
block 805 (FIG. 8).
[0130] FIG. 8 is a block flow diagram depicting a method for
authorizing a declined transaction according to an exemplary
embodiment. The method 800 is described with reference to the
components illustrated in FIG. 1.
[0131] If the payment system 160 is not the issuer that maintains
the financial account (see block 457 (FIG. 4)), the issuer 170
notifies the payment system 160 of the declined transaction via the
card network 150, in block 805.
[0132] In block 810, the payment system 160 receives the
notification of the declined transaction from the issuer 170 via
the card network 150.
[0133] The payment system 160 determines the reason the transaction
was declined, in block 815. If the payment system 160 is the issuer
that maintains the financial account (sec block 453 (FIG. 4) or
blocks 545, 555 (FIG. 5)) and the transaction was declined, the
payment system 160 determines the reason the transaction was
declined.
[0134] In block 820, the payment system 160 determines whether the
transaction was declined because the transaction did not meet one
or more user-defined or other user-overrideable rules.
[0135] If the transaction meets the user-defined rules, the method
800 proceeds to block 860 (FIG. 8).
[0136] If the transaction does not meet the user-defined rules, the
payment system 160 communicates a real-time override request to the
user 101, in block 825. In an exemplary embodiment, the override
request is communicated to the user's mobile device 120. In an
exemplary embodiment, the user 101 is prompted to override the
user-defined rule using the user interface 123 of the mobile device
120.
[0137] In block 830, the user 101 responds to the override request
using the user interface 123 of the mobile device 120. In an
exemplary embodiment, the mobile device 120 communicates the
override request and initiates an interaction with the user 101 to
present options available for selection. In an exemplary
embodiment, the application 122 is engaged and processes the
override request received from the payment system 160 to present
the information via the user interface 123. The application 122 may
create a list of options available to the user 101 based on the
information received from the payment system 160 and the
information stored in the application 122. In another exemplary
embodiment, the application 122 creates a series of prompts
requesting user 101 choices for the available options. In an
exemplary embodiment, a user response is optional.
[0138] If the user 101 does not authorize an override of the rules,
in block 835, the transaction is declined and ends.
[0139] If the user 101 authorizes the override, the mobile device
120 communicates the override authorization to the payment system
160, in block 840.
[0140] In block 845, the payment system 160 receives the override
authorization from the mobile device 120.
[0141] The payment system 160 determines the issuer 170 of the
financial account, in block 850.
[0142] If the payment system 160 is the issuer of the financial
account, the payment system 160 authorizes the transaction, in
block 853. The method 800 then proceeds to block 465 (FIG. 4).
[0143] If the payment system 160 is not the issuer of the financial
account, the payment system 160 sends a new payment request to the
issuer(s) 170 via the card network 150, in block 855. The method
800 then proceeds to block 457 (FIG. 4).
[0144] If the transaction is declined, but meets the user-defined
rules (see block 820 (FIG. 8)), the methods 800 proceeds to block
860 (FIG. 8).
[0145] In block 860, the payment system 160 determines whether the
transaction was declined for insufficient funds.
[0146] If the transaction was not declined for insufficient funds,
the transaction terminates.
[0147] If the transaction was terminated for insufficient funds,
the payment system 160 communicates a request to the user 101 to
override the rules and select a different financial account, in
block 865. In an exemplary embodiment, the request is communicated
to the user's mobile device 120. In an exemplary embodiment, the
user 101 is prompted to select a new account using the user
interface 123 of the mobile device 120.
[0148] In block 870, the user 101 responds to the request using the
user interface 123 of the mobile device 120. In an exemplary
embodiment, the mobile device 120 communicates the request and
initiates an interaction with the user 101 to present options
available for selection. In an exemplary embodiment, the
application 122 is engaged and processes the request received from
the payment system 160 to present the information via the user
interface 123. The application 122 may create a list of options
available to the user 101 based on the information received from
the payment system 160 and the information stored in the
application 122. In another exemplary embodiment, the application
122 creates a series of prompts requesting user 101 choices for the
available options. In an exemplary embodiment, a user response is
optional.
[0149] If the user 101 does not select a different financial
account, in block 875, the transaction is declined and ends.
[0150] If the user 101 selects a different financial account, the
mobile device 120 communicates the selection to the payment system
160, in block 880.
[0151] In block 885, the payment system 160 receives the selection
from the mobile device 120.
[0152] The payment system 160 determines the issuer 170 of the
financial account, in block 890.
[0153] If the payment system 160 is the issuer of the financial
account, the payment system 160 authorizes the transaction, in
block 893. The method 800 then proceeds to block 465 (FIG. 4).
[0154] If the payment system 160 is not the issuer of the financial
account, the payment system 160 sends a new payment request to the
issuer(s) 170 via the card network 150, in block 897. The method
800 then proceeds to block 457 (FIG. 4).
[0155] In exemplary embodiments, the real-time authorization
provided by the method 800 can be performed in conjunction with, or
instead of, declining the payment request. For example, if the
payment system 160 determines to decline a payment request or
receives a payment request denial from an issuer 170, the payment
system 160 communicate a notice of declination to the merchant
system 110. After the user submits an authorization to override a
rule, a confirmation that the user is making the purchase even
though fraud protection rules identified the transaction as
possible fraud, or a selection of a different financial account,
the user may immediately reinitiate the payment transaction with
the merchant by using the proxy card again. This time, upon receipt
of the payment request, the payment system 160 will approve the
payment request (or process the payment request using the specified
financial account). Alternatively, the payment system 160 can
communicate the notice message to the user 101, wait for a
response, and authorize or further process the payment request
after receiving the user's 101 response without issuing a notice of
declination to the merchant system 110.
[0156] Referring back to FIG. 4, if the transaction is approved,
the issuer 170 sends an authorization message to the payment system
160 via the card network 150, in block 460. If the payment system
160 is the issuer of the financial account (see block 447), the
payment system 160 notes the authorization of the transaction.
[0157] In block 465, the payment system 160 generated an
authorization message and optionally adds user identification
information to the authorization message. In an exemplary
embodiment, the user 101 identification information may include an
e-mail address, physical address, phone number, name, store loyalty
number, or other form of identifying information. In an exemplary
embodiment, the user's 101 identifying information may be used by
the merchant 110 to send offers, coupons, vouchers, advertisements,
or other forms redemption offers to the user 101.
[0158] In block 470, the payment system 160 sends offers to the
user 101 to be used on a future transaction. The method sending
offers is described in more detail hereinafter with reference to
the methods described in FIG. 7.
[0159] FIG. 7 is a block flow diagram depicting a method for
sending offers according to an exemplary embodiment. The method 470
is described with reference to the components illustrated in FIG.
1.
[0160] In block 710, the merchant 110 submits offers to the payment
system 160. In an exemplary embodiment the merchant 110 submits
offers designed to promote return customers. For example, the
merchant 110 may submit an offer for a percentage off the user's
101 next transaction. In an alternative exemplary embodiment, the
merchant 110 submits offers based on the products/services
purchased in the transaction. For example, the merchant 110 may
submit an offer for a reduced price on the same or related product
to be redeemed on the next visit. In an exemplary embodiment, the
offers are submitted in advance of the transaction and stored by
the payment system 160 in the data storage unit 167.
[0161] The payment system 160 reads the product identification
information inserted by the merchant 110 in the payment request, in
block 720. In an exemplary embodiment, the product identification
information is the product/service SKU number.
[0162] In block 730, the payment system 160 reads the merchant 110
identification information from the payment request.
[0163] In block 740, the payment system 160 matches the merchant
110 identification information and the product identification
information to determine whether one or more offer can be sent to
the user 101. In an exemplary embodiment, the offers were submitted
by the merchant in block 710. In an alternative exemplary
embodiment, the offers are generalized offers based on the product
identification information (for example, manufacturer's
coupons).
[0164] The payment system 160 sends the user 101 one or more
offers, in block 750. In an exemplary embodiment, the offers are
saved in the user's 101 payment system 160 account and are
associated with the proxy card 150. In an exemplary embodiment, the
notification of the offers is communicated to the user via the
mobile device, e-mail, SMS, text message, or other form of
communication methods designated by the user 101. In an alternative
exemplary embodiment, the offers are sent via a communication
method designated by the user 101.
[0165] From block 750, the method 470 proceeds to block 475 (FIG.
4).
[0166] Returning to FIG. 4, in block 475, the payment system 160
forwards a transaction authorization message to the card network
150.
[0167] In block 480, the card network 150 forwards the
authorization message to the acquired 140.
[0168] The acquirer 140 send the authorization message to the
merchant 110, in block 485.
[0169] In block 490, the merchant system 110 optionally reads the
user 101 identification information inserted in the payment
authorization message by the payment system 160. In an exemplary
embodiment, the merchant POS terminal 118 is able to extract the
user 101 information from the authorization message and store the
information for later use. For example, the merchant may use the
identification information to contact the user 101 for survey
information, to forward loyalty card information, or to forward
other offers to the user 101. In an alternative exemplary
embodiment, the user identification information can be provided in
the proxy card account information stored on the magnetic stripe of
the proxy card or otherwise associated with the proxy card account
identifier. In this case, the terminal reader 113 reads the user
information when collecting the initial information from the proxy
card 105.
[0170] After use of each financial account for a particular payment
request, the payment system 160 updates the used financial account
for the user's 101 proxy card 105 in the data storage unit 167. For
example, if a single-use coupon, prepaid or other offer, or loyalty
card is applied, the account is updated to note use of the item and
that further use is not allowed. If a stored value card is used,
the account is updated to note the amount used and any remaining
amount that is available. If a debit or credit card is used, the
account is updated to show the amount available and the remaining
amount that is available. The payment system 160 also can increment
or decrement loyalty cards or reward cards provided by the
merchant, allowing the loyalty or other rewards to accumulate for
future use.
General
[0171] Users may be allowed to limit or otherwise affect the
operation of the features disclosed herein. For example, users may
be given opportunities to opt-in or opt-out of the collection or
use of certain data or the activation of certain features. In
addition, users may be given the opportunity to change the manner
in which the features are employed, including for situations in
which users may have concerns regarding privacy. Instructions also
may be provided to users to notify them regarding policies about
the use of information, including personally identifiable
information, and manners in which each user may affect such use of
information. Thus, information can be used to benefit a user, if
desired, through receipt of relevant advertisements, offers, or
other information, without risking disclosure of personal
information or the user's identity.
[0172] One or more aspects of the exemplary embodiments may include
a computer program that embodies the functions described and
illustrated herein, wherein the computer program is implemented in
a computer system that comprises instructions stored in a
machine-readable medium and a processor that executes the
instructions. However, it should be apparent that there could be
many different ways of implementing the exemplary embodiments in
computer programming, and the exemplary embodiments should not be
construed as limited to any one set of computer program
instructions. Further, a skilled programmer would be able to write
such a computer program to implement an embodiment based on the
appended flow charts and associated description in the application
text. Therefore, disclosure of a particular set of program code
instructions is not considered necessary for an adequate
understanding of how to make and use the exemplary embodiments.
Moreover, any reference to an act being performed by a computer
should not be construed as being performed by a single computer as
more than one computer may perform the act.
[0173] The exemplary systems, methods, and blocks described in the
embodiments presented previously are illustrative, and, in
alternative embodiments, certain blocks can be performed in a
different order, in parallel with one another, omitted entirely,
and/or combined between different exemplary methods, and/or certain
additional blocks can be performed, without departing from the
scope and spirit of the invention. Accordingly, such alternative
embodiments are included in the invention described herein.
[0174] The invention can be used with computer hardware and
software that performs the methods and processing functions
described above. As will be appreciated by those having ordinary
skill in the art, the systems, methods, and procedures described
herein can be embodied in a programmable computer, computer
executable software, or digital circuitry. The software can be
stored on computer readable media. For example, computer readable
media can include a floppy disk, RAM, ROM, hard disk, removable
media, flash memory, memory stick, optical media, magneto-optical
media, CD-ROM, etc. Digital circuitry can include integrated
circuits, gate arrays, building block logic, field programmable
gate arrays ("FPGA"), etc.
[0175] Although specific embodiments of the invention have been
described above in detail, the description is merely for purposes
of illustration. Various modifications of, and equivalent blocks
and components corresponding to, the disclosed aspects of the
exemplary embodiments, in addition to those described above, can be
made by those having ordinary skill in the art without departing
from the spirit and scope of the invention defined in the following
claims, the scope of which is to be accorded the broadest
interpretation so as to encompass such modifications and equivalent
structures.
* * * * *