Systems and techniques for automatic fast welfare distribution

Abstract

Systems and techniques for providing automatic allocation of transaction-related benefits to accounts used to conduct transactions are described herein. In certain embodiments, the systems receive transaction details from a transaction processing network when a transaction is conducted. The systems determine an appropriate benefits provider for the transaction conducted from an account and provide a subset of the transaction details to the benefits provider. The benefits provider compares the subset of the transaction details to a limited set of transaction details received from a resource provider to identify the transaction and determine an amount of a benefit, if any, to which the transaction qualifies. The benefits provider then provides the amount of the benefit to the systems, which then causes the transaction processing network to credit the amount of the benefit to the account.

Description

BACKGROUND

[0001] Various entities (e.g., product manufacturers, government agencies, retailers, etc.) often use the distribution of benefits (e.g., rebates, discounts, tax exemptions, etc.) to users for conducting particular transactions to promote user consumption patterns. However, participating in benefit distribution can often be inefficient and cumbersome, which discourages many users from doing so and reduces the efficacy of the benefit distribution system. By way of illustration, consider the following scenarios.

[0002] In a first scenario, an entity such as a product manufacturer or government agency can wish to incentivize the purchase of a particular product regardless of where the product is purchased. For example, a government agency can offer a rebate for the purchase of energy-efficient products. However, participating in this process can require the purchaser to fill out various forms with personal details that are physically mailed along with a receipt by a postmark date. Users can be discouraged by the length of the forms or can forget to send the forms by the postmark date.

[0003] In a second scenario, transactions between a resource provider in a particular region and users who do not reside in the region often include additional costs (e.g., taxes) that the users should not bear. In these transactions, the users can be eligible to receive a recovery (i.e., a refund) of those additional costs. However, the process of making a recovery claim can be complex and time-consuming. Additionally, users can not be aware of certain requirements (e.g., recovery eligibility rules for a particular location) at the time of purchase, which can result in these users becoming ineligible to make a recovery request. Furthermore, users are often unaware of the specific eligibility requirements for making a recovery request when traveling. This is especially true when users travel to multiple states or locations within a region and the eligibility rules differ between these locations.

[0004] Embodiments of the present disclosure address these and other problems, individually and collectively. SUMMARY

[0005] Embodiments described herein relate to systems and techniques for automatically distributing transaction-related benefits to accounts used to conduct transactions. In certain embodiments, the system receives transaction details from a transaction processing network when a transaction is conducted. The system determines an appropriate benefit provider for the transaction conducted from an account and provides a subset of the transaction details to the benefit provider. The benefit provider compares the subset of the transaction details to a limited set of transaction details received from a resource provider to identify the transaction and determine an amount of a benefit the transaction is eligible for, if any. The benefit provider then provides the amount of the benefit to the system, which then causes the transaction processing network to credit the amount of the benefit to the account.

[0006] One embodiment relates to a method performed by a benefit processor server, comprising: receiving transaction details related to a transaction conducted at a resource provider computer operated by a resource provider using a portable device of a user; identifying a benefit provider computer associated with the transaction, wherein the benefit provider computer receives limited transaction details of the transaction independently from the resource provider computer; providing a subset of the transaction details to the benefit provider computer, the subset of the transaction details for use by the benefit provider computer to identify the transaction; receiving an indication of a value associated with the transaction from the benefit provider computer; and sending a credit request message to an authorizing entity computer to credit the value to an account associated with the portable device.

[0007] Another embodiment relates to a benefit processor server, comprising: a processor; and a memory comprising instructions that, when executed with the processor, cause the benefit processor server to at least: receive transaction details related to a transaction conducted at a resource provider computer operated by a resource provider using a portable device of a user; identify a benefit provider computer associated with the transaction, wherein the benefit provider computer receives limited transaction details of the transaction independently from the resource provider computer; provide a subset of the transaction details to the benefit provider computer, the subset of the transaction details for use by the benefit provider computer to identify the transaction; receive an indication of a value associated with the transaction from the benefit provider computer; and send a credit request message to an authorizing entity computer to credit the value to an account associated with the portable device.

[0008] These and other embodiments of the present disclosure are described in further detail below. BRIEF DESCRIPTION OF DRAWINGS

[0009] Figure 1 A block diagram illustrating an overview of an automatic benefit allocation system in accordance with at least some embodiments is depicted;

[0010] Figure 2 An example system architecture that can be implemented to facilitate automatic allocation of transaction-related benefits in accordance with embodiments of the present disclosure is depicted;

[0011] Figure 3 A process flow for providing automatic benefit allocation of transaction-related benefits in accordance with at least some embodiments is depicted;

[0012] Figure 4 A first illustrative process for obtaining a benefit in an automatic benefit allocation system via a portable device in accordance with at least some embodiments is depicted;

[0013] Figure 5 A second illustrative process for obtaining a benefit in an automatic benefit allocation system via a portable device in accordance with at least some embodiments is depicted; and

[0014] Figure 6 A flow diagram illustrating an example process for automatically allocating transaction-related benefits to a payment account used in a transaction is depicted in accordance with at least some embodiments. DETAILED DESCRIPTION

[0015] In the following description, various embodiments will be described. For the purpose of explanation, specific configurations and details are set forth in order to provide a thorough understanding of the embodiments. However, it will also be apparent to one skilled in the art that the embodiments can be practiced without the specific detail.

[0016] In some embodiments, when a user uses an account maintained by an authorizing entity to transact with a resource provider, the resource provider generates an authorization request message to complete the transaction, sends the authorization request message to a transaction processing network. The transaction processing network then processes the authorization request message by routing the authorization request message to the authorizing entity that maintains the account. A benefit processor server receives transaction details from the transaction processing network as the transaction processing network processes the authorization request message. The benefit processor server then determines eligibility for various benefits independent of the authorization process. If the benefit processor server determines that the transaction is eligible for one or more benefits, the benefit processor server sends a subset of the transaction details to a benefit provider associated with the eligible benefits. The benefit provider is then able to match the subset of transaction details with limited transaction details provided by the resource provider in order to identify the transaction and determine a benefit amount. The benefit amount is then provided back to the benefit processor computer by the benefit provider. The benefit processor computer then sends a credit request message to the transaction processing network that is routed to the authorizing entity and the account is credited the determined benefit amount.

[0017] Before discussing details of some embodiments of the present disclosure, a description of some terminology can be helpful in understanding various embodiments.

[0018] A "portable device" can be any suitable device operated by a user that is portable and can communicate with external entities such as access devices. Examples of user devices include cards on which data is stored, mobile phones, laptop computers, transponders, wearable devices such as smart watches, automobiles with remote communication capabilities, access cards, smart media, and the like. A payment device can be an example of a portable device.

[0019] A "payment device" can include a device that can be used to conduct a financial transaction, such as providing payment information to a merchant. Payment devices can take any suitable form. For example, suitable payment devices can be hand-held and compact so that they can fit into a user's wallet and / or pocket (e.g., pocket-sized). They can include smart cards, magnetic stripe cards, keychain devices, and the like. If the payment device is in the form of a debit card, credit card, or smart card, the payment device can also optionally have features such as a magnetic stripe. Such devices can operate in a contact or a contactless mode.

