WO2020142105A1

WO2020142105A1 - Smart payment systems and methods

Info

Publication number: WO2020142105A1
Application number: PCT/US2019/012370
Authority: WO
Inventors: Prasanth Yeddula; Ashwini Laxminarayana TANTRY
Original assignee: Visa International Service Association
Priority date: 2019-01-04
Filing date: 2019-01-04
Publication date: 2020-07-09

Abstract

A processor-implemented method for payment selection including receiving a user identifier and a beacon identifier from a user computing device, and receiving the beacon identifier and purchase item information from a smart billing machine associated with the beacon ID in a transaction. The method includes identifying the user payment accounts of the user and determining benefit information for each of the payment accounts. The method includes determining a payment account plan including assigning each of the one or more purchase items to one of the user payment accounts and transmitting the payment account plan to the user computing device so as to enable the user computing device to complete the transaction based on the payment account plan.

Description

SMART PAYMENT SYSTEMS AND METHODS

FIELD OF THE INVENTION

[0001 ] The invention relates to systems and methods for managing payment account selection.

BACKGROUND

[0002] Many payment accounts offer various loyalty or rewards programs to incentivize consumers to use their respective payment accounts for making purchases. For example, a credit card company may offer rewards points to its users based upon the amount of dollars spent through transactions using that company’s credit card. Many other payment accounts may also offer rewards, such as bank debit cards, retailers that offer rewards cards, or even groups of retailers or other merchants offering shared rewards. Some credit or debit card issuers may offer various different types of rewards programs that offer bonus points for certain types of purchases, such as airline tickets, hotels, gasoline, restaurants, groceries, etc. Some rewards programs may even offer different bonus rewards multipliers from week to week, or from month to month.

[0003] A single user may sign up with more than one of payment account, for which the user may receive multiple cards. Traditionally, a user would need to decide which payment account to use for each new transaction, often unaware of what particularly rewards or points are available for each separate payment account. A system is needed that will help users more effectively take advantage of their various payment account programs. SUMMARY

[0004] The following presents a simplified summary of the present disclosure in order to provide a basic understanding of some aspects of the disclosure. This summary is not an extensive overview of the disclosure. It is not intended to identify key or critical elements of the disclosure or to delineate the scope of the disclosure. The following summary merely presents some concepts of the disclosure in a simplified form as a prelude to the more detailed description provided below.

[0005] In some embodiments, the disclosure describes a smart payment system that may optimize benefits to a user associated with a plurality of user payment accounts. The system and methods may include determining a payment account plan for a transaction that may assign individual purchase items in the transaction to particular payment accounts based on the benefits those payment accounts may provide.

BRIEF DESCRIPTION OF THE DRAWINGS

[0006] The invention may be better understood by references to the detailed description when considered in connection with the accompanying drawings. The components in the figures are not necessarily to scale, emphasis instead being placed upon illustrating the principles of the invention. In the figures, like reference numerals designate corresponding parts throughout the different views.

[0007] Fig. 1 is an illustration of the elements of an embodiment of a system that includes a system for monitoring and preventing fraud as disclosed herein; [0008] Fig. 2 is a schematic illustration of elements of an embodiment of an example computing device;

[0009] Fig. 3 is a schematic illustration of elements of an embodiment of a server type computing device;

[001 0] Fig. 4 is a block diagram illustrating system elements for an embodiment of a smart payment system in accordance with the current disclosure;

[001 1 ] Fig. 5 is an example signaling flow diagram showing communications within a smart payment system in accordance with the current disclosure;

[001 2] Fig. 6A is a user interface diagram illustrating example features of an embodiment of a graphical user interface for the smart payment system as described herein;

[001 3] Fig. 6B is a user interface diagram illustrating example features of the graphical user interface of Fig. 6A;

[001 4] Fig. 7 is a flow chart of an embodiment of a process for using the smart payment system described herein;

[001 5] Fig. 8 is a flow chart of another embodiment of a process for using the smart payment system described herein; and

[001 6] Fig. 9 is a transaction flow diagram of an embodiment of the smart payment system as described herein.

[001 7] Persons of ordinary skill in the art will appreciate that elements in the figures are illustrated for simplicity and clarity so not all connections and options have been shown to avoid obscuring the inventive aspects. For example, common but well- understood elements that are useful or necessary in a commercially feasible embodiment are not often depicted in order to facilitate a less obstructed view of these various embodiments of the present disclosure. It will be further appreciated that certain actions and/or steps may be described or depicted in a particular order of occurrence while those skilled in the art will understand that such specificity with respect to sequence is not actually required. It will also be understood that the terms and expressions used herein are to be defined with respect to their corresponding respective areas of inquiry and study except where specific meaning have otherwise been set forth herein.

DETAILED DESCRIPTION

[0018] The present invention now will be described more fully hereinafter with reference to the accompanying drawings, which form a part hereof, and which show, by way of illustration, specific exemplary embodiments by which the invention may be practiced. These illustrations and exemplary embodiments are presented with the understanding that the present disclosure is an exemplification of the principles of one or more inventions and is not intended to limit any one of the inventions to the embodiments illustrated. The invention may be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art. Among other things, the present invention may be embodied as methods or devices. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. The following detailed description is, therefore, not to be taken in a limiting sense.

[001 9] The smart payment system and methods described herein may provide a user of multiple payments accounts an efficient way to maximize the rewards received through one or more payment accounts for a given purchase or transaction using a digital wallet device or service. A user may add one or more payment accounts to the user’s digital wallet, which may then be tokenized and ready for making payments using a user device that includes the digital wallet. The various payment accounts associated with the digital wallet may each correspond to a particular points or rewards program, or may provide other benefits to the user. Each rewards account program may accumulate rewards points for each purchase made using the program’s respective payment account, or provide rewards for purchases of items in particular product categories or brands. Additionally, some merchants may offer additional rewards, rebates, discounts, etc., for certain purchases or for using a particular payment account.

[0020] Traditionally, a user making purchases or other transactions using a digital wallet program or another payment method may need to select which of the multiple payment accounts the user would like to use for a particular transaction, which may include various multiple purchased items. In some cases, a default payment account may be selected by the user, or the user may be prompted to select an account for each transaction. Often, however, at the time of a particular purchase or other transaction, a user may be unaware of the loyalty, rewards points, or other benefits available for any particular product or service or overall transaction, or what type of rewards or points may be earned with a given transaction. This may mean a user could use a card or other payment account at random without knowing the loyalty points that could be earned by using a different account, or the other benefits that could be received (e.g., offers, cash back, discounts, etc.).

[0021 ] In some embodiments, the smart payment system may allow a user to take advantage of the benefits associated with their payment accounts even if the user may not be aware of those benefits at the time of the purchase. In some embodiments, a smart wallet application on or available to a user computing device may automatically select the payment account among the user’s multiple payment accounts that provides the greatest benefit to the user. In some embodiments, the user may only need to trigger the transaction by tapping a button on a smart wallet application or other triggering activity, and the smart payment system may complete the transaction with one or more of the user’s payment accounts in an optimal combination. For example, in a user may use the smart payment application to initiate a purchase of multiple items that may belong to different product categories. The smart payment system may determine that it would be most advantageous to the user to use different payment accounts for each product in the transaction, and may use each respective payment account to pay for each respective item without the user needing to provide additional input or initiate multiple transactions.

