US20140012704A1

US20140012704A1 - Selecting a preferred payment instrument based on a merchant category

Info

Publication number: US20140012704A1
Application number: US13/542,303
Authority: US
Inventors: Boris Mizhen; Kendra Shannon Curtis
Original assignee: Google LLC
Current assignee: Google LLC
Priority date: 2012-07-05
Filing date: 2012-07-05
Publication date: 2014-01-09
Also published as: AU2013207643B2; WO2014008471A1; US10185954B2; AU2013207643A1; US20160196549A1

Abstract

The invention provides a computer-implemented method to select a preferred card for a purchase based on a merchant category. In the exemplary method, the computer associates a plurality of financial accounts with an account of a user; associates a merchant category with a financial account associated with the user account; and receives data from a transaction. The computer can maintain a database of merchant categories; determine the category of the merchant based on the data associated with the transaction; and extract data to identify the merchant, such as merchant name, address, or telephone number. The computer can determine the geo-location of the user device and determine the merchant identify from the location. The computer can determine a merchant category of the merchant from the merchant identity; select the financial account associated with the merchant category of the merchant; and communicate the financial account selected to conduct the transaction.

Description

TECHNICAL FIELD

The present disclosure relates generally to contactless payment transactions, and more particularly to a method for selecting a preferred payment instrument in a contactless payment transaction based on a category of the merchant.

BACKGROUND

Contactless payments can be transacted by a mobile device of a user with a point of sale terminal of a merchant. The mobile device can communicate with the terminal via near field communication (“NFC”), BLUETOOTH, Wi-Fi, infrared, or any other suitable communication technology. The mobile device can host a payment application, such as a digital wallet, that can complete a transaction with the terminal.
The point of sale terminal can obtain the payment information from the user device and transmit transaction details to the user device. The point of sale terminal can submit the transaction details to the card network to receive payment from the card issuer.
The payment application on a mobile device can support multiple financial accounts and the cards associated with the account. The user can conduct a transaction with different financial instruments, such as credit cards, debit cards, stored value cards, or other payment cards, supported by the application. Currently, the user must select a card at the time of purchase with which to conduct the transaction. That is, at the time of purchase, the user must select a card and apply it to the purchase. Alternatively, the user may assign a card for all transactions until the assignment is changed.
Some cards may be better suited for a particular transaction than other cards. For example, some cards provide better rewards or provide better terms for transactions with certain merchant categories. Remembering which card is the best card for every transaction can create a burden for a user.
A similar process and corresponding deficiencies apply to the use of a payment application for conducting a transaction with an online merchant. The user can attempt a purchase with an online merchant, select a card on the payment application to conduct the transaction, and submit the payment information. The user may have a digital wallet for online purchases that has a card assigned to all purchases.

SUMMARY

The present invention provides a computer-implemented method to select a preferred card for a purchase based on a merchant category. In the exemplary method, the computer associates a plurality of financial accounts with an account of a user, the user account being maintained on the computer; associates a merchant category with a financial account associated with the user account; and receives data from a transaction of the user account with a merchant from a user network device. The computer can maintain a database of merchant categories; determine the category of the merchant based on the data associated with the transaction; and extract data to identify the merchant, such as merchant name, address, or telephone number. The computer can determine the geo-location of the user device and determine the merchant identify from the location. The computer can determine a merchant category of the merchant from the merchant identity; select the financial account associated with the merchant category of the merchant; and communicate the financial account selected to conduct the transaction.
Another aspect of the present invention provides a computer program product that is installed on a server located in a payment system to select a preferred card for a purchase based on a merchant category. The computer program product includes a non-transitory computer-readable storage device having computer-readable program instructions stored therein. The computer-readable program instructions include computer program instructions to associate a plurality of financial accounts with an account of a user, the user account being maintained on the computer; associate a merchant category with a financial account associated with the user account; and receive data from a transaction of the user account with a merchant from a user network device. The instructions can be further configured to maintain a database of merchant categories; determine the category of the merchant based on the data associated with the transaction; and extract data to identify the merchant, such as merchant name, address, or telephone number. The instructions can be further configured to determine the geo-location of the user device and determine the merchant identify from the location. The instructions can be further configured to determine a merchant category of the merchant from the merchant identity; select the financial account associated with the merchant category of the merchant; and communicate the financial account selected to conduct the transaction.
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

FIG. 1 is a block diagram depicting a system for a payment system to select a preferred card for a contactless payment transaction based on the merchant category, in accordance with certain exemplary embodiments.

FIG. 2 is a block flow diagram depicting a method to establish a preferred card rule, in accordance with certain exemplary embodiments.