[0020] An "access device" can be any suitable device that provides access to a remote system. Access devices can take any suitable form. Some examples of access devices include POS or point of sale devices (e.g., POS terminals), cellular phones, PDAs, personal computers (PCs), tablet PCs, hand-held specialized readers, set-top boxes, electronic cash registers (ECRs), automated teller machines (ATMs), virtual cash registers (VCRs), kiosks, security systems, access systems, and the like. Access devices can use any suitable contact or contactless mode of operation to send data to or receive data from a user mobile device or otherwise associate with a user mobile device.

[0021] An "authorization request message" can be an electronic message that requests authorization for a transaction. In some embodiments, an authorization request message is sent to a transaction processing computer and / or an issuer of a portable device to request authorization for a transaction. An authorization request message according to some embodiments can comply with ISO 8583, which is a standard for systems that exchange electronic transaction information associated with payments made by users using portable devices or accounts. An authorization request message can include an issuer account identifier, which can be associated with a portable device or account. An authorization request message can also include additional data elements, including one or more of: a service code, a CVV (card verification value), a dCVV (dynamic card verification value), a PAN (primary account number or "account number"), a token, a user name, an expiration date, and the like. An authorization request message can also include "transaction information," such as any information associated with a current transaction, such as a transaction amount, a merchant identifier, a merchant location, an acquirer bank identification number (BIN), a card acceptor ID, information identifying items being purchased, and the like, as well as any other information that can be used to determine whether to identify and / or authorize a transaction.

[0022] An "authorization response message" can be a message in response to an authorization request. In some cases, an authorization response message can be an electronic message reply generated by an issuing financial institution or a transaction processing computer to an authorization request message. For example only, an authorization response message can include one or more of the following status indicators: approved - the transaction was approved; declined - the transaction was not approved; or call center - more information is pending a response, the merchant must call a toll-free authorization phone number. An authorization response message can also include an authorization code, which can be a code returned by a credit card issuing bank to an access device (e.g., a POS device) of a resource provider in response to an authorization request message in an electronic message (directly or through a transaction processing computer) indicating that the transaction was approved.

[0023] An "authorization entity" can be an entity that authorizes a request. Examples of an authorization entity can be an issuer, a government agency, a file repository, an access administrator, etc. An "issuer" can generally refer to a business entity (e.g., a bank) that maintains an account for a user. An issuer can also issue account credentials to a user that are stored on a user device, such as a cellular phone, a smart card, a tablet, or a laptop. In some embodiments, an authorization entity can be a server operated by a transaction processing network on behalf of an issuer. For example, a transaction processing network can maintain stand-in-processing (STIP) rules that are executed by the transaction processing network to authorize a request when an issuer is unavailable.

[0024] A "benefit agency" can be any entity responsible for distributing a benefit or reimbursement related to a transaction for at least a portion of a value of the transaction. In some embodiments, a benefit agency can be a government entity, such as a customs organization or a tax authority. In some embodiments, a benefit agency can be a manufacturer or seller of a good.

[0025] The term "resource" generally refers to any asset that can be used or consumed. For example, a resource can be a computer resource (e.g., stored data or a networked computer account), a physical resource (e.g., a tangible object or a physical location), or other electronic resources or communications between computers (e.g., a communication signal corresponding to an account used to perform a transaction). Some non-limiting examples of a resource can be a good or a service, a physical building, a computer account or file, or a payment account. In some embodiments, a resource can refer to a financial product, such as a loan or a line of credit.

[0026] A "resource provider" can be an entity capable of providing a resource, such as a good, a service, information, and / or access. Examples of a resource provider include a merchant, an online or other electronic retailer, an access device, a secure data access point, etc. A "merchant" can generally be an entity that participates in a transaction and can sell or provide access to a good or a service. A "resource provider computer" can be any computing device operated by a resource provider.

[0027] A "server computer" can include a powerful computer or cluster of computers. For example, the server computer can be a large mainframe, a minicomputer cluster, or a

[0028] A "service computer" or "service provider computer" can include any system associated with an entity that provides a resource or service. In some embodiments, a service computer can handle the functions of a computer application associated with an entity that provides a resource or service. A service computer can provide any suitable service. For example, a service computer can be a merchant, a utility company, a payment processing network, a wallet provider, a merchant, a website operator, or a bank.

[0029] A "transaction" can be any interaction or exchange between two or more parties. For example, a transaction can include a first entity requesting a resource from a second entity. In this example, the transaction is complete when the resource is provided to the first entity or the transaction is declined.

[0030] A "user" can include an individual. In some embodiments, a user can be associated with one or more personal accounts and / or mobile devices. A user can also be referred to as a cardholder, account holder, or consumer.

[0031] Details of some embodiments of the disclosure will now be described in greater detail.

[0032] Figure 1 A block diagram showing an overview of an automated benefit allocation system in accordance with at least some embodiments is depicted. In Figure 1 In some embodiments, a user 102 can be able to conduct a transaction with a resource provider computer 104. In some embodiments, the transaction can be conducted via a portable device 106 and an access device 108 in communication with the resource provider computer 104. The resource provider computer 104 can be in further communication with an acquirer computer 110 configured to send an authorization request to a transaction processing network 112. In addition to processing the authorization request by forwarding it to the appropriate authorizing entity 114, the processing network 112 can also provide a notification to a benefit processor environment (which includes at least one benefit processor server 116), which in turn can be in communication with a benefit provider environment (which includes at least one benefit provider server 118).

[0033] The portable device 106 can be any device that can be used to conduct a transaction with the resource provider computer 104. In some embodiments, the portable device 106 can be a mobile device (e.g., a smartphone). The portable device 106 can be configured to communicate with the resource provider computer 104 via an access device 108, which can include a contactless element. For example, the resource provider computer 104 can be a point-of-sale (POS) device that includes the access device 108 as a contactless card reader. In some embodiments, the portable device 106 can include a mobile application that enables the portable device 106 to communicate with the benefit processor server 116.

[0034] The resource provider computer 104 can be any computing device operated by or on behalf of a resource provider. In some embodiments, the resource provider computer 104 can be configured to control access to one or more resources. For example, the resource provider can be a merchant or other seller of goods and / or services. In this example, the resource provider computer 104 can be a POS device (e.g., a cash register).

[0035] The acquirer computer 110 can be any computing device configured to conduct transactions on behalf of the resource provider computer 104. In some embodiments, transactions conducted by multiple resource provider computers 104 are processed by one or more acquirer computers 110. The acquirer computer 110 sends authorization request messages for transactions to the appropriate processing network 112. In some embodiments, the appropriate processing network 112 for a particular transaction can be determined by the acquirer computer 110 based on a network identifier included within payment information to be used to complete the transaction.

[0036] The transaction processing network 112 can be any collection of computing devices configured to route authorization request messages to appropriate authorization entity computers 114. In some embodiments, the appropriate authorization entity computer 114 for a particular transaction can be determined by the processing network 112 based on a network identifier included within payment information to be used to complete the transaction. In some embodiments, the transaction processing network 112 can additionally be configured to perform alternative processing on behalf of the authorization entity computer 114. In addition to routing authorization request messages received from the acquirer computer 110 to the appropriate authorization entity computer 114, the processing network 112 can also provide transaction details from the authorization request messages to the benefit processor server 116.