[0022] Various factors may be included in the smart payment system’s determination of which payment account or payment accounts to use for a particular transaction. For example, in some embodiments, the smart payment system may base its determination on issuer rewards points, merchant offers, issuer-gateway offers, membership-based issuer offers, merchandise-based incentives or offers, gift cards or pre-paid cards available, retail credit cards, category of merchandise purchased, etc.

[0023] In some embodiments, the smart payment system may provide the user with an option to proceed with a transaction using smart payments or with manual payment account selection. The manual payment account selection may include providing the user an opportunity to select which payment account to use for the transaction. Using smart payments, on the other hand, may trigger the smart payment system to initiate the automatic payment account selection as described herein. In some embodiments, once the smart payment system has determined the best payment account option or options for the user in a particular transaction, the smart payment system may send a notification to a user computing device. In some embodiments, the notification may alert the user regarding the payment account or accounts selected for the transaction. In some embodiments, the user may then authorize the smart payment system to complete the transaction via the user device, e.g., through the smart payment application. In some embodiments, the smart payment system may automatically select the payment account(s) used for the transaction based on the benefits without contacting the user for authorization. In some embodiments, once the user has authorized the transaction, the smart payment system may reach out to the issuer(s) of the selected account(s) and request an open authorization (OAuth) and proceed with the transaction.

[0024] In a general example, a first payment account associated may offer different benefits for a given transaction or purchase than a second payment account. For a given transaction, it may be difficult for the user to know or to easily find out what sort of benefits, if any, may be associated with each of the first and second payment accounts. The smart payment system may, in some embodiments, determine which of the user’s various payment accounts or combination of payment accounts would provide the user with the greatest benefit. The system may then, either automatically or upon additional prompting from the user, select the payment account or combination of accounts that will provide the greatest benefit to the user. For example, if the system determines that the second payment account will provide a more advantageous benefit than the first payment account, the system may execute the transaction with the second payment account in order to earn those benefits. In some embodiments, if the transaction includes purchasing more than one type of product or service, the system may determine that purchasing a first product with the first payment account and the second product with the second payment account will maximize benefits for the user. In some embodiments, the system may determine an optimal combination of payment accounts based on any number of factors such as category of merchandise purchased, retail offers, credit card or payment account reward points, issuer-gateway offers, merchant offers, manufacturer offers, membership-based issuer offers, merchandise- based decisions, gift or prepaid cards or credits, retail credit cards, etc.

[0025] Accordingly, the system may, among other things, provide a technical solution to the problem of imperfect knowledge of rewards or other benefits associated with payment accounts, and a technical problem of the inability to readily access benefit information for multiple different payment accounts and multiple different purchase items. Further, it will be appreciated by those skilled in the art that the systems and methods described herein are not merely computer implemented activities that could be performed in a person’s head or using pen and paper. In contrast, the systems and method of the smart payment system provide at least technical solutions rooted in computer technology that.

[0026] At a high level, in an embodiment, the disclosure describes a processor- implemented method for payment selection. The method may include receiving, from a user computing device, a user identifier associated with a user and payment account information associated with a plurality of user payment accounts associated with the user. The method may also include receiving, from the user computing device, the user identifier and a beacon identifier associated with a smart billing machine. The method may include receiving, from the smart billing machine, the beacon identifier associated with the smart billing machine and purchase item information associated with one or more purchase items in a transaction. Based on receiving the beacon identifier from both the user computing device and the smart billing machine, the method may include identifying the plurality of user payment accounts associated with the user. The method may also include determining benefit information associated with each of the plurality of user payment accounts associated with the user. Based on the benefit information, the method may include determining a payment account plan that includes assigning each of the one or more purchase items to one of the plurality of user payment accounts, and transmitting the payment account plan to the user computing device so as to enable the user computing device to complete the transaction based on the payment account plan.

[0027] In another embodiment, the disclosure describes a method comprising including receiving, from a user computing device, a user identifier associated with a user and payment account information associated with a plurality of user payment accounts associated with the user. The plurality of user payment accounts may include a first user payment account and a second user payment account. The method may also include receiving, from the user computing device, the user identifier and a beacon identifier associated with a smart billing machine. The method my include receiving, from the smart billing machine, the beacon identifier associated with the smart billing machine and purchase item information associated with one or more purchase items in a transaction. The one or more purchase items may include a first purchase item and a second purchase item. Based on receiving the beacon identifier from both the user computing device and the smart billing machine, the method may include identifying the plurality of user payment accounts associated with the user and determining benefit information associated with each of the plurality of user payment accounts. The method may include determining that a benefit associated with purchasing the first purchase item with the first user payment account is greater than a benefit associated with purchasing the first purchased item with the second user payment account, and determining that a benefit associated with purchasing the second purchase item with the second user payment account is greater than a benefit associated with purchasing the second purchase item with the first user payment account. The method may include determining a payment account plan that includes assigning each the first purchase item to the first user payment account and the second purchase item to the second user payment account, and transmitting the payment account plan to the user computing device so as to enable the user computing device to complete the transaction based on the payment account plan. [0028] In another embodiment, the disclosure describes a method that may include receiving, from a user computing device, a user identifier associated with a user and payment account information associated with a plurality of user payment accounts associated with the user. The method may include determining benefit information associated with each of the plurality of user payment accounts associated with the user. Based on the benefit information, assigning a first product category to a first user payment account of the plurality of user payment accounts and a second product category to a second user payment account of the plurality of user payment accounts. The method may include receiving, from the user computing device, the user identifier and a beacon identifier associated with a smart billing machine and receiving, from the smart billing machine, the beacon identifier associated with the smart billing machine and purchase item information associated with one or more purchase items in a transaction. The method may include, in response at least to receiving the beacon identifier from both the user computing device and the smart billing machine, determining that a first purchase item of the one or more purchase items belongs to the first product category and that a second purchase item of the one or more purchase items belongs to the second product category. The method may also include determining a payment account plan that includes assigning the first purchase item to the first user payment account and the second purchase item to the second user payment account, and transmitting the payment account plan to the user computing device so as to enable the user computing device to complete the transaction based on the payment account plan. [0029] A high level illustration of some of the elements in a sample computing system 50 that may be physically configured to implement the smart payment system and process is illustrated in Fig. 1. The system 50 may include one or more user computing devices 55, such as smart phones or tablet computers, mobile computing devices, wearable mobile devices, desktop computers, laptop computers, or any other computing devices that allow users to interface with a digital communications network, such as digital communication network 60. Connection to the digital communication network 60 may be wired or wireless, and may be via the internet or via a cellular network or any other suitable connection service. The system 50 may also include at least one point-of-sale (POS) device 69, such as in a merchant store, that may be able to connect to wirelessly connect to the user computing device 55. In some embodiments, the POS device 69 may be a smart POS device. The POS device 69 may also be connected to or be a part of a smart billing machine 71. In some embodiments, the POS device, the smart billing machine 71 or both may be connected wired or wirelessly to the digital communication network 60.

[0030] Various other computer servers may also be connected to via the digital communication network 60, such as a smart payment server 65 and a payment server 70. In some embodiments, the smart payment server 65 may be included as a server within or be a part of the payment server 70. The payment server 70 may represent, for example, a credit card issuer, a bank, or another financial institution. Various of these servers or computer entities may also be connected through a secure payment network 75. The payment network 75 may be an electronic payment system used to accept, transmit, or process transactions made by users with payment cards for money, goods, or services, and to transfer information and funds among payment card issuers, merchants, payment card holders, payment processors, acquirers, etc. In the illustrated embodiment, at least the smart payment server 65, the payment server 70, a token server 80, an issuer server 85, and a merchant server 90 may be connected via the payment network 75, but it is contemplated that other entities, such as one or more acquirer, may be connected as well. In some embodiments, it is contemplated that multiple issuer servers associated with multiple different issuers and/or multiple merchant servers associated with multiple different merchants may also be connected to the payment network 75. It is also contemplated that the payment server 70 and smart payment server 65 may also be connected to the one or more user computing devices 55 over the digital communication network 60.