FIG. 3 is a block flow diagram depicting a method for selecting a preferred card in a contactless payment transaction based on the merchant category, in accordance with certain exemplary embodiments.

FIG. 4 is a block flow diagram depicting a method to analyze transaction details and determine a merchant category, in accordance with certain exemplary embodiments.

DETAILED DESCRIPTION OF THE EXEMPLARY EMBODIMENTS

Overview

A payment system and payment application include 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 a digital wallet on a user device. The different financial accounts used for payment transactions will be collectively referred to as “cards”. The user sets rules specifying which financial account will be accessed when a contactless transaction is attempted. The user can then add, delete, or change the default payment rules associated with the user. 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. In an exemplary embodiment, the user can access the payment system account using a mobile device application. The rules can be maintained on the payment application on the user devise or on a server at the payment system.
The user can access a user interface through the user device or on the payment system to establish rules for the preferred card selection. The user can identify a card and associate a merchant category with the card. A transaction at any merchant who is associated with the merchant category will be conducted with the identified card. A user can associate different merchant categories with different cards.
Additionally or alternatively, the user can be presented with a list of merchant categories and associate cards with the categories that the user is likely to encounter.
Merchants can be categorized based on user-configured categories, payment system configured categories, or industry standard categories such as a merchant category code (“MCC”). A database of merchant categories and the assigned merchants can be maintained on the payment system and/or the payment application. The merchants in the database can be identified based on data including products sold, address, name, geo-location, phone number, and any other identifying data.
If a user has not associated a card and a merchant account, the payment system may recommend an association to the user. The payment system can receive the identities of cards associated with merchant categories from other users of the payment system. The payment system can determine which card of the user is the most often selected for a particular merchant category. The payment system can recommend that the user associate the identified card with that particular merchant category. Additionally or alternatively, the payment system can be configured to use the recommended card as a default option should the user not make a selection for a particular category. Additionally or alternatively, the payment system may be configured to use a recommended card in all transactions. That is, the user may not associate any cards with merchant categories and may use a recommended card for all transactions.
At the point of sale device of a merchant a user can tap or swipe a mobile device to initiate a payment transaction. The user may initiate the transaction in any other suitable manner, such as pressing a real or virtual button or speaking a voice command. The user device and the point of sale terminal or other terminal reader device can establish a communication.
The point of sale terminal can transmit details of the merchant and/or the product to be purchased to the user device. The payment application on the user device can receive the details and determine if the merchant is identified in a category. The merchant details can be compared to the details of merchant categories stored in the merchant category database. Merchant details can include any information that may identify the merchant such as address, name, phone number, and any other identifying data.
The user device can additionally or alternatively determine the geo-location of the merchant based on a location application on the device. For example, the user device can use the global positioning system capabilities of the user device or other location determining hardware or software to determine the geo-location of the merchant. The geo-location can be compared to the geo-location of merchants stored in the database to identify a merchant. Alternatively, any other database, registry, or source may be utilized to determine the identity of a merchant based on the geo-location provided.
Alternatively, if the identity of the merchant cannot be determined, the payment system can use the purchased products to identify a merchant category. The purchased products can be compared to the products sold by merchants in the category database. If an unidentified merchant sells similar products to other merchants in a category then the unidentified merchant can be placed into that category.
When the payment system identifies the category of the merchant, the payment system can select the preferred card and transmit the identity of the preferred card to the user device. Additionally or alternatively, the payment system can transmit the category of the merchant to the user device and the payment application can determine the preferred card.
The payment application can display, via a user interface, the identity of the preferred card to the user. The user can accept the card selected and proceed with the transaction or reject the selected card and select an alternative card. Alternatively, the payment application may proceed with the transaction without the approval of the user.
After selecting the preferred card, the payment application can transmit the card information to the point of sale terminal and complete the transaction.
In an alternate embodiment, all of the steps can be performed in an online transaction. The user device may attempt a transaction with an online merchant. The merchant can submit the transaction and the merchant details. The payment system can determine a category of the online merchant. The payment system can select a preferred card for that category and transmit the identification of the preferred card to the merchant to conduct the transaction.
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