[0037] The authorization entity computer 114 can be any computing device operated by or on behalf of an authorization entity. In some embodiments, the authorization entity can be an issuer or other entity configured to authorize transactions. In some embodiments, the authorization entity can provide authentication for a portable device (e.g., a credit card).

[0038] The welfare processor server 116 can be any computing device capable of performing at least a portion of the functionality described herein. In some embodiments, the welfare processor server 116 can receive information related to transactions conducted at one or more resource provider computers 104. The welfare processor server 116 can identify any information related to potential welfare distribution included in the transaction information, and in some cases, estimate the amount of money that will be associated with the welfare. The welfare processor server 116 can be configured to track and compile welfare information for each transaction. In some embodiments, the welfare processor server 116 can be configured to generate and provide a notification to the portable device 106 upon determining that a user 102 of the portable device 106 who is eligible for a welfare has conducted a transaction. In some embodiments, the welfare processor server 116 can also be configured to generate a voucher including welfare information for which the user is eligible (e.g., value added tax (VAT) recovery) relative to each transaction. Upon identifying a transaction for which a user is eligible for a welfare, at least a portion of the transaction details are provided to the welfare provider 118 by the welfare processor server 116. Upon receiving confirmation of the welfare to be applied to a particular transaction, the welfare processor server 116 can be further configured to credit the confirmed welfare to the payment account used in the transaction. In some embodiments, the welfare processor server 116 can be operated by the same entity that operates the transaction processing network 112.

[0039] The benefit provider server 118 can be any computing device operated by an entity responsible for providing a particular transaction-related benefit. In some embodiments, the benefit provider can be a manufacturer of goods that provides rebates for the purchase of the goods. In some embodiments, the benefit provider can be a tax refund provider responsible for distributing tax refunds. In some embodiments, the benefit provider can manage the distribution of benefits on behalf of a benefit agency (e.g., a government entity). By way of illustrative example, the benefit provider 118 can be a manufacturer of energy-efficient products that are eligible for government rebates. In this example, the manufacturer can provide government rebates to purchasers of the products and can then file a claim on behalf of the user with the government entity that distributes the rebates. Note that this advantageously enables users to automatically (e.g., without taking any overt action) obtain government rebates regardless of where they purchase the products at a resource provider. Using this system, the government rebates are applied directly to the user's payment account that was used to complete the purchase. By way of a second illustrative example, the benefit provider 118 can be a tax refund provider that distributes tax refunds to eligible parties (e.g., non-residents) of eligible transactions. In this example, the benefit provider 118 can evaluate the details of a transaction and the details of the user in the transaction in order to determine whether the transaction is eligible for a refund claim (e.g., based on certain tax fees paid in the transaction being exempt for non-residents). Upon determining that the transaction is eligible for a refund benefit, the benefit provider 118 notifies the benefit processor 116 of the eligible amount on behalf of the user and files a claim with the benefit agency 120 (e.g., the tax authority in this example).

[0040] For clarity, Figure 1 Embodiments of the disclosure can include more than one of each component. Additionally, some embodiments of the disclosure can include fewer or additional components than those shown in Figure 1 Additionally, components in Figure 1 may communicate using any suitable communication protocol over any suitable communication medium, including the Internet.

[0041] Figure 2 An example system architecture that can be implemented to facilitate the automatic distribution of transaction-related benefits in accordance with embodiments of the disclosure is depicted. The system architecture 200 is depicted as including a benefit processor server 202, which can be an example of the benefit processor computer 116 depicted in Figure 1 The benefit processor server 202 can communicate with a benefit provider server 204 and a transaction processing server 206 via a network 208.

[0042] In at least some embodiments, the benefits processor server 202 can include at least one memory 214 and one or more processing units (or processors) 216. The one or more processors 216 can be implemented in hardware, computer-executable instructions, firmware, or combinations thereof, as appropriate. A computer-executable instructions or firmware embodiment of the one or more processors 216 can include computer-executable instructions or machine-executable instructions written in any suitable programming language to perform the various functions described. Additionally, it should be noted that, in some embodiments, the benefits processor server 202 can be embodied by one or more virtual machines implemented in a hosted computing environment. The hosted computing environment can include one or more rapidly provisioned and released computing resources, which can include computing, networking and / or storage devices. The hosted computing environment can also be referred to as a cloud computing environment.

[0043] The memory 214 can store program instructions that are loadable and executable on the one or more processors 216, as well as data generated during the execution of these programs. Depending on the configuration and type of the benefits processor server 202, the memory 214 can be volatile (such as random access memory (RAM)) and / or non-volatile (such as read-only memory (ROM), flash memory, etc.). The benefits processor server 202 can also include additional storage 218, such as removable storage and / or non-removable storage including, but not limited to, magnetic storage, optical disk storage, and / or tape storage. The disk drives and their associated computer-readable media can provide non-volatile storage of computer-readable instructions, data structures, program modules, and other data for the computing devices. In some embodiments, memory 214 can include multiple different types of memory, such as static random access memory (SRAM), dynamic random access memory (DRAM), or ROM. Turning in more detail to the contents of the memory 214, the memory 214 can include an operating system and one or more application programs or services for implementing the features disclosed herein, including at least a module for determining eligibility of a transaction for a benefit (eligibility determination module 220) and / or a module for assigning an eligible benefit to a user of a transaction (assignment module 222). The memory 214 can also include account data 224 providing data associated with one or more accounts, and benefit eligibility data 226 providing data indicative of eligibility requirements for various benefits and / or products.

[0044] Removable and non-removable storage 214 and additional storage 218 are examples of computer-readable storage media. For example, computer-readable storage media can include volatile or non-volatile, removable or non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. As used herein, a module can refer to a program module executed by a computing system (e.g., a processor) that is part of the benefits provider server 204, the transaction processing server 206, the benefits processor server 202, or any other suitable computing device. The benefits processor server 202 can also include a communications interface 228 that allows the benefits processor server 202 to communicate with a stored database, another computing device or server, a user terminal, and / or other devices on the network 208. The benefits processor server 202 can also include input / output (I / O) devices and / or ports 230, such as for enabling connection with a keyboard, mouse, pen, voice input device, touch input device, display, speaker, printer, etc.

[0045] Turning in more detail to the contents of the memory 214, the memory 214 can include an operating system 209 and one or more application programs or services for implementing the features disclosed herein, including at least a qualification module 220 and / or an allocation module 222, as well as account data 224 and / or benefits eligibility data 226. The stored data (e.g., account data 224 and / or benefits eligibility data 226) can include any suitable persistent data storage system. In some embodiments, the data can be stored in a database. Information stored in the database can be accessed by one or more modules via a database query or any other suitable data retrieval means.

[0046] In some embodiments, the qualification module 220, in conjunction with the processor 216, can be configured to identify transactions received by the transaction processing server 206 that are eligible for a benefits allocation. A benefits provider can provide eligibility data to the benefits processor server 202 indicating conditions that will make a transaction eligible for a benefits to be allocated. For example, the eligibility data can include an indication of a product or product type that, when purchased, will entitle the purchaser to a certain benefit (e.g., rebate, discount, etc.). Multiple benefits providers can provide eligibility data such that the benefits processor server 202 can maintain a mapping of the eligibility data to its corresponding benefits provider within the benefits eligibility data 226.