[0031 ] In one embodiment, the computing device 55 may be a device that operates using a portable power source, such as a battery. The computing device 55 may also have a display 56 which may or may not be a touch sensitive display. More specifically, the display 56 may have a capacitance sensor, for example, that may be used to provide input data to the computing device 55. In other embodiments, an input pad 57 such as arrows, scroll wheels, keyboards, etc., may be used to provide inputs to the computing device 55. In addition, the computing device 55 may have a microphone 58 which may accept and store verbal data, a camera 59 to accept images and a speaker 61 to communicate sounds.

[0032] Fig. 2 is a simplified illustration of the physical elements that make up an embodiment of a computing device 55 and Fig. 3 is a simplified illustration of the physical elements that make up an embodiment of a server type computing device, such as the smart payment server 65, but the merchant server 90, the token server 80, and the issuer server 85 may reflect similar physical elements in some embodiments. Referring to Fig. 2, a sample computing device 55 is illustrated that is physically configured according to be part of the computing system 50 shown in Fig. 1. The user computing device 55 may have a processor 1451 that is physically configured according to computer executable instructions. In some embodiments, the processor can be specially designed or configured to optimize communication between the server 65 and the computing device 55 relating to the smart payment service described herein. The computing device 55 may have a portable power supply 1455 such as a battery, which may be rechargeable. It may also have a sound and video module 1461 which assists in displaying video and sound and may turn off when not in use to conserve power and battery life. The computing device 55 may also have volatile memory 1465 and non volatile memory 1471. The computing device 55 may have GPS capabilities that may be a separate circuit or may be part of the processor 1451. There also may be an input/output bus 1475 that shuttles data to and from the various user input/output devices such as a microphone, a camera 59, a display 56, or other input/output devices. The user computing device 55 also may control communicating with the networks, such as communications network 60 in Fig. 1 , either through wireless or wired devices. Of course, this is just one embodiment of the user computing device 55 and the number and types of user computing devices 55 is limited only by the imagination.

[0033] The physical elements that make up an embodiment of a server, such as the smart payment server 65, are further illustrated in Fig. 3. In some embodiments, the smart payment server 65 is specially configured to run the smart payment service as described herein. At a high level, the smart payment server 65 may include a digital storage such as a magnetic disk, an optical disk, flash storage, non-volatile storage, etc. Structured data may be stored in the digital storage such as in a database. More specifically, the server 65 may have a processor 1500 that is physically configured according to computer executable instructions. In some embodiments, the processor 1500 can be specially designed or configured to optimize communication between a user computing device, such as computing device 55, and the server 65 relating to the payment selection service as described herein. The server 65 may also have a sound and video module 1505 which assists in displaying video and sound and may turn off when not in use to conserve power and battery life. The server 65 may also have volatile memory 1510 and non-volatile memory 1515.

[0034] A database 1525 for digitally storing structured data may be stored in the memory 1510 or 1515 or may be separate. The database 1525 may also be part of a cloud of servers and may be stored in a distributed manner across a plurality of servers. There also may be an input/output bus 1520 that shuttles data to and from the various user input devices such as a microphone, a camera, a display monitor or screen, etc. The input/output bus 1520 also may control communicating with the networks, such as communications network 60 and payment network 75, either through wireless or wired devices. In some embodiments, a smart payment controller for running the payment selection service through a smart payment application may be located on the user computing device 55. However, in other embodiments, the smart payment controller may be located on smart payment server 65, or both the computing device 55 and the server 65. Of course, this is just one embodiment of the smart payment server 65 and additional types of servers are contemplated herein.

[0035] In the embodiment illustrated in Fig. 1 , the smart payment server 65 may be connected to the merchant server 90 either through the digital communication network 60, through the payment network 75 or through other connections. In some embodiments, the merchant server 90 may be associated with any type of merchant offering goods or services for purchase with payment cards, whether those purchases are online or otherwise. For online purchases, the merchant server 90 or a group of servers may host a merchant website where the merchant’s goods or services may be purchased by a user. In some embodiments, the smart payment system may collect payment information from the user, such as payment card credentials, that may be used for the immediate transactions as well as for future purchases with the same or other merchants as further described herein. As such, the smart payment system may consolidate the entities to which a user shares its confidential payment information. Specifically, the user may share its payment card information with the smart payment system via software or other interface hosted by the system, and the smart payment system may store the payment and other account information for use in future purchases. In some embodiments, the smart payment system may also store information regarding rewards points, loyalty programs, or other benefits associated with the stored payment accounts. The smart payment system may also be in contact with other payment account issuers to receive up-to-date information regarding the details of associated account benefits. [0036] In some embodiments, the smart payment system may be hosted on or otherwise run by the smart payment server 65. In some embodiments, the smart payment system may be hosted by another entity, such as an issuer using an issuer server 85 or a merchant using a merchant server 90. In some embodiments, a user may access the smart payment server 65 via a computing device 55 such as a smartphone, and may set up an account with the smart payment system. The user may provide payment account or banking information for one or more payment accounts provided by one or more card issuers or associated with one or more merchants or banks. One or more of the payment accounts may be associated with any of a variety of benefit programs. The smart payment system may store such payment account information associated with the user’s account that can be retrieved at the user’s request to complete e-commerce transactions. Purchases using payment information stored with the smart payment system, however, may occur in any of a variety of ways. In some embodiments, the user may select a payment account or card stored through the smart payment system for use performing a given transaction. As described in more detail below, the smart payment system may determine which of a user’s payment accounts to use for a given transaction based on the benefits available.

[0037] The computing device 55, the POS device 69, and the smart billing machine 71 may be able to communicate with a computer server or a plurality servers, such as the smart payment server 65, the payment server 70, issuer servers 85, and merchant servers 90. The computing device 55 may be able to communicate in a variety of ways. In some embodiments, the communication may be wired such as through an Ethernet cable, a USB cable or RJ6 cable. In other embodiments, the communication may be wireless such as through Wi-Fi (802.11 standard), Bluetooth, cellular communication or near field communication devices. The communication may be direct to the server or may be through a digital communication network 60 such as cellular service, through the Internet, through a private network, through Bluetooth, etc. In some embodiments, the user computing device 55 may communicate with the POS device 69 and/or the smart billing machine 71 wirelessly using any of the wireless communication methods listed above.

[0038] In some embodiments, the smart payment server 65 may be associated with the smart payment system, and may send and receive information to and from a user computing device 55 associated with the user payment accounts of a user. Specifically, software may be included on the user computing device 55 allowing notifications to be received from the smart payment system via the digital communications network 60. In some embodiments, the software may be an application, such as a smart payment application, through which a user may complete transactions, such as banking, money transfer, merchant purchases, etc. In some embodiments, the software may be an add-on to a web browser included on the user computing device 55. In some embodiments, the smart payment system’s software may be an application installed on the user computing device 55 that allows for the use of other applications on the user computing device, such as applications provided by a bank, online merchant, email service, payment provider, etc. In yet other embodiments, the smart payment service may provide notifications using software native to the user computing device 55, such as SMS messaging or other notifications. In such embodiments, the smart payment system may send notifications to the user computing device 55 regarding smart payment selections, such as are described in further detail below.