Turning now to the drawings, in which like numerals represent like (but not necessarily identical) elements throughout the figures, exemplary embodiments of the present invention are described in detail.
FIG. 1 is a block diagram depicting a system for selecting a preferred card in a contactless payment transaction with a user network device, in accordance with certain exemplary embodiments. As depicted in FIG. 1, the system 100 includes network devices 110, 130, 140, and 170 that are configured to communicate with one another via one or more networks 105.
Each network 105 includes a wired or wireless telecommunication means by which network devices (including devices 110, 130, 140, and 170) can exchange data. For example, each network 105 can include a local area network (“LAN”), a wide area network (“WAN”), an intranet, an Internet, a mobile telephone network, or any combination thereof. Throughout the discussion of exemplary embodiments, 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.
Each network device 110, 130, 140, and 170 includes a device having a communication module capable of transmitting and receiving data over the network 105. For example, each network device 110, 130, 140, and 170 can include a server, desktop computer, laptop computer, tablet computer, smart phone, handheld computer, personal digital assistant (“PDA”), or any other wired or wireless, processor-driven device. In the exemplary embodiment depicted in FIG. 1, the network devices 110, 130, 140 and 170 are operated by end-users or consumers, merchant operators, payment system operators, and card issuer operators, respectively.
The user 101 can use a communication application 112, such as a web browser application or a stand-alone application, to view, download, upload, or otherwise access documents or web pages via a distributed network 105. The network 105 includes a wired or wireless telecommunication system or device by which network devices (including devices 110, 130, 140, and 170) can exchange data. For example, the network 105 can include a local area network (“LAN”), a wide area network (“WAN”), an intranet, an Internet, storage area network (SAN), personal area network (PAN), a metropolitan area network (MAN), a wireless local area network (WLAN), a virtual private network (VPN), a cellular or other mobile communication network, Bluetooth, NFC, or any combination thereof or any other appropriate architecture or system that facilitates the communication of signals, data, and/or messages.
The communication application 112 can interact with web servers or other computing devices connected to the network 105, including the point of sale terminal 132 of the merchant 130, the merchant server 135 of the merchant 130, the web server 141 of the payment system 140, and the card issuer 170. The communication application 112 can further communicate with the terminal reader 132 and/or the point of sale terminal 132 of the merchant 130 via any contactless communication technology such as NFC,z BLUETOOTH, Wi-Fi, infrared, or other suitable technology.
The user network device 110 may include a digital wallet application 111. The digital wallet 111 may encompass any application, hardware, software, or process the user device 110 may employ to assist the user 101 in completing a purchase. The digital wallet 111 can interact with the communication application 112 or can be embodied as a companion application of the communication application 112. As a companion application, the digital wallet 111 executes within the communication application 112. That is, the digital wallet 111 may be an application program embedded in the communication application 112.
The user device 110 can include a payment application 115. The payment application 115 can interact with the communication application 112 or be embodied as a companion application of the communication application 112 and execute within the communication application 112. The payment application 115 may further be embodied as a companion application of the digital wallet 111 and execute within the digital wallet 111. The payment application 115 may employ a software interface for configuration that may open in the digital wallet application 111 or may open in the web browser application 112. Alternatively, the payment application 115 may be execute on the user device 110 independent of the digital wallet 111 and the communication application 112.
The payment application 115 is operable to allow a user 101 to configure payment accounts on the user device 110 and the payment system 140. The payment application 115 can allow the user 101 to receive transaction details, select preferred cards for a transaction, receive notice of a card selection, provide card information, and provide other suitable services.
The user device 110 also includes a data storage unit 113 accessible by the digital wallet 111, the payment application 115, and the communication application 112. The exemplary data storage unit 113 can include one or more tangible computer-readable storage devices. The data storage unit 113 can be stored on the user device 110 or can be logically coupled to the user device 110. For example, the data storage unit 113 can include on-board flash memory and/or one or more removable memory cards or removable flash memory.
The payment system 140 includes a data storage unit 147 accessible by the web server 144. The exemplary data storage unit 147 can include one or more tangible computer-readable storage devices.
Some or all of the functions of the payment system 140 may be alternatively performed on the payment application 115 of the digital wallet 111. Additionally or alternatively, some or all of the functions of the payment application 115 and the digital wallet 111 may be performed on the payment system 140.
The user 101 can use a web server 144 on the payment system 140 to view, register, download, upload, or otherwise access the payment system 140 via a website (not illustrated) and a communication network 105). 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 user account. The registered financial card accounts may have multiple issuers 170 that maintain each financial account. The payment system 140 also may function as the issuer for the associated financial account. The user's 101 registration information is saved in the payment system's 140 data storage unit 147 and is accessible the by web server 144.
The user 101 also may use the web server 144 to define contactless payment rules and bidding rules. The creation of payment application 115 card selection rules is discussed in more detail hereinafter with reference to the methods described in FIG. 3.
The merchant 130 may use a web server 135 to view, download, upload, create offers, sell products online, or otherwise access the payment system 140 via a website 134 and a communication network 105. The web server 135 may be part of the merchant 130 and located at the merchant 130 location. The web server 135 may alternatively be located at a remote location. The merchant 130 represents an entity that offers products for the user 101 to purchase or use. The merchant 130 includes a point of sale (“POS”) terminal 132. The POS terminal 132 may be operated by a salesperson that enters the purchase data into the POS terminal 132 to complete the purchase transaction. The merchant 130 may be embodied as a physical merchant at a physical location or an online merchant. The merchant 130 can employ a terminal reader 131 that can communicate with the user device 110 and receive payment information. The terminal reader 131 may be a function of the POS terminal 132 or may be logically coupled to the POS terminal 132.
The user 101 may request a purchase from the merchant 130. In an exemplary embodiment, the purchase is initiated by a wireless “tap” of the mobile device 110 with the terminal reader 131. In an alternative exemplary embodiment, the purchase is initiated when the user 101 enters an account identification number at the POS terminal 132 or in the mobile device 110. In another alternative exemplary embodiment, the purchase is initiated online with the merchant server 135. The purchase may be initiated via the merchant website 136. 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 131. The merchant's POS terminal 132 interacts with an acquirer (for example Chase PaymentTech, or other third party payment processing companies), a card network (for example VISA, MasterCard, American Express, Discover or other card processing networks), the payment system 140, and the issuer 170 (for example Citibank, CapitalOne, Bank of America, and other financial institutions to authorize payment). System Process
The components of the exemplary operating environment 100 are described hereinafter with reference to the exemplary methods illustrated in FIGS. 2.
FIG. 2 is a block flow diagram depicting a method 200 to select a preferred card in a contactless payment transaction with a user network device, in accordance with certain exemplary embodiments.
With reference to FIGS. 1 and 2, in block 205, the user 101 configures the rules for the payment application 115. The rules can include instructions for selecting a card to use in a transaction with a merchant 130. The rules include instructions to select a card based on the merchant categories associated with the card. The details of a method to define the preferred card rules are discussed in greater detail in the method 205 with reference to FIG. 3.
FIG. 3 is a block flow diagram depicting a method 205 for establishing a preferred card rule in a payment application 115, in accordance with certain exemplary embodiments.
In block 305, a user 101 identifies a card associated with a financial account with a card issuer 170. The payment system 140 and payment application 115 can include 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). The user 101 can set rules specifying which financial account will be accessed when a contactless transaction is attempted. The user 101 can then add, delete, or change the default payment rules associated with the user 101. The user 101 can change these default static rules, create new rules, or delete a rule. In an exemplary embodiment, the user 101 can access the payment system account and modify the rules at any time, including a time immediately before a payment transaction is initiated. In an exemplary embodiment, the user 101 can access the payment system account using a payment application 115 on a user device 110. The rules can be maintained on the payment application 115 on the user devise 110 or on a server 144 at the payment system 140.
In block 310, the user 101 can associate one or more merchant categories with the identified card. For example, the user 101 can configure all transactions with the merchants from a particular category to be conducted with the identified card. Merchants 130 can be categorized based on user 101 configured categories, payment system 140 configured categories, or industry standard categories such as a merchant category code (“MCC”). A database of merchant categories and the assigned merchants can be maintained on the payment system 140 and/or the payment application 115. The user 101 may be presented with a list of merchant categories and offered the opportunity to associate one or more of the categories with the identified card. Alternatively, the user 101 may be presented with the option of entering text descriptions of businesses, names of businesses, or other text input. The payment system 140 may receive the user input and determine the corresponding merchant category from a database of merchant categories.
In block 315, during configuration, if a user 101 has not associated a merchant category with any card of the user 101, the payment system 140 can recommend a card. Alternatively, the payment system 140 can recommend a card at the time of a transaction with a merchant 130 in a category that is not associated with a card.
The payment system 140 can search the accounts of other users of a card issued by a card network 170 associated with the account of the user 101. The payment system 140 can additionally or alternatively focus the search on other users of a card that has the same conditions, terms, rewards, or any other suitable criteria. The payment system 140 can identify frequently associated merchant categories in the accounts of the other users of the card.
In block 320, if a merchant category is associated in the account of a number of users over a defined threshold or a threshold percentage of users, the payment system 140 can recommend the identified merchant category to the user 101. The recommendation can be transmitted to the user 101 via the payment application 115, email, text, or other suitable communication technology.
In block 325, the payment system 140 may alternatively search the merchant categories for a ranking of the most frequent cards with which the merchant categories are associated. The payment system 140 can search the associated cards to determine if the user 101 has any of the highly ranked cards associated with the user account.
In block 330, the payment system 140 can determine which card of the user 101 is the most highly ranked for a particular merchant category. The payment system 140 can recommend the user 101 associate the most highly ranked card and the particular merchant category. The recommendation may be transmitted to the user 101 via the payment application 115, email, text, or other suitable communication technology.
In block 335, the user 101 associates the recommended card with the recommended merchant category. The association may be performed by the user 101 during configuration or at any time after configuration. Additionally or alternatively, the recommendation may be made at the time that a purchase is attempted at a merchant 130 that belongs to a merchant category that has not been associated with a card.
Additionally or alternatively, the user account may be configured to automatically associate a merchant category with a card if the user 101 has not previously performed the association. The automatic association may occur at any time in the process including, but not limited to, the time of sign up, the time of configuration, or when a purchase is attempted.
The user 101 may additionally configure a default card to be used for any transaction with a merchant 130 belonging to a merchant category that has not been associated with a card. The default card may additionally or alternatively, be employed in a transaction where the merchant category cannot be established.
From block 335, the method 205 returns to block 210 in FIG. 2.
Returning now to FIG. 2, in block 210, a user 101 visits a merchant 130 and selects a product for purchase. The term “product(s)” should be interpreted to include tangible and intangible products, as well as services. The user 101 can approach a point of sale (“POS”) terminal 132 of a merchant 130. To initiate a payment transaction, the user 101 can “tap” or swipe a user network device 110, such as a near field communication (“NFC”) enabled user device 110, to a terminal reader 131 executing on, or logically coupled to, the POS device 132. The user 101 may initiate the transaction in any other suitable manner, such as pressing a real or virtual button or speaking a voice command. The user device 110 and the POS terminal 132 or other terminal reader 131 device can establish a communication. The user device 110 and the POS terminal 132 can communicate via near field communication (“NFC”), BLUETOOTH, Wi-Fi, infrared, or any other suitable communication technology.
In block 215, the POS terminal 132 can transmit a payment processing request to the user device 110. The POS terminal 132 can transmit details of the transaction to the user device 110 and request details of the financial account or card that will conduct the transaction. The POS terminal 132 can transmit details of the merchant 130. The details about the merchant 130 may include, but not be limited to, the merchant category code (“MCC”), the location, the name, the products sold by the merchant 130, and other suitable details that may assist the payment system 140 in determining the merchant category.
The user device 110 can additionally or alternatively determine the geo-location of the merchant 130 based on a location application on the device. For example, the user device 110 can use the global positioning system capabilities of the user device 110 or other location determining application or hardware to determine the geo-location of the merchant 130. The geo-location of the transaction can be compared to the geo-location of merchants stored in a database to identify a merchant 130.
In block 220, the transaction details and the merchant details can be transmitted to the payment system 140 by the payment application 115. The transmission may be conducted via an Internet connection over the network 105, email, text, or any other suitable communication technology. The payment system 140 can compare the details of the merchant 130 to determine the category of the merchant 130.
The details of the block 220 to determine the category of the merchant 130 are further described in method 220 in FIG. 4.
In block 405 of FIG. 4, the payment system 140 may utilize the categories as defined by the MCC or the payment system 140 may create and maintain another established category system or develop a new category system. The category system may additionally or alternatively be configured by the user 101 or other operator.
In an alternate exemplary embodiment, the categorizing of the merchant 130 may be executed on the payment application 115.
The category of the merchant 130 can be determined through an analysis of the details provided with the transaction. For example, the details may specify an MCC of the merchant 130. The payment system can use the MCC to directly establish the category of the merchant 130. The details may additionally or alternatively provide a different type of category designation, such as one developed by the payment system 140, the merchant 130, the user 101 or another suitable party. Additionally or alternatively, the details may provide a general description of the category of the merchant. For example, the details may specify that the merchant 130 associated with the transaction is a restaurant, an oil change facility, or a hair salon. The payment system 140 can use the specified merchant type to associate the merchant with a category.
If the MCC or other category designation is provided, then method 220 follows the “YES” branch of block 405 to block 225 with respect to FIG. 2. If the MCC or other category designation is not provided, then method 220 follows the “NO” branch of block 405 to block 410.
Following the “NO” branch of to block 410, if no MCC or other category is provided, the payment system 140 can determine if the merchant 130 name or other identifying detail has previously been recorded in a database. If the merchant 130 has previously conducted a transaction with the payment system 140, the merchant 130 may already be identified by name in a category. If the details provide the name of the merchant 130, the payment system 140 can identify the category to which the merchant 130 belongs by searching the category database and determining the category with which the merchant 130 identity has previously been associated. The payment system 140 can use other identifying information from the details to find the merchant 130 in the database to determine the category of the merchant 130. Other identifiers that may be in a category database for a merchant 130 may include the address, phone number, or other identifying details of a merchant 130.
If the merchant is identified, then method 220 follows the “YES” branch of block 410 to block 425. If the merchant is not identified, then method 220 follows the “NO” branch of block 410 to block 415.
Following the “NO” branch of to block 415, if the identity of the merchant 130 cannot be determined, the payment system 140 can identify the geo-location of the user device 110. By determining the location of the user device 110, the payment system 140 can identify the merchant 130 associated with that location. In an offline transaction, one skilled in the art would understand that if the user 101 is conducting a transaction utilizing the user device 110, then the user device 110 would be at the same location as the merchant 130 associated with the transaction. The geo-location of the user device 110 can be determined from the global positioning system hardware and software utilized by the user device 110. For example, the user device 110 can transmit the geo-location to the payment system 140 upon request or with every transaction request. Additionally or alternatively, the user device 110 can determine the geo-location from any other hardware or software technology available to the user device 110, such as a geo-location received from a Wi-Fi system being accessed by the user device 110 or other system.
In block 420, the payment system 140 can use the geo-location of the user device 110, and thus the location of the merchant 130, to determine the identity of the merchant 130. The identity may be determined by using a registry of merchant addresses, a mapping application or website, or other database or system to identify a merchant 130 from the geo-location of the merchant 130.
If the merchant is identified from the geo-location, then method 220 follows the “YES” branch of block 420 to block 425. If the merchant is not identified, then method 220 follows the “NO” branch of block 420 to block 430.
Following the YES branches of blocks 410 and 420 to block 425, the payment system can use the identity of the merchant 130 to identify the category to which the merchant 130 belongs. If the merchant 130 has previously conducted a transaction with the payment system 140, then the payment system 140 may have placed the merchant 130 in a category at that time. If the payment system 140 has previously placed the merchant 130 into a category, then the payment system 140 can identify the merchant in the database and extract the category in which the merchant 130 is stored.
Alternatively, the payment system 140 may employ a system for identifying merchants 130 and placing the merchants 130 in categories at a time other than at the time of a transaction. That is, the payment system 140 may continuously or periodically search for merchants 130 that are not categorized and attempt to place the merchants 130 in categories in the database. The payment system 140 may additionally or alternatively, subscribe to a system or service that updates the category codes, such as an MCC, and supplies the categories of merchants 130 to the payment system 140. The payment system 140 may utilize any other system or process to update the merchants 130 located in the category database.
If the merchant 130 is identified in a category, the payment system 140 can determine that the merchant 130 associated with the current transaction is the same merchant 130 located in the database. The payment system 140 can thus determine the category of the merchant 130.
If the merchant category is determined from the merchant 130 identity, then method 220 follows the “YES” branch of block 425 to block 225 with respect to FIG. 2. If the merchant category is not determined from the merchant 130 identity, then method 220 follows the “NO” branch of block 425 to block 430.
Following the NO branch of block 425, in block 430, the payment system 140 can use the products associated with the transaction to identify a merchant category. The products associated with the transaction can be identified from the description of the products, a model number associated with the products, a stock-keeping unit (“SKU”) or other identifying code, or other identifier from the transaction.
In block 435, the products can be compared to the products sold by other merchants in the category database. If the merchant 130 sells similar products to other merchants in a category then the merchant 130 can be placed into that category. The payment system 140 may employ a scoring system to determine the category. For example, the merchant 130 may receive points for every product in common with the merchants in a product category. A threshold of points may be required to place the merchant 130 in the category. Any scoring system or other system for determining if the products of the merchant 130 match the products of the merchants in a category may be utilized.
In block 440, the payment system 140 associates the merchant 130 with the category of the merchants with which the merchant 130 sells similar products. The payment system 140 may associate the merchant 130 with the category for only the pending transaction or the payment system 140 may associate the merchant 130 with the selected category for future transactions. The association may be permanent or may be associated until such time as a more accurate category is assigned.
From block 440, the method 220 returns to block 225 in FIG. 2.
Returning to FIG. 2, in block 225, when the payment system 140 identifies the category of the merchant 130, the payment system 140 can select the preferred card and transmit the identity of the preferred card to the user device 110. In an alternative exemplary embodiment, the payment system 140 can transmit the category of the merchant 130 to the user device and the payment application 115 can determine the preferred card for the merchant category.
In block 230, the payment application 115 can display, via a user interface, the identity of the preferred card to the user 101. The user 101 can accept the card selected and proceed with the transaction or reject the selected card and select an alternative card. Alternatively, the payment application 115 may proceed with the transaction without the approval of the user 101.
In block 235, after selecting the preferred card, the payment application 115 can transmit the card information to the POS terminal 132 and complete the transaction.
In block 240, the merchant 130 can receive the card information and conduct the transaction with the issuer 170 of the selected card.
Some or all of the functions of the payment system 140 may be alternatively performed on the payment application 115 of the digital wallet 111. Additionally or alternatively, some or all of the functions of the payment application 115 and the digital wallet 111 may be performed on the payment system 140.
In an alternate embodiment, all of the steps can be performed in an online transaction. The user device 110 can attempt a transaction with an online merchant 130. The merchant 130 can submit the transaction and the merchant details. The payment system 140 or a payment application 115 can determine a category of the online merchant 130 via the process as described above. The payment system 140 or a payment application 115 can select a preferred card for that category and transmit the identification of the preferred card to the merchant 130 to conduct the transaction.
From block 240, the method 200 ends.