[0047] In certain embodiments, the eligibility determination module 220 can receive transaction details from the transaction processing server 206 as transactions (e.g., authorization request messages) are processed. More specifically, the eligibility determination module 220 can receive a plurality of product identifiers for one or more products associated with a transaction. In some embodiments, the transaction details are relayed to the eligibility determination module 220 by the allocation module 222. Upon receiving the plurality of product identifiers, the eligibility determination module 220 can determine from the benefit eligibility data 226 whether any of the products associated with the product identifiers make the transaction eligible for a benefit allocation. Additionally, in some embodiments, the transaction details can include a payment account identifier that can be used to identify the user and / or account from the user account data 224. This can allow the eligibility determination module 220 to access demographic or other data for the user making the transaction. In some cases, the eligibility data associated with a particular benefit can also include conditions related to attributes of the user. For example, only users living within a particular geographic region or outside of a particular geographic region can be eligible for the benefit. In another example, only users with an income level below a certain threshold income level can be eligible for the benefit. In embodiments where the eligibility data associated with a particular benefit includes conditions related to attributes of the user, the eligibility determination module 220 can also make the determination. Upon determining that a particular transaction satisfies each of the conditions set forth for a benefit in the benefit eligibility data 226, the eligibility determination module 220 identifies the benefit provider server 204 responsible for allocating the benefit. The eligibility determination module 220 communicates this information to the allocation module 222.

[0048] In some embodiments, the allocation module 222, in conjunction with the processor 216, can be configured to manage and allocate benefits. In some embodiments, the allocation module 222 receives complete transaction details from the transaction processing server 206 while the transaction is in progress. The allocation module 222 then relays the transaction details to the eligibility module 220, which determines which benefits, if any, the transaction is eligible for. If the transaction is not eligible for any benefits, the allocation module 222 can take no further action. However, if the allocation module 222 receives an indication that the transaction is eligible for one or more benefits (as well as a list of the benefit provider servers 204 that allocate those benefits), the allocation module 222 is further configured to provide limited transaction details of the transaction to each of the benefit provider servers 204. The benefit provider servers 204 can be determined using a routing table (not shown) that matches identifiers of particular benefit provider servers and addresses (e.g., IP addresses) to identifiers of different resource providers. In some embodiments, the limited transaction details can include enough information to identify the transaction without providing confidential information. For example, the limited transaction details can include two or more of the following: resource provider identifier (e.g., merchant id), transaction date / time, last four digits of the payment account, authorization code, transaction amount, etc. By providing limited transaction details, the benefit provider servers 204 are able to initiate the benefit process for the user without receiving or storing the user's actual account information.

[0049] In some embodiments, the user can be required to enroll prior to a transaction to receive a benefit. For example, in the context of a benefit being a tax refund, the user can need to provide a passport and / or travel plans to the benefit processor prior to the transaction being eligible for the benefit. In this context, the allocation module 222 can only send transaction details for transactions associated with an enrolled user that is currently being routed to the eligibility determination module 220.

[0050] Additionally, the allocation module 222 can also be configured to automatically initiate the allocation of the benefit to the payment account. This can be done by the allocation module 222 upon receiving confirmation of the benefit eligibility and / or the benefit amount from the benefit provider server 204. To do so, the allocation module 222 can be configured to initiate a funds transfer from an account associated with the benefit provider to the payment account used in the transaction.

[0051] In at least some embodiments, the benefit provider server 204 can include at least one server device configured to implement the features disclosed herein. Such a server device can execute an application or service (e.g., the benefit platform 232) that computes benefit eligibility amounts and initiates benefit distribution as described herein. In some embodiments, the benefit provider server 204 can receive transaction data from a plurality of resource providers, which can be stored in a database of aggregated transaction data 234. The received transaction data can include only a subset of transaction details. For example, the benefit provider server 204 can receive an indication of a sale of a particular product and a transaction number for the sale of the particular product. In some cases, the benefit provider server 204 can receive a serial number or other identifier. It should be noted that the benefit provider server 204 can not be provided with confidential information (e.g., payment details, etc.) and thus can not have access to that data otherwise. When a benefit is allocated for a transaction, the transaction data 234 can be updated to reflect the allocation. Additionally, the benefit platform 232 can be further configured to submit claims to a benefit agency (e.g., a government entity) on behalf of the benefit distributor.

[0052] In at least some embodiments, the transaction processing server 206 can include at least one server device configured to implement the features disclosed herein. Such a server device can execute an application or service (e.g., the transaction management module 236) configured to route authorization request messages to the appropriate authorization entity server. Additionally, the transaction management module 236 can send a portion of each authorization request message to the benefit processor server 202. The portion of each authorization request message sent to the benefit processor server 202 can include at least an identifier of an item involved in the transaction. It should be noted that this can be done concurrently with the normal authorization process and does not require the process to be paused. Additionally, upon receiving an indication of a benefit allocation (e.g., from the benefit processor server 202), the transaction management module 236 can be configured to settle a payment from an account associated with the benefit provider to an account associated with a portable device of the benefit based authorization request message.

[0053] Figure 3A process flow for providing automatic benefit allocation for transaction-related benefits in accordance with at least some embodiments is depicted. Process 300 is shown as a logical flow diagram, where each operation represents a series of operations that can be implemented in hardware, computer instructions, or combinations thereof. In the context of computer instructions, the operations represent computer-executable instructions stored, for example, on one or more computer-readable storage media that, when executed by one or more processors, perform the recited operations. Generally, computer-executable instructions include routines, programs, objects, components, data structures, and the like that perform particular functions or implement particular data types. The order in which the operations are described is not intended to be construed as a limitation, and any number of the described operations can be omitted or combined in any order and / or in parallel to implement this and any other processes described herein.

[0054] Some or all of process 300 (or any other processes described herein, or variations and / or combinations thereof) can be performed under the control of one or more processing devices configured with executable instructions and can be implemented as code (e.g., executable instructions, one or more computer programs or one or more applications) executing collectively on one or more processing devices. According to at least one embodiment, Figure 3 Process 300 can be performed at least by Figure 2 the benefit processor server 202 depicted in FIG. 1. The code can be stored on a computer-readable storage medium, e.g., in the form of a computer program including a plurality of instructions executable by one or more processors. The computer-readable storage medium can be non-transitory.

[0055] Figure 3 Process 300 is depicted as involving a number of interactions between various components, which have been described elsewhere. For example, process 300 can involve interactions between the portable device 106, the resource provider computer 104, the acquirer computer 110, the authorization entity 114, the benefit processor environment 302 (which includes at least one benefit processor server 116), the benefit provider environment 304 (which includes at least one benefit provider server 118), and the transaction processing environment 306 (which includes the transaction processing network 112). In some embodiments, process 300 can also involve interactions with the benefit institution 120.