[0039] Fig. 4 is a data flow diagram generally illustrating an embodiment of a smart payment system 100 that may determine which of a plurality of user payment accounts to use for each item in a transaction in order to maximize or otherwise optimize user benefits associated with the transaction. Although aspects of the smart payment system 100 as represented in the data flow diagram may generally indicate an application of the system for transactions taking place in physical retailers, it is contemplated that, in some embodiments, at least certain aspects of the system 100 may occur alternatively in an online retailer environment. Those aspects should be clear to those skilled in the art upon reviewing this disclosure. In some embodiments, a transaction may be initiated, at 102, when one or more purchase items are scanned at a checkout counter or otherwise registered by a smart billing machine 71 , such as in an electronic shopping cart, etc.. In some embodiments, the purchase items may be scanned using a barcode scanning, radio frequency identification (RFID), manual entry, or any other suitable method of registering an item for purchase. In some embodiments, the purchase items may be selected in an online retail space. In some embodiments, the smart billing machine 71 may be associated with a unique beacon identifier (beacon ID) that may be used to identify a particular smart billing machine. At 104, the smart billing machine 71 , or a component connected to the smart billing machine, may transmit the beacon ID to a user computing device 55. In some embodiments, the beacon ID may be transmitted over wire or wirelessly, using any suitable wireless transmission protocol; for example, Wi-Fi (802.11 standard), Bluetooth, cellular communication or near field communication (NFC), RFID, etc. In some embodiments, the smart billing machine 71 may broadcast an NFC or other wireless signal substantially continuously. In some embodiments, the smart billing machine 71 may begin broadcasting the beacon ID when purchase items are being scanned or otherwise registered by the smart billing machine.

[0040] The user computing device 55 may receive the beacon ID. More specifically, in some embodiments, a smart wallet application running on the user computing device 55 may receive the beacon ID and store it, at least temporarily, as the beacon ID associated with a current transaction for which the purchase items may be scanned. In some embodiments, upon receiving the beacon ID from the smart billing machine 71 , the user computing device 55, via the smart wallet application, may present the user with the option of proceeding with payment using the smart payment system or using a manual payment system. If the user selects payment using a manual payment system, the transaction may proceed by requesting, from the user, which payment account to use for the entire transaction or for each individual purchase item. If the user chooses to proceed using the smart payment system, however, the smart payment system may proceed as described herein. It is contemplated that, in some embodiments, the user computing device may not request a selection by the user before proceeding, or that a user may predetermine whether to be asked for a selection for subsequent transactions during setup of the system 100 or application enrollment.

[0041 ] At 106, the user computing device 55 may transmit, using the smart wallet application, the beacon ID and a user identifier (user ID) associated with the smart wallet application to a smart payment server 65. The user ID may be any type of identifying information associated with a particular user’s smart payment accounts, or information that may identify the particular user’s account. For example, a user may have a user ID associated with the smart wallet account, and one or more payment accounts associated with the smart wallet account that may be accessible using the smart payment application, via the user computing device 55 or otherwise. For each of the user’s payment accounts, the user may have previously provided the smart wallet application with any required user credentials (e.g., user ID and/or password) or provided permission to conduct transactions using those payment accounts through an access token system or other suitable methods known to those skilled in the art. In some embodiments, the user ID and the beacon ID may be transmitted to the smart payment server 65 over a digital communication network, such as the digital communication network 60 described with reference to Fig. 4. In some embodiments, at 108, the smart billing machine 71 may transmit the same beacon ID and purchase item information about the purchase items scanned for the transaction to the smart payment server 65 over the digital communication network.

[0042] Accordingly, the smart payment server 65 may receive, from the user computing device 55, a user ID for the user’s smart wallet account and the beacon ID of the smart billing machine 71 associated with a particular transaction. Likewise, the smart payment server 65 may receive, from the smart billing machine 71 , purchase item information reflecting the products or services being purchased in the transaction, and the same beacon ID of the smart billing machine that was received from the user computing device 55. Thus, based on the determination that the beacon ID received from the user computing device 55 matches the beacon ID received from the smart billing machine 71 , the smart payment server 65 may associate the received user ID and associated smart wallet account with the purchase item information provided by the smart billing machine.

[0043] In some embodiments, the smart payment server 65 may, at 110, transmit a request for benefit information to a payment server, such as the payment server 70 shown in Fig. 1. The request for benefit information may include may include requesting that the payment server 70 determine any benefits available to the user through any of the one or more payment accounts associated with the user’s smart wallet account or any benefits provided by the merchant or merchants, either generally or based on the particular item being purchased. For example, a user may have a first payment account and a second payment account associated with the user’s smart wallet account, and may additionally have a first merchant account and a second merchant account. The payment accounts may be credit card accounts, debit accounts, bank accounts, or any other suitable payment account. The merchant accounts may be loyalty or frequent buyer programs through a particular merchant retailer or brand. In some embodiments, the request for benefit information may additionally check with each underlying merchant for each purchase item to determine whether any benefits may be accrued to the user for any particular combination of payment account with a particular purchase item. For example, an issuer of the first payment account may be offering a benefit particularly for purchases of a particular brand, or a particular product brand may be offering a discount or rebate for purchases made using a particular type of payment or payment account. In another non-limiting example, an issuer of the first payment account may offer benefits based on a first category of purchases, and the second payment account may offer benefits based on a second category of purchases. It should be understood that the combinations of payment account benefits, merchant benefits, or brand benefits may be large in number. In some embodiments, the payment server 70 may be one in the same as the smart payment server 65, or the smart payment server may be included within the payment server.

[0044] In some embodiments, once the request for benefit information is received by the payment server 70, the payment server (or in some embodiments, the smart payment server 65 directly), may request and receive, at 112 and 114, benefit information from one or more issuer servers 85a, 85b via, in some embodiments, a payment network such as the payment network 75 referenced in Fig. 1. For example, a first issuer server 85a may be associated with a first payment account offering first payment account benefits and a second issuer server 85b may be associated with a second payment account offering second payment account benefits. At 116 and 118, the payment server 70 may similarly request and receive benefit information from one or more merchant servers 90a, 90b. For example, a first merchant server 90a may be associated with a first merchant and a second merchant server 90b may be associated with a second merchant. For example, the first merchant server 90a may provide benefits related to card-based merchant offers, and the second merchant server 90b may provide benefits relating to gifts or other prepared offers from the merchant or issuer. In some embodiments, the benefit information for each payment account or merchant may have been cached prior to the request. In such embodiments, the payment server 70 may respond to the request without retrieving additional benefit information. At 120, the payment server 70 may transmit the retrieved benefit information to the smart payment server in response to the request for benefit information. In some embodiments, the benefit information may be transmitted as a whole for the entire transaction, or in some embodiments, the payment server 70 may transmit the benefit information in multiple transmissions separated by issuer, merchant, purchase product, etc.