General

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. 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.
One or more aspects of the invention may comprise 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 invention in computer programming, and the invention 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 of the disclosed invention 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 invention. Further, those skilled in the art will appreciate that one or more aspects of the invention described herein may be performed by hardware, software, or a combination thereof, as may be embodied in one or more computing systems. 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.
The exemplary embodiments described herein can be used with computer hardware and software that perform the methods and processing functions described previously. 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.
The exemplary systems, methods, and acts described in the embodiments presented previously are illustrative, and, in alternative embodiments, certain acts can be performed in a different order, in parallel with one another, omitted entirely, and/or combined between different exemplary embodiments, and/or certain additional acts can be performed, without departing from the scope and spirit of the invention. Accordingly, such alternative embodiments are included in the inventions described herein.
Although specific embodiments have been described above in detail, the description is merely for purposes of illustration. It should be appreciated, therefore, that many aspects described above are not intended as required or essential elements unless explicitly stated otherwise. Modifications of, and equivalent components or acts corresponding to, the disclosed aspects of the exemplary embodiments, in addition to those described above, can be made by a person of ordinary skill in the art, having the benefit of the present disclosure, 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.

Claims

What is claimed is:

1. A computer-implemented method to select a payment instrument for a purchase based on a merchant category, comprising:

associating, by a computer, a plurality of financial accounts with a user account of a user, the user account being maintained by the computer;

