U.S. patent application number 16/706947 was filed with the patent office on 2021-06-10 for systems and methods for binding unique tokens with transaction parameters to authorize transactions.
This patent application is currently assigned to Capital One Services, LLC. The applicant listed for this patent is Capital One Services, LLC. Invention is credited to Johanna DAVIS, Allison FENICHEL, Varun GUPTA.
Application Number | 20210174355 16/706947 |
Document ID | / |
Family ID | 1000004564290 |
Filed Date | 2021-06-10 |
United States Patent
Application |
20210174355 |
Kind Code |
A1 |
GUPTA; Varun ; et
al. |
June 10, 2021 |
SYSTEMS AND METHODS FOR BINDING UNIQUE TOKENS WITH TRANSACTION
PARAMETERS TO AUTHORIZE TRANSACTIONS
Abstract
A system for binding unique tokens with transaction parameters
to authorize transactions based on monitoring user interactions
with one or more applications on a user device. Upon monitoring the
system determines first payment transaction initiation by a user at
a merchant payment gateway associated with the one or more
applications based on the monitoring. The system generates and
displays on the user device a unique token based at least on an
input received from the user device. The system receives the unique
token as part of an authorization request. Upon receiving the
unique token, the system identifies first transaction parameters
associated with the first payment transaction and automatically
binds the generated unique token with the identified first
transaction parameters.
Inventors: |
GUPTA; Varun; (Edison,
NJ) ; FENICHEL; Allison; (Brooklyn, NY) ;
DAVIS; Johanna; (Philadelphia, PA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Capital One Services, LLC |
McLean |
VA |
US |
|
|
Assignee: |
Capital One Services, LLC
McLean
VA
|
Family ID: |
1000004564290 |
Appl. No.: |
16/706947 |
Filed: |
December 9, 2019 |
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
G06Q 20/405 20130101;
G06Q 20/385 20130101; G06Q 20/3674 20130101 |
International
Class: |
G06Q 20/38 20060101
G06Q020/38; G06Q 20/36 20060101 G06Q020/36; G06Q 20/40 20060101
G06Q020/40 |
Claims
1. A system for binding unique tokens with merchant identifiers to
authorize transactions, the system comprising: one or more memory
devices storing instructions; and one or more processors configured
to execute the instructions to: monitor, with one or more
applications on a user device, user interactions of a user of the
user device; detect, based on the monitoring, a first payment
transaction initiation by the user at a merchant payment gateway of
a webpage; compare a webpage identifier of the webpage with a
predetermined list of webpages stored in a database; determine,
based on the comparison, whether the webpage identifier is
associated with at least one webpage from the list of webpages; in
response to a determination that the webpage identifier is not
associated with at least one webpage from the list of webpages,
generate and provide a unique token to the user device, the unique
token being configured to be input by the user as a payment
credential at the merchant payment gateway via the user device for
completing a transaction; receive the unique token as part of a
first authorization request to authorize the first payment
transaction; upon successfully authorizing the first payment
transaction in response to the first authorization request:
identify one or more first transaction parameters identifying a
merchant associated with the first payment transaction; and
automatically bind and store the generated unique token with the
identified one or more first transaction parameters; receive a
second authorization request to authorize a second payment
transaction using the unique token input at the merchant payment
gateway; identify, based on the received second authorization
request, one or more second transaction parameters identifying a
merchant associated with the second payment transaction; compare
the identified one or more second transaction parameters with the
one or more first transaction parameters; and authorize the second
payment transaction based on a result of the comparison indicating
a match between the merchant identified by the first transaction
parameter and the merchant identified by the second transaction
parameter.
2. The system of claim 1, wherein the unique token is a unique
virtual number utilized at the merchant payment gateway instead of
a payment card number.
3. The system of claim 1, wherein the one or more first transaction
parameters comprise at least one of the webpage identifier of the
webpage, a merchant category code associated with the first
merchant, a name of the first merchant, a masked name of the first
merchant, or a merchant identifier of the first merchant.
4. The system of claim 1, the one or more processors being further
configured to execute instructions to: identify an initiation of
the second payment transaction at the merchant payment gateway
based on the monitoring.
5. (canceled)
6. The system of claim 1, the one or more processors being further
configured to execute instructions to: decline authorization of the
second payment transaction based on the comparison indicating that
at least one of the one or more second transaction parameters does
not match with the one or more first transaction parameters.
7. The system of claim 1, the one or more processors being further
configured to execute instructions to: generate the unique token
associated with the first merchant further based at least on a
merchant identifier.
8. A computer implemented method for binding unique tokens with
merchant identifiers to authorize transactions, the method
comprising: monitoring, with one or more applications on a user
device, user interactions of a user of the user device; detecting a
first payment transaction initiation by the user at a merchant
payment gateway of a webpage associated with the one or more
applications based on the monitoring; upon determining that an
identifier associated with the webpage is not associated with a
previously generated token, generating and providing a unique token
to the user device, the unique token being configured to be input
by the user as a payment credential at the merchant payment gateway
via the user device for completing a transaction; receiving the
unique token as part of a first authorization request to authorize
the first payment transaction; upon successfully authorizing the
first payment transaction in response to the first authorization
request: identifying one or more first transaction parameters
associated with the first payment transaction, the first
transaction parameters identifying a merchant associated with the
transaction; and automatically binding and storing the generated
unique token with the identified one or more first transaction
parameters; receiving a second authorization request to authorize a
second payment transaction using the unique token input at the
merchant payment gateway; identifying, based on the received second
authorization request, one or more second transaction parameters
identifying a merchant associated with the second payment
transaction; comparing the identified one or more second
transaction parameters with the one or more first transaction
parameters; and authorizing the second payment transaction based on
a result of the comparison indicating a match between the merchant
identified by the first transaction parameter and the merchant
identified by the second transaction parameter.
9. The method of claim 8, wherein the unique token is a unique
virtual number utilized at the merchant payment gateway instead of
a payment card number.
10. The method of claim 8, wherein the one or more first
transaction parameters comprise at least one of the identifier
associated with the webpage, a merchant category code associated
with the first merchant, a name of the first merchant, a masked
name of the first merchant, or a merchant identifier of the first
merchant.
11. The method of claim 8, the method further comprising:
identifying an initiation of the second payment transaction at the
merchant payment gateway based on the monitoring.
12. (canceled)
13. The method of claim 8, the method further comprising: declining
authorization of the second payment transaction based on the
comparison indicating that at least one of the one or more second
transaction parameters does not match with the one or more first
transaction parameters.
14. The method of claim 8, the method further comprising:
generating the unique token associated with the first merchant
further based at least on a merchant identifier.
15. A non-transitory computer-readable medium storing instructions
executable by one or more processors to perform operations for
binding unique tokens with merchant identifiers to authorize
transactions, the operations comprising: monitoring, with one or
more applications on a user device, user interactions of a user of
the user device; determining, based on the monitoring, a first
payment transaction initiation by the user at a merchant payment
gateway of a webpage; comparing a webpage identifier of the webpage
with a predetermined list of webpages stored in a database;
determining, based on the comparison, whether the webpage
identifier is associated with at least one webpage from the
predetermined list; in response to a determination that the webpage
identifier is not associated with at least one webpage from the
list of webpages, generating and providing a unique token to the
user device, the unique token being configured to be input by the
user as a payment credential at a payment interface of the webpage
at the user device for completing a transaction; receiving the
unique token as part of a first authorization request to authorize
the first payment transaction; upon successfully authorizing the
first payment transaction in response to the first authorization
request: identifying one or more first transaction parameters
identifying a merchant associated with the first payment
transaction, the first transaction parameters comprising
information identifying a merchant associated with the transaction;
and automatically binding and storing the generated unique token
with the identified one or more first transaction parameters, the
generated unique token being sufficient to complete a subsequent
transaction only if one or more parameters of the subsequent
transaction matches the identified one or more first transaction
parameters; receiving a second authorization request to authorize a
second payment transaction using the unique token at the merchant
payment gateway; identify, based on the received second
authorization request, one or more second transaction parameters
identifying a merchant associated with the second payment
transaction; comparing the identified one or more second
transaction parameters with the one or more first transaction
parameters; and authorizing the second payment transaction based on
a result of the comparison indicating a match between the merchant
identified by the first transaction parameter and the merchant
identified by the second transaction parameter.
16. The non-transitory computer-readable medium of claim 15,
wherein the unique token is a unique virtual number utilized at the
merchant payment gateway instead of a payment card number.
17. The non-transitory computer-readable medium of claim 15,
wherein the one or more first transaction parameters comprise at
least one of the webpage identifier of the webpage, a merchant
category code associated with the first merchant, a name of the
first merchant, a masked name of the first merchant, or a merchant
identifier of the first merchant.
18. The non-transitory computer-readable medium of claim 15, the
operations further comprising: identifying an initiation of the
second payment transaction at the merchant payment gateway based on
the monitoring.
19. (canceled)
20. The non-transitory computer-readable medium of claim 15, the
operations further comprising: declining authorization of the
second payment transaction based on the comparison indicating that
at least one of the one or more second transaction parameters does
not match with the one or more first transaction parameters.
21. The system of claim 4, wherein the one or more processors are
further configured to execute instructions to prompt the user to
input the unique token at the merchant payment gateway to initiate
the second transaction.
22. The method of claim 11, wherein the method further comprises
prompting the user to input the unique token at the merchant
payment gateway to initiate the second transaction.
23. The non-transitory computer-readable medium of claim 18,
wherein the operations further comprise prompting the user to input
the unique token at the merchant payment gateway to initiate the
second transaction.
Description
TECHNICAL FIELD
[0001] Embodiments of the present disclosure relate to systems and
methods for binding unique tokens. More particularly, embodiments
of the present disclosure relate to binding unique tokens with
transaction parameters to authorize transactions.
BACKGROUND
[0002] Users (e.g., online shopping customers) often utilize
e-commerce websites (e.g. www.amazon.com, www.walmart.com or
www.ebay.com) to purchase various items. By way of example, a user
may purchase items and/or products by providing their payment
information (e.g., credit card information, debit card information,
bank account information, etc.) to process a transaction. As part
of authorization of the transaction, the payment information is
transmitted via one or more servers over a network. However, during
the process of transmitting and authorizing the transaction, the
payment information may be exposed to multiple devices that may
compromise the payment information, potentially leading to
fraudulent activities. In such cases, the entire process of online
purchasing is inefficient as the process does not provide security
for the user's payment information and may result in the need for
the user to replace their old payment information with new payment
information. The user may prefer making purchases, without worrying
or stressing about their payment information being compromised,
thus resulting in a safe, secure, and seamless shopping
experience.
SUMMARY
[0003] In accordance with embodiments of the present disclosure,
there is provided a system for binding unique tokens with merchant
identifiers to authorize transactions, the system comprising: one
or more memory devices storing instructions; and one or more
processors configured to execute the instructions to: monitor user
interactions with one or more applications on a user device.
Determine a first payment transaction initiation by a user at a
merchant payment gateway associated with the one or more
applications based on the monitoring. Generate and display on the
user device a unique token based at least on an input received from
the user device. Receive the unique token as part of an
authorization request to authorize the first payment transaction.
Identify one or more first transaction parameters associated with
the first payment transaction, upon successfully authorizing the
first payment transaction in response to the authorization request.
Automatically bind and store the generated unique token with the
identified one or more first transaction parameters.
[0004] In accordance with embodiments of the present disclosure,
there is also provided a computer implemented method for binding
unique tokens with merchant identifiers to authorize transactions,
the method comprising: monitoring user interactions with one or
more applications on a user device. Determining a first payment
transaction initiation by a user at a merchant payment gateway
associated with the one or more applications based on the
monitoring. Generating and displaying on the user device a unique
token based at least on an input received from the user device.
Receiving the unique token as part of an authorization request to
authorize the first payment transaction. Identifying one or more
first transaction parameters associated with the first payment
transaction, upon successfully authorizing the first payment
transaction in response to the authorization request. Automatically
binding and storing the generated unique token with the identified
one or more first transaction parameters.
[0005] In accordance with embodiments of the present disclosure,
there is further provided a non-transitory computer-readable medium
storing instructions executable by one or more processors to
perform operations for binding unique tokens with merchant
identifiers to authorize transactions, the operations comprising:
monitoring user interactions with one or more applications on a
user device. Determining a first payment transaction initiation by
a user at a merchant payment gateway associated with the one or
more applications based of the monitoring. Generating and
displaying on the user device a unique token based at least on an
input received from the user device. Receiving the unique token as
part of an authorization request to authorize the first payment
transaction. Identifying one or more first transaction parameters
associated with the first payment transaction, upon successfully
authorizing the first payment transaction in response to the
authorization request. Automatically binding and storing the
generated unique token with the identified one or more first
transaction parameters.
BRIEF DESCRIPTION OF DRAWINGS
[0006] The accompanying drawings, which are incorporated in and
constitute a part of his specification, illustrate disclosed
embodiments and, together with the description, serve to explain
the disclosed embodiments. In the drawings:
[0007] FIG. 1 is a block diagram of an exemplary system, consistent
with disclosed embodiments;
[0008] FIG. 2 is a block diagram of an exemplary user device,
consistent with disclosed embodiments;
[0009] FIG. 3 is a block diagram of an exemplary server system,
consistent with disclosed embodiments; and
[0010] FIGS. 4A-4E contain a flowchart of an exemplary process of
binding unique tokens with merchant identifiers to authorize
transactions, consistent with disclosed embodiments.
DETAILED DESCRIPTION
[0011] Reference will now be made in detail to the disclosed
embodiments, examples of which are illustrated in the accompanying
drawings. Wherever convenient, the same reference numbers will be
used throughout the drawings to refer to the same or like
parts.
[0012] The following description is directed to binding of unique
tokens with merchant identifiers to authorize online transactions,
and is made by example only. It should be appreciated that the
present disclosure is not limited to the specific disclosed
embodiments and details, which are exemplary only. It is further
understood that one possessing ordinary skill in the art, would
appreciate the use of the embodiments of the present disclosure for
their intended purposes and benefits in any number of alternative
embodiments, depending on specific design and other needs. The
systems and methods discussed herein may be just as applicable in
other environments that may benefit from the ability to bind unique
tokens to online merchants and/or authorize payment transactions
conducted at the online merchant.
[0013] FIG. 1 is a block diagram of an exemplary system 100 for
performing one or more operations consistent with disclosed
embodiments. In some embodiments, system 100 includes one or more
user devices 102(1), 102(2), . . . , 102(n), one or more service
provider systems 104, one or more databases 106, and a network 108.
The components and arrangement of the components included in system
100 may vary. Thus, system 100 may include other components that
perform or assist in the performance of one or more operations
consistent with the disclosed embodiments.
[0014] As more fully described below, components of system 100 may
include one or more computing devices (e.g., computer(s),
server(s), etc.), memory storing data and/or software instructions
(e.g., database(s), memory devices, etc.), and other known
computing components. In some embodiments, the one or more
computing devices may be configured to execute software
instructions stored in the memory to perform one or more operations
consistent with the disclosed embodiments. Aspects of service
provider system(s) 104, database(s) 106, and user devices
102(1)-102(n) may be configured to communicate with one or more
other components of system 100 via network 108, for example. In
certain aspects, customers 114(1)-114(n) are respectively
associated with and operate user devices 102(1)-102(n), to interact
with one or more components of system 100 by sending and receiving
communications, initiating operations, and/or providing input for
one or more operations consistent with the disclosed embodiments.
By way of example, customer 114(1) may be a first customer and
customer 114(2) may be a second customer. Customers 114(1)-114(n)
may each have a financial banking account with service provider
system 104.
[0015] Service provider system 104 may be configured to access one
or more payment parameters and one or more transaction parameters
associated with user device 102(1). The one or more payment
parameters and one or more transaction parameters may be stored in
database 106 by service provider system 104 upon successful
authorization of a payment transaction associated with user device
102(1) at a merchant website of a merchant. The one or more payment
parameters may include user personal identification information or
user financial account information. The user personal
identification information includes at least one of name, address,
date of birth, phone number, or zip code. The user financial
account information includes at least one of bank name, bank
address, or billing address. The one or more transaction parameters
include at least one of a merchant category code associated with
the merchant, a name of the merchant, a masked name of the
merchant, a merchant identifier number of the merchant, or at least
one of the one or more payment parameters.
[0016] Database 106 of system 100 may be communicatively coupled to
service provider system 104 and user devices 102(1)-102(n) via
network 108. Database 106 may include one or more memory devices
that store information and are accessed and/or managed by one or
more components of system 100. By way of example, database 110 may
include Oracle.TM. databases, Sybase.TM. databases, or other
relational databases or nonrelational databases, such as Hadoop
sequence files, HBase, or Cassandra. Database 106 may include
computing components (e.g., database management system, database
server, etc.) configured to receive and process requests for data
stored in memory devices of database 106 and to provide data from
database 106.
[0017] Database 106 is configured to store one or more payment
parameters and one or more transaction parameters as, for example,
described above. The one or more payment parameters may include
user personal identification information or user financial account
information as, for example, described above.
[0018] Service provider system 104 may be associated with a
financial service entity that provides, maintains, manages, or
otherwise offers financial services. For example, the financial
service entity may be a bank, credit card issuer, or any other type
of financial service entity that generates, provides, manages,
and/or maintains financial service accounts for one or more users.
Financial service accounts may include, for example, credit card
accounts, loan accounts, checking accounts, savings accounts,
reward or loyalty program accounts, and/or any other type of
financial service account known to those skilled in the art. In
providing, maintaining, managing or otherwise offering financial
services, service provider system 104 may be enabled to
authenticate financial transactions associated with financial
service accounts of customers 114(1)-114(n).
[0019] In one aspect, service provider system 104 may include one
or more computing devices, configured to perform one or more
operations consistent with disclosed embodiments, as described more
fully below in relation to FIG. 3. In one aspect, service provider
system 104 may include one or more servers or server systems.
Service provider system 104 may include one or more processors
configured to execute software instructions stored in a memory or
other storage device. The one or more processors may be configured
to execute the stored software instructions to perform
internet-related communication and financial service-based
processes and provide binding of unique tokens with merchant
identifiers to authorize transactions. The one or more computing
devices of service provider system 104 may also be configured to
communicate with other components of system 100 to predict
geolocations of customers 114(1)-114(n). In some embodiments,
service provider system 104 may provide one or more mobile banking
applications, web-sites, browser extensions, or online portals that
are accessible by user devices 102(1)-102(n) over network 108. The
disclosed embodiments are not limited to any particular
configuration of service provider system 104.
[0020] Service provider system 104 and user devices 102(1)-102(n)
may be configured to communicate with each other over network 108.
Network 108 may comprise any type of computer networking
arrangement configured to provide communications or exchange data,
or both, between components of system 100. For example, network 108
may include any type of network (including infrastructure) that
provides communications, exchanges information, and/or facilitates
the exchange of information, such as the Internet, a private data
network, a virtual private network using a public network, a LAN or
WAN network, a Wi-Fi.TM. network, and/or other suitable connections
that may enable information exchange among various components of
system 100. Network 108 may also include a public switched
telephone network ("PSTN") and/or a wireless cellular network.
Network 108 may be a secured network or unsecured network. In some
embodiments, one or more components of system 100 may communicate
directly through a dedicated communication link(s).
[0021] User devices 102(1)-102(n) may be one or more computing
devices configured to perform one or more operations consistent
with the disclosed embodiments, as described more fully below in
relation to FIG. 2. User devices 102(1)-102(n) may execute browser
or related mobile display software that displays customer account
profiles and interfaces for financial transactions, on a display
included in, or connected to, user devices 102(1)-102(n). User
devices 102(1)-102(n) may also store and execute other mobile
applications that allow customers 114(1)-114(n) to select a method
by which customers 114(1)-114(n) wish to receive notifications from
service provider system 104.
[0022] It is to be understood that the configuration of the
functional blocks of system 100 has been defined herein for
convenience of description. The components and arrangement of the
components included in system 100 may vary. For example, in some
embodiments, system 100 may include other components that perform
or assist in the performance of one or more processes consistent
with disclosed methods. System 100 includes a number of components
generally described as computing devices. Each of the computing
devices may include any number of computing components particularly
configured as a special purpose computing device to perform the
functionality disclosed herein. Alternatives (including
equivalents, extensions, variations, deviations, etc., of those
described herein) will be apparent to persons skilled in the
relevant art(s) based on the teachings contained herein. Such
alternatives fall within the scope and spirit of the disclosed
embodiments.
[0023] FIG. 2 shows an exemplary configuration of user device
102(1), consistent with disclosed embodiments. User devices
102(2)-102(n) may be similarly configured. User device 102(1)
enables associated customer 114(1) to perform remote interactions
or mobile transactions with service provider system 104, for
example, or receive information from service provider system 104.
In some embodiments, user device 102(1) may be a personal computing
device. For example, user device 102(1) may be a smartphone, a
laptop or notebook computer, a tablet, a multifunctional watch, a
pair of multifunctional glasses, or any mobile or wearable device
with computing ability, or any combination of these computers
and/or affiliated components.
[0024] User device 102(1) includes one or more processors 202
configured to execute software instructions stored in memory, such
as a memory 204. Memory 204 may store one or more software programs
206 that when executed by processor 202 perform known
Internet-related communication, content display processes, and
other interactive processes for customer 114(1). For instance, user
device 102(1) may execute a browser or related mobile display
software that generates and displays interfaces including content
on a display device 208 included in, or in communication with, user
device 102(1). User device 102(1) may be a mobile device that
executes mobile device applications and/or mobile device
communication software, included in programs 206, that allows user
device 102(1) to communicate with service provider system 104 and
other components via network 108, to generate and display content
in interfaces via display device 208. The disclosed embodiments are
not limited to any particular configuration of user device 102(1).
User device 102(1) may include any arrangement of one or more
computing devices configured to perform one or more operations
consistent with disclosed embodiments.
[0025] User device 102(1) may be configured to store, in memory
204, one or more operating systems that perform known operating
system functions when executed by processor 202. By way of example,
the operating systems may include Microsoft Windows.TM., Unix.TM.
Linux.TM. Android.TM., Apple.TM. Mac OS operating systems, iOS,
Chrome OS, or other types of operating systems. Accordingly,
disclosed embodiments may operate and function with computer
systems running any type of operating system. User device 102(1)
may also include communication software stored in memory 204 that,
when executed by processor 202, provides communications with
network 108, such as Web browser software, tablet or smart handheld
device networking software, etc.
[0026] Display device 208 may include, for example, a liquid
crystal display (LCD), a light emitting diode screen (LED), an
organic light emitting diode screen (OLED), a touch screen, and
other known display devices. Display device 208 may display various
information to customer 114(1). For example, display device 208 may
display an interactive interface to customer 114(1) enabling
customer 114(1) to operate user devices 102(1) to perform certain
aspects of the disclosed methods. Display device 208 may display
touchable or selectable options for customer 114(1) to select and
may receive customer selection of options through a touch
screen.
[0027] User device 102(1) includes I/O devices 212 that allow user
device 102(1) to send and receive information or interact with
customer 114(1) or another device. For example, I/O devices 212 may
include various input/output devices, such as a keyboard, a
mouse-type device, a gesture sensor, an action sensor, a physical
button, switch, microphone, touchscreen panel, stylus, etc., that
may be manipulated by customer 114(1) to input information using
user devices 102(1). I/O devices 212 may also include an audio
output device, such as a speaker configured to provide sound and
audio feedback to customer 114(1) operating user device 102(1). In
some embodiments, I/O devices 212 may include a light emitting
component, such as an LED or other component capable of providing a
visible signal to customer 114(1). I/O devices 212 may also include
haptic output devices, to provide haptic feedback to customer
114(1). I/O devices 212 may also include one or more communication
modules (not shown) for sending and receiving information from
other components in system 100 by, for example, establishing wired
or wireless connectivity between user device 102(1) and network
108. I/O devices 212 may include radio frequency, infrared, or
other near-field communication interfaces, for communicating with
other devices associated with network 108 or customer 114(1).
Exemplary communication modules of I/O devices 212 may include, for
example, a short-range or near field wireless communication modem,
a Wi-Fi.TM. communication modem, or a cellular communication modem.
I/O devices 212 may include a transceiver or transmitter configured
to communicate using one or more wireless technologies/protocols
that may include, without limitation, cellular (e.g., 3G, 4G, etc.)
technology, Wi-Fi.TM. hotspot technology, RFID, near-field
communication (NFC) or BLUETOOTH.RTM. technologies, etc. More
generally, any uni- or bi-directional communication technology
known to one of ordinary skill in the art may be implemented in
user device 102(1) to exchange information with service provider
system 104 or database 106 via network 108.
[0028] As described above, user device 102(1) may be a device that
executes mobile applications for performing operations consistent
with disclosed embodiments. Thus, in some embodiments, programs 206
stored on user devices 102(1) may include one or more software
applications 214 installed thereon, that enable user device 102(1)
to communicate with service provider system 104 via network 108 and
perform aspects of the disclosed methods. For example, user device
102(1) may connect to service provider system 104 by using browser
software to access and receive information or perform other
operations associated with an internet service provider.
[0029] According to an exemplary embodiment, software applications
214 associated with service provider system 104 may be installed on
user device 102(1), as shown in FIG. 2. For example, service
provider system 104 may receive a request from user device 102(1)
to download one or more software applications 214 to user device
102(1). In one embodiment, service provider system 104 may receive
the request from customer 114(1), using a web browser application
installed on user device 102(1). In another embodiment, service
provider system 104 may receive the request to download one or more
software applications 214 associated with service provider system
104 onto user device 102(1) from a webpage or another portal
associated with service provider system 104 accessed by customer
114(1) via, e.g., user device 102(1). In this embodiment, service
provider system 104 may store software instructions corresponding
to one or more software applications 214 in database 106. For
responding to the download request, service provider system 104 may
receive additional information from user device 102(1) regarding
the particular device specifications of user device 102(1) to
enable user device 102(1) to download software instructions
corresponding to the particular specifications. Alternatively,
service provider system 104 may push a download request link to
user device 102(1) or transmit software code corresponding to one
or more software applications 214 directly to user device 102(1)
in, for example, an e-mail, a text or short message service (SMS)
message, a prompt through an app, or other suitable method. User
device 102(1) may receive the software code related to one or more
software applications 214, such as via network 108, to download and
install the software code.
[0030] FIG. 3 shows an exemplary server 300 consistent with the
disclosed embodiments. Variations of exemplary server 300 may
constitute one or more components of service provider system 104.
In one embodiment, server 300 includes one or more processors 302,
one or more input/output (I/O) devices 304, and one or more
memories 306. In some embodiments, server 300 may be a part of
service provider system 104. In some embodiments, server 300 may
take the form of a specially programmed server or computing system
used by service provider system 104. In some embodiments, server
300 may be configured as an apparatus, embedded system, dedicated
circuit, or the like based on the storage, execution, and/or
implementation of software instructions that perform one or more
operations consistent with the disclosed embodiments.
[0031] Processor(s) 302 may include one or more known processing
devices, such as a microprocessor from the Pentium.TM. or Xeon.TM.
family manufactured by Intel.TM., or the Turion.TM. family
manufactured by AMD.TM. for example. The disclosed embodiments are
not limited to any type of processor(s) otherwise configured to
meet the computing demands required of different components of
system 100.
[0032] Input/output (I/O) devices 304 may include various
input/output devices, such as a keyboard, a mouse-type device, a
gesture sensor, an action sensor, a physical button, switch,
microphone, touchscreen panel, stylus, etc. I/O devices 304 may
also include an audio output device. Exemplary communication
modules of I/O devices 304 may include, for example, a short-range
or near field wireless communication modem, a Wi-Fi.TM.
communication modem, or a cellular communication modem. I/O devices
304 may include a transceiver or transmitter configured to
communicate using one or more wireless technologies/protocols that
may include, without limitation, cellular (e.g., 3G, 4G, etc.)
technology, Wi-Fi.TM. hotspot technology, RFID, near-field
communication (NFC) or BLUETOOTH.RTM. technologies, etc. More
generally, any uni- or bi-directional communication technology
known to one of ordinary skill in the art may be implemented in
server 300 to exchange information with user devices 102(1)-102(n)
or database 106 via network 108.
[0033] Memory 306 may include one or more storage devices
configured to store instructions used by processor 302 to perform
functions related to disclosed embodiments. For example, memory 306
may be configured with one or more software instructions, such as
program(s) 308 that may perform one or more operations when
executed by processor(s) 302. The disclosed embodiments are not
limited to separate programs or computers configured to perform
dedicated tasks. For example, memory 306 may include a single
program 308 that performs the functions of server 300, or program
308 may comprise multiple programs. In certain embodiments, memory
306 may store sets of instructions or programs 308 for receiving
and storing a list of form fields of a checkout form associated
with a plurality of websites, monitoring user interactions with the
plurality of websites, predicting geolocations of customers
114(1)-114(n) based on analyzing user parameters associated with
customers 114(1)-114(n). These sets of instructions may be executed
by processor(s) 302 to perform communication and/or processes
consistent with disclosed embodiments.
[0034] FIGS. 4A-4E contain a flowchart of an exemplary process 400
for binding of unique tokens with merchant identifiers to authorize
transactions, consistent with disclosed embodiments. In certain
aspects, service provider system 104 utilizes server 300 to execute
software instructions that perform one or more of the operations of
process 400. Also, server 300 may perform all of the functions of
service provider system 104.
[0035] Service provider system 104 in step 401 of FIG. 4A monitors
user interactions with one or more of software applications
installed on user device 102(1). The user interactions may include
any interaction of customer 114(1) with the one or more software
applications installed on user device 102(1). The one or more
software applications may include web browser applications and/or
e-commerce merchant applications, although any other user
interactions with a software application may also be included. The
e-commerce merchant applications are from e-commerce merchants. The
e-commerce merchants may include, e.g., www.amazon.com,
www.walmart.com, or www.ebay.com, although any other e-commerce
merchants may also be included. The user interactions may include
any user interaction with a website displayed via a web browser
application.
[0036] The user interactions may further include a request to
generate a token at a mobile application using a mobile device. The
mobile application may include a user interface that includes
options to generate a token for a plurality of websites, which
include e-commerce websites. By way of example, the mobile
application may include a button, which upon selection from the
user generates a token. The user may then proceed to utilize the
token at a merchant of their choice. Upon successful payment
authorization at the merchant, the token is bound to that merchant.
In another example, the mobile application may include a list of
merchant names for which the user would like to generate a token.
Upon selecting a merchant name from the lists of merchant names,
the token is generated for that merchant. The user may then proceed
to utilize the token to complete a purchase at the selected
merchant. Upon successful payment authorization at the merchant,
the token is bound to that merchant.
[0037] The user interactions may be monitored by web extensions
installed on a website, web browser, or a user device 102(1)
utilized by customer 114(1). The web extensions may monitor a user
interaction with a website, including detecting one or more payment
fields associated with the website, or where the user interaction
may include customer 114(1) entering payment information on a
website. Customer 114(1) may enter payment information for various
purposes, e.g., making a charitable donation and/or making a
purchase. In another example, the user interactions may also
include, entering a credit card number in a credit card field of a
browser interface, receiving a form filled by the customer 114(1)
manually via a mobile application, a website, or any payment
mechanism and generating a token based on the received form. The
received form may include customer 114(1) personal information
and/or user payment information. The customer 114(1) personal
information may include customers address, name, age and/or marital
status, although any other user information associated with the
customer 114(1) may also be included. The user payment information
may include credit card number, debit card number and/or bank
account number, although any other user payment information may
also be included. The token may be a virtual number unique to a
specific website that is utilized by customer 114(1) in place of a
credit card number, as explained in detail below.
[0038] Service provider system 104 in step 402 determines if
customer 114(1) associated with user device 102(1) is accessing a
payment gateway, based on monitoring customer 114(1) interactions
with e-commerce websites. Service provider system 104 identifies
that customer 114(1) is accessing a payment gateway when service
provider system 104 detects a payment input field on a website,
determines that customer 114(1) performs interactions such as
clicking on a checkout button of the e-commerce website, customer
114(1) enters a credit card number on a website (websites may
include any website where a payment is processed, e.g., charity
website, e-commerce websites, etc.), accesses a checkout webpage
displayed on a web browser software application installed on user
device 102(1), web browses an e-commerce website via a web browser,
adds items in an online shopping cart of the e-commerce website,
opens a mobile application installed on user device 102(1), or
clicks on an item in the e-commerce website, although any other
user interaction with a software application may also be included.
When service provider system 104 determines that customer 114(1)
associated with user device 102(1) is not at a payment gateway of
the e-commerce website, then process 400 takes the No branch of
step 402 to loop back to step 401. When service provider system 104
determines that customer 114(1) associated with user device 102(1)
is at a payment gateway of the e-commerce website, process 400
takes the Yes branch of step 402 to step 404.
[0039] Service provider system 104 in step 404 displays a prompt on
the e-commerce website asking if customer 114(1) would like to
generate a unique token that can be utilized as part of the payment
transaction process. The token is a unique sequence of numbers that
is utilized by a customer, e.g., customer 114(1), in place of a
credit card number. This unique sequence of numbers is also
referred to as a virtual number. The token may provide advantages
of protecting credit card numbers from being compromised and thus
may provide the advantage of avoiding replacements of physical
credit cards. By utilizing virtual numbers in place of credit card
numbers, credit card numbers will not be compromised. Further, the
token also may provide advantages to the customer of obviating the
need to input or enter their credit card number each time while
making a payment transaction. By not entering their credit card
number each time, the chance of fraudulent activities associated
with processing of credit card numbers to authorize a purchase
transaction is reduced. The creation of tokens is explained in
detail below.
[0040] The prompt displayed on the e-commerce website in step 404
may display a message such as "Would you like to generate a new
token?", with two options of "Yes" or "No" to select from. When
customer 114(1) selects the "No" option, service provider system
104 determines that customer 114(1) would not like to generate a
new token and process 400 takes the No branch of step 404 to step
406. When customer 114(1) selects the "Yes" option, service
provider system 104 determines that customer 114(1) would like to
perform a payment transaction with a new token, referred to herein
as a first payment transaction for convenience of explanation, at
the e-commerce website and would like to generate a new token.
Process 400 takes the Yes branch of step 404 to step 418.
[0041] Service provider system 104 in step 418 compares a webpage
identifier associated with the e-commerce website, where customer
114(1) is performing the first payment transaction, to a list of
trusted merchant webpage identifiers previously stored in database
106. The list of trusted merchant webpage identifiers includes a
list of uniform resource locators (URLs) associated with e-commerce
websites that may be predefined by a system administrator and
stored on database 106. The e-commerce websites associated with the
list of trusted merchant webpage identifiers may be determined by
the system administrator to be those websites that are popular and
most frequently used in the e-commerce market environment. By way
of example, the list of known or trusted merchant webpage
identifiers may include www.amazon.com, www.walmart.com,
www.macys.com, www.kohls.com, www.target.com, www.verizon.com, or
www.ebay.com, although any other website may also be included. In
this example, the webpage identifier associated with the e-commerce
website, where customer 114(1) is performing the first payment
transaction, is www.xyz.com. Based on the comparison, service
provider system 104 determines that the www.xyz.com webpage
identifier associated with the e-commerce website, where customer
114(1) is performing the first payment transaction, does not match
any entry in the list of the known or trusted merchant webpage
identifiers stored in database 106.
[0042] In another example, a user may utilize a mobile application
that may include a button, which upon selection generates a token.
The generated token in this example is independent of a webpage
identifier or a merchant. Further, service provider system 104
generates a token that is a unique number, such that each customer
will be provided with a token that is unique to the customer and is
different than any other tokens. The user may then proceed to
utilize the token at a merchant webpage of their choice. The token
may be a 16-digit number that the user may input in a credit card
number field on a payment interface. By entering the unique token
in place of the credit card number, this technology provides
advantages of protecting credit card numbers from being
compromised. Since credit card numbers are not compromised, this
technology provides the advantage of avoiding the need to replace
of physical credit cards. Upon successful payment authorization at
the merchant, the merchant website identifier is bound to the
token.
[0043] Service provider system 104 in step 420 determines if the
webpage identifier associated with the e-commerce website, where
customer 114(1) is performing the first payment transaction is a
known or trusted merchant webpage identifier. Based on the
comparison performed in step 418, service provider system 104
determines that the www.xyz.com webpage identifier associated with
the e-commerce website, does not match the list of known or trusted
merchant webpage identifiers stored in the database 106. Therefore,
service provider system 104 determines that the www.xyz.com webpage
identifier is not a known or trusted merchant webpage identifier.
Upon determining that the www.xyz.com webpage identifier is not a
known trusted merchant webpage identifier, service provider system
104 takes the No branch of step 420 and proceeds to step 422 of
FIG. 4B.
[0044] In step 422, service provider system 104 generates a first
token which in this example is independent of a merchant webpage
identifier or payment information. Service provider system 104
determines that customer 114(1) is logged into their bank account
and associates the generated first token with the bank account of
customer 114(1). Customer 114(1) may then proceed to utilize the
first token at a merchant webpage of their choice for payment
processing, merchant webpage having a merchant identifier. The
first token may be a 16-digit unique number that customer 114(1)
may input in a credit card number field on a payment interface and
utilize for payment authorization. Upon successful payment
authorization of payment at the merchant, the merchant website
identifier is bound to the first token.
[0045] In another example, service provider system 104 may generate
a first token based on user payment information detected in step
401. User payment information may include a credit card number or
account identifier, a debit card number or account identifier,
and/or a bank account number or account identifier. Service
provider system 104, utilizes the user payment information to
generate a first token. Service provider system 104 bounds the
generated first token with the credit card number or account
identifier, debit card number or account identifier, and/or bank
account number or account identifier and stores it in memory
306.
[0046] In another embodiment, service provider system 104 in step
422 utilizes the merchant information (e.g. merchant webpage
identifier associated with the e-commerce website) to generate a
first token that is associated with the e-commerce website of
www.xyz.com, where customer 114(1) is performing the first payment
transaction. Service provider system 104 may receive user payment
information from customer 114(1) as part of the first payment
transaction. The user payment information may be received as an
input from customer 114(1) via the e-commerce website. As described
above, the user payment information may include a credit card
number or account identifier, a debit card number or account
identifier, a bank account number or account identifier, or any
other financial account number or identifier that may be utilized
to provide payment for the first payment transaction in association
with a new unique token. Service provider system 104 bounds and
stores in database 106, the webpage identifier associated with the
e-commerce website, where customer 114(1) is performing the first
payment transaction, and the payment information received from
customer 114(1). Service provider system 104 generates a unique
virtual number that may be utilized by the customer 114(1) to
perform the first payment transaction. The generated virtual number
may be a sequence of numbers determined by service provider system
104 to be unique. The virtual number is also referred to as a first
token. In this example, the first token is "56781", although any
other number may also be generated. The first token is then
included in a list of authorized tokens stored in database 106. The
first token is then displayed on the e-commerce website for
customer 114(1) to view. Customer 114(1) may then utilize the first
token for any future transactions in place of providing their
physical account number, physical credit card number or physical
debit card number.
[0047] By way of example, the first token may be unique to a
specific e-commerce website where customer 114(1) would perform a
first payment transaction. By way of another example, the first
token is not unique to an e-commerce website where customer 114(1)
is performing the first payment transaction. In this scenario, the
first token initially may be utilized by customer 114(1) at any
website.
[0048] Service provider system 104 in step 424 receives the
generated first token along with payment information from customer
114(1) via the interface displayed on the e-commerce website as
part of a transaction authorization request for the first payment
transaction. The payment information may include merchant account
information associated with the e-commerce website (e.g., merchant
account number associated with a bank, etc.), phone number
associated with the e-commerce website, location information
associated with the e-commerce website (state, address, etc.),
although any other transaction parameter associated with a
transaction may also be included. The transaction authorization
request may be generated upon receiving an input from customer
114(1) to process payment information. In step 422 the first token
may also be stored on the web browser (e.g., using a browser plugin
or extension) of user device 102(1) and in step 424 the first token
may be automatically entered into an input box displayed on the
e-commerce website by service provider system 104, upon the web
browser extension receiving the first token from service provider
system 104. In another example, the first token displayed in step
422 is inputted by customer 114(1) in an input box displayed on the
e-commerce website in step 424.
[0049] Service provider system 104 in step 426 compares the
received payment information received with the first token with the
payment information and/or merchant information (e.g. webpage
identifier associated with the e-commerce website) bound to the
received first token to determine if the payment transaction is
authorized. More particularly, service provider system 104 compares
the received payment information with a payment information
associated with the account that is bound to the received token
that is previously stored in a database. When service provider
system 104 determines that the payment information associated with
the account that is bound to the received token matches with the
received payment information, then service provider system 104
determines that the first payment transaction is authorized.
[0050] When service provider system 104 determines that the payment
information bound with the account that corresponds to the received
token does not match with the received payment information, then
service provider system 104 determines that the first payment
transaction is not authorized.
[0051] Service provider system 104 in step 428 determines if the
first payment transaction has been authorized. When service
provider system 104 determines that the first payment transaction
is not authorized, then process 400 takes the No branch of step 428
to step 430. In step 430, service provider system 104 declines the
first payment transaction and process 400 ends.
[0052] When service provider system 104 determines that the first
payment transaction is authorized, then the process 400 takes the
Yes branch to step 432.
[0053] Service provider system 104 in step 432, identifies first
transaction parameters associated with the authorized first payment
transaction. The first transaction parameters may include one or
more merchant identifying information, such as a merchant category
code associated with the e-commerce website for the first payment
transaction, a merchant name, a name of the e-commerce website for
the first payment transaction, a masked name of the e-commerce
website for the first payment transaction, a webpage identifier of
the e-commerce website for the first payment transaction, merchant
account information associated with the e-commerce website (e.g.,
merchant account number associated with a bank, etc), phone number
associated with the e-commerce website, location information
associated with the e-commerce website (state, address, etc),
although any other transaction parameter associated with a
transaction may also be included. In this example, the merchant
category code associated with the e-commerce website for the first
payment transaction is "99771", the name of the e-commerce website
for the first payment transaction is "xyz.com, Inc.", the webpage
identifier of the e-commerce website for the first payment
transaction is "www.xyz.com".
[0054] Service provider system 104 in step 434, stores the
identified first transaction parameters in step 432 in database
106.
[0055] Service provider system 104 in step 436, associates the
first transaction parameters with the first token stored in
database 106. Further, the identified first transaction parameters
are associated with the payment information and the webpage
identifier corresponding to the first token stored in the database
106. This association of the first token with the first transaction
parameters is also referred to herein as binding the first token
with the first transaction parameters. Upon binding the first token
with the first transaction parameters, the first token is unique to
the e-commerce website and is referred to herein as a first unique
token.
[0056] Service provider system 104 then returns to step 401.
Service provider system 104 performs steps 401-406. In step 402,
the service provider system 104 determines customer 114(1) has
accessed the payment gateway to perform a second payment
transaction different from the above described first payment
transaction.
[0057] Upon reaching step 406, the service provider system 104
displays a prompt on the e-commerce website asking if customer
114(1) has previously generated a unique token for the e-commerce
website. In this example, the first token is considered a
previously generated unique token that the user would like to
utilize to purchase an item as part of the second payment
transaction. The prompt displayed on the website may display a
message such as "Would you like to utilize a previously generated
token?", with two option of "Yes" or "No" to select from. When
customer 114(1) selects the "No" option, service provider system
104 determines that the customer 114(1) would not like to utilize a
token and process 400 takes the No branch of step 406 to step 410.
When customer 114(1) selects the "Yes" option, service provider
system 104 determines that customer 114(1) would like to utilize a
previously generated unique token and process 400 takes the Yes
branch of step 406 to step 408.
[0058] In another embodiment, in step 406 service provider system
104 automatically populates a user payment information field with a
previously created token for a second payment transaction. Service
provider system 104 determines that customer 114(1) is logged into
their account and identifies a previously created and stored token
associated with the website that the customer 114(1) is at for the
second payment transaction.
[0059] Service provider system 104 in step 440 identifies second
transaction parameters associated with the second payment
transaction in response to the second payment authorization request
generated in step 408. In response to receiving the second payment
authorization request with the first input token, service provider
system 104 retrieves second transaction parameters from the second
payment transaction. The second transaction parameters may include
a merchant category code associated with the e-commerce website
associated with the second payment transaction, a name of the
e-commerce website associated with the second payment transaction,
a masked name of the e-commerce website associated with the second
payment transaction, and/or a webpage identifier of the e-commerce
website associated with the second payment transaction.
[0060] Service provider system 104 in step 442 determines if the
received first input token matches one of a list of tokens
previously stored in database 106. Service provider system 104
compares the first input token with the list of authorized tokens
stored in database 106. Service provider system 104 determines if
the first input token matches to a token from the list of
authorized tokens. When service provider system 104 determines that
the first input token does not match any of the tokens included in
the list of authorized tokens, then service provider system 104
determines that the second payment transaction is not authorized
and the method takes the No branch of step 442 to step 444. In step
444, service provider system 104 determines that the second payment
transaction has been declined and process 400 ends.
[0061] When service provider system 104 determines that the
received first input token matches a token in the list of
authorized tokens, then service provider system 104 takes the Yes
branch of step 442 to step 446. In this example, service provider
system 104 determines that the received first input token "56781",
matches the first token "56781" stored in the list of authorized
tokens.
[0062] Service provider system 104 in step 446 identifies the
transaction parameters that are bound with the first token that
matches to the first input token, based on the determination made
in step 444 that the received first input token matches to the
first token. In this example, service provider system 104
identifies that the transaction parameters that are bound with the
first token are the first transaction parameters.
[0063] Service provider system 104 in step 448, determines if the
received second transaction parameters associated with the first
input token match at least one of the identified first transaction
parameters associated with the first token.
[0064] In this example, the merchant category code associated with
the e-commerce website for the second payment transaction is
"99771", the name of the e-commerce website for the second payment
transaction is "xyz.com, Inc.", and the webpage identifier of the
e-commerce website for the second payment transaction is
""www.xyz.com". While the merchant category code associated with
the e-commerce website for the first payment transaction is "9971",
the name of the e-commerce website for the first payment
transaction is "xyz.com, Inc.", and the webpage identifier of the
e-commerce website for the first payment transaction is
www.xyz.com. As a result, all of the second transaction parameters
match with the first transaction parameters, so the method takes
the Yes branch of step 448 to step 452. In another example, if any
one of the second transaction parameters matches the first
transaction parameters, then the method takes the Yes branch of
step 448 to step 452. By way of example, when any one of the
merchant category code, the name of the e-commerce website, or the
webpage identifier matches the corresponding first transaction
parameters, then the method takes the Yes branch of step 448 to
step 452. In yet another example, only if a merchant category code
of the second transaction parameters matches the corresponding the
merchant category code of the first transaction parameters, then
the method takes the Yes branch of step 448 to step 452. In yet
another example, when any two of the merchant category code, the
name of the e-commerce website, and/or the webpage identifier match
with the corresponding first transaction parameters, then the
method takes the Yes branch of step 448 to step 452. Any
combination and number of second transaction parameters may be
matched with the first transaction parameters.
[0065] Service provider system 104 in step 452 authorizes the
second payment transaction, and process 400 ends.
[0066] Referring back to FIG. 4A, in step 420 service provider
system 104 determines if the webpage identifier associated with the
e-commerce website, where customer 114(1) is performing a third
payment transaction, is a trusted merchant webpage identifier. In
this example, the webpage identifier associated with the e-commerce
website, where customer 114(1) performed the first payment
transaction is www.amazon.com.
[0067] Based on the comparison performed in step 418, service
provider system 104 determines that the www.amazon.com webpage
identifier associated with the e-commerce website does match to the
list of trusted merchant webpage identifiers stored in the database
106, thus the service provider system 104 determines that the
www.amazon.com webpage identifier is a trusted merchant webpage
identifier as part of a third payment transaction. Upon determining
that the www.amazon.com webpage identifier is a trusted merchant
webpage identifier, service provider system 104 takes the Yes
branch at step 420 and proceeds to step 454 of FIG. 4D.
[0068] Service provider system 104 in step 454 generates a second
token that is unique to the e-commerce website of www.amazon.com,
where customer 114(1) is performing the third payment
transaction.
[0069] In step 454, service provider system 104 generates a second
token which in this example is independent of a merchant webpage
identifier or payment information. Service provider system 104
determines that customer 114(1) is logged into their bank account
and associates the generated second token with the bank account of
customer 114(1). The user may then proceed to utilize the second
token at a merchant webpage of their choice for payment processing,
the merchant webpage having a merchant identifier. The second token
may be a 16-digit unique number that the user may input in a credit
card number field on a payment interface and utilized for payment
authorization. Upon successful payment authorization of payment at
the merchant, the merchant website identifier is then bounded to
the second token.
[0070] Service provider system 104 may receive user payment
information from customer 114(1) as part of the third payment
transaction. The user payment information may be received as an
input from customer 114(1) via the e-commerce website. The user
payment information may include credit card number, debit card
number, bank account number, or any other financial account number
that may be utilized to provide payment for the third payment
transaction. Service provider system 104 associates and stores in
database 106, the webpage identifier associated with the e-commerce
website, where customer 114(1) is performing the third payment
transaction and the payment information received from customer
114(1). The generated second token is then associated with the
received payment information and/or merchant information (e.g.
merchant webpage identifier associated with the e-commerce website)
and stored in database 106. Service provider system 104 generates a
virtual number that is associated to the webpage identifier
corresponding with the e-commerce website, where customer 114(1) is
performing the third payment transaction. The generated virtual
number may be a sequence of numbers determined by service provider
system 104, where customer 114(1) is performing the third payment
transaction. The virtual number is also referred to as the second
token, where customer 114(1) is performing the third payment
transaction. The association of the generated second token with the
received payment information and the webpage identifier is also
referred to herein as binding the second token with the payment
information and the webpage identifier. In this example, the second
token is "123459", although any other number may also be
associated. The second token is then included in a list of
authorized tokens stored in database 106. The second token is then
displayed on the e-commerce website for customer 114(1) to view.
The customer 114(1) may then utilize the second token. The second
token provides advantages as that of the first token, of protecting
credit card numbers from being compromised and thus this technology
provides the advantage of avoiding replacements of physical credit
cards. By utilizing tokens in place of credit card numbers
customers, credit card numbers will not be compromised.
[0071] Service provider system 104 in step 456 receives the
generated second token along with payment information from customer
114(1) via the interface displayed on the e-commerce website. The
second token displayed in step 454 is inputted by customer 114(1)
in an input box displayed on the e-commerce website in step
456.
[0072] In another example, in step 454 the second token may be
stored on the web browser of user device 102(1) and in step 456 the
second token may be retrieved from the web browser and
automatically entered into the input box displayed on the
e-commerce website in step 456 by service provider system 104, upon
generating the second token.
[0073] Service provider system 104 in step 458 compares the
received payment information and/or merchant information (e.g.
webpage identifier associated with the e-commerce website) bound to
the second token received in step 456 to determine if the payment
transaction is authorized. Service provider system 104 compares the
received payment information with merchant information associated
with the account that corresponds to the received token that is
previously stored. When service provider system 104 determines that
the merchant information bound with the account that corresponds to
the received token matches with the received payment information,
then service provider system 104 determines that the first payment
transaction is authorized.
[0074] When service provider system 104 determines that the
merchant information associated with the account that corresponds
to the received token does not match with the received payment
information, then service provider system 104 determines that the
first payment transaction is not authorized.
[0075] Service provider system 104 in step 460 determines if the
third payment transaction has been authorized. When service
provider system 104 determines that the third payment transaction
is not authorized, then process 400 takes the No branch of step 460
to step 462. In step 462, service provider system 104 determines
that the third payment transaction has been declined and process
400 ends.
[0076] When service provider system 104 determines that the third
payment transaction is authorized, then process takes the Yes
branch of step 460 to step 464.
[0077] Service provider system 104 in step 464, binds the second
token with the websites and the process loops back to step 400.
Service provider system 104 performs steps 401-404. In step 401,
service provider system 104 determines customer 114(1) to be at a
payment gateway to perform a fourth payment transaction, performs
steps 401-404, and then proceeds to step 466.
[0078] In this method, service provider system 104 stores third
transaction parameters and associates it with the second token,
similar to steps 432 and 434 as explained above. The third
transaction parameters may include merchant category code
associated with the e-commerce website associated with the third
payment transaction, a name of the e-commerce website associated
with the third payment transaction, a masked name of the e-commerce
website associated with the third payment transaction, and/or a
webpage identifier of the e-commerce website associated with the
third payment transaction.
[0079] Upon reaching the step 466, service provider system 104 may
display a prompt on the e-commerce website asking if customer
114(1) has previously generated a unique token at the e-commerce
website. In this example, the second token is the previously
generated unique token, that the user would like to utilize to
purchase an item as part of the fourth payment transaction. The
prompt displayed on the website may display a message such as
"Would you like to utilize a previously generated token?", with two
option of "Yes" or "No" to select from. When customer 114(1)
selects the "Yes" option, service provider system 104 determines
that customer 114(1) would like to utilize the generated unique
token and process 400 takes the Yes branch of step 466 to step
468.
[0080] Service provider system 104 in step 468 receives the second
token as an input for payment information from customer 114(1) as
part of an initiation of the fourth payment transaction. Second
token is received along with payment information which includes
merchant account information associated with the e-commerce website
(e.g. merchant account number associated with a bank, etc), phone
number associated with the e-commerce website, location information
associated with the e-commerce website (state, address, etc),
although any other transaction parameter associated with a
transaction may also be included The received second token is
referred to as a second input token. In this example, the second
input token is "123459", although any other number may also be
associated. As part of the prompt displayed in step 466, service
provider system 104 displays an input box to input the token for
initiating the fourth payment transaction. Service provider system
104 initiates processing of the fourth payment transaction upon
receiving from customer 114(1) the second input token as an input
in the input box. As part of initiating the processing of the
fourth payment transaction, service provider system 104 generates a
fourth payment authorization request based on the second input
token and process 400 proceeds to step 470.
[0081] Service provider system 104 in step 470 determines if the
received second input token matches one of a list of tokens
previously stored in database 106. Service provider system 104
compares the second input token with the list of authorized tokens
stored in database 106. Service provider system 104 determines if
the second input token matches a token from the list of authorized
tokens. When service provider system 104 determines that the second
input token does not match with any of the tokens included in the
list of authorized tokens, then service provider system 104
determines that the fourth payment transaction is not authorized
and the method takes the No branch of step 470 to step 472. In step
472, service provider system 104 determines that the fourth payment
transaction has been declined and process 400 ends.
[0082] When service provider system 104 determines that the
received second input token matches a token in the list of
authorized tokens, then service provider system 104 determines that
the fourth payment transaction is authorized, and process 400 takes
the Yes branch of step 470 to step 474. In this example, service
provider system 104 determines that the received second input token
"123459", matches the second token "123459" stored in the list of
authorized tokens.
[0083] In another example, service provider system 104 may identify
third transaction parameters associated with the determined second
token stored in the list of authorized tokens, and then compare the
received transaction parameters associated with the received second
input token with the third transaction parameters. By way of
example, upon determining that one or more of the received
transaction parameters associated with the received second input
token match with corresponding one or more of the third transaction
parameters, then the transaction authorized. Service provider
system 104 in step 474 authorizes the fourth payment transaction,
and process 400 ends. When, upon determining that one or more of
the received transaction parameters associated with the received
second input token do not match with corresponding one or more of
the third transaction parameter, then the transaction is not
authorized. Service provider system 104 in step 472, and process
ends
[0084] In step 406, when the customer 114(1) selects the "No"
option, service provider system 104 determines that customer 114(1)
would not like to utilize a token and the method takes the No
branch of step 406 to step 410.
[0085] Service provider system 104 in step 410, receives user
payment information from customer 114(1) as part of the fourth
payment transaction. The user payment information may be received
as an input from customer 114(1) via the e-commerce website. In
response to receiving the user payment information, service
provider system 104 generates a fourth payment transaction
authorization request.
[0086] Service provider system 104 in step 412, in response to the
fourth payment transaction authorization request generated in step
410, processes the received payment information to authorize the
payment. When service provider system 104 determines that the
payment information is valid, then the process 400 takes the Yes
branch of step 412 and proceeds to the step 414. In step 414,
service provider system 104 approves the fourth payment transaction
and process 400 ends. When service provider system 104 determines
that the payment information is not valid, then the method takes
the No branch of step 412 and proceeds to step 416. In step 416,
service provider system 104 declines the fourth payment transaction
and process 400 ends.
[0087] The above embodiments disclose benefits of binding unique
tokens with merchant identifiers to authorize transactions. As
described above, customers generate and utilize a unique token to
conduct a payment transaction at an e-commerce website. Further,
the unique token is bound to the e-commerce website and can be
utilized only at the e-commerce website to which it is bound. By
way of example, a unique token generated for the www.amazon.com
website can only be utilized at the www.amazon.com website and
cannot be utilized at any other website. The customers payment
information is associated with the unique token, and thus for any
payment transactions, the customer may need only to provide their
unique token in place of the payment information. By utilizing
unique tokens, customers are provided the advantage of not
providing their payment information (e.g., credit card number,
debit card number, etc.) for payment transaction. Since the
customers do not have to provide their payment information, the
customers need not worry about payment security fraud and/or online
theft while of their payment information is entered online. The
disclosed embodiments provide a solution for problems including,
but not limited to, online payment fraud, financial loss, etc.
[0088] The above embodiments disclose benefits for binding unique
tokens with merchant identifiers to authorize transactions. While
illustrative embodiments have been described herein, the scope
thereof includes any and all embodiments having equivalent
elements, modifications, omissions, combinations (e.g., of aspects
across various embodiments), adaptations and/or alterations as
would be appreciated by those in the art based on the present
disclosure. For example, the number and orientation of components
shown in the exemplary systems may be modified. Thus, the foregoing
description has been presented for purposes of illustration only.
It is not exhaustive and is not limiting to the precise forms or
embodiments disclosed. Modifications and adaptations will be
apparent to those skilled in the art from consideration of the
specification and practice of the disclosed embodiments.
[0089] The elements in the claims are to be interpreted broadly
based on the language employed in the claims and not limited to
examples described in the present specification or during the
prosecution of the application, which examples are to be construed
as non-exclusive. It is intended, therefore, that the specification
and examples be considered as exemplary only, with a true scope and
spirit being indicated by the following claims and their full scope
of equivalents.
* * * * *
References