[0045] Once the benefit information is received from the payment server 70, the smart payment server 65 may determine the optimal combination of payment accounts or other purchasing offers (e.g., gift cards or merchant credit) for the user to maximize overall user benefits. In some embodiments, the optimal combination of benefits may be determined based on algorithms or other methods to maximize the user’s desired benefit. For example, in some embodiments, the smart payment system 100 may maximize the discounts, cash back, rebates, etc., that are available in order to save the user as much money as possible. In some embodiments, maximizing the overall benefit may include minimizing the cost of the particular transaction. In some embodiments, the overall benefit may be determined by comparing a benefit provided by a first payment account for a particular purchase item to a benefit provided by a second purchase account for the same purchase item, and repeating this process for each purchase item and for each payment account. Thus, in some embodiments, the payment account plan may be determined by individually assigning each purchase item to one of the one or more payment accounts based on which payment account may provide the best benefit. In some embodiments, however, it is contemplated that some payment accounts may offer bulk benefits for purchasing a minimum number of purchase items or if the sum of prices for a group of purchase items exceeds some minimum threshold price. In such embodiments, the overall benefit to a user may be greater by taking advantage of such bulk benefits even though the benefits for a particular one of the purchase items in the bulk purchase group may be higher for a different payment account. It is contemplated that the smart payment system 100 would take such scenarios into account when determining the payment account plan that will provide the maximum benefit to the user.

[0046] In some embodiments, the smart payment system 100 may provide users with options for how to optimize benefits. For example, a user may instruct the smart payment system 100 to save as much money as possible, as described above. Alternatively, the user may choose to maximize points for a particular payment account, for example frequent flyer miles or hotel chain points. Alternatively, the user may choose to find a balance between various types of benefits, providing a rank or weight to each benefit type or category. In such embodiments, the algorithm for determining an optimal payment account plan may differ. In some embodiments, a user may select the type or types of benefits to optimize using the smart wallet application run on the user’s user payment device 55, for example. In some embodiments, the user may provide which benefit(s) to optimize upon setting up the smart payment account. In some embodiments, the smart payment server 65 may determine multiple payment account plans that may optimize different benefits, and provide the user with an option to select which plan to use for a given transaction. In other embodiments, a user may select which benefits to optimize at the onset of a transaction, for example, when the user computing device 55 receives the beacon ID from the smart billing machine 71. [0047] Regardless of which benefits are to be optimized, the smart payment server 65 may determine a payment account plan based on the available benefits. The payment account plan may include which payment accounts or other resources (e.g., gift cards or merchant credit) to use for which particular purchase items in the transaction, or for which categories of purchase items. In some embodiments, the payment account plan may include dividing the purchase items into groups of transactions, or determining the sequence of transactions that may result in the optimum benefits. At 122, the smart payment server 65 may transmit the payment account plan to the user computing device 55. In some embodiments, at 124, the user computing device 55, via the smart wallet application in some embodiments, present the one or more payment accounts to the smart POS device 69 or the smart billing machine 71 in the order determined by the smart payment server 65 to complete the transaction. In some embodiments, at 126, the smart payment server 65 may also transmit the payment account plan to the smart billing machine 71. The smart billing machine 71 may organize the payment authorizations expected from the user computing device 55 based on the payment account plan. In some embodiments, the smart billing machine 71 may transmit the payment account plan to the smart POS device 69 to organize authorizations expected from the user computing device 55. Upon receiving the payment account plan, the smart POS device 69 may broadcasting NFC signals and prepare for accepting one or more payment account authorizations according to that plan. In some embodiments, it is contemplated that payment account plan may be transmitted to only one of the user computing device 55 or the smart billing machine 71 (or smart POS device 69). [0048] In some embodiments, the smart wallet application may generate a notification on the user computing device 55 to request purchase approval for the payment account plan determined by the smart payment server 65. In some embodiments, the smart wallet application may proceed with completing the transaction without further input from the user. In some embodiments, the user may predetermine whether the smart wallet application will request purchase approval or not prior to completing the purchase. In some embodiments, when the smart payment system 100 is used, a transaction may be made purchasing multiple products or services using multiple payments accounts that optimizes user benefits through a single input or selection by the user through the user computing device 55. In some embodiments, the smart wallet application may provide a notification on the user computing device 55 once the transaction is complete. The notification may provide the details of which payment accounts were used to purchase each purchase item, and a summary of the benefits that were accrued based on the transaction.

[0049] Fig. 5 illustrates an embodiment of a signal flow diagram 200 for using the smart payment system. At 202, the smart billing machine 71 may receive one or more purchase items, which may be products or services, or other transaction items. At 204, the smart billing machine 71 may transmit a beacon ID particular to the smart billing machine and purchase item information for the purchase items (received at 202) to the smart payment server 65. At 206, the smart payment server may receive the beacon ID and the purchase item information. At 208, the smart billing machine 71 may also transmit the beacon ID to the user computing device 55, which may receive the beacon ID at 210. At 212, the user computing device 55 may transmit the beacon ID and a user ID associated with a user’s smart wallet account to the smart payment server 65, which may receive them at 214. The smart payment server 65 may match the beacon ID received from the smart billing machine 71 and the beacon ID received from the user computing device 55. Based on the matching beacon IDs, at 216, the smart payment server may determine the payment account issuers or providers and/or merchants included in the transaction based on the payment accounts or merchant accounts associated with the smart wallet account matching the provided user ID and/or the merchant, brands, or retailers included in the purchase item information. In some embodiments, at 218, the smart payment server 65 may transmit a request for benefit information for the one or more payment accounts or merchants identified in 216 to the payment server 70, which may receive the request at 220. At 222, the payment server 70 may transmit a request for benefit information from one or more issuer servers 85a, 85b associated with one or more payment accounts included in the user’s smart wallet account and one or more merchant servers 85a, 85b associated with the smart wallet account or with the particular transaction information. Each issuer server 85a, 85b may receive the request for benefit information at 228 and transmit the benefit information associated with the particular issuer payment account back to the payment server 70 at 230. Likewise, each merchant server 90a, 90b may receive the request for benefit information at 224 and transmit the benefit information associated with the particular merchant back to the payment server 70 at 226. The payment server 70 may receive the benefit information from the one or more issuer servers 85a, 85b and the one or more merchant servers 85a 85b at 232. At 234, the payment server 70 may transmit the received benefit information, either one at a time or all at once, to the smart payment server 65, which may receive the benefit information at 236.

[0050] At 238, the smart payment server 65 may process the benefit information based on one or more benefit optimization algorithms to determine a payment account plan that may provide the maximum benefit to the user. As described above, the maximum benefit may be providing the user with as much money as possible, or may include maximizing other benefits such as loyalty points, frequent flyer miles, cash back, rebates, coupon offerings, etc. Once the payment plan has been determined, the smart payment server may transmit the payment account plan to the user computing device 55 at 240, and the user computing device may receive the payment account plan at 242. In some embodiments, the smart payment server 65 may also transmit the payment account plan to the smart billing machine 71 to prepare to receive the particular order of authorizations detailed in the payment account plan. At 244, the user computing device 55 may present the payment accounts from the payment account plan to the smart billing machine 71 or an associated smart POS device. In some embodiments, the user computing device may present the payment account authorizations all at once to the smart billing machine 71 , or may present each payment account authorization one by one, moving on to subsequent payment account authorizations once the previous authorization has been accepted by the smart billing machine. At 246, the smart billing machine 71 may process the payment provided through the one or more accounts associated with the user’s smart wallet account. In some embodiments, the smart wallet application may request approval from the user to complete the transaction according to the account payment plan prior to executing the one or more authorizations. In other embodiments, the smart wallet application may execute the planned authorizations and transactions automatically.