for one or more of the financial accounts associated with the user account, associating, by the computer, one of a plurality of merchant categories with the respective financial account in a category database;

receiving, by the computer from a user network device, data from a transaction of the user account with a merchant;

determining, by the computer, a merchant category of the merchant by extracting an identification of the merchant from the data from the transaction, locating the identified merchant in the category database, and determining the category associated with the merchant in the database;

selecting, by the computer, one of the financial accounts associated with the merchant category of the merchant; and

communicating, by the computer, the selected financial account to the user network device to conduct the transaction.

2. The computer-implemented method of claim 1, wherein extracting the identification of the merchant from the data comprises identifying, by the computer, one of more of the following features of the merchant from the data:

a merchant name;

a merchant address;

a merchant telephone number; and

a merchant store number.

3. The computer-implemented method of claim 1, wherein the transaction data comprises location data identifying a location of the user network device, and wherein extracting the identification of the merchant from the transaction data comprises:

extracting, by the computer, the location data identifying the location of the user network device; and

determining, by the computer, the identity of the merchant associated with the location of the user network device.

4. The computer-implemented method of claim 1, wherein determining the merchant category of the merchant comprises:

identifying, by the computer, one of more products associated with the transaction;

comparing, by the computer, the associated products with a list of products associated with other merchants in the category database; and