[0056] When a transaction is conducted at the resource provider 104, the process 300 can begin at S351. In some embodiments, the transaction can involve a purchase made by the user using the payment account 308. For example, the resource provider 104 can be a merchant and the user can purchase one or more products from the merchant using a credit card. To complete the conducted transaction, at S352, the resource provider 104 communicates the transaction details to the acquirer computer 110. Then, at S353, the acquirer computer 110 forwards the transaction details to the processing network 112 of the transaction processing environment 306 (via an authorization request message). At S354, the transaction processing network 112 in turn routes the transaction details to the authorization entity 114 that maintains the payment account 308 used to conduct the transaction. The authorization entity 114 then determines whether to approve or decline the transaction based on the transaction details and information stored in association with the payment account 308. Once the authorization entity 114 has made a determination as to whether to approve or decline the transaction, the authorization entity 114 provides an authorization response message back to the transaction processing network 112, which is then communicated back to the acquirer computer 110 and ultimately to the resource provider 104. The transaction is then completed.

[0057] In certain embodiments, in addition to conducting the transaction described above, the resource provider 104 can provide limited or complete transaction details to the benefit provider environment 304 for transactions it conducts at S355, which can be stored in a database of transaction data 234. In some embodiments, the resource provider 104 can provide transaction details to the benefit provider environment for every transaction it conducts. In some embodiments, the resource provider 104 can provide transaction details to the benefit provider environment 304 only for transactions involving particular products or product types. For example, the benefit provider can be a manufacturer of a particular product or product line. In this example, the resource provider 104 can report transaction details to the benefit provider for every product it sells. By way of illustration, for a single transaction in step S355, the limited transaction details can include a resource provider identifier (e.g., merchant id), a transaction date / time, the last four digits of the payment account, an authorization code, a transaction amount, and one or more product identifiers for the product(s) purchased by the user during the transaction. In this regard, the number of limited transaction details can be greater than the number of limited transaction details provided to the benefit provider environment 304 in step S358, which can be a subset of the transaction details provided to the benefit provider environment 304 in step S355.

[0058] In addition to, and in some cases concurrently with, routing transaction details to the authorization entity at S354, the processing network 112 can also trigger a payment authorization notification to the transaction management module 236 at S355. The transaction management module 236 can then provide at least a subset of the transaction details of the transaction to the benefit processor environment 302 at S356.

[0059] Upon receiving the transaction details, the assignment module 222 provides the transaction details to the eligibility module 220 at S357 to determine whether the transaction is eligible for one or more benefits. Upon receiving the transaction details, the eligibility determination module 220 can determine whether the transaction satisfies the conditions for being eligible for a benefit. For example, the eligibility module 220 can determine whether any products associated with the product identifiers included in the transaction details make the transaction eligible for a benefit assignment. In some embodiments, the eligibility module 220 can determine whether the user in the transaction satisfies the conditions for being eligible for a benefit. For example, in the context where the benefit is a tax refund (e.g., for value added tax), eligible transactions are limited to certain product types, and users residing outside of a particular geographic zone. The eligibility module 220 can maintain details related to any number of benefits offered by any number of different benefit providers. For example, in the context where the benefit is a tax refund, separate benefit providers can each be responsible for providing a recycling service in different geographic zones. In another example, each benefit provider can be associated with or operate on behalf of a different manufacturer of products or product lines (e.g., brands).

[0060] Upon determining that the transaction is eligible for a benefit, the eligibility module 220 can identify to the assignment module 222 the benefit provider associated with the eligible benefit. The benefit provider server 204 can be determined using a routing table (not shown) that matches identifiers and addresses (e.g., IP addresses) of particular benefit provider servers with identifiers of different resource providers. The assignment module 222 then forwards limited transaction data to the indicated benefit provider environment 304 at S358. In some embodiments, the limited transaction details can include a resource provider identifier (e.g., merchant id), transaction date / time, last four digits of payment account, authorization code, transaction amount, etc.

[0061] Upon receiving the limited transaction details from the allocation module 222, the benefits platform 232 within the benefits provider environment 304 can perform a lookup operation to obtain a record of the transaction at S359. This can involve identifying the transaction within the transaction data by matching the provided limited transaction data to data stored within the transaction data 234. The benefits provider can then make an independent eligibility decision for the transaction based on information stored in the transaction database 234 relating to the transaction that was made. In some embodiments, the benefits provider can determine an amount associated with the benefit. For example, the benefit amount can be calculated as a percentage of the pre-tax amount paid in the transaction. Then, at S360, the benefits platform 232 provides a response to the allocation module 222. If the benefits platform 232 determines that the transaction is not eligible for a benefits allocation, the response provided at S360 can include a reason (e.g., a reason code). If the benefits platform 232 determines that the transaction is eligible for a benefit, it can respond with an approval and / or an amount of the benefit to be allocated.

[0062] Upon receiving the indication of the benefit / amount to be allocated, the allocation module 222 can be further configured to automatically initiate the allocation of the benefit to the payment account. This can be done by the allocation module 222 initiating a funds transfer from an account associated with the benefits provider to the payment account used in the transaction. In some embodiments, an identifier of the payment account from which the benefit is to be allocated can be stored relative to the benefits provider. In some embodiments, the identifier of the payment account from which the benefit is to be allocated can be provided to the benefits processor environment at step S360. It should be noted that in the provided example, the benefits provider environment is not provided with the payment account details used to complete the transaction. This reduces the risk of exposure of the user payment account identifier to potential data breaches or man-in-the-middle attacks, as well as subsequent fraudulent use of the user payment account identifier. In some embodiments, at S361, the allocation module 222 can provide a notification to the portable device 106 associated with the payment account involved in the transaction. The notification can indicate that a benefit is being dispersed. In some embodiments, the notification can be provided to the portable device 106 via a push notification to a mobile application installed on the portable device 106.

[0063] To initiate the transfer of funds, the allocation module 222 can provide a debit adjustment notification to the transaction management module 236 at S362, which can forward the debit adjustment notification to the processing network 112 at 363, and subsequently to the authorizing entity 114 at S364. The transaction management module 236 later settles the benefits allocation transaction by obtaining funds from a payment account associated with the benefits provider and transferring those funds to the payment account used to complete the transaction at the resource provider 104. However, in some embodiments, the funds associated with the allocated benefit can be provided to the payment account immediately.

[0064] In some embodiments, the debit adjustment notification can be in the form of a credit transaction message, which can include a message to initiate a credit to an account. In some embodiments, the credit transaction message can be an original credit transaction (OCT) message. An OCT (original credit transaction) is generally a clearing and settlement credit transaction that is designed for commercial applications, such as commercial transfers or corporate disbursements to users. When used in embodiments of the present application, the OCT transaction can be used to deliver funds to a target account. In some cases, it is separate from the AFT transaction, and in some cases, can occur after the AFT transaction. The user’s account can be a credit or debit card account, and the account can be credited very quickly (nearly in real-time). The settlement process between the authorizing entity computer operated by the authorizing entity 114 and the benefit provider environment 304 can occur at a later time. In this regard, the benefit provider environment 304 can have a merchant bank identification number (merchant BIN) to allow such settlement to occur.

[0065] In some embodiments, once the benefit has been allocated to the payment account of the transaction, the processing network can provide a notification to the benefit provider at S365. The benefit provider can then update the transaction data 234 to indicate that the benefit has been allocated, which can prevent duplication of the benefit allocation.

[0066] Additionally, in some embodiments, upon receiving an indication that the benefit has been successfully allocated to the account, the benefit provider can make a claim on the benefit agency 120 on behalf of the user in the transaction at S366. For example, if the benefit provider is a tax refund provider responsible for allocating tax refunds on behalf of a regional government, the benefit provider can make a claim on the tax authority to recover the benefit provided.