[0051 ] Figs. 6A and 6B illustrate example embodiments of a graphical user interface (GUI) 300 that may be provided on a user computing device 55 through an embodiment of the smart payment application. In some embodiments, as shown in 6A, the GUI 300 may include an alert banner 302 notifying the user that a beacon ID from a smart billing machine, such as smart billing machine 71 , has been received and detected by the user computing device 55. The GUI 300 may also include an inquiry banner 304, and response buttons 306, 308. The inquiry banner 304 may ask the user whether the user would like to use the smart payment system or manual payment selection for the current transaction. If the user selects the manual payment selection response button 308, the smart payment application may provide options for the user to select which payment account or accounts included in the user’s smart payment account to use for the transaction. If the user selects the smart payment system response button 306, the smart payment application may proceed to execute the smart payment system as described with reference to Figs. 4 and 5, for example. In some embodiments, as shown in Fig. 6B, the GUI 300 may show a smart payment transaction summary 310. The smart payment transaction summary 310 may include an account summary 312 and a benefits summary 314. The account summary 312 may show the breakdown of how the smart payment system divided the purchase items amongst the user’s payment accounts. For example, in Fig. 6A, the smart payment system used Account A to purchase Items 1 -3, Account B to purchase Items 4-6, Account C to purchase Items 7-9, and Account D to purchase Items 10-12 because the system may have determined that such a distribution was optimal for the transaction. One of skill in the art would understand that, in other embodiments, any combination of payment accounts may be determined to be optimal for a particular transaction and the distribution in Fig. 6B is merely illustrative. The benefits summary 314 may include a summary of the benefits earned by each account based on the current transaction, and the total benefit received as a result of the particular account distribution. In the example shown, Account A earned $5, Account B earned $3, Account C earned $4, and Account D earned $5, for a total benefit of $17. One skilled in the art would recognize that the benefits may be quantified differently or be distributed in any number of ways. For example, the user may prefer or the smart payment application may default to quantifying benefits in terms of loyalty points or some other denomination of benefits. In some embodiments, the benefits awarded through a first payment account program and a second payment account program may not be directly comparable. In such embodiments, the user may include pre-determ ined weighting to compare the benefits from each payment account or merchant account. For example, one type of payment account may offer benefits as cash back, while another type of payment account may offer loyalty points or frequent flyer miles, for instance. In some embodiments, the user may determine and select how to weigh the cash back versus the loyalty points depending on the payment account. In some embodiments, the smart payment application may include a default weighting in order to compare benefits for payment accounts including different benefit denominations.

[0052] Fig. 7 is a flow chart of an embodiment of a method of using the smart payment system. At 402, a server, such as smart payment server 65 or payment server 70, may receive a user ID from a user computing device such as user computing device 55. In some embodiments, the user computing device 55 may be running a smart payment application that transmits the user ID. The user ID may be associated with a smart payment account of a user, and the user may select one or more payment accounts for association with the smart payment account. Payment account information may be received for the one or more payment accounts of the user. In some embodiments, the payment accounts may be tokenized for use by the smart payment system. At 404, the smart payment server 65 may store the user ID and payment account information in a database, such as database 1525 referred to in Fig. 3, so as to associate the user ID and the one or more payment accounts with one another.

[0053] At 406, the smart payment server may receive a beacon ID and user ID from a user computing device. The beacon ID may be associated with a smart billing machine, such as smart billing machine 71. In some embodiments, the beacon ID may have been transmitted (wirelessly or otherwise) by the smart billing machine 71 (e.g., via an associated smart POS device 69), received by the user computing device 55, and then transmitted from the user computing device to the smart payment server 65 via a digital communication network. At 408, the smart payment server 65 may receive a beacon ID and purchase item information from a smart billing machine 71. The purchase item information may be information related to items being purchased in a transaction that have been scanned or otherwise entered into the smart billing machine

71 , such as at a retailer. The beacon ID may be associated with the smart billing machine 71. At 410, the smart payment server 65 may determine whether the beacon ID received at 406 from the user computing device matches the beacon ID received at 408 from the smart billing machine 71. If both beacon IDs match, the smart payment server 65 may determine that the purchase item information received from smart billing machine 71 is associated with purchase items in a transaction being initiated by the user associated with the received user ID and payment accounts. Accordingly, at 412, the smart payment server 65 may identify the one or more payment accounts associated with the received user ID and, in some embodiments, the merchant or brands associated with the purchase items. For example, the smart payment server 65 may identify that one or more of the purchase items are being sold by a first merchant, or that the type of product being purchased is branded or otherwise sold by a second merchant.

[0054] Once the payment accounts and/or merchants have been identified, the payment server may, at 414, transmit one or more requests for benefit information associated with the identified payment accounts or merchants. In some embodiments, the user’s smart payment account may include a first payment account associated with a first issuer having a first issuer server, and a second payment account associated with a second issuer server. In such embodiments, the smart payment server 65 may transmit a request for benefit information related to the first payment account to the first issuer server, and transmit a request for benefit information related to the second payment account to the second issuer server. Of course, those skilled in the art would understand that fewer or more payment accounts with associated issuer servers may be used in other embodiments. In some embodiments, the payment account may include loyalty or other merchant accounts for the merchant at which the transaction may be being made. In such embodiments, the smart payment server may transmit a request for benefits associated with the merchant account. In some embodiments, the user payment account may include a gift card or other such merchandise credit for the particular merchant with which the transaction is taking place. In such embodiments, the smart payment server may transmit a benefit request to the merchant server or another server that may store data related to gift card or other merchandise credit accounts. It should be understood that, in some embodiments, a payment server such as payment server 70 may transmit requests to each issuer or merchant server at the request of the smart payment server, but the smart payment server may transmit the benefit information requests itself in other embodiments.

[0055] At 416, the smart payment server may receive the requested benefit information from the issuer servers, merchant servers, or other requested locations. At 418, the smart payment server 65 may analyze the benefit information related to each of the payment accounts and in view of the purchase items and other merchant benefit available to determine a payment account plan for the particular transaction that may optimize the benefit to the user. For example, in some embodiments, a first payment account may include the highest overall cash-back benefit of all the available payment accounts, but a second payment account may include a relatively higher cash-back benefit for a first particular purchase item. Further, a second particular purchase item may be eligible for a rebate through the merchant or manufacturer if a merchant account is used. In such a scenario, in some embodiments, the smart payment server 65 may determine the payment account plan for such an exemplary transaction to include using the second payment account to purchase the first particular purchase item, the merchant account to purchase the second particular purchase item, and the first payment account to purchase any remaining purchase items. It should be understood, however, that in other embodiments, many other combinations of payment accounts and purchase items may result in a more beneficial payment account plan.

[0056] At 420, the smart payment server may transmit the payment account plan to the user computing device 55, and may transmit the payment account plan to the smart billing machine 71 at 422. In some embodiments, the user computing device 55, through the smart payment application, may communicate with the smart billing machine 71 , or a smart POS device 69 associated with the smart billing machine, to execute the transaction according to the payment account plan, thus automatically optimizing the benefits to the user through the smart payment system.

[0057] In some embodiments, the smart payment server 65 determine payment account plans based on benefit information that has been received by the smart payment server prior to any particular transaction. The smart payment server 65 may then pre-determ ine a hierarchy of payment accounts to be used for the purchases of products or services in one or more product categories. Figure 8 is a flow chart of one such embodiment of a method 500 of using the smart payment system. At 502, a server such as the smart payment server 65 or payment server 70 may receive and store a user ID and payment account info in a similar manner as described above with reference to method 400 shown in Figure 7. At 504, the smart payment server 65 may identify one or more payment accounts received by the user and associated with the user ID received from, for example, a user computing device. The one or more payment accounts may be associated with one or more issuers, merchants, or other entities. At 506, the smart payment server may transmit a request for benefit information to the one or more issues, merchants, or other entities associated with the one or more payment accounts, and receive the benefit information in return. As described elsewhere herein, it should be understood that different embodiments may involve different numbers of issuers and merchants, which may include different combinations of benefits. In some embodiments, requesting and/or receiving updated benefit information may occur periodically so that the smart payment server 65 may include updated benefit information. In other embodiments, the individual issuers and/or merchants may push updated benefit information to the smart payment server 65 when the updates occur or on a periodic basis. At 508, the smart payment server 65 may determine product categories for each of the one or more payment accounts based on the benefit information associated with each payment account. For example, a first payment account may provide 5% cash back for all purchases in a first category, (e.g., gasoline purchases), while a second payment account may offer 7% cash back for purchases in a second category (e.g., grocery purchases). A third payment account may offer 3% cash back on all purchases regardless of category.