determining, by the computer, that the merchant is associated with a category of merchants based on a similarity of the products associated with the merchant and the products associated with the merchants associated with the category.

5. The computer-implemented method of claim 1, further comprising:

receiving, by the computer, data from a plurality of accounts of other users;

determining, by the computer, financial accounts of the accounts of other users that are in common with the user account;

determining, by the computer, merchant categories associated with the common financial accounts of the user account and the other user accounts; and

recommending, by the computer, the merchant categories that are most frequently associated with the financial accounts of the accounts of other users that are in common with the user account.

6. The computer-implemented method of claim 1, wherein the category database comprises merchant names, merchant addresses, merchant phone numbers, merchant product offerings, merchant category codes, and merchant geo-locations.

7. A computer program product, comprising:

a non-transitory computer-readable storage device having computer-executable program instructions embodied thereon that when executed by a computer select a payment instrument for a purchase based on a merchant category, the computer-executable program instructions comprising:

computer-executable program instructions to associate a plurality of financial accounts with a user account of a user, the user account being maintained by the computer;

computer-executable program instructions to associate, for one or more of the financial accounts associated with the user account, one of a plurality of merchant categories with the respective financial account in a category database;

computer-executable program instructions to receive, from a user network device, data from a transaction of the user account with a merchant;

computer-executable program instructions to determine a merchant category of the merchant by

