Patent Application
20150134438
Aspects of the present disclosure relate in general to processing data related to card transactions, and more particularly to fast, accurate estimation rewards earned from card transactions.
Rewards programs have become popular and prevalent in a variety of contexts in the marketplace. Rewards programs, also known by various other names such as incentive programs, loyalty programs, or points programs, are designed to encourage repetitive consumption, buying, or usage behavior. Recently, rewards programs pertaining to payment cards have proliferated. Numerous card issuers offer a variety of card products that enable people to earn and accumulate rewards based on the usage of cards. This type of reward program is especially attractive to many people because of the widespread use of payment cards in society.
Card rewards programs exist in various forms. For example, some cards provide cash back with each transaction (typically as a percentage of the amount of the transaction, e.g., 1% cash back), others provide points that can used to acquire various goods or services (e.g., 1 point for every dollar charged to a credit card), and others provide goods or services directly (e.g., a discrete good or service whenever a card is used for a transaction exceeding a fixed amount). Some card rewards programs provide rewards that are dependent on the type of transaction (e.g., 1 point for each dollar charged at any gas station, 2 points for each dollar charged at any supermarket, 3 points for each dollar charged at a particular merchant, etc.). Regardless of the form in which rewards are characterized (e.g., as cash, points, discrete goods/services, or any other form), cardholders typically can learn the status and extent of their rewards through periodic statements (e.g., monthly statements), online portals (e.g., web portals), or telephone inquiries to an appropriate entities.
But with traditional technologies there is considerable delay associated with updating and reporting the rewards earned for a particular card transaction. For example, a cardholder who uses a rewards card for a transaction and desires to know how many points she earned is typically forced to wait at least several days (and often a week or more). Such a delay is frustrating for cardholders and may inhibit widespread participation in such rewards programs.
In some embodiments of the present disclosure, an indication is received of a transaction between a cardholder and a merchant, wherein a card is used by the cardholder for the transaction, and the card is an instance of one of a plurality of card products available from respective ones of a plurality of card issuers. From a computer database that has stored therein a set of one or more reward parameters associated with each card product, a selected set of reward parameters associated with said one card product is retrieved. An amount and a merchant identifier are determined for the transaction. At one or more computer processors, an estimate of rewards earned due to the transaction is generated, wherein the estimate is generated prior to a clearance of the card transaction and is based on at least the amount and the retrieved set of reward parameters.
In some embodiments, transaction data is received regarding a transaction, between a cardholder and a merchant, attempted by the cardholder using a card. From the transaction data, at least an amount of the transaction, a card identifier identifying the card, and a merchant identifier identifying the merchant are determined. At one or more computer processors, the card is matched to one of a plurality of sets of one or more reward parameters stored at a computer database, each set of stored reward parameters associated with a different card product among a plurality of card products. The matching may be based on the card identifier. At the one or more computer processors, an estimate of rewards earned by the cardholder due to the transaction is generated, wherein the estimate is generated on the same day as the use of the card by the cardholder based on the transaction data and the reward parameters matched to the card.
In some embodiments, a system comprises at least one computer processor, a computer database, and a non-transitory computer-readable storage medium having instructions stored tangibly thereon. Multiple sets of one or more reward parameters are stored in the database. The sets of reward parameters are associated with respective card products among a plurality of card products available from one or more card issuers. The instructions stored on the computer-readable storage medium, when executed by the computer processor(s), cause the computer processor(s) to receive an indication of a transaction between a cardholder and a merchant, wherein a card is used by the cardholder for the transaction, and the card is an instance of one card product in the plurality of card products. An amount and a merchant identifier for the transaction are determined. The set of reward parameters associated with said one card product is retrieved from the database. The computer processor(s) generate an estimate of rewards earned due to the transaction, wherein the estimate is generated prior to clearance of the transaction and is based on at least the amount and the set of reward parameters associated with said one card product retrieved from the database.
The following will be apparent from elements of the figures, which are provided for illustrative purposes and are not necessarily to scale.
This description of the exemplary embodiments is intended to be read in connection with the accompanying drawings, which are to be considered part of the entire written description.
Various embodiments of the present disclosure address the foregoing drawbacks of traditional processing for card rewards programs, namely, the delay associated with reporting rewards accrued for transactions and the resulting frustration experienced by cardholders.
When a credit card is presented as payment to a merchant for a purchase, various processing occurs among a number of entities.
After several days, the purchase is cleared (block 140). As one skilled in the art will appreciate, to clear the transaction, the merchant bank sends the batch of transactions corresponding to a single day to a card processing network, which routes respective transactions to the relevant issuer. The issuer sends the funds to the card network, which then routes the funds to the merchant bank. The merchant then receives the funds from the merchant bank, minus certain fees. The clearance process takes several days (typically three to five days). Then, the transaction is posted (block 150), and the accrued rewards associated with transaction are posted on the cardholder's statement (block 160), which is typically provided to the cardholder electronically (e.g., via a web portal or a software application connected to the Internet), by telephone, or by traditional mail. Thus, with existing processing methodology, the rewards accruing to the cardholder as a result of the transaction are only available for viewing by the cardholder a relatively long time (e.g., more than one week) after the purchase.
The merchant may be any type of person or entity that accepts a card as a valid form of payment for good(s)/service(s). The card may be presented to the merchant in any manner. For example, the card may be presented (e.g., swiped) at a card reader, card data may be entered (e.g., manually) via a terminal, an image of the card may be processed, an electronic component on the card may be scanned or may transmit a signal representing card data, or any other technique may be used to provide to the merchant the card data (e.g., card number, expiration date, and/or card verification value, and/or other card parameters).
After the purchase is authorized (block 120), an estimate of the rewards accrued due to the transaction is generated (block 230). The estimated rewards are presented to the cardholder (block 240), e.g., posted on the cardholder's electronic statement (for viewing at a web portal or with a software application connected to the Internet, for example). The estimated rewards accrued due to the transaction could also be made available by telephone (e.g., so that the cardholder may call a human operator or an automated agent to obtain the rewards estimate shortly after the transaction is complete), or by any other method of delivering information in real time. Blocks 230 and 240 may occur in real-time, thus making the estimated rewards available to the cardholder without the lengthy delays associated with batching and clearance.
A database of card profiles 370 includes information regarding one or more card products that issuer 350 makes available. For example, issuer 350 (or any other issuer) may issue cards corresponding to various card products. Each card (e.g., physical or virtual card) that is issued to a user is an instance of a particular card product. A user may have a first card that is an instance of a first card product and a second card that is an instance of a second card product from the same or different issuer as the first card. The two card products may provide different parameters by which the user may earn rewards for each purchase made with each card. A set of one or more rewards parameters associated with each card product is stored in database 370. The set of one or more rewards parameters associated with a particular card product is also associated with any card that is an instance of that card product. Based on the specified data 360 (e.g., based on the card identifier that identifies the card used in the present transaction), one of the stored sets of reward parameters (i.e., one of the card profiles) is retrieved from database 370 (block 380). The reward parameters for the matching card profile are used to generate the estimate of the rewards accrued due to the transaction (block 230). The estimate is generated prior to clearance of the card transaction and is based on at least the amount of the transaction and the retrieved set of reward parameters. The estimated rewards are presented to the cardholder (block 240). The estimated rewards may be an estimate of any type of rewards, e.g., points, miles, cash back or a discount to be redeemable for the present transaction or future transaction(s), or any other type of reward or incentive.
In some embodiments, the rewards estimate is further based on the merchant identifier, and at least one of the reward parameters in the retrieved set of reward parameters is dependent on the identity of the merchant. For example, issuer 350 may have a card product that yields 1 point per dollar spent at any merchant, plus a one-time additional 1000 points when the cardholder first uses her card at a given merchant. This rule can be stored in database 370 in the form of suitable reward parameters, and the merchant identifier can be used to determine that the present transaction is a transaction corresponding to that given merchant, and the rewards estimate is generated accordingly.
In some embodiments, a merchant category code (MCC) for the present transaction is also determined when the transaction is registered. The MCC is a classification code that classifies merchants based on the types of goods/services they provide. The MCC may have the format of a four digit code. The merchant identifier may be used to look-up the MCC, e.g., with a table mapping merchant identifiers to MCCs. At least one of the reward parameters in the retrieved set of reward parameters may be dependent on the merchant category code. For example, a particular card may yield an additional 1000 points for any transaction made at any drug store or pharmacy, corresponding to the merchant category code “5912”. This rule can be stored in at least one database 370 in the form of suitable reward parameters, and the estimate can be generated based on the rule.
Because database 370 aggregates data regarding various card products of various issuers, cardholders can seamlessly receive real-time rewards estimates regardless of which card is used. Whereas one issuer does not know the activities of a cardholder regarding a card issued by another issuer, embodiments of the present disclosure register the transaction and determine specified data regarding the transaction based on information that is available to the card network 340 and therefore not confined to the knowledge or awareness of any single issuer.
In some embodiments, the database 370 can be updated with a new set of one or more reward parameters for at least one card product responsive to a change in a reward policy by a corresponding card issuer. For example, an issuer may change the amount of points awarded per dollar spent with a particular card, and that change in the card profile can be recorded at database 370. Database 370 may be updated and/or maintained in various ways. For example, database 370 may be maintained by card network 340, which may poll one or more issuers (e.g., periodically, such as monthly, or aperiodically) for any updates to the rewards policies for any card products available from the issuers. Alternatively, one or more databases 370 may be maintained and/or updated by one or more issuers. For example, each issuer may maintain its own database 370 containing rewards parameters for its card products, and information from the database can be outputted to enable rewards estimates to be computed. As another option, database 370 may be maintained by card network 340 and may be updated based on electronic messages received from cardholders. With this approach, which may be referred to as crowd sourcing, individual cardholders may provide notifications (e.g., at a web portal or via a software application) regarding changes in the rewards programs for their rewards cards. One of ordinary skill in the art will appreciate that any combination of these maintenance/updating techniques, or additional maintenance/updating techniques, can be used to store and update reward parameters.
It is possible that an issuer may have recently changed its rewards policy for a given card product without that change being reflected yet at database 370. In that case, the given card product's stored profiles (set of reward parameter(s)) may be stale and may lead to an estimate that does not reflect the true amount of rewards earned by a transaction. The estimated rewards may be reconciled subsequent to generation or display of the estimate, e.g., reconciliation at the end of the month. Estimates may also be modified based on post-clearance events, such as returns. For example, if a cardholder buys a book with a rewards card and earns 50 points, the estimate of the accrued rewards is generated based on information available during the authorization process. That estimate may be presented (e.g., displayed) to the cardholder in real-time. If the cardholder later returns the book to the merchant for a refund, the estimate may be modified as part of the reconciliation process, so that the accrued rewards for the book purchase are canceled.
In some embodiments, an initial rewards balance (e.g., points balance) is determined during registration, which corresponds to the balance prior to the accrual of any rewards due to the present transaction. The initial points balance may be added (e.g., at one or more computer processors) to the estimated number of accrued points for the present transaction, to generate a final points balance. The final points balance may be presented to the cardholder in real-time.
Computer system 400 may also include a main memory 404, such as a random access memory (RAM), and a secondary memory 408. The secondary memory 408 may include, for example, a hard disk drive (HDD) 410 and/or removable storage drive 412, which may represent a floppy disk drive, a magnetic tape drive, an optical disk drive, a memory stick, or the like as is known in the art. The removable storage drive 412 reads from and/or writes to a removable storage unit 416. Removable storage unit 416 may be a floppy disk, magnetic tape, optical disk, or the like. As will be understood, the removable storage unit 416 may include a computer readable storage medium having tangibly stored therein (embodied thereon) data and/or computer software instructions, e.g., for causing the processor(s) to perform various operations.
In alternative embodiments, secondary memory 408 may include other similar devices for allowing computer programs or other instructions to be loaded into computer system 400. Secondary memory 408 may include a removable storage unit 418 and a corresponding removable storage interface 414, which may be similar to removable storage drive 412, with its own removable storage unit 416. Examples of such removable storage units include, but are not limited to, USB or flash drives, which allow software and data to be transferred from the removable storage unit 416, 418 to computer system 400.
Computer system 400 may also include a communications interface 420. Communications interface 420 allows software and data to be transferred between computer system 400 and external devices. Examples of communications interface 420 may include a modem, Ethernet card, wireless network card, a Personal Computer Memory Card International Association (PCMCIA) slot and card, or the like. Software and data transferred via communications interface 420 may be in the form of signals, which may be electronic, electromagnetic, optical, or the like that are capable of being received by communications interface 420. These signals may be provided to communications interface 420 via a communications path (e.g., channel), which may be implemented using wire, cable, fiber optics, a telephone line, a cellular link, a radio frequency (RF) link and other communication channels.
In this document, the terms “computer program medium” and “non-transitory computer-readable storage medium” refer to media such as, but not limited to, media at removable storage drive 412, or a hard disk installed in hard disk drive 410, or removable storage unit 416. These computer program products provide software to computer system 400. Computer programs (also referred to as computer control logic) may be stored in main memory 404 and/or secondary memory 408. Computer programs may also be received via communications interface 420. Such computer programs, when executed by a processor, enable the computer system 400 to perform the features of the methods discussed herein. For example, main memory 404, secondary memory 408, or removable storage units 416 or 418 may be encoded with computer program code (instructions) for performing operations corresponding to various processes disclosed herein.
It is understood by those familiar with the art that the system described herein may be implemented in hardware, firmware, or software encoded on a non-transitory computer-readable storage medium.
The systems and processes are not limited to the specific embodiments described herein. In addition, components of each system and each process can be practiced independent and separate from other each process can be practiced independent and separate from other components and processes described herein.
The previous description of the embodiments is provided to enable any person skilled in the art to practice the disclosure. The various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without the use of inventive faculty. Thus, the present disclosure is not intended to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.