[0058] At 510, the smart payment server 65 may receive a beacon ID and user ID from a user computing device 55 in a similar manner as received at 406 in Figure 7. The beacon ID may be associated with a smart billing machine 71 , and may have been previously transmitted to the user computing device 55 during, for example, a checkout process in a store. At 512, the smart payment server 65 may also receive a beacon ID and purchase item information from a smart billing machine 71 that has received the purchase item information during a scanning of products to be purchased by a user in a transaction. At 514, the smart payment server 65 may determine whether the beacon ID received at 510 from the user computing device matches the beacon ID received at 512 from the smart billing machine 71. If both beacon IDs match, the smart payment server 65 may determine that the purchase item information received from smart billing machine 71 is associated with purchase items in a transaction being initiated by the user associated with the received user ID and payment accounts. Accordingly, in some embodiments, the smart payment server 65 may identify the one or more payment accounts associated with the received user ID.

[0059] At 516, the smart payment server 65 may identify one or more product categories for the purchase items. In some embodiments, the product categories may be included within the purchase item information received from the smart billing machine 71. In some embodiments, the product categories may be stored in a database accessible to the smart payment server 65. In some embodiments, one or more purchase items may not fall within any particular product category and may be categorized as“unknown” or“miscellaneous,” for example. At 518, the smart payment server 65 may determine whether a particular purchase item falls within a first product category, for example, a gasoline purchase. If yes, the smart payment server 65 may proceed with the purchase of the that purchase item using the first payment account, at 520, based on the predetermination that gasoline purchases (first product category) should be assigned to the first payment account to achieve optimal benefits. It should be understood that proceeding with the purchase of the particular purchase item using the first payment account may mean that the smart payment server 65 assigns the first payment account to the particular purchase item in a payment account plan, such as that referred to and described at 418 of Figure 7. If the purchase item is not included in the first product category, then the smart payment server 65 may, at 522, determine whether a particular purchase item falls within a second product category, for example a grocery purchase. If yes, the smart payment server 65 may proceed to associate the purchase item with the second payment account in the payment account plan based on the previous determination that using the second payment account for grocery purchases may result in optimal benefits. If the purchase item does not fall within the second product category, at 526, the smart payment server may assign the purchase item to be purchased using the third payment account, for example, because of the predetermination that the third payment account is optimal for purchase items that do not fall within the first or second product categories. The steps of identifying whether a particular purchase item falls within a particular product category may repeat for as many purchase items in a particular transaction, such that each purchase item may be categorized into a product category or deemed to have an unknown product category. Additionally, one skilled in the art will recognize that any number of product categories and any number of associated payment accounts may be included in method 500. Once all of the purchase items for a transaction have been categorized and assigned to a payment account and into a payment account plan for the transaction, in some embodiments, the smart payment server 65 may transmit the payment account plan to one or both of the user computing device 55 and the smart billing machine 71 for completion of the transaction.

[0060] Fig. 9 shows an embodiment of a transaction data flow 600 that may be implemented in the smart payment system 100, particularly in embodiments of the system that may provide options for a“single tap” for multiple transactions. In other words, in some embodiments, a user may initiate the smart payment system using the smart payment application running on the user computing device 55 merely by making a selection to use the smart payment system to complete a purchase (e.g., by selecting smart payment system 306 in the user interface shown in Fig. 6A). The single selection to use the smart payment system may, in some embodiments, result in multiple transactions using multiple payment accounts for different purchase items. Referring to Fig. 9, an example data flow 600 between a smart billing machine 71 and a user computing device 55 is shown. At 602, the smart billing machine 71 may conduct preprocessing prior to enabling a contactless interface between the smart billing machine and a user computing device. In some embodiments, contactless interfacing may be enable at this point. At 604, discovery processing occur, and the user computing device 55 may be presented for payment at 605. In some embodiments, presentment for payment may include the user computing device 55 moving within NFC or Bluetooth range of the smart billing machine 71 (or associated smart POS device 69).

[0061 ] At 606 the smart billing machine 71 or smart POS device 69 may undergo an application selection process that may include selecting a proximity payment system environment (PPSE) command at 608. At 610, the user computing device 55 may accept an application from the smart billing machine 71 , for example, the application “2PAY.SYS.DDF01 ,” but other applications may be used in other embodiments. The user computing device 55 may response back with file control information (FCI) data that includes a list of application identifications (AIDS) for each payment account included in the smart wallet account for the particular user initiating the transaction. The smart billing machine 71 or smart POS device 69 may accept the list of AIDS for each payment account and may select one AID for each payment account and, at 612, confirm the selection back to the user computing device 55. The user computing device 55 may then respond back to the smart billing machine 71 with an FCI template including multi/single processing options data object list (PDOL) information and status successful (e.g., SW1 SW2 =‘9000’). In some embodiments, if there is an issue with the FCI, the data status may be different and the smart billing machine 71 or smart POS device 69 may repeat the process with a different AID.

[0062] At 614, the smart billing machine 71 or smart POS device 69 may proceed with initiating application processing, and may, at 616, respond back to the user computing device 55 with GET processing options (GPO) commands including a command template for each payment account The user computing device 55 may, at 618, process data element in the GPO command and respond back to the smart billing machine 71 or smart POS device 69 with personalization data for each payment account. In some embodiments, this may include determining path, performing account action analysis, performing any cryptography (e.g., tokenization), and returning application data. At 620, the smart billing machine 71 or smart POS device 69 may read the application data and respond back to the user computing device 55 with read record command at 622. The user computing device 55 may then, at 624, respond back to the smart billing machine 71 or smart POS device 69 by providing application records and/or additional data (e.g., Track2 data, etc.) for each payment account. At 625, the user computing device 55 may be removed from NFC or RFID range, and the account read may be complete at 626. At 628, processing restrictions may be implemented. [0063] The various participants and elements described herein may operate one or more computer apparatuses to facilitate the functions described herein. Any of the elements in the above-described Figures, including any servers, user terminals, or databases, may use any suitable number of subsystems to facilitate the functions described herein.

[0064] Any of the software components or functions described in this application, may be implemented as software code or computer readable instructions that may be executed by at least one processor using any suitable computer language such as, for example, Java, C++ or Perl using, for example, conventional or object-oriented techniques. In some examples, the at least one processor may be specifically programmed.

[0065] The software code may be stored as a series of instructions, or commands on a non-transitory computer readable medium, such as a random access memory (RAM), a read only memory (ROM), a magnetic medium such as a hard-drive or a floppy disk, or an optical medium such as a CD-ROM. Any such computer readable medium may reside on or within a single computational apparatus, and may be present on or within different computational apparatuses within a system or network.