extracting, from the transaction data, a location identifying the location of the user network device,

determining the identity of the merchant associated with the location of the user network device,

locating the identified merchant in the category database, and

determining the category associated with the merchant in the database;

computer-executable program instructions to select one of the financial accounts associated with the merchant category of the merchant; and

computer-executable program instructions to communicate the selected financial account to the user network device to conduct the transaction.

8. The computer program product of claim 7, wherein extracting the identification of the merchant from the data comprises identifying, by the computer, one of more of the following features of the merchant from the data:

a merchant name;

a merchant address;

a merchant telephone number; and

a merchant store number.

9. The computer program product of claim 7, wherein the transaction data comprises identification data identifying a merchant, and wherein determining the category of the merchant from the transaction data comprises:

extracting an identification of the merchant from the data from the transaction;

locating the identified merchant in the category database; and

determining the category associated with the merchant in the database.

10. The computer program product of claim 7, wherein determining the merchant category of the merchant comprises:

identifying one of more products associated with the transaction;

comparing the associated products with a list of products associated with other merchants in the category database; and

determining that the merchant is associated with a category of merchants based on a similarity of the products associated with the merchant and the products associated with the merchants associated with the category.

11. The computer program product of claim 7, further comprising:

computer-executable program instructions to receive data from a plurality of accounts of other users;