[0067] Figure 4 A first illustrative process for obtaining a benefit in an automated benefit allocation system via a portable device is depicted in accordance with at least some embodiments. The process 400 is depicted as a series of graphical user interfaces (GUIs) (e.g., GUIs 402, 404, and 406) presented via a portable device, which can be an example of the portable device 106 depicted in FIG. 1. In some embodiments, portions of the process 400 can coincide with the process 300 described above. Figure 1 A first illustrative process for obtaining a benefit in an automated benefit allocation system via a portable device is depicted in accordance with at least some embodiments. The process 400 is depicted as a series of graphical user interfaces (GUIs) (e.g., GUIs 402, 404, and 406) presented via a portable device, which can be an example of the portable device 106 depicted in FIG. 1. In some embodiments, portions of the process 400 can coincide with the process 300 described above.

[0068] As depicted at 402, the user can select a payment to complete the transaction using the portable device. In this case, the portable device can be a smartphone or other suitable mobile device having a contactless transmitter / reader. Some embodiments can be implemented via a mobile application installed on a mobile application and executed on the portable device. In some embodiments, the mobile application can require the user of the portable device to log in by self-authenticating before providing the functionality described herein. The mobile application can be associated with an authorizing entity or other payment provider and maintained on their behalf.

[0069] In some embodiments, the user can select a payment account to be used to complete the transaction. For example, the mobile application can store a plurality of payment account identifiers associated with the user and / or account in memory or can obtain a plurality of payment accounts from a remote server. The mobile application can then allow the user to select one of the payment accounts to be used to complete the transaction, for example, via a drop-down menu 408. In some embodiments, the portable device can then approach the contactless transmitter / reader of the POS device. Upon being brought within the communication range of the contactless transmitter / reader, the portable device is provided a plurality of details of the transaction. The portable device can then generate a cryptogram from the provided plurality of details and can provide the cryptogram and the payment account to the contactless transmitter / reader of the POS device.

[0070] As depicted at 404, the mobile application can receive a notification upon completion of the transaction. In some embodiments, the notification can be provided to the mobile application by the POS device. In some embodiments, upon receiving an indication that the transaction has been authorized, the mobile application can receive a notification from a remote server in communication with the transaction processing network. Once the transaction is authorized, any benefits that the transaction qualifies for are determined as described with respect to process 300 depicted in FIG. 3. The benefits are then distributed by automatically crediting the benefits to the payment account used to make the transaction at 402. Figure 3

[0071] ​As depicted at 406, the mobile application can receive and present a notification of one or more benefits allocated with respect to the conducted transaction. For example, consider a scenario in which the transaction involves the purchase of an electric water heater from a retail store. In this example, the system can determine that the particular brand of electric water heater is eligible for a rebate issued by a local government for the purchase of energy efficient devices. In this example, the system automatically submits the transaction to the benefit provider (e.g., a third party that handles rebates on behalf of the local government) on behalf of the user. The benefit provider then determines the amount of the transaction for which the user is eligible and provides that information back to the system. Once the system receives confirmation that the transaction is eligible for a rebate and the amount of the transaction for which the user is eligible, the rebate is automatically applied to the user's payment account (e.g., the payment account used to complete the transaction) and the user is provided with a notification indicating that the rebate was applied. It should be noted that in this example, the user need not take any overt action to obtain the rebate other than conducting the transaction. It should also be noted that the benefit is allocated regardless of where the transaction is conducted, so the retailer need not be a participant in the campaign. Furthermore, by responding to the transaction in the manner described, the system can prevent rebate fraud due to duplicate receipts.

[0072] Figure 5 A second illustrative process for obtaining a benefit in an automated benefit allocation system via a portable device is depicted in accordance with at least some embodiments. Process 500 is depicted as a series of graphical user interfaces (GUIs) (e.g., GUIs 502, 504, and 506) presented via a portable device, which can be an example of the portable device 106 depicted in FIG. 1. Figure 1 In some embodiments, portions of the process 500 can coincide with the process 300 described above.

[0073] Similar to the example described above Figure 4 In some embodiments, portions of the process 500 can coincide with the process 300 described above. For example, consider a scenario in which a transaction is conducted by a non-resident alien and the transaction involves a payment for which the non-resident alien is exempt from paying taxes. By way of illustration, in certain European countries, U.S. citizens are exempt from paying value added tax (VAT) on certain products and product types. Thus, a U.S. citizen traveling through Europe can be eligible for a credit on various transactions conducted. Typically, this process involves significant action on the part of the non-resident alien and typically involves collecting receipts from merchants for each transaction and taking action at a customs station in the airport upon leaving the country. Once submitted, the credit process can take several weeks to issue any credit (typically by mail check).

[0074] In the context implemented by the embodiments described above, the system automatically submits each transaction to a benefit provider (e.g., a third party that processes recycling on behalf of a local government) on behalf of the user. In some embodiments, the benefit provider can be selected based on the resource provider involved in the transaction. For example, each resource provider can be serviced by one of a plurality of available benefit providers. In this example, the benefit processor can maintain a mapping of resource providers to their respective benefit providers. The benefit provider then determines the amount of the transaction for which the user is eligible for a benefit, and provides that information back to the system. Once the system receives confirmation that the transaction is eligible for a recycling credit, and the amount of the transaction for which the user is eligible, the recycling credit is automatically applied to the payment account of the user (e.g., the payment account used to complete the transaction), and the aggregated recycling credit information can be provided to the mobile application. It should be noted that in this example, the user need not take any overt action to obtain a recycling credit other than making the transaction. It should also be noted that the retailer need not take any overt action (e.g., provide transaction credentials) with respect to the user to obtain a recycling credit.

[0075] Figure 6 A flow diagram depicting an example process showing automatic allocation of transaction-related benefits to payment accounts used in transactions, in accordance with at least some embodiments, is depicted. Process 600 can be performed by a benefit processor computer, such as with respect to Figure 2 the benefit processor server 204 described above.

[0076] Process 600 can begin at 602 when transaction details are received from a transaction processing network with respect to a transaction. The transaction details can be obtained from an authorization request message received by the transaction processing network from a resource provider with respect to a transaction conducted between the resource provider and a user. The authorization request message includes at least an indication of a payment account maintained by an authorizing entity. The authorization request message can also include other transaction details, such as an identifier of a resource provider (e.g., merchant id) identifier of one or more products involved in the transaction, a transaction amount, or any other suitable transaction details.

[0077] At 604, the process 600 involves identifying a benefit provider associated with the transaction. In some embodiments, the benefit provider computer operates on behalf of a manufacturer, and the benefit is a rebate on a good manufactured by the manufacturer. In some embodiments, the benefit provider computer operates on behalf of a tax refund provider, and the benefit is a reimbursement for taxes paid by the user. In some embodiments, the resource provider identifies the benefit provider computer associated with the transaction based on the resource provider. For example, each resource provider can be serviced by a particular benefit provider. In this example, the benefit processor computer can maintain a mapping of resource providers to each respective benefit provider. Once it has been determined that the transaction is eligible for one or more benefits, the benefit provider associated with the eligible benefits is identified. In some embodiments, the benefit provider computer associated with the transaction is identified based on one or more products involved in the transaction. For example, the benefit provider computer can be a product manufacturer or a rebate distribution manager for rebates specific to the product.

