Patent Application
20240289834
The present invention pertains to machine-implemented techniques for facilitating and making payments, and more particularly, to a technique for applying rewards points associated with a payment card to a payment transaction.
Many credit cards have rewards programs that are designed as incentives for cardholders to use their cards more frequently and for large purchases. A cardholder consumer) typically earns rewards points on his or her credit card by making purchases with the credit card and can redeem rewards points for merchandise or services, or can use them to offset the card's unpaid balance.
One way of redeeming rewards points for good or services is for the cardholder to request a merchant to apply rewards points from his or her credit card to a transaction (e.g., a purchase) at the time of checkout for the transaction, such as when the cardholder provides his or her credit card information to the merchant. That approach is not optimal, however, because consumers often forget about their rewards points when making purchases and therefore neglect to use their points. Further, when making a purchase, a consumer may not know his or her rewards points balance or may be unsure of whether the balance is sufficient to cover the purchase price (rewards points often do not have a one-to-one relationship with the local currency). Likewise, a consumer may be unsure of whether their rewards points can be redeemed for the type of goods or services being purchased.
As a result, consumers tend to accumulate rewards points on their credit cards but redeem them infrequently. Consequently, credit card rewards programs may not be as effective as they were intended to be, at encouraging consumers to use their credit cards.
One or more embodiments of the present invention are illustrated by way of example and not limitation in the figures of the accompanying drawings, in which like references indicate similar elements.
In this description, references to “an embodiment”, “one embodiment” or the like, mean that the particular feature, function, structure or characteristic being described is included in at least one embodiment of the technique introduced here. Occurrences of such phrases in this specification do not necessarily all refer to the same embodiment. On the other hand, the embodiments referred to also are not necessarily mutually exclusive.
Introduced here is a computer-implemented technique that makes it easier for consumers to use rewards points earned by their payment cards. In the technique, a centralized server computer system that includes one or more computers, collectively called the payment service system (PSS), stores information associated with a person's payment card (or multiple payment cards), such as a credit and/or debit card, including information indicative of rewards points associated with the card. At some point in time the PSS receives from a remote device a message indicative of a completed credit card based transaction between the person and another entity (e.g., another person or a business). The transaction includes a payment of a specified amount (transaction amount) from the person to the other entity. The PSS determines how many rewards points of the card used in the transaction correspond to the transaction amount and, if the cardholder so requests, causes the rewards points to be used to satisfy at least a portion of the transaction amount. The PSS may do this in response to an express request from the person (the cardholder) in relation to that specific transaction, or it may do it automatically (e.g., according to a previously-specified user preference or a default setting or policy).
Notably, the technique can be applied to a particular transaction in a post-transaction manner (i.e., after the transaction is complete between the merchant and the consumer), thereby avoiding at least some of the disadvantages of the conventional points redemption method described above. For example, in some embodiments the transaction has already been completed when the PSS receives a transaction message indicative of the transaction. In such embodiments the transaction message may originate from a merchant's point-of-sale (POS) terminal or the issuing bank of a consumer's card and may be an indication of a completed purchase by the consumer using the consumer's credit card. In such cases the PSS may send an interactive digital receipt to a user device of the consumer (e.g., a smartphone, tablet computer, notebook computer, desktop computer, or the like). Alternatively, the PSS may send the user device a message that enables the consumer to access and retrieve the interactive digital receipt.
The interactive digital receipt, when displayed by the consumers' user device, includes the transaction amount (e.g., purchase price), the number of points that correspond to the transaction amount, and a prompt for the consumer to provide an input indicating his or her request to apply the rewards points to the transaction. In response to such input by the consumer, the user device sends a message to the PSS, which applies the rewards points to the transaction, or to a portion of the transaction amount specified by the consumer. The PSS may do this by, for example, causing some or all of the transaction amount to be voided from the transaction (assuming the transaction has not yet been funded by the card-issuing bank) or by causing reversal of payment of some or all of the transaction amount (assuming the transaction has already been funded by the issuing bank). The PSS can communicate with the issuing bank directly or through a third party, for purposes of applying the rewards points to the transaction.
The interactive digital receipt may include a list of items involved in the purchase (i.e., a “shopping basket” list) and the corresponding number of rewards points for each item (tax may also be factored in). Consequently, the consumer can request, via the interactive digital receipt, the PSS to apply rewards points to only a specified portion of the purchase price, e.g., to a portion corresponding to only one or more specified items in the purchase.
In some embodiments, the PSS may automatically apply rewards points to some or all of the transaction amount, i.e., without waiting for a request to do so from the consumer for that transaction.
Further, in some embodiments, the PSS tracks multiple types of rewards points associated with the consumer's credit card and enables the consumer to apply rewards points from any one or more of those multiple categories, or even from multiple different cards, to a particular transaction.
In some embodiments, the technique introduced here also enables a person to use credit card rewards points for at least a portion of a cash transfer from his or her bank account to the bank account of another person or entity. For example, in some embodiments the PSS stores not only information about a person's credit card, including rewards points information, but also information about a bank account and associated debit card of the person. In such embodiments, the initial message received by the PSS is an electronic message from the person's device representing a request to make a cash payment of a specified amount to another person or other entity (e.g., a business). The PSS then determines how many rewards points correspond to the specified payment amount. Optionally, before applying the rewards points to the payment (cash transfer), the PSS may send a message to the payer's device, informing him or her of the exact number of rewards points corresponding to the specified transfer amount, and asking the person to indicate whether he or she wants rewards points to be used for the cash transfer (and, optionally, how many points should be used). If the person so indicates by an input to his or her user device, the user device sends a message to the PSS, in response to which the PSS causes at least a portion of the cash transfer amount to be satisfied from the payer's rewards points. This action can include causing at least some of the cash transfer amount to be satisfied from the payer's credit card rewards points and deposited to an account of the payee (e.g., by using debit card information of the payee's bank account), and causing any remainder of the cash transfer amount to be debited from the payer's bank account (e.g., by using the payer's debit card information) and deposited to an account of the payee.
The illustrated environment also includes a computer system 114 of the merchant's acquiring bank (“acquirer”) for credit card transactions, a computer system 118 of the issuing bank (“issuer”) of the user's payment card 18, a computer system 116 of a card payment network (e.g., Visa or MasterCard), and a computer system 108 of a payment service. The payment card 18 can be a conventional credit card, for example. Alternatively, the payment card 18 can be a debit card, automatic teller machine (ATM) card, or the like. Each of the aforementioned computer systems can include one or more distinct physical computers and/or other processing devices which, in the case of multiple devices, can be connected to each other through one or more wired and/or wireless networks.
All of the aforementioned devices are coupled to each other through an internetwork 106, which can be or include the Internet and one or more wireless networks (e.g., a cellular telecommunications network and/or WiFi network).
The PSS 108 in at least some embodiments includes one or more server computers programmed to provide payment related services to consumers, including at least some aspects of the rewards points technique introduced here. The PSS 108 can be operated by a payment service 110, which can be a business enterprise that provides and facilitates various types of payment related services for consumers. Consumers can register with the payment service 110 to receive such services, and such consumers are referred to herein as “registered users.” One type of service provided by the payment service 110 is enabling registered users to apply rewards points associated with their payment cards to already-completed transactions, as described further below.
The PSS 108 stores information about registered users provided voluntarily by them, such as their names, addresses, credit card numbers, debit card numbers, bank account numbers, mobile telephone numbers, email addresses, etc. Further, the PSS 108 stores rewards points information associated with registered users' payment cards. The PSS 108 may obtain current rewards points balances of registered users from the corresponding card issuers (e.g., issuer 118) directly or through a third party. For example, the PSS 108 may use a published application programming interface (API) of a card issuer to obtain current rewards points balances for credit cards of registered users.
The PSS 108 also stores information about devices used by its registered users, particularly mobile devices (e.g., smartphones and tablet computers), but also potentially including users' conventional devices such as desktop computers. Hence, the PSS 108 can communicate with a user's device 102 over internetwork 106.
The rewards points technique introduced here can be applied with both traditional card-present transactions (i.e., transactions involving reading a customer payment card present at the merchant's POS) as well a s “cardless” payment card transactions, the latter of which are described further below. In a traditional card-present payment card transaction, the merchant swipes the consumer's payment card 18 through a card reader 105 at the POS system 104. The POS system 104 sends data read from the card (e.g., the consumer/cardholder's name, credit card number, expiration date and card verification value (CW)) to the computer system 114 of the merchant's acquirer (hereinafter “acquirer 114”). The acquirer 114 sends this data to the computer system 116 of the card payment network (e.g., Visa or MasterCard) (hereinafter “card payment network 116”), which forwards the data to the computer system 118 of the issuing bank (hereinafter “issuer 118”). If the transaction is approved by the issuer 118, a payment authorization message is sent from the issuer 118 to the merchant POS system 104, via a path generally opposite that described above.
Note that in this description, any references to sending or transmitting a message, signal, etc. to another device (recipient device) means that the message is sent with the intention that its information content ultimately be delivered to the recipient device; hence, such references do not mean that the message must be sent directly to the recipient device. That is, unless stated otherwise, there can be one or more intermediary entities that receive and forward the message/signal, either “as is” or in modified form, prior to its delivery to the recipient device. This clarification also applies to any references herein to receiving a message/signal from another device; i.e., direct point-to-point communication is not required unless stated otherwise herein.
The rewards points technique introduced here can also be applied with cardless payment card transactions. Just as registered users have a relationship with the payment service 110 (e.g., by preregistering), some merchants also may have a relationship with the payment service 110 (e.g., by preregistering with the payment service 110), to enable the providing of additional services to consumers. Such merchants are referred to herein as “registered merchants.” Registered merchants may use specially-configured POS systems (including software configured to communicate with the PSS 108) to enable registered consumers to use their payment cards to pay for purchases at a merchant's physical location, without the consumers having to have their cards in their physical possession at the time of the purchase, e.g., by using a “pay-by-name/pay-by-face” paradigm. Such transactions are called “cardless” payment card transactions herein. In general, in the case of a transaction with a registered merchant, the PSS 108 can function as an intermediary between the registered merchant and the registered merchant's acquirer 114. Note, however, that the details of how a “cardless” payment card transaction can be performed are not germane to the rewards points technique introduced here.
As noted above, the rewards points technique can be applied in a post-transaction manner to credit card transactions with non-registered merchants and to credit card transactions with registered merchants (e.g., cardless transactions). In either scenario, the PSS 108 may receive a transaction message indicative of a completed payment card transaction. In the context of this description, a transaction is deemed to be “complete” when the merchant's POS has received a message indicating that the transaction has been authorized by the appropriate third party (e.g., the card issuer), such that the consumer is deemed by the merchant to have fully paid. In the case of a non-registered merchant, the PSS 108 may receive the transaction message from the consumer's credit card issuer, as described above. If the transaction is with a registered merchant, the PSS 108 may instead receive the transaction message indicating the completed card transaction directly from the registered merchant (e.g., in a “cardless” credit card transaction). In other embodiments, the PSS 108 may receive the transaction message indicating the completed credit card transaction from some other entity.
The transaction message can include data descriptive of the transaction, such as the name of the cardholder, card number and expiration date, name and address of the merchant, total amount (payment amount) of the transaction, date and time of the transaction, and a list of items (goods and/or services) purchased in the transaction and their individual prices (i.e., a “shopping cart” list). The PSS 108 can use information in the transaction message to enable post-transaction application of rewards points to the transaction amount, as described further below. Note that the term “purchase” is used broadly herein to refer to any type of payment-based transaction and is not limited to a situation where an item changes ownership. Hence, a “purchase” in this description also can include a lease or rental, or a transaction involving services, or the like. Likewise, the term “sale” (as in “point-of-sale”) also refers to any type of payment-oriented transaction.
The PSS 108, in response to a transaction message indicating a completed payment card based transaction involving a user 101, may send an interactive digital receipt for the transaction to the user's mobile device 102 (or another designated device associated with the user 101), where it is displayed or output to the user in some other manner. The interactive digital receipt in some embodiments provides a graphical user interface (GUI) and may include both program code and data. From the interactive digital receipt, the user can input a request, to the device 102, to apply rewards points associated with the user's credit card to the subject transaction. The request is sent by the user device 102 in a message to the PSS 108 via the internetwork 106 (which may include a wireless telecommunications network). The PSS 108 then causes the rewards points to be applied to the transaction.
The main function of the digital receipt generator 201 is to generate interactive digital receipts in response to card based transactions involving registered users. More particularly, the digital receipt generator 201 generates digital receipts in response to receiving transaction messages (e.g., from card issuers and/or registered merchant's POS systems) indicative of completed card based transactions (which may be card-present transactions or cardless transactions). The main functions of the rewards points computation module 202 are to determine (in response to a transaction message) the number of rewards points currently redeemable by a given user associated with a card used in a recent transaction, and to determine the number of rewards points corresponding to the amount of the transaction. In this regard, the rewards points computation module 202 may include logic to enable the PSS 108 to communicate with a card issuer's computer system directly or through a third party, to ascertain the number of rewards points currently available to a registered user, and to notify the issuer whenever rewards points are used for a transaction.
The main functions of the payment processing module 203 are to cause actual movement of funds and/or modification of transaction amounts in connection with applying rewards points. This may occur in any of several ways. For example, if a completed transaction has not yet been “captured” (i.e., the funds are being held by the issuer but have not yet been removed from the cardholder's account), then the payment processing module 203 may cause authorization of the transaction to be voided (e.g., by sending an electronic message to the issuing bank or by causing the merchant's POS system to do so), in which case the payment processing module 203 may request a new authorization for a lower amount if the rewards points are only being used for a portion of the total transaction amount. Alternatively, if the transaction has already been captured (i.e., the funds have been removed from the cardholder's account), then the payment processing module 203 may accomplish this by causing at least a portion of the transaction amount to be refunded or reversed. Note that as used herein, “causing” an action to occur means that the causing entity either performs the action itself or initiates a sequence of events that is ordinarily expected to lead to that action (which can be subject to satisfying certain intermediary conditions). Note that in some alternative embodiments, two or more of the digital receipt generator 201, the rewards points computation module 202 or the payment processing module 203 can be combined into a single functional module.
An example use scenario will now be described from a user's perspective, for at least one embodiment of the rewards points technique, with reference to
In the screen of
The interactive digital receipt can include an itemized list of goods and/or services purchased in the transaction and their individual prices, i.e., a “shopping cart” list, as shown in the example of
In some embodiments, the PSS 108 can track rewards points balances and related information for multiple categories or types of rewards points for a given card of a user, or for separate cards of a user. Consequently, in a similar manner to the itemization described above, the PSS 108 can present the user with the option to select one or more of multiple rewards points categories/types, whose points he or she wishes to apply to a given transaction. Hence, the user can apply points from two or more different categories/types (and potentially, from two or more different cards) to a given transaction.
Next, at step 506 the PSS 108 sends to a user device of the consumer a message containing the interactive digital receipt, or for enabling the user device to access, retrieve and output the interactive digital receipt. In some cases the user device may be a mobile device of the consumer, whose telephone number was previously provided to the PSS 108 by the user and stored in a database of the PSS 108. In other cases the user device may be a conventional desktop computer or other device belonging to the user.
The interactive digital receipt can be sent to the user device in any of various formats and communication protocols, such as by email, short messaging service (SMS) message, multimedia messaging service (MMS) message, or the like. In some embodiments, the PSS 108 may simply send the user (e.g., via e-mail or SMS message) a hyperlink to a location where the interactive digital receipt is stored, which is downloaded to the user device only when the user activates the hyperlink. The user may have previously set a preference indicating which user device or devices should receive interactive digital receipts or related messages from the PSS 108.
After sending the interactive digital receipt (or a message for enabling access to it), if the PSS 108 then does not receive a request to use rewards points for the transaction from the user within a predetermined timeout period (step 507), the process simply ends without applying any rewards points to the transaction. Note that in some embodiments, the user may have the option to set a preference to apply any available rewards points to every transaction or to certain types of transactions, by default. If, however, the PSS 108 does receive a request to use rewards points within the timeout period, then the PSS 108 attempts to authenticate the request at step 508. Authentication may be done by, for example, requiring the user to input the payment card's CVV or some other personal information into the GUI when submitting the request, which is then compared by the PSS 108 to information in the PSS's databases. If the user's request is authenticated, the PSS 108 then causes the specified number of rewards points to be used to offset at least a portion of the transaction amount (depending upon how many rewards points the user indicated should be applied) at step 509. In some embodiments, step 509 is accomplished by the PPS 108 sending two or more messages to the issuer, either directly or through a third-party. For example, in some embodiments the PPS 108 sends to the issuer (either directly or through third-party) at least one request to deduct the appropriate number of rewards points from the user's account. Additionally, the PPS 108 sends to the issuer (either directly or through third-party) request to reconcile transaction amount. This could include reversal of the hold if the transaction has been authorized but not yet captured, or it could include reversal of the transaction and refunding of the money, if the transaction has already been captured. Additionally, this may be for the entire amount of the transaction or some partial amount, depending on how many rewards points were used, as indicated above.
If the request fails authentication, the PSS 108 instead just sends an error message to the user's device at step 510.
In some embodiments, the technique introduced here also enables a registered user to use credit card rewards points for a direct cash transfer from the person's bank account to the bank account of another person or entity. For example, in some embodiments the PSS 108 stores not only information about a person's credit card, including rewards points information, but also information about the person's bank account and an associated debit card. Such embodiments are now described further with reference to
In a cash transfer embodiment, instead of initially receiving a transaction message indicative of a completed transaction with the merchant, the initial message received by the PSS 108 may be an electronic message, from a registered user's device, representing a request to make a cash payment of a specified amount directly from the user's bank account to the bank account of another person or other entity. The user may have initiated such a request on his smartphone or other mobile device by using a mobile application (hereinafter the “cash app”) on the mobile device, associated with the payment service 110. The cash app may take the user through a series of screens, examples of which are shown in
As shown in
Additionally, the payer can input a brief memo indicating the purpose of the cash transfer, as shown in
An example of the remainder of the process is described now in relation to
For purposes of enabling a cash transfer, it is assumed that the payer has previously provided to the PSS 108 detailed information about his or her bank account and an associated debit card. Hence, the PSS 108 can use the conventional debit card “rails” to effect such a transfer. Additionally, the user has previously provided the PSS 108 with information of a second payment card of the user that earns rewards points, which in this example is assumed to be (but is not necessarily) a credit card of the payer. Note that unlike in the consumer/merchant embodiments described above, however, the second payment card has not yet been used in relation to the requested cash transfer.
The PSS 108 then at step 703 computes the number of rewards points of the second card that equal the requested payment amount, using a known conversion factor. Next, at step 704 the PSS 108 communicates with the card issuer to determine the number of redeemable rewards points currently associated with the second payment card. Assuming the user has some redeemable rewards points, the PSS 108 next at step 705 generates a message containing rewards points information, and a prompt the user to indicate whether the awards points should be used for the cash transfer. In particular, in a manner similar to the digital receipt described above, this message can indicate the number of rewards points that corresponding to the requested cash transfer amount, as well as the total number of redeemable awards points available to the payer.
After sending the message, if the PSS 108 then does not receive a request to use rewards points for the payment from the user within a predetermined timeout period (step 707), the process simply continues by causing the cash transfer to be executed at step 710. This may be accomplished, for example, by debiting the payment amount from the payer's bank account and depositing the funds into the payee's bank account. In other embodiments, the user may have the option to set a preference to apply any available rewards points to every cash transfer, by default.
If the PSS 108 does receive a request from the payer to use rewards points for the payment within the timeout period, however, then the PSS 108 attempts to authenticate the payer's request at step 708. Authentication may be done, for example, in the same manner described above in the consumer/merchant examples. If the request fails authentication, the PSS 108 instead just sends an error message to the user's device at step 711. If the user's request is authenticated, the PSS 108 then at step 709 causes the specified number of rewards points to be used to offset at least a portion of the transaction amount (depending upon how many rewards points the user indicated should be applied). This action can include causing at least some of the cash transfer amount to be satisfied from the payer's credit card rewards points and deposited to the payee's bank account (e.g., by using the payee's debit card information), and causing any remainder of the specified transfer amount to be debited from the payer's bank account (e.g., by using the payer's debit card information) and deposited to the payee's bank account in similar manner.
In certain embodiments, the issuer of the payer's credit card maintains a pool of funds associated with its credit card rewards points program, and rewards points can be redeemed for funds from that pool. Hence, in step 709 above, satisfying some or all of a cash transfer amount from a payer's credit card rewards points can be accomplished in any of at least three ways: For example, the funds can be obtained by the PSS 108 directly from the issuer's rewards points pool of funds such as mentioned above. Alternatively, the funds can be debited from the cardholder's bank account by the PSS 108 and subsequently reimbursed from the issuer's rewards points pool of funds. As yet another alternative, the funds can be obtained by the PSS 108 as a cash advance from the cardholder's credit card account and then subsequently reimbursed from the issuer's rewards points pool of funds. It will be recognized that various other approaches are also possible.
In the illustrated embodiment, the architecture 800 includes one or more processors 810, memory 811, one or more communication device(s) 812, one or more input/output (I/O) devices 813, and one or more mass storage devices 814, all coupled to each other through an interconnect 815. The interconnect 815 may be or include one or more conductive traces, buses, point-to-point connections, controllers, adapters and/or other conventional connection devices. The processor(s) 810 control the overall operation of the processing device 800 and can be or include, for example, one or more general-purpose programmable microprocessors, digital signal processors (DSPs), mobile application processors, microcontrollers, application specific integrated circuits (ASICs), programmable gate arrays (PGAs), or the like, or a combination of such devices.
Memory 811 can be or include one or more physical storage devices, which may be in the form of random access memory (RAM), read-only memory (ROM) (which may be erasable and programmable), flash memory, miniature hard disk drive, or other suitable type of storage device, or a combination of such devices. The mass storage device(s) 814 can be or include one or more hard drives, digital versatile disks (DVDs), flash memories, or the like. Memory 811 and/or mass storage 814 can store (individually or collectively) data and instructions that configure the processor(s) 810 to execute operations to implement the techniques described above. The communication devices 812 may be or include, for example, an Ethernet adapter, cable modem, Wi-Fi adapter, cellular transceiver, baseband processor, Bluetooth or Bluetooth Low Energy (BLE) transceiver, or the like, or a combination thereof. Depending on the specific nature and purpose of the processing device 800, the I/O devices 813 can include devices such as a display (which may be a touch screen display), audio speaker, keyboard, mouse or other pointing device, microphone, camera, etc. Note, however, that such I/O devices may be unnecessary if the processing device 800 is embodied solely as a server computer.
In the case of a user device, the communication devices 812 can be or include, for example, a cellular telecommunications transceiver (e.g., 3G or 4G/LTE), Wi-Fi transceiver, baseband processor, Bluetooth or BLE transceiver, or the like, or a combination thereof. In the case of the PSS 108, the communication devices 812 can be or include, for example, any of the aforementioned types of communication devices, a wired Ethernet adapter, cable modem, DSL modem, or the like, or a combination of such devices.
Although the present invention has been described with reference to specific exemplary embodiments, it will be recognized that the invention is not limited to the embodiments described, but can be practiced with modification and alteration within the spirit and scope of the appended claims. Accordingly, the specification and drawings are to be regarded in an illustrative sense rather than a restrictive sense.
This application is a continuation of and claims priority to U.S. patent application Ser. No. 17/019,015, filed Sep. 14, 2020, which is a continuation of and claims priority to claims the benefit of U.S. patent application Ser. No. 14/506,541, filed Oct. 3, 2014, and issued as U.S. Pat. No. 10,776,809 on Sep. 15, 2020, which claims priority from U.S. provisional patent application No. 62/049,298, filed Sep. 11, 2014, which a r e incorporated by reference herein in their entirety.
| Number | Date | Country | |
|---|---|---|---|
| 62049298 | Sep 2014 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 17019015 | Sep 2020 | US |
| Child | 18658934 | US | |
| Parent | 14506541 | Oct 2014 | US |
| Child | 17019015 | US |