computer-executable program instructions to determine financial accounts of the accounts of other users that are in common with the user account;

computer-executable program instructions to determine merchant categories associated with the common financial accounts of the user account and the other user accounts; and

computer-executable program instructions to recommend the merchant categories that are most frequently associated with the financial accounts of the accounts of other users that are in common with the user account.

12. The computer program product of claim 7, wherein the category database comprises merchant names, merchant addresses, merchant phone numbers, merchant product offerings, merchant category codes, and merchant geo-locations.

13. A system to select a payment instrument for a purchase based on a merchant category, the system comprising:

a storage resource;

a network module; and

a processor communicatively coupled to the storage resource and the network module, wherein the processor executes application code instructions that are stored in the storage resource and that cause the system to:

associate a plurality of financial accounts with a user account of a user, the user account being maintained by the computer;

associate, for one or more of the financial accounts associated with the user account, one of a plurality of merchant categories with the respective financial account in a category database;

receive, from a user network device, data from a transaction of the user account with a merchant;

determine a merchant category of the merchant by

identifying one of more products associated with the transaction,

comparing the associated products with a list of products associated with other merchants in the category database,

determining that the merchant is associated with a category of merchants based on a similarity of the products associated with the merchant and the products associated with the merchants associated with the category;

select one of the financial accounts associated with the merchant category of the merchant; and

communicate the selected financial account to the user network device to conduct the transaction.

14. The system of claim 13, wherein extracting the identification of the merchant from the data comprises identifying, by the computer, one of more of the following features of the merchant from the data:

a merchant name;

a merchant address;

a merchant telephone number; and

a merchant store number.

15. The system of claim 13, wherein the transaction data comprises location data identifying a location of the user network device, and wherein determining the category of the merchant from the transaction data comprises instructions further causing the system to:

extract the location data identifying the location of the user network device; and

determine the identity of the merchant associated with the location of the user network device;

locate the identified merchant in the category database; and

determine the category associated with the merchant in the database.

16. The system of claim 13, wherein the transaction data comprises identification data identifying a merchant, and wherein determining the category of the merchant from the transaction data comprises:

locating the identified merchant in the category database; and

determining the category associated with the merchant in the database.

17. The system of claim 13, the instructions further causing the system to:

receive data from a plurality of accounts of other users;

determine financial accounts of the accounts of other users that are in common with the user account;

determine merchant categories associated with the common financial accounts of the user account and the other user accounts; and

recommend the merchant categories that are most frequently associated with the financial accounts of the accounts of other users that are in common with the user account.

18. The system of claim 13, wherein the category database comprises merchant names, merchant addresses, merchant phone numbers, merchant product offerings, merchant category codes, and merchant geo-locations.