[0078] Identifying the benefit provider associated with the transaction can involve determining that the transaction is eligible for each of a plurality of benefits by comparing the transaction details to benefit eligibility data provided for each of the plurality of benefits. In some embodiments, eligibility for a benefit can also be determined based on information stored in association with the user in the transaction. For example, eligibility for a particular benefit can depend on the user's residence, net income, or other demographic data. In these embodiments, the benefit processor computer can retrieve user data stored with respect to the user in order to determine eligibility for a benefit.

[0079] In some embodiments, one or more benefit providers can independently receive limited transaction details from the resource provider, which can include non-sensitive data. Examples of such non-sensitive data can include the date / time of the transaction, a transaction identifier, the transaction amount, the amount of a particular good sold, the amount of tax paid, etc. In some embodiments, the resource provider can provide a product identifier (e.g., a serial number) for a particular good sold by the resource provider. By way of example, the resource provider can notify the manufacturer each time one of its goods is sold, which can enable the manufacturer to ship new products and / or maintain warranty information for the good. The limited transaction details for the transaction can be stored by the benefit provider computer in a database that includes limited transaction details for a plurality of transactions. In some embodiments, the plurality of transactions can be associated with a plurality of different resource provider computers.

[0080] At 606, the process 600 involves providing a subset of transaction details to the identified benefit provider. The subset of transaction details can be limited to non-sensitive data. In some embodiments, the subset of transaction details can include one or more of a resource provider identifier, a transaction date, the last four digits of a payment account, an authorization code, or a transaction amount. In some embodiments, the portable device used to complete the transaction is a sixteen digit payment token, and the subset of transaction details includes the last four digits of the sixteen digit payment token. Upon receiving the subset of transaction details, the benefit provider identifies the transaction from a database of transaction data. To do so, the benefit provider computer can match the limited transaction details of the transaction received from the resource provider to the subset of transaction details.

[0081] At 608, the process 600 involves receiving a value, such as a benefit value, from the benefit provider. In some embodiments, the benefit value is determined as a portion of the transaction amount. In some embodiments, the benefit value can be equal to a particular tax fee included in the transaction. In some embodiments, the benefit value can be calculated using some algorithm known to the benefit provider.

[0082] At 610, the process 600 involves sending a credit request message to an authorizing entity to obtain a benefit value for an account used in the transaction. To credit the benefit value to the account, the transaction processing network can cause the authorizing entity to credit and a second authorizing entity to debit the amount of the benefit value to an account associated with the benefit provider computer, respectively. An indication of the account associated with the benefit provider computer can be retrieved by the benefit processor computer and provided in the credit request message. During the settlement process, the benefit value credited to the account associated with the portable device is withdrawn from the account associated with the benefit provider computer. In some embodiments, the benefit value is credited to the account associated with the portable device before the benefit processor server receives funds corresponding to the benefit value from the account associated with the benefit provider computer. In the context where the benefit provider computer operates on behalf of a tax refund provider and the benefit is a reimbursement of taxes paid by the user, the tax refund provider can subsequently submit a claim to a tax authority on behalf of the user.

[0083] In some embodiments, the benefit processor computer can additionally provide a notification to the portable device associated with the user that a benefit amount has been credited. In some embodiments, the benefit processor computer can maintain an account for the user along with the benefit data. The user can be able to log into the account via a mobile application installed on their mobile device in order to provide information stored with respect to the account. For example, the user can log into the account and be provided with an aggregated list of benefits credited to the user.

[0084] In some embodiments, after the benefit value credit is credited to the account associated with the transaction, a notification is provided to the benefit provider to update the limited transaction details stored in the transaction database to indicate that the benefit value has been redeemed. If the benefit provider subsequently receives transaction details that match the transaction for which the benefit value was indicated as redeemed, the benefit provider can return a benefit value of zero. For example, if the limited transaction details of the redeemed transaction include a unique product identifier (e.g., a serial number) and a second transaction is received that includes the same unique product identifier, the benefit provider can return a benefit value of 0.

[0085] Embodiments of the present disclosure provide several advantages over conventional systems. For example, the system enables a product manufacturer or a sponsoring entity (e.g., a government entity) to provide incentives for purchasing a particular product or a particular type of product without requiring merchant cooperation or overt user action (beyond making a purchase). Additionally, the benefit distribution system, as implemented in the manner described herein, provides benefits that can prevent fraud because a user cannot copy a receipt in order to claim a benefit for which they are not eligible. Benefit distribution efficiency also becomes more efficient because benefits can be distributed in a matter of minutes as opposed to days or even weeks in previous systems.

[0086] Additionally, when implemented in a tax refund system (e.g., to reclaim value added tax for non-residents), the user is not required to obtain a receipt at the time of the transaction or for the merchant to provide a receipt. Instead, the refund credit can be distributed to the user almost immediately without any additional effort on the part of the user. This can also incentivize users to make more transactions abroad.

[0087] Furthermore, the system described herein is advantageous over other systems because the benefit can be delivered directly to the account associated with the request without actually providing the account to the benefit provider. In the context of a tax refund, this means that the user does not need to share payment account details with a tax refund processor at the airport (i.e., the reclaim agency) and further reduces the cash handling fees for the processor because the processor does not need to provide the refund as cash. It should be noted that in embodiments, the benefit provider is not provided payment account details, making the way in which the benefit is distributed more secure.

[0088] In certain embodiments of the systems described herein, the user need not present any benefit information (e.g., a coupon) at the time of purchase. Instead, when the user completes a transaction at a merchant using their payment card, the processor for the payment card automatically initiates the benefit distribution process. To do so, the payment processor, upon identifying a potentially eligible transaction, determines the appropriate benefit provider based on the details of the transaction. The payment processor then provides some details to the benefit provider, which can be used to identify the transaction from a list of saved transaction data. However, in order to protect privacy and improve data security, the details provided can not be sufficient to identify the payment information (e.g., PAN or token) used to complete the transaction, which limits the user’s exposure to risk. The benefit provider then determines the eligibility of the transaction and provides that information to the payment processor. Once that has been completed, the payment processor can credit the benefit amount to the user (typically within 30 minutes of the transaction). In some embodiments, the payment processor essentially “lends” the benefit amount to the cardholder, and then reimburses the benefit amount after settlement with the benefit provider. This enables benefits to be provided extremely quickly. Moreover, the benefit provider never possesses the PAN or token, so the user is never at risk of a breach by the benefit provider.

[0089] It should be understood that any of the embodiments of the present disclosure can be implemented in the form of control logic using hardware (e.g., an application specific integrated circuit or field programmable gate array) and / or using computer software, wherein a general purpose programmable processor is programmed to perform the control logic. As used herein, a processor includes a single-core processor, multi-core processor on a same integrated chip, or multiple processing units on a single circuit board or networked. Based on the disclosure and teachings provided herein, a person of ordinary skill in the art will know and appreciate other ways and / or methods to implement embodiments of the present disclosure using hardware and a combination of hardware and software.