[0066] It may be understood that the present invention as described above can be implemented in the form of control logic using computer software in a modular or integrated manner. Based on the disclosure and teachings provided herein, a person of ordinary skill in the art may know and appreciate other ways and/or methods to implement the present invention using hardware and a combination of hardware and software. [0067] The above description is illustrative and is not restrictive. Many variations of the invention will become apparent to those skilled in the art upon review of the disclosure. The scope of the invention should, therefore, be determined not with reference to the above description, but instead should be determined with reference to the pending claims along with their full scope or equivalents.

[0068] One or more features from any embodiment may be combined with one or more features of any other embodiment without departing from the scope of the invention. A recitation of “a”,“an” or“the” is intended to mean“one or more” unless specifically indicated to the contrary.

[0069] One or more of the elements of the present system may be claimed as means for accomplishing a particular function. Where such means-plus-function elements are used to describe certain elements of a claimed system it will be understood by those of ordinary skill in the art having the present specification, figures and claims before them, that the corresponding structure is a general purpose computer, processor, or microprocessor (as the case may be) programmed (or physically configured) to perform the particularly recited function using functionality found in any general purpose computer without special programming and/or by implementing one or more algorithms to achieve the recited functionality. As would be understood by those of ordinary skill in the art that algorithm may be expressed within this disclosure as a mathematical formula, a flow chart, a narrative, and/or in any other manner that provides sufficient structure for those of ordinary skill in the art to implement the recited process and its equivalents. [0070] While the present disclosure may be embodied in many different forms, the drawings and discussion are presented with the understanding that the present disclosure is an exemplification of the principles of one or more inventions and is not intended to limit any one of the inventions to the embodiments illustrated.

[0071 ] The present disclosure provides a solution to the long-felt need described above. In particular, the system and the methods described herein may be configured to efficiently provide substantially real-time or automatically approvable payment selection to maximize the benefits for a user. Further advantages and modifications of the above described system and method will readily occur to those skilled in the art. The disclosure, in its broader aspects, is therefore not limited to the specific details, representative system and methods, and illustrative examples shown and described above. Various modifications and variations can be made to the above specification without departing from the scope or spirit of the present disclosure, and it is intended that the present disclosure covers all such modifications and variations provided they come within the scope of the following claims and their equivalents.

Claims

CLAIMS:

1. A processor-implemented method for payment selection, the method comprising:

receiving, from a user computing device via a digital communication network: a user identifier associated with a user, and

payment account information associated with a plurality of user payment accounts associated with the user;

receiving, from the user computing device via the digital communication network, the user identifier and a beacon identifier associated with a smart billing machine;

receiving, from the smart billing machine via the digital communication network, the beacon identifier associated with the smart billing machine and purchase item information associated with one or more purchase items in a transaction;

based on receiving the beacon identifier from both the user computing device and the smart billing machine, identifying, via one or more processors, the plurality of user payment accounts associated with the user;

determining benefit information associated with each of the plurality of user payment accounts associated with the user;

based on the benefit information, determining, via the one or more processors, a payment account plan that includes assigning each of the one or more purchase items to one of the plurality of user payment accounts; and

transmitting, via the digital communication network, the payment account plan to the user computing device so as to enable the user computing device to complete the transaction based on the payment account plan.

2. The method of claim 1 , wherein the transaction is completed based on the payment account plan with no additional user interaction.

3. The method of claim 1 , wherein the payment account plan is determined by maximizing an overall benefit for the user.

4. The method of claim 3, wherein maximizing the overall benefit to the user includes minimizing a cost of the transaction.

5. The method of claims 3, wherein maximizing the overall benefit to the user includes maximizing a cash back award for the transaction.

6. The method of claim 1 , wherein the plurality of user payment accounts include a first user payment account and a second user payment account, and further comprising comparing, for each of the one or more purchase items, a first benefit provided by purchasing one of the one or more purchase items with the first user payment account, and a second benefit provided by purchasing the same one of the one or more purchase items with the second user payment account.

7. The method of claim 6 further comprising assigning the one of the one or more purchase items to the first user payment account when the first benefit is greater than the second benefit.

8. The method of claim 1 , wherein determining benefit information includes transmitting, via the digital communication network, a request for benefit information to an issuer server associated with each of the plurality of user payment accounts, and receiving, via the digital communication network, responsive benefit information from each of the issuer servers.

9. The method of claim 1 , wherein the plurality of user payment accounts includes a first user payment account and a second user payment account, and wherein the purchase item information includes at least a first purchase item and a second purchase item, and wherein determining the payment account plan includes:

comparing a benefit provided by purchasing the first purchase item with the first user payment account with a benefit provided by purchasing the first purchase item with the second user payment account; and

comparing a benefit provided by purchasing the second purchase item with the first user payment account with the benefit provided by purchasing the second purchase item with the second user payment account.

10. The method of claim 9 further comprising assigning the first purchase item to the first user payment account when the benefit provided by purchasing the first purchase item with the first user payment account is greater than the benefit provided by purchasing the first purchase item with the second user payment account.

11. The method of claim 1 further comprising transmitting, via the digital communication network, the payment account plan to the smart billing machine so as to enable the smart billing machine to complete the transaction based on the payment account plan.

12. A processor-implemented method for payment selection, the method comprising:

payment account information associated with a plurality of user payment accounts associated with the user, the plurality of user payment accounts including a first user payment account and a second user payment account;

receiving, from the smart billing machine via the digital communication network, the beacon identifier associated with the smart billing machine and purchase item information associated with one or more purchase items in a transaction, the one or more purchase items including a first purchase item and a second purchase item;

determining, via the one or more processors, that a benefit associated with purchasing the first purchase item with the first user payment account is greater than a benefit associated with purchasing the first purchased item with the second user payment account; determining, via the one or more processors, that a benefit associated with purchasing the second purchase item with the second user payment account is greater than a benefit associated with purchasing the second purchase item with the first user payment account;

determining, via the one or more processors, a payment account plan that includes assigning each the first purchase item to the first user payment account and the second purchase item to the second user payment account; and

13. The method of claim 12, wherein the transaction is completed based on the payment account plan with no additional user interaction.

14. The method of claim 12, wherein the payment account plan is determined by maximizing an overall benefit for the user.

15. The method of claim 14, wherein maximizing the overall benefit to the user includes minimizing a cost of the transaction.

16. The method of claims 14, wherein maximizing the overall benefit to the user includes maximizing a cash back award for the transaction.

17. A processor-implemented method for payment selection, the method comprising:

based on the benefit information, assigning, via the one or more processors, a first product category to a first user payment account of the plurality of user payment accounts and a second product category to a second user payment account of the plurality of user payment accounts;

in response at least to receiving the beacon identifier from both the user computing device and the smart billing machine, determining, via one or more processors, that a first purchase item of the one or more purchase items belongs to the first product category and that a second purchase item of the one or more purchase items belongs to the second product category;

determining, via the one or more processors, a payment account plan that includes assigning the first purchase item to the first user payment account and the second purchase item to the second user payment account; and transmitting, via the digital communication network, the payment account plan to the user computing device so as to enable the user computing device to complete the transaction based on the payment account plan.

18. The method of claim 17 further comprising assigning a third purchase item of the one or more purchase items based on a determination that the third purchase item does not belong to the first product category or the second product category.

19. The method of claim 17, wherein the first product category is assigned to the first user payment account based on a determination that the first user payment account provides a greater benefit related to purchase items in the first product category than any other of the plurality of user payment accounts.

20. The method of claims 19, wherein the first product category is assigned to the first user payment account based on a determination that the first user payment account provides a lower cost for purchase items in the first product category than any other of the plurality of user payment accounts.