[0090] Any of the software components or functions described in this application can be implemented as software code to be executed by a processor using any suitable computer language such as, for example, Java, C, C++, C#, Objective-C, Swift, or scripting language such as Perl or Python using, for example, conventional or object-oriented techniques. The software code can be stored as a series of instructions or commands on a computer readable medium for storage and / or transmission, suitable media include random access memory (RAM), read only memory (ROM), a magnetic medium such as a hard-drive or a floppy disk, or an optical medium such as a compact disk (CD) or DVD (digital versatile disk), flash memory, and the like. The computer readable medium can be any combination of such storage or transmission devices.

[0091] Such programs can also be encoded and transmitted using carrier signals adapted to be transmitted via multiple protocols, including wireless, optical, and / or wired cables, to include in-band and out-of-band modulation techniques. Accordingly, a computer-readable medium according to an embodiment of the present disclosure can be created using a data signal encoded with such programs. Computer-readable media encoded with the program code can be packaged with a compatible device or provided separately from other devices (e.g., via Internet download). Any such computer-readable medium can reside on or within a single computer product (e.g., hard drive, CD, or entire computer system), and can be present on or within different computer products within a system or network. Computer systems can include monitors, printers, or other suitable devices for providing any of the results mentioned herein to a user.

[0092] The above description is illustrative and not restrictive. Many variations of the disclosure will become apparent to those of skill in the art upon reading this disclosure. The scope of the disclosure should, therefore, be determined not with reference to the above description, but instead with reference to the appended claims, along with their full scope or equivalents.

[0093] One or more features from any embodiment can be combined with one or more features of any other embodiment, without departing from the scope of the disclosure.

[0094] The recitation "a," "an," or "the" is intended to mean "one or more" unless specifically indicated to the contrary.

[0095] All patents, patent applications, publications, and descriptions mentioned above are herein incorporated by reference in their entirety for all purposes. None is admitted to be prior art.

Claims

1. A method comprising: receiving, at a benefit processor server, transaction details relating to a transaction conducted at a resource provider computer using a portable device of a user, the resource provider computer operated by a resource provider, the transaction details including transaction identification information and product identification information identifying a product involved in the transaction; identifying, by the benefit processor server, a benefit provider computer associated with the transaction, wherein the benefit provider computer independently receives limited transaction details of the transaction from the resource provider computer, the limited transaction details including at least the transaction identification information and the product identification information; providing, by the benefit processor server, a subset of the limited transaction details of the transaction to the benefit provider computer, wherein the subset of transaction details is used by the benefit provider computer to identify the transaction by (1) comparing the subset of transaction details to a plurality of transaction data stored in a database of the benefit provider computer and (2) matching the subset of transaction details to the limited transaction details, wherein the plurality of transaction data corresponds to a plurality of transactions and includes the limited transaction details; receiving, by the benefit processor server, from the benefit provider computer, an indication of a benefit value associated with the transaction; and sending, by the benefit processor server, a credit request message to an authorizing entity computer to credit the value to an account associated with the portable device, wherein crediting the value causes the benefit provider computer to update the limited transaction details in the database to indicate that a benefit related to the product identification information has been redeemed.

2. The method of claim 1, wherein the benefit is credited to the account associated with the portable device prior to the benefit processor server receiving funds corresponding to the value from an account associated with the benefit provider computer.

3. The method of claim 1, wherein the portable device includes a sixteen digit token, and wherein the subset of transaction details includes at least the last four digits of the sixteen digit token.

4. The method of claim 1, wherein the plurality of transactions are associated with a plurality of different resource provider computers.

5. The method of claim 1, wherein the benefit provider computer associated with the transaction is identified based on an identifier of the resource provider.

6. The method of claim 1, wherein the benefit provider computer associated with the transaction is identified based on the product involved in the transaction.

7. The method of claim 1, wherein the value is determined by the benefit provider computer as a portion of an amount of the transaction.

8. The method of claim 1, wherein the value credited to the account associated with the portable device is withdrawn from an account associated with the benefit provider computer.

9. The method of claim 1, wherein the benefit processor server stores a routing table that is capable of using an identifier of the resource provider to identify the benefit provider computer.

10. A benefit processor server, comprising: a processor; and a memory, the memory comprising instructions that, when executed with the processor, cause the benefit processor server to at least: receive transaction details relating to a transaction conducted at a resource provider computer using a portable device of a user, the resource provider computer operated by a resource provider, the transaction details including transaction identifying information and product identifying information identifying a product involved in the transaction; identify a benefit provider computer associated with the transaction, wherein the benefit provider computer independently receives limited transaction details of the transaction from the resource provider computer, the limited transaction details including at least the transaction identifying information and the product identifying information; provide a subset of transaction details of the transaction to the benefit provider computer, wherein the subset of transaction details is used by the benefit provider computer to identify the transaction by (1) comparing the subset of transaction details to a plurality of transaction data stored in a database of the benefit provider computer and (2) matching the subset of transaction details to the limited transaction details, wherein the plurality of transaction data corresponds to a plurality of transactions and includes the limited transaction details; receive an indication of a benefit value associated with the transaction from the benefit provider computer; and send a credit request message to an authorizing entity computer to credit the value to an account associated with the portable device, wherein crediting the value causes the benefit provider computer to update the limited transaction details in the database to indicate that a benefit relating to the product identifying information has been redeemed.

11. The benefit processor server of claim 10, wherein the subset of transaction details includes one or more of: a resource provider identifier, a transaction date, last four digits of the account, an authorization code, or a transaction amount.

12. The benefit processor server of claim 10, wherein the limited transaction details include at least a product identifier, and wherein the benefit value is indicated as zero if the benefit has been processed for the product identifier.

13. The benefit processor server of claim 10, wherein the benefit provider computer associated with the transaction is determined based at least in part on stored information associated with an owner of the account.

14. A benefit provider server, comprising: a processor; and a memory, the memory comprising instructions that, when executed by the processor, cause the benefit provider server to at least: receiving, from one or more resource provider computers, limited transaction details relating to a plurality of transactions conducted by the one or more resource provider computers, wherein, for each of the plurality of transactions, the limited transaction details include at least transaction identifying information and product identifying information; receiving, from a benefit processor server, a subset of transaction details relating to a first transaction conducted by a first resource provider computer using a portable device of a user, the first resource provider computer being one of the one or more resource provider computers, wherein the subset of transaction details includes information about the first transaction; identifying the first transaction of the plurality of transactions by matching the subset of transaction details with the limited transaction details; determining a value of a benefit associated with the first transaction based at least in part on the limited transaction details stored for the first transaction; providing the value of the benefit to the benefit processor server, wherein the benefit processor server subsequently sends a credit request message to an authorizing entity computer to credit the value to an account associated with the portable device of the user; and updating the limited transaction details to indicate that the benefit associated with the product identifier has been redeemed after the value is credited to the portable device.

15. The benefit provider server of claim 14, wherein the benefit provider server operates on behalf of a manufacturer, and the benefit is a rebate on a good manufactured by the manufacturer.

16. The benefit provider server of claim 14, wherein the benefit provider server operates on behalf of a tax refund provider, and the benefit is a reimbursement for taxes paid by the user.

17. The benefit provider server of claim 16, wherein the instructions further cause the benefit provider server to submit a claim to a tax authority on behalf of the user.

Images