US20140351142A1 - Systems and methods for processing payment transactions - Google Patents

Systems and methods for processing payment transactions Download PDF

Info

Publication number
US20140351142A1
US20140351142A1 US14456804 US201414456804A US2014351142A1 US 20140351142 A1 US20140351142 A1 US 20140351142A1 US 14456804 US14456804 US 14456804 US 201414456804 A US201414456804 A US 201414456804A US 2014351142 A1 US2014351142 A1 US 2014351142A1
Authority
US
Grant status
Application
Patent type
Prior art keywords
transaction
payment account
associated
consumer
rules
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
US14456804
Inventor
Vijay Kumar Royyuru
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
First Data Corp
Original Assignee
First Data Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices
    • G06Q20/32Payment architectures, schemes or protocols characterised by the use of specific devices using wireless devices
    • G06Q20/327Short range or proximity payments by means of M-devices
    • G06Q20/3278RFID or NFC payments by means of M-devices
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/405Establishing or using transaction specific rules
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00Commerce, e.g. shopping or e-commerce
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/02Banking, e.g. interest calculation, credit approval, mortgages, home banking or on-line banking

Abstract

Embodiments of the disclosure can include systems and methods for processing transactions. In one embodiment, a computer-implemented method for processing proposed transactions can be provided. The method can include storing, by a service provider system comprising one or more computers, one or more issuer rules associated with the applicability of one or more payment accounts to proposed transaction; receiving, by the service provider system from a merchant computer, information associated with a proposed transaction, the information comprising one of an identification of a payment account or an identification of a consumer payment device; evaluating, by the service provider system utilizing the one or more issuer rules, the proposed transaction; and determining, by the service provider system based at least in part upon the evaluation, at least one of (i) a payment account to utilize in association with the proposed transaction or (ii) whether the proposed transaction will be approved or denied.

Description

    RELATED APPLICATIONS
  • This application is a divisional of U.S. application Ser. No. 13/627,654, titled “Systems and Methods for Processing Payment Transactions,” filed on Sep. 26, 2012, which claims priority benefit of U.S. Provisional Application No. 61/539,206, titled “Systems and Methods for Processing Payment Transactions,” filed on Sep. 26, 2011, the contents of both of which are incorporated herein by reference.
  • FIELD OF THE DISCLOSURE
  • Embodiments of the disclosure relate generally to the processing of payment transactions, and more specifically to the evaluation of payment transactions in which payment processing parameters are decoupled from a payment account issuer.
  • BACKGROUND OF THE DISCLOSURE
  • A wide variety of different payment devices and/or payment accounts, such as credit card accounts, debit accounts, and/or stored value accounts, are utilized to facilitate transactions. Payment accounts may include both closed loop and open loop payment accounts. A closed loop payment account, such as a private label credit card account or a prepaid merchant-specific account, can only be utilized as designated locations and/or in association with designated merchants. For example, a merchant-specific card associated with a merchant-specific account can only be utilized at merchant locations associated with the merchant. Open loop payment accounts can typically be utilized at any location that accepts the payment account. For example, a Visa or Mastercard payment account may be utilized at any accepting merchant.
  • Regardless of the type of payment account, an issuer of the payment account may wish to establish various rules and/or parameters associated with the payment account's use. For example, a merchant may wish to allow a merchant-specific payment account to be utilized in association with other merchant in the event that certain criteria are met. Additionally, a consumer utilizing a payment account may wish to establish various rules and/or parameters associated with the payment account's use. Accordingly, there is an opportunity for improved systems and methods for processing transactions in which payment processing parameters are decoupled from a payment account issuer.
  • SUMMARY
  • Embodiments of the disclosure can include systems and methods for processing transactions. Certain embodiments can provide evaluation of payment transactions in which payment processing parameters are decoupled from a payment account issuer. In one embodiment, a computer-implemented method for processing proposed transactions can be provided. The method can include storing, by a service provider system comprising one or more computers, one or more issuer rules associated with the applicability of one or more payment accounts to proposed transaction; receiving, by the service provider system from a merchant computer, information associated with a proposed transaction, the information comprising one of an identification of a payment account or an identification of a consumer payment device; evaluating, by the service provider system utilizing the one or more issuer rules, the proposed transaction; and determining, by the service provider system based at least in part upon the evaluation, at least one of (i) a payment account to utilize in association with the proposed transaction or (ii) whether the proposed transaction will be approved or denied.
  • In at one aspect of an embodiment, the computer-implemented method can further include storing, by the service provider system, one or more consumer rules associated with the applicability of one or more payment accounts to proposed transactions, wherein evaluating the proposed transaction comprises evaluating the proposed transaction utilizing the one or more consumer rules.
  • In one embodiment, a system for processing proposed transactions can be provided. The system can include at least one memory configured to store computer-executable instructions; and at least one processor configured to access the at least one memory and execute the computer-executable instructions. The computer-executable instructions can be operable to store one or more issuer rules associated with the applicability of one or more payment accounts to proposed transaction; receive information associated with a proposed transaction, the information comprising one of an identification of a payment account or an identification of a consumer payment device; evaluate, utilizing the one or more issuer rules, the proposed transaction; and determine, based at least in part upon the evaluation, at least one of (i) a payment account to utilize in association with the proposed transaction or (ii) whether the proposed transaction will be approved or denied.
  • In one aspect of an embodiment, the system can further include computer-executable instructions operable to store one or more consumer rules associated with the applicability of one or more payment accounts to proposed transactions, wherein evaluating the proposed transaction comprises evaluating the proposed transaction utilizing the one or more consumer rules.
  • In another embodiment, a method for processing proposed transactions can be provided. The method can include storing one or more issuer rules associated with the applicability of one or more payment accounts to proposed transaction; receiving information associated with a proposed transaction, the information comprising one of an identification of a payment account or an identification of a consumer payment device; evaluating, utilizing the one or more issuer rules, the proposed transaction; and determining, based at least in part upon the evaluation, at least one of (i) a payment account to utilize in association with the proposed transaction or (ii) whether the proposed transaction will be approved or denied.
  • In one aspect of an embodiment, the method can further include storing one or more consumer rules associated with the applicability of one or more payment accounts to proposed transactions, wherein evaluating the proposed transaction comprises evaluating the proposed transaction utilizing the one or more consumer rules.
  • BRIEF DESCRIPTION OF THE FIGURES
  • FIG. 1 illustrates a block diagram of an example system that may be utilized in accordance with various embodiments of the disclosure.
  • FIG. 2 illustrates a flow diagram of an example process for storing restrictions and/or preferences associated with the use of a payment account, according to an example embodiment of the disclosure.
  • FIG. 3 illustrates a flow diagram of one example process for processing a proposed payment transaction, according to an example embodiment of the disclosure.
  • FIG. 4 illustrates a flow diagram of another example process for processing a proposed payment transaction and selecting a payment account to be utilized in association with the proposed payment transaction, according to an example embodiment of the disclosure.
  • DETAILED DESCRIPTION OF CERTAIN EMBODIMENTS OF THE DISCLOSURE
  • Various embodiments of the disclosure are directed to the processing of payment transactions in which rules, restrictions, and/or parameters associated with a payment account have been decoupled from an issuer of the payment account and/or a payment device (e.g., a payment card, a payment application, wallet information, etc.) associated with the payment account. In one example embodiment, restrictions and/or preferences associated with a payment account may be stored by a service provider. For example, an issuer may provide one or more restrictions and/or parameters to the service provider, such as parameters associated with approved merchants, parameters associated with approved merchant types and/or product types, geographical parameters, transaction amount parameters, and/or temporal parameters. As another example, a consumer associated with the payment account may provide one or more consumer parameters and/or preferences to the service provider, such as preferences for utilizing the payment account in association with various merchants, merchant types, transaction amounts, and/or other criteria. As desired, restrictions and/or parameters may be stored in association with any number of payment accounts.
  • Following the storage of restrictions and/or parameters associated with one or more payment accounts, information associated with a proposed transaction may be received by the service provider. The service provider may evaluate the proposed transaction and apply any number of the stored restrictions and/or parameters. In this regard, the service provider may determine whether a particular payment account may be utilized for the proposed transaction. Additionally, in certain embodiments, the service provider may select a payment account to utilize in association with the proposed transaction.
  • As a result of the decoupling of the payment account processing rules, a wide variety of flexibility may be provided. As one example, a merchant issuer may issue to a consumer a payment device (e.g., merchant-specific card, merchant-specific wallet application, etc.) associated with a closed-loop payment account; however, the merchant may allow the payment device and associated payment account to be utilized at one or more other merchants and/or merchant types. For example, a department store may allow a payment account to be utilized at various grocery stores. When the consumer attempts to utilize the payment account to facilitate a grocery store transaction, the service provider may receive information associated with the proposed transaction and apply merchant issuer rules to the proposed transaction. The service provider may then determine that the payment account may be utilized for the grocery store transaction, and the service provider may approve the proposed transaction for routing or other communication to a processing entity, such as an issuer or financial institution system, for clearance and/or settlement.
  • As another example, an issuer may specify at the service provider various restrictions and/or parameters associated with other merchants, types of merchants (or other criteria). Additionally, the issuer may offer a wide variety of incentives for utilizing a payment account in certain situations. For example, an issuer may offer an increased reward incentive (e.g., cash back, coupons, etc.) in the event that a consumer uses the payment account for transactions at a particular merchant or merchant type (e.g., grocery stores, gas stations, etc.). The consumer may then provide processing preferences to the service provider. For example, the consumer may specify that the payment account should be utilized for transactions involving the particular merchant or merchant type. Subsequently, during the processing of a proposed transaction, the service provider may utilize the stored preferences and/or parameters in order to select the payment account as a payment account to utilize for the proposed transaction. As desired, the service provider may additional determine or identify the applicability of an issuer incentive for the proposed transaction. The service may then direct the routing or communication of the proposed transaction to a suitable processing entity associated with the selected payment account.
  • Embodiments of the disclosure now will be described more fully hereinafter with reference to the accompanying drawings, in which embodiments of the disclosure are shown. This disclosure may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art. Like numbers refer to like elements throughout.
  • System Overview
  • FIG. 1 represents a block diagram of an example system 100 for providing transaction processing services, according to one embodiment of the disclosure. The system 100 may facilitate the decoupling of payment account processing parameters from a payment account issuer and/or from a payment device. As shown in FIG. 1, the system may include one or more service provider computers 105 associated with a transaction processing service provider, one or more merchant computers and/or merchant devices (collectively referred to as merchant computers 110), one or more consumer devices 115, and/or one or more issuer and/or financial institution system 120. Any number of suitable networks, such as the illustrated networks 125, 130 and transaction networks 135, may facilitate communication between various components of the systems. Each of these components will now be discussed in further detail.
  • First, each service provider computer 105 may include any number of processor-driven devices, including but not limited to, a server computer, a mainframe computer, one or more networked computers, a desktop computer, a personal computer, a laptop computer, a mobile computer, or any other processor-based device. A service provider computer 105 may utilize one or more processors 140 to execute computer-readable instructions that facilitate the storage and/or management of various rules, preferences, and/or parameters associated with evaluating proposed transactions. Additionally, the service provider computer 105 may utilize the one or more processors 140 to execute computer-readable instructions that facilitate the processing of a proposed transaction. As a result of executing these computer-readable instructions, a special purpose computer or particular machine may be formed that facilitates the decoupling of transaction processing rules and/or parameters.
  • In addition to having one or more processors 140, the service provider computer 105 may further include one or more memory devices 141, input/output (“I/O”) interface(s) 142, and/or network interface(s) 143. The memory 141 may be any computer-readable medium, coupled to the processor(s) 140, such as random access memory (“RAM”), read-only memory (“ROM”), and/or removable storage devices. The memory 141 may store a wide variety of data files 144 and/or various program modules, such as an operating system (“OS”) 145, a database management system (“DBMS”) 146, and/or a transaction processing module 147. The data files 144 may include any suitable data that facilitates the operation of the service provider computer 105 and/or interaction of the service provider computer 105 with one or more other components of the system 100. For example, the data files 144 may include card issuer identification information, merchant identification information, consumer identification information, data utilized to communicate with the card issuers, merchants, and/or consumers, data that facilitates the storage of transaction processing rules, and/or data that facilitates the processing of a proposed transaction. The OS 145 may be suitable module that facilitates the general operation of the service provider computer 105, as well as the execution of other program modules. For example, the OS may be, but is not limited to, Microsoft Windows®, Apple OSX™, Unix, a mainframe computer operating system (e.g., IBM z/OS, MVS, OS/390, etc.), or a specially designed operating system. The DBMS 146 may be a suitable program module that facilitate management of the data files 144, data stored in the memory 141, and/or data stored in one or more separate databases, such as one or more transaction processing rules databases 148.
  • The rules databases 148 may be configured to store a wide variety of rules that may be utilized to evaluate proposed transactions, including but not limited to, payment account issuer rules and/or preferences, merchant rules and/or preferences, and/or consumer rules and/or preferences. In certain embodiments, one or more host modules may be associated with the service provider computer 105, and the host modules may facilitate interaction with other components of the system 100. For example, one or more Web servers 150 may be provided, and the Web servers 150 may facilitate the presentation of any number of suitable graphical user interfaces to collect rules from issuer/financial institution systems 130, merchant computers 110, and/or consumer devices 115. Other example host modules may facilitate inter-process communications and/or other types of communications in order to facilitate the receipt of processing rules and/or preferences. Yet other example host modules may facilitate the receipt of proposed transactions to be processed.
  • A wide variety of suitable processing rules may be utilized as desired in various embodiments of the disclosure. In certain embodiments, issuer rules may be utilized. An issuer, which may also be a merchant, may be an entity that issues and/or sponsors a payment account. A wide variety of different types of payment accounts may be issued, such as credit accounts, debit accounts, and/or stored value accounts. Additionally, an issued payment account may be an open loop payment account that may be utilized in association with a wide variety of merchants. Alternatively, an issued payment account may be a closed loop payment account (e.g., a merchant-specific payment account, a closed loop prepaid card, etc.) that would conventionally be intended for use at only designated merchant locations and/or within a predefined network. Embodiments of the disclosure may facilitate the decoupling of transaction processing rules from the issuer. As a result, it may be possible to utilize a closed loop payment account outside of a predefined network. Additionally, a wide variety of other parameters may be utilized in association with open loop and closed loop accounts.
  • In certain embodiments, an issuer may define one or more rules and/or parameters that will be utilized by the service provider to process a proposed transaction. Examples of suitable rules include, but are not limited to, merchant rules, merchant type or merchant category code (“MCC”) rules, product type rules, geographical rules, transaction amount and/or other monetary amount rules, temporal rules, and/or various incentive rules. Example merchant rules specify merchants and/or groups of merchants for which proposed transactions will be allowed. Example merchant type and/or MCC rules may specify types of merchants and/or MCCs for which proposed transactions will be allowed. Example geographical rules may establish geographical areas associated with a wide variety of different purposes, such as the allowance of a proposed transaction, the applicability of an incentive, and/or the applicability of other rules (e.g., monetary amount rules, etc.). Example transaction amount rules may establish various monetary thresholds associated with a wide variety of purposes, such as the allowance of a proposed transaction (e.g., a transaction under $50 at an out-of-network merchant will be allowed, etc.), the applicability of other rules, and/or the applicability of an incentive offer (e.g., a transaction utilizing a particular MCC that is above a designated amount will qualify for an incentive, etc.). Example monetary amount rules may look at monetary amounts other than a transaction amount, such as historical transaction amounts and/or average transaction amounts for a consumer. For example, if a historical consumer transaction exceeds a threshold value, then an incentive or other processing rules may be applicable to a proposed transaction. Example temporal rules may specify various time constraints for the acceptance of a transaction and/or the applicability of other rules (e.g., a transaction at a designated merchant within a designated time period (e.g., 30 days, etc.) following the delivery of an earlier incentive qualifies for a discount, etc.). Other rules may specify conditions for awarded and/or applying an incentive (e.g., a discount, a cash-back incentive, a loyalty points incentive, etc.). Indeed, a wide variety of different types of issuer rules may be utilized as desired in various embodiments of the disclosure. Additionally, a wide variety of rule combinations may be applicable to various proposed transactions.
  • Additionally, in certain embodiments, a consumer may define one or more rules preferences, and/or parameters associated with various payment accounts of the consumers. The consumer payment accounts may be associated with a wide variety of different issuers and/or merchants. In certain embodiments, a consumer may establish a wide variety of different rules and/or preferences associated with the selection of an account to be utilized in association with a proposed transaction. For example, the consumer may establish various merchant, merchant type, geographical, temporal, and/or monetary amount rules associated with the selection of a payment account for a proposed transaction. As one example, the consumer may specify a particular payment account to utilize (if supported) at grocery stores. As another example, the consumer may specify a particular payment account to utilize for transactions that exceed a threshold amount. In certain embodiments, the consumer may establish rules based upon a review of various incentives offered by merchants. For example, a consumer may establish rules in order to take advantage of an offered incentive. Additionally, in certain embodiments, the consumer may establish rules in association with a wide variety of different payment devices, such as a payment card, a contactless payment device, and/or a transaction-enabled mobile device. For example, the consumer may specify that when a first payment device is utilized, a first set of rules will be applied, while a second set of rules is utilized for a second payment device. As one example, the customer may specify that a particular payment account will be utilized if a payment device (e.g., payment card, etc.) is utilized at a designated merchant. Indeed, the consumer has flexibility to establish a wide variety of different rules and/or combinations of rules that will be evaluated in conjunction with proposed transactions.
  • The transaction processing module 147 may include any number of suitable software modules and/or applications that facilitate the storage of transaction processing rules and/or parameters, as well as the evaluation of proposed transactions. In operation, the transaction processing module 147 may direct the operations of a host module (e.g., the Web server) to facilitate the receipt a wide variety of different transaction processing rules from issuers, merchants, and/or consumers. The transaction processing module 147 may evaluate received rules, resolve conflicts between the rules, and/or establish a hierarchy for applying the rules to a proposed transaction. The transaction processing module 147 may then direct storage of the rules in one or more suitable databases 148.
  • The transaction processing module 147 may also be configured to receive information associated with a proposed transaction. For example, proposed transaction information may be received from a merchant computer or device 110 (e.g., a merchant point of sale device, etc.). As another example, proposed transaction information may be received from a merchant acquiring platform 155 or merchant gateway associated with a merchant computer 110. Following receipt of a proposed transaction, the transaction processing module 147 may identify one or more applicable rules, and the transaction processing module 147 may evaluate the proposed transaction utilizing the applicable rules. In this regard, the transaction processing module 147 may determine whether the proposed transaction may be routed to an issuer for approval and/or settlement processing. Alternatively, the transaction processing module 147 may determine a payment account to utilize in association with the proposed transaction. Indeed, the transaction processing module 147 may function as a cloud-level module that facilitates the decoupling of transaction processing rules from a payment account issuer.
  • A few examples of the operations that may be performed by the transaction processing module are described in greater detail below with reference to FIGS. 2-4.
  • With continued reference to the service provider computer 105, the one or more I/O interfaces 142 may facilitate communication between the service provider computer 105 and one or more input/output devices; for example, one or more user interface devices, such as a display, a keypad, a mouse, a pointing device, a control panel, a touch screen display, a remote control, a microphone, a speaker, etc., that facilitate user interaction with the service provider computer 105. The one or more network interfaces 143 may facilitate connection of the service provider computer 105 to one or more suitable networks, for example, the network(s) 125, 130, 135 illustrated in FIG. 1. In this regard, the service provider computer 105 may receive and/or communicate information to other components of the system 100.
  • With continued reference to FIG. 1, any number of merchant computers 110 may be provided. In certain embodiments, a merchant computer 110 may be a suitable point-of-sale (“POS”) device (e.g., a POS terminal) located at a physical merchant location. In other embodiments, a merchant computer 110 may be a suitable server that facilitates the processing of online purchase transactions. As desired, each merchant computer 110 may include any number of processor-driven devices, including but not limited to, a server computer, a mainframe computer, one or more networked computers, a desktop computer, a personal computer, a laptop computer, a mobile computer, or any other processor-based device. A merchant computer 110 may utilize one or more processors 160 to execute computer-readable instructions that facilitate the processing of transaction requests, the generation of proposed transactions, and/or the communication of proposed transactions to a processing entity (e.g., an acquiring platform, a service provider computer 105, etc.). As a result of executing these computer-readable instructions, a special purpose computer or particular machine may be formed that facilitates the generation and/or output of proposed transactions. Additionally, in certain embodiments, a merchant computer 110 (which may or may not be located at a POS) may utilize the one or more processors 160 to execute computer-readable instructions that facilitate the provision of issuer and/or merchant rules to the service provider computer 105.
  • In addition to having one or more processors 160, the merchant computer 110 may further include and/or be associated with one or more memory devices 161, consumer device readers 162, input/output (“I/O”) interface(s) 163, and/or network interface(s) 164. The memory 161 may be any computer-readable medium, coupled to the processor(s) 160, such as random access memory (“RAM”), read-only memory (“ROM”), and/or removable storage devices. The memory 161 may store a wide variety of data files 165 and/or various program modules, such as an operating system (“OS”) 166, and/or a transaction module 167. The data files 165 may include any suitable data that facilitates the operation of the merchant computer 110 and/or interaction of the merchant computer 110 with one or more other components of the system 100. For example, the data files 165 may include acquiring platform information, service provider information, and/or routing information for proposed transactions. The OS 166 may be suitable module that facilitates the general operation of the merchant computer 110, as well as the execution of other program modules. For example, the OS 166 may be, but is not limited to, Microsoft Windows®, Apple OSX™, Unix, a mainframe computer operating system (e.g., IBM z/OS, MVS, OS/390, etc.), or a specially designed operating system. As desired, the merchant computer 110 may additionally include one or more host modules that facilitate interaction with remote consumer devices 115. For example, a suitable Web server and/or Web server module may facilitate online shopping by consumers and/or the receipt of transaction requests.
  • The transaction module 167 may include any number of suitable software modules and/or applications that facilitate the receipt of transaction information, the receipt of payment account information from a consumer device, the generation of a proposed transaction, and/or the output of the proposed transaction. In one example embodiment, the transaction module 167 may identify a wide variety of transaction information, such as identifiers of products to be purchased (e.g., UPC identifiers, etc.), amounts associated with the products, and/or a total transaction amount. Additionally, the transaction module 167 may receive payment account information collected from a consumer device. For example, the transaction module 167 may interact with a consumer device reader 162 to receive payment account information at a point of sale. As another example, the transaction module 167 may receive payment account information via one or more suitable networks 125, such as the Internet. Following the identification of transaction information and payment account information, the transaction module 167 may generate a proposed transaction or proposed transaction request, and the transaction module 167 may direct communication of the proposed transaction to a suitable entity for processing. For example, the proposed transaction may be output for communication to an acquiring platform 155, and the acquiring platform 155 may forward the proposed transaction to the service provider computer 105. As another example, the proposed transaction may be output for communication to the service provider computer 105. In certain embodiments, the service provider computer 105 may be associated with a particular acquiring platform 155. Alternatively, the service provider computer 105 may communicate with a plurality of different acquiring platforms. Following, the output of a proposed transaction, the transaction module 167 may receive and process a wide variety of responses, such as an approval of the proposed transaction, a denial of the proposed transaction, and/or messages associated with applied rules and/or identified incentives.
  • With continued reference to the merchant computer 110, one or more consumer device readers 162 may be provided in certain embodiments. A consumer device reader 162 may facilitate communication with a consumer device at a point of sale. For example, a consumer device reader 162 may facilitate the reading of payment account information from a consumer device. A wide variety of different types of consumer device readers may be utilized as desired in various embodiments of the disclosure, including but not limited to, magnetic stripe readers, radio frequency readers, near field communication readers, etc. In certain embodiments, a reader 162 may be incorporated into the merchant computer 110. In other embodiments, a reader 162 may be in communication with the merchant computer 110.
  • The one or more I/O interfaces 163 may facilitate communication between the merchant computer 110 and one or more input/output devices; for example, one or more user interface devices, such as a display, a keypad, a mouse, a pointing device, a control panel, a touch screen display, a remote control, a microphone, a speaker, a consumer device reader 162, etc., that facilitate user interaction with the service provider computer 105. The one or more network interfaces 164 may facilitate connection of the merchant computer 110 to one or more suitable networks, for example, the network(s) 125, 135 illustrated in FIG. 1. In this regard, the merchant computer 110 may receive and/or communicate information to other components of the system 100.
  • Additionally, with continued reference to FIG. 1, any number of consumer devices 115 may be provided. Examples of suitable consumer devices 115 include, but are not limited to, transaction cards, contactless transaction devices (e.g., transaction devices including a contactless chip, etc.), mobile devices (e.g., mobile phones, smart phones, etc.), and/or personal computers. Certain consumer devices 115, such as mobile devices and/or personal computers, may be utilized by a consumer to provide consumer rules and/or preferences to the service provider computer 105. For example, a consumer may utilize a consumer device 115 to access a Web server 150 that presents one or more Web pages that facilitate the provision of rules and/or parameters to the service provider computer. Additionally, various consumer devices 115 may facilitate the provision of payment account information to a merchant computer 110 in association with a proposed transaction. For example, a payment card, contactless device, or a transaction-enabled mobile device (e.g., a mobile device including NFC or other contactess technology) may be presented at a point of sale to provide payment account information to a merchant computer 110. As another example, a personal computer or mobile device may be utilized to access a Web site of the merchant via one or more suitable networks 125 (e.g., the Internet, a cellular network, etc.) and a purchase transaction may be requested. During a purchase request, various payment account information may be provided to a merchant computer 110 by the consumer device 115. As desired, certain consumer devices 115 may be processor-driven devices that include components similar to those described above for the service provider computer 105 and/or the merchant computer 110. For example, certain consumer devices 115 may include one or more processors, memory devices, I/O interfaces, and/or network interfaces.
  • With continued reference to FIG. 1, any number of issuer and/or financial institution systems 120 may be provided. An issuer system 120 may facilitate the backend processing of a proposed transaction. For example, an issuer system 120 may facilitate the approval and/or settlement of a proposed transaction. In certain embodiments, a proposed transaction may be routed to an issuer system 120 via a suitable transaction network 135, and the issuer system 120 may evaluate the proposed transaction. An approval or rejection of the proposed transaction may then be output for communication to a merchant computer 110. The issuer system 120 may then facilitate the settlement of the proposed transaction.
  • Additionally, as desired in various embodiments, an issuer system 120 (which may or may not be associated with a merchant) may provide a wide variety of rules and/or parameters to the service provider computer 105. For example, rules may be provided to an associated Web server 150 via one or more suitable networks 130. As another example, rules may be provided via an interprocess communication and/or via any number of suitable communication techniques. As desired, an issuer system 120 may be or may include any number processor-driven devices that include components similar to those described above for the service provider computer 105 and/or the merchant computer 110. For example, an issuer device 120 may include one or more processors, memory devices, I/O interfaces, and/or network interfaces that facilitate the operations of the issuer device 120.
  • A wide variety of suitable networks 125, 130, 135 may be utilized in association with embodiments of the disclosure. Certain networks 125, 130 (which may be the same network or different networks) may facilitate the communication of rules to the service provider computer 105 and/or the communication of transaction requests (e.g., eCommerce requests) from the consumer devices 115 to merchant computers 110. These networks 125, 130 may include any telecommunication and/or data network, whether public, private, or a combination thereof, including a local area network, a wide area network, an intranet, an internet, the Internet, intermediate handheld data transfer devices, a publicly switched telephone network (“PSTN”), a cellular network, and/or any combination thereof and may be wired and/or wireless. Other networks 135 may be suitable transaction networks that facilitate the routing of proposed transactions. These transaction networks 135 may include branded networks (e.g., a VISA network, etc.), debit and/or PIN networks, and/or a wide variety of other suitable transaction networks. Due to network connectivity, various methodologies as described herein may be practiced in the context of distributed computing environments. It will also be appreciated that the various networks may include a plurality of networks, each with devices such as gateways and routers for providing connectivity between or among networks. Additionally, instead of, or in addition to, a network, dedicated communication links may be used to connect various devices in accordance with an example embodiment.
  • In one example implementation of the system 100, a service provider may collect rules and/or parameters from a wide variety of different entities and/or devices, such as payment account issuers, merchants, and/or consumers. These various rules and/or parameters may be stored for subsequent use in processing proposed transactions. Following the storage of rules and/or parameters, a consumer may utilize a consumer device 115 to provide payment account information to a merchant system 110. For example, a consumer may present a payment card, contactless device, or mobile device at a merchant point of sale, and payment account information may be read from the consumer device. As another example, a consumer may provide payment account information to a merchant system 110 in association with an eCommerce or Web-based transaction. The merchant computer 110 may generate a proposed transaction, and the merchant computer 110 may output the proposed transaction for communication to the service provider computers 105 either directly or via one or more other entities, such as an acquiring platform 155. The service provider computers 105 may utilize at least a portion of the stored rules to process the proposed transaction, and the service provider computers 105 may optionally direct the routing of the proposed transaction to a suitable and/or identified issuer or financial institution system for authorization and/or settlement. As a result, the application of processing rules may be decoupled from an issuer of a payment account. Accordingly, it may be possible to utilize closed loop payment accounts in association with other merchants. Additionally, a wide variety of other processing rules and/or parameters may be applied to a proposed transaction in order to determine whether a payment account is appropriate and/or to select a payment account to be utilized.
  • The system 100 shown in and described with respect to FIG. 1 is provided by way of example only. Numerous other operating environments, system architectures, and device configurations are possible. Other system embodiments can include fewer or greater numbers of components and may incorporate some or all of the functionality described with respect to the system components shown in FIG. 1. Accordingly, embodiments of the disclosure should not be construed as being limited to any particular operating environment, system architecture, or device configuration.
  • Operational Overview
  • FIG. 2 illustrates a flow diagram of an example method 200 for storing rules, restrictions, and/or preferences associated with the use of a payment account, according to an example embodiment of the disclosure. In certain embodiments, the operations of the method 200 may be performed by a suitable service provider computer and/or associated Web servers, such as the service provider computer 105 and Web servers 150 illustrated in FIG. 1. The method 200 may begin at block 205.
  • At block 205, one or more payment accounts associated with an issuer (e.g., a payment account issuer) may be identified or determined. In certain embodiments, the payment accounts may be identified based at least in part upon information received from the issuer, such as a list of issuer payment accounts for which rules should be associated. At block 210, one or more issuer restrictions and/or rules associated with user of the identified payment accounts may be received and/or otherwise obtained. For example, one or more issuer rules may be received in a batch file communication, an interprocess communication, or another communication with an issuer (or merchant) system. As another example, an employee of an issuer may access the one or more Web servers 150, and the issuer restrictions may be entered, established, and/or modified via one or more Web pages provided by the Web servers 150. For example, one or more Web pages may provide options for defining rules associated with payment accounts, and selections of the various options may be received and processed in order to establish one or more issuer rules. Following the receipt of issuer rules, the rules may be stored for subsequent access.
  • As desired in various embodiments, a wide variety of different types of issuer rules may be received, obtained, and/or identified. In certain embodiments, the issuer rules may be associated with various merchants and/or merchant types (e.g., MCCs) for which transactions associated with a payment account may be processed. A wide variety of other parameters and/or conditions may be associated with the issuer rules, including but not limited to, geographical parameters, temporal parameters, transaction amount parameters, and/or other monetary amount parameters. As one example, the issuer rules may specify one or more merchants at which a payment account may be utilized and/or conditions associated with processing transactions associated with the payment account. In this regard, an issuer of a closed loop payment account may allow the payment account to be utilized at merchants outside of the closed loop. Additionally, the issuer may specify one or more conditions associated with use of the payment account at the merchants. For example, an issuer (e.g., a retailer) may allow a payment account to be utilized at grocery stores while preventing use of the payment account at competitors. As another example, an issuer may allow a payment account to be utilized at a designated merchant if the transaction amount is lower than a predetermined threshold value.
  • In certain embodiments, the issuer rules may specify one or more incentives and/or special offers (e.g., discounts, cash back offers, loyalty offers, etc.) associated with the issuer. The issuer rules may additionally specify one or more conditions for applying an incentive. For example, an issuer may offer loyalty points for transactions completed at particular merchants and/or merchant types, such as merchants outside of a closed loop. As another example, an issuer may typically provide for a predetermined cash back incentive (e.g., 3%, etc.) in the event that the payment account is utilized at certain types of merchants (e.g., grocery stores, pharmacies, gas stations, etc.). The issuer may then provide for an increased incentive (e.g., 5%, etc.) in the event that one or more additional conditions are met. For example, transactions for more than a predetermined threshold or transactions made within a specified time period may quality for an increased incentive. A wide variety of other incentives may be established as desired in various embodiments of the disclosure.
  • At block 215, payment account information and/or at least a portion of the issuer rules and/or restrictions (e.g., incentive offers, payment account limitations, etc.) may be presented to a consumer associated with a payment account. For example, a consumer may utilize a suitable consumer device to access one or more Web pages hosted by the Web server. In this regard, the consumer may identify payment accounts associated with the consumer, and the consumer may view various issuer rules and/or incentives associated with the payment accounts. At block 220, one or more consumer preferences associated with the use of the consumer's payment accounts and/or consumer payment devices (e.g., payment cards, transaction-enabled mobile devices, etc.) may be received and/or obtained. For example, the consumer may utilize various options presented by the Web pages in order to specify one or more consumer rules.
  • A wide variety of consumer rules may be utilized as desired in various embodiments of the disclosure. Examples of suitable consumer rules may include rules associated with various merchants at which a payment account will be utilized, rules associated with various merchant types (e.g., MCCs) at which a payment account will be utilized, geographic and/or temporal rules associated with the use of a payment account, product type rules associated with use of a payment account, and/or various transaction and/or other amount rules associated with the use of a payment account. As desired, a combination of any of these rules may be associated with a payment account. For example, the consumer may specify that transactions associated with a particular merchant over a specified time period (e.g., the next 30 days, etc.) will be facilitated utilizing a particular payment account.
  • Additionally, certain consumer rules may be associated with the use of various consumer payment devices. For example, the consumer may specify different rules for different payment devices, such as different payment cards and/or other payment devices (e.g., contactless devices, transaction-enabled mobile devices, specific payment applications stored on mobile devices, etc.). For example, the consumer may specify that if a particular payment device is utilized at a particular merchant or merchant type, then a certain payment account should be utilized for the transaction. Other examples will be appreciated in light of the disclosure set forth herein. Indeed, embodiments of the disclosure may provide a consumer with relatively wide flexibility in defining rules that are applicable to various types of transactions.
  • At block 225, a wide variety of incentives and/or rewards associated with the use of one or more consumer payment accounts may be determined and/identified. For example, correspondences and/or matches between issuer-specified conditions for incentives and consumer rules for selecting a payment account may be determined. In the event that a correspondence is found, a determination may be made that a consumer may potentially qualify for a given incentive. As desired, information associated with the determined correspondence may be stored. Alternatively, in other embodiments, incentive qualification determination may be made during the processing of proposed transaction rather than prior to the processing of a proposed transaction.
  • At block 230, a wide variety of payment account information may be stored by the service provider computer 105 for subsequent access during the processing of proposed payment transactions. For example, identification information for one or more payment accounts for a consumer, consumer rules associated with the payment accounts and/or various consumer devices, issuer rules associated with the payment accounts, and/or incentive determinations may be stored for subsequent access.
  • The method 200 may end following block 230.
  • FIG. 3 illustrates a flow diagram of one example method 300 for processing a proposed payment transaction, according to an example embodiment of the disclosure. In certain embodiments, the operations of the method 300 may be performed by a suitable service provider computer, such as the service provider computer 105 illustrated in FIG. 1. The method 300 may begin at block 305.
  • At block 305, information associated with a proposed transaction may be received. The information may be received from a merchant computer, from an acquiring platform associated with the merchant, and/or from another suitable entity. A wide variety of different types of information associated with a proposed transaction may be received as desired in various embodiments, including but not limited to, merchant identification information, merchant type (e.g., MCC) information, consumer identification information, identification information for a consumer device, consumer account information, transaction amount information, and/or information associated with one or more purchased products and/or services.
  • At block 310, a designated payment account may be identified. For example, the received transaction information may be evaluated in order to identify a payment account number for a designated payment account. As another example, identification information for a payment device (e.g., a mobile identifier, a secure element identifier for a mobile device, etc.) may be evaluated in order to identify a designated payment account. At block 315, a merchant and/or a merchant type associated with the proposed transaction may be identified. For example, a merchant identifier and/or an MCC associated with the proposed transaction may be identified. As desired, other information associated with the proposed transaction may be identified, such as a geographical location associated with the merchant and/or the consumer, a transaction date, and/or a transaction amount.
  • At block 320, one or more stored rules and/or parameters associated with the designated payment account may be accessed from memory or otherwise identified (e.g., obtained from an external data source, etc.). A wide variety of rules and/or parameters may be accessed as desired in various embodiments of the disclosure, including issuer rules and/or consumer rules. At block 325, the proposed transaction may be evaluated or analyzed utilizing the accessed rules and/or parameters. For example, one or more rules associated with the use of the payment account may be compared to one or more transaction parameters. In this regard, a determination may be made as to whether the designated payment account may be utilized in association with the proposed transaction.
  • At block 330, a determination may be made as to whether the various rules and/or parameters have been satisfied. For example, a determination may be made as to whether the rules permit the payment account to be utilized at the identified merchant and/or in association with the designated merchant type. As another example, a determination may be made as to whether geographical, temporal, payment amount, and/or other parameters associated with the use of the payment account have been satisfied. Additionally, as desired, a determination may be made as to whether an incentive should be applied to the proposed transaction. In the event that one or more incentive rules have been satisfied, the incentive may be applied to the transaction or an indication may be associated with the proposed transaction to specify that an incentive should be applied.
  • If it is determined at block 330 that the various rules and/or parameters have not been satisfied, then operations may continue at block 335. At block 335, a rejection for the proposed transaction may be generated, and the generated rejection may be output for communication to the merchant device that submitted the proposed transaction. If, however, it is determined at block 330 that the various rules and/or parameters have been satisfied, then operations may continue at block 340. At block 340, the proposed transaction may be approved for routing or other communication to an issuer or financial institution system. In this regard, authorization and/or settlement of the proposed transaction may be performed by the issuer or financial institution system.
  • The method 300 may end following either block 335 or block 340.
  • FIG. 4 illustrates a flow diagram of another example method 400 for processing a proposed payment transaction and selecting a payment account to be utilized in association with the proposed payment transaction, according to an example embodiment of the disclosure. In certain embodiments, the operations of the method 400 may be performed by a suitable service provider computer, such as the service provider computer 105 illustrated in FIG. 1. The method 400 may begin at block 405.
  • At block 405, information associated with a proposed transaction may be received. The information may be received from a merchant computer, from an acquiring platform associated with the merchant, and/or from another suitable entity. A wide variety of different types of information associated with a proposed transaction may be received as desired in various embodiments, including but not limited to, merchant identification information, merchant type (e.g., MCC) information, consumer identification information, identification information for a consumer device, identification information for one or more payment accounts for the consumer, transaction amount information, geographical location information for the merchant and/or the consumer, and/or information associated with one or more purchased products and/or services.
  • At block 410, the proposed transaction may be identified as a decoupled transaction. In other words, the proposed transaction may be identified as a transaction in which payment eligibility determinations and/or other payment conditions are decoupled from one or more payment account issuers that ultimately authorize and/or settle the proposed transaction. A wide variety of suitable methods and/or techniques may be utilized as desired to identify the proposed transaction as a decoupled transaction. For example, an identified consumer payment device and/or various received payment account information (e.g., a portion of a payment account number, etc.) may be evaluated in order to identify the proposed transaction as a decoupled transaction.
  • At block 415, a consumer associated with the proposed transaction may be identified. For example, identification information for a consumer payment device (e.g., a mobile device identifier, a secure element identifier, etc.) and/or received information associated with one or more payment account numbers may be utilized to identify a consumer. Additionally, at block 420, information associated with the proposed transaction may be utilized to identify a merchant and/or a merchant type (e.g., MCC, etc.) associated with the proposed transaction. As desired, a wide variety of other factors associated with the proposed transaction may also be identified, such as a transaction date and time, a geographical location of the merchant and/or the consumer, and/or a transaction amount.
  • At block 425, one or more rules for selecting a payment account may be accessed from memory and/or one or more external storage devices. For example, one or more consumer-specified rules associated with selecting a payment account may be accessed. Additionally, one or more issuer-specified rules associated with one or more payment accounts of the consumer may be accessed. At block 430, the proposed transaction may be evaluated utilizing at least a portion of the accessed rules. In this regard, a payment account to utilize for the proposed transaction may be selected at block 435. A wide variety of rules may be implemented in order to select a payment account for the proposed transaction. As one example, consumer payment device information (e.g., a mobile device identifier, a payment application identifier, a payment account number read from a payment device, etc.) may be utilized in conjunction with merchant information and/or other transaction parameters (e.g., geographical location, temporal parameters, amount parameters, etc.) in order to identify a payment account preference of the consumer. Additionally, one or more issuer rules may be evaluated in order to determine whether the consumer-preferred payment account is acceptable for use in conjunction with the proposed transaction. In the event that the consumer-preferred account is not acceptable, then another consumer payment account may be selected and evaluated in order to determine whether it is acceptable for use. Indeed, a wide variety of consumer and/or issuer rules may be evaluated in order to select a payment account for the proposed transaction. Additionally, a wide variety of issuer rules may be utilized to determine whether the proposed transaction qualifies for any incentives.
  • At block 440, the proposed transaction may be approved for routing and/or routed to a processing system associated with the selected payment account. For example, the proposed transaction may be routed to an issuer system and/or a financial institution system associated with the selected payment account. In this regard, authorization and/or settlement of the proposed transaction may be facilitated.
  • The method 400 may end following block 440.
  • The operations described and shown in the methods 200, 300, 400 of FIGS. 2-4 may be carried out or performed in any suitable order as desired in various embodiments of the disclosure. Additionally, in certain embodiments, at least a portion of the operations may be carried out in parallel. Furthermore, in certain embodiments, less than or more than the operations described in FIGS. 2-4 may be performed.
  • The disclosure is described above with reference to block and flow diagrams of systems, methods, apparatuses, and/or computer program products according to example embodiments of the disclosure. It will be understood that one or more blocks of the block diagrams and flow diagrams, and combinations of blocks in the block diagrams and the flow diagrams, respectively, can be implemented by computer-executable program instructions. Likewise, some blocks of the block diagrams and flow diagrams may not necessarily need to be performed in the order presented, or may not necessarily need to be performed at all, according to some embodiments of the disclosure.
  • Various block and/or flow diagrams of systems, methods, apparatus, and/or computer program products according to example embodiments of the disclosure are described above. It will be understood that one or more blocks of the block diagrams and flow diagrams, and combinations of blocks in the block diagrams and flow diagrams, respectively, can be implemented by computer-executable program instructions. Likewise, some blocks of the block diagrams and flow diagrams may not necessarily need to be performed in the order presented, or may not necessarily need to be performed at all, according to some embodiments of the disclosure.
  • These computer-executable program instructions may be loaded onto a special purpose computer or other particular machine, a processor, or other programmable data processing apparatus to produce a particular machine, such that the instructions that execute on the computer, processor, or other programmable data processing apparatus create means for implementing one or more functions specified in the flow diagram block or blocks. These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means that implement one or more functions specified in the flow diagram block or blocks. As an example, embodiments of the disclosure may provide for a computer program product, comprising a computer-usable medium having a computer-readable program code or program instructions embodied therein, said computer-readable program code adapted to be executed to implement one or more functions specified in the flow diagram block or blocks. The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational elements or steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions that execute on the computer or other programmable apparatus provide elements or steps for implementing the functions specified in the flow diagram block or blocks.
  • Accordingly, blocks of the block diagrams and flow diagrams support combinations of means for performing the specified functions, combinations of elements or steps for performing the specified functions and program instruction means for performing the specified functions. It will also be understood that each block of the block diagrams and flow diagrams, and combinations of blocks in the block diagrams and flow diagrams, can be implemented by special purpose, hardware-based computer systems that perform the specified functions, elements or steps, or combinations of special purpose hardware and computer instructions.
  • Many modifications and other embodiments of the disclosure set forth herein will be apparent having the benefit of the teachings presented in the foregoing descriptions and the associated drawings. Therefore, it is to be understood that the disclosure is not to be limited to the specific embodiments disclosed and that modifications and other embodiments are intended to be included within the scope of the appended claims. Although specific terms are employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.

Claims (6)

    The claimed disclosure is:
  1. 1. A system comprising:
    at least one memory configured to store computer-executable instructions; and
    at least one processor configured to access the at least one memory and execute the computer-executable instructions to:
    receive information associated with a proposed transaction;
    identify a closed loop payment account associated with the proposed transaction based at least in part on the information associated with the proposed transaction;
    determine the proposed transaction is a decoupled transaction based at least in part on the information associated with the proposed transaction;
    determine whether one or more issuer rules associated with the closed loop payment account have been satisfied;
    if the one or more issuer rules associated with the closed loop payment account have been satisfied, transmitting an approval of the proposed transaction; and
    if the one or more issuer rules associated with the closed loop payment account have not been satisfied, transmitting a rejection of the proposed transaction.
  2. 2. The system of claim 1, wherein the at least one processor is further configured to execute the computer-executable instructions to:
    receive the one or more issuer rules in a batch file communication or an interprocess communication; and
    store the received one or more issuer rules.
  3. 3. The system of claim 1, wherein the one or more issuer rules associated with the one or more closed loop payment accounts comprise at least one of geographical parameters, temporal parameters, transaction amount parameters, monetary amount parameters or identification of one or more merchants.
  4. 4. The system of claim 1, wherein the one or more issuer rules associated with the one or more closed loop payment accounts comprise one or more incentives or special offers.
  5. 5. The system of claim 1, wherein the at least one processor is further configured to execute the computer-executable instructions to:
    identify a consumer based at least in part on the information associated with the proposed transaction;
    store the identification of the payment account or the identification of the consumer payment device associated with the consumer.
  6. 6. The system of claim 1, wherein if the one or more issuer rules associated with the closed loop payment account have not been satisfied, the at least one processor is further configured to execute the computer-executable instructions to:
    identify a consumer associated with the closed loop payment account;
    retrieve information for a second payment account associated with the consumer; and
    facilitate the proposed transaction based at least in part on the information for the second payment account.
US14456804 2011-09-26 2014-08-11 Systems and methods for processing payment transactions Pending US20140351142A1 (en)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US201161539206 true 2011-09-26 2011-09-26
US13627654 US8924300B2 (en) 2011-09-26 2012-09-26 Systems and methods for processing payment transactions
US14456804 US20140351142A1 (en) 2011-09-26 2014-08-11 Systems and methods for processing payment transactions

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US14456804 US20140351142A1 (en) 2011-09-26 2014-08-11 Systems and methods for processing payment transactions

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US13627654 Division US8924300B2 (en) 2011-09-26 2012-09-26 Systems and methods for processing payment transactions

Publications (1)

Publication Number Publication Date
US20140351142A1 true true US20140351142A1 (en) 2014-11-27

Family

ID=47912273

Family Applications (6)

Application Number Title Priority Date Filing Date
US13627678 Pending US20130080236A1 (en) 2011-09-26 2012-09-26 Systems and Methods for Enrolling Consumers in Loyalty Programs
US13627670 Active 2036-01-25 US10089617B2 (en) 2011-09-26 2012-09-26 Systems and methods for facilitating card present transactions
US13627683 Pending US20130080219A1 (en) 2011-09-26 2012-09-26 Systems and Methods for Providing Value Added Services in Association with Payment Transactions
US13627654 Active 2032-10-15 US8924300B2 (en) 2011-09-26 2012-09-26 Systems and methods for processing payment transactions
US13627665 Active US8688604B2 (en) 2011-09-26 2012-09-26 Systems and methods for facilitating communication between a point of sale device and a consumer device
US14456804 Pending US20140351142A1 (en) 2011-09-26 2014-08-11 Systems and methods for processing payment transactions

Family Applications Before (5)

Application Number Title Priority Date Filing Date
US13627678 Pending US20130080236A1 (en) 2011-09-26 2012-09-26 Systems and Methods for Enrolling Consumers in Loyalty Programs
US13627670 Active 2036-01-25 US10089617B2 (en) 2011-09-26 2012-09-26 Systems and methods for facilitating card present transactions
US13627683 Pending US20130080219A1 (en) 2011-09-26 2012-09-26 Systems and Methods for Providing Value Added Services in Association with Payment Transactions
US13627654 Active 2032-10-15 US8924300B2 (en) 2011-09-26 2012-09-26 Systems and methods for processing payment transactions
US13627665 Active US8688604B2 (en) 2011-09-26 2012-09-26 Systems and methods for facilitating communication between a point of sale device and a consumer device

Country Status (1)

Country Link
US (6) US20130080236A1 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016196449A1 (en) * 2015-06-01 2016-12-08 Jpmorgan Chase Bank, N.A. System and method for loyalty integration for merchant specific digital wallets

Families Citing this family (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2011127084A3 (en) 2010-04-05 2011-12-29 Vivotech, Inc. Systems, methods, and computer readable media for performing multiple transactions through a single near field communication (nfc) tap
US8799087B2 (en) * 2010-10-27 2014-08-05 Mastercard International Incorporated Systems, methods, and computer readable media for utilizing one or more preferred application lists in a wireless device reader
US8538845B2 (en) 2011-06-03 2013-09-17 Mozido, Llc Monetary transaction system
US20130080236A1 (en) 2011-09-26 2013-03-28 First Data Corporation Systems and Methods for Enrolling Consumers in Loyalty Programs
US9208488B2 (en) 2011-11-21 2015-12-08 Mozido, Inc. Using a mobile wallet infrastructure to support multiple mobile wallet providers
US20140006136A1 (en) * 2012-06-28 2014-01-02 Bank Of America Corporation Expedited registration and processing of offers at a point of transaction
US20140006272A1 (en) * 2012-06-28 2014-01-02 Bank Of America Corporation Notifying mobile device users of a suggested payment type prior to conducting a transaction at a merchant
US20140164193A1 (en) * 2012-12-11 2014-06-12 Toshiba Tec Kabushiki Kaisha Electronic receipt system, commodity sales data processing apparatus, electronic receipt management server and method
US20140222597A1 (en) * 2013-02-04 2014-08-07 Mastercard International Incorporated Intelligent mobile payment system and method
US20140297472A1 (en) * 2013-03-27 2014-10-02 Michael Joseph Ryan Anonymous check-in at a merchant location
US20140304158A1 (en) * 2013-04-05 2014-10-09 Gourab Basu Processor Issuer Detection and User Level Stand-In Authorization
US20150032642A1 (en) * 2013-07-26 2015-01-29 Bank Of America Corporation Use of an e-receipt to verify ownership and service of a product
EP3028227A1 (en) 2013-07-29 2016-06-08 ExxonMobil Research and Engineering Company System and method to purchase and dispense fuel and other products using a mobile device with improved user experience
US9589265B2 (en) * 2013-09-11 2017-03-07 Chien-Kang Yang Mobile payment method
US8812705B1 (en) * 2013-10-15 2014-08-19 Google Inc. Accessing location-based content
WO2015066083A1 (en) * 2013-10-28 2015-05-07 Firstnod, Llc System and method for merchandising
US9785940B2 (en) 2014-03-27 2017-10-10 Bank of the Ozarks System and method for distributed real time authorization of payment transactions
US9830606B2 (en) * 2014-10-31 2017-11-28 Visa International Services Association Systems and methods for enrolling a user in a membership account
US20160294967A1 (en) * 2015-03-31 2016-10-06 Toshiba Global Commerce Solutions Holdings Corporation Discoverable and shareable device brokers in pos system
US20170278124A1 (en) * 2016-03-28 2017-09-28 Visa International Service Association Merchant loyalty account enrollment through payment checkout platform services

Citations (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5717989A (en) * 1994-10-13 1998-02-10 Full Service Trade System Ltd. Full service trade system
US20020062249A1 (en) * 2000-11-17 2002-05-23 Iannacci Gregory Fx System and method for an automated benefit recognition, acquisition, value exchange, and transaction settlement system using multivariable linear and nonlinear modeling
US20030069737A1 (en) * 2001-10-04 2003-04-10 Netscape Communications Corporation Hierarchical rule determination system
US20030069736A1 (en) * 2001-10-04 2003-04-10 Netscape Communications Corporation Inheritance and relationship to directory information in an e-commerce application
US20040049452A1 (en) * 2002-09-09 2004-03-11 First Data Corporation Multiple credit line presentation instrument
US20060235795A1 (en) * 2005-04-19 2006-10-19 Microsoft Corporation Secure network commercial transactions
US20080021787A1 (en) * 2006-07-14 2008-01-24 Mackouse Jack Customer controlled account, system, and process
US20080149707A1 (en) * 2006-10-19 2008-06-26 Alfred Urcuyo Bank card management system
US20100063903A1 (en) * 2008-03-10 2010-03-11 Thayne Whipple Hierarchically applied rules engine ("hare")
US20100274678A1 (en) * 2009-04-22 2010-10-28 Gofigure Payments, Llc Systems, methods and devices for facilitating mobile payments
US20100312700A1 (en) * 2008-11-08 2010-12-09 Coulter Todd R System and method for managing status of a payment instrument
US20100312636A1 (en) * 2008-11-08 2010-12-09 Coulter Todd R System and method for applying stored value to a financial transaction
US20110035278A1 (en) * 2009-08-04 2011-02-10 Visa U.S.A. Inc. Systems and Methods for Closing the Loop between Online Activities and Offline Purchases
US20110137740A1 (en) * 2009-12-04 2011-06-09 Ashmit Bhattacharya Processing value-ascertainable items
US20110251892A1 (en) * 2010-04-09 2011-10-13 Kevin Laracey Mobile Phone Payment Processing Methods and Systems
US20110276475A1 (en) * 2010-05-04 2011-11-10 Cheryl Godejohn Payment transaction dispute resolution system
US20130282563A1 (en) * 2011-08-31 2013-10-24 First Data Corporation Systems and Methods for Routing Debit Transactions
US8768838B1 (en) * 2005-02-02 2014-07-01 Nexus Payments, LLC Financial transactions using a rule-module nexus and a user account registry
US20140250004A1 (en) * 2011-06-20 2014-09-04 Amazon Technologies, Inc. Coupling Prepaid Debit Cards to Online Stored-Value Accounts

Family Cites Families (51)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5566327A (en) 1994-07-08 1996-10-15 Sehr; Richard P. Computerized theme park information management system utilizing partitioned smart cards and biometric verification
US20020055906A1 (en) * 1998-03-11 2002-05-09 Katz Ronald A. Methods and apparatus for intelligent selection of goods and services in telephonic and electronic commerce
US7364068B1 (en) * 1998-03-11 2008-04-29 West Corporation Methods and apparatus for intelligent selection of goods and services offered to conferees
US6505772B1 (en) * 2000-06-22 2003-01-14 First Data Corporation System for utilizing a single card to provide multiple services in an open network environment
US7119659B2 (en) * 2001-07-10 2006-10-10 American Express Travel Related Services Company, Inc. Systems and methods for providing a RF transaction device for use in a private label transaction
US7099850B1 (en) * 2001-09-21 2006-08-29 Jpmorgan Chase Bank, N.A. Methods for providing cardless payment
US8046238B2 (en) * 2001-12-20 2011-10-25 Accenture Global Services Limited Business transaction management
US7822688B2 (en) * 2002-08-08 2010-10-26 Fujitsu Limited Wireless wallet
US7494055B2 (en) 2002-09-17 2009-02-24 Vivotech, Inc. Collaborative negotiation techniques for mobile personal trusted device financial transactions
US20040083170A1 (en) * 2002-10-23 2004-04-29 Bam Ajay R. System and method of integrating loyalty/reward programs with payment identification systems
US20040122685A1 (en) * 2002-12-20 2004-06-24 Daryl Bunce Verification system for facilitating transactions via communication networks, and associated method
US20040249710A1 (en) * 2003-05-16 2004-12-09 David Smith Methods and apparatus for implementing loyalty programs using portable electronic data storage devices
WO2005048145B1 (en) 2003-10-13 2005-07-07 Starbucks Corp D B A Starbucks Dual card
US20050192895A1 (en) * 2004-02-10 2005-09-01 First Data Corporation Methods and systems for processing transactions
US20050250538A1 (en) * 2004-05-07 2005-11-10 July Systems, Inc. Method and system for making card-based payments using mobile devices
US20100205091A1 (en) * 2004-10-22 2010-08-12 Zevez Payments, Inc. Automated payment transaction system
US7912770B2 (en) * 2004-10-29 2011-03-22 American Express Travel Related Services Company, Inc. Method and apparatus for consumer interaction based on spend capacity
US7578430B2 (en) * 2004-12-06 2009-08-25 First Date Corporation Loyalty program enrollment systems and methods
US20060208065A1 (en) * 2005-01-18 2006-09-21 Isaac Mendelovich Method for managing consumer accounts and transactions
US8700729B2 (en) * 2005-01-21 2014-04-15 Robin Dua Method and apparatus for managing credentials through a wireless network
US20060229974A1 (en) * 2005-04-11 2006-10-12 I4 Licensing Llc Method of extending credit to at least one consumer and method of processing a transaction between a consumer and a merchant
US8452654B1 (en) * 2005-06-16 2013-05-28 Rbs Nb System and method for issuing rewards to card holders
US20070203832A1 (en) * 2006-02-28 2007-08-30 Rene Pierre Babi Intermediary payment system and method for gaming
US8396711B2 (en) * 2006-05-01 2013-03-12 Microsoft Corporation Voice authentication system and method
US8783561B2 (en) * 2006-07-14 2014-07-22 Modiv Media, Inc. System and method for administering a loyalty program and processing payments
US20080208760A1 (en) 2007-02-26 2008-08-28 14 Commerce Inc. Method and system for verifying an electronic transaction
US8433648B2 (en) 2007-02-26 2013-04-30 Bill Me Later, Inc. Method and system for engaging in a transaction between a consumer and a merchant
US7689508B2 (en) * 2007-11-20 2010-03-30 Wells Fargo Bank N.A. Mobile device credit account
US9799028B2 (en) * 2007-11-30 2017-10-24 U.S. Bank National Association Seller routing arrangements and methods for disparate network systems
US8352323B2 (en) * 2007-11-30 2013-01-08 Blaze Mobile, Inc. Conducting an online payment transaction using an NFC enabled mobile communication device
US8306912B2 (en) 2007-12-19 2012-11-06 Metabank Private label promotion card system, program product, and associated computer-implemented methods
WO2011019365A3 (en) * 2009-08-14 2011-04-07 Payfone, Inc. System and method for paying a merchant using a cellular telephone account
US8799067B2 (en) * 2008-09-12 2014-08-05 Visa Usa Inc. System and method for a merchant debit card program including a plurality of issuers
US8239276B2 (en) 2008-09-30 2012-08-07 Apple Inc. On-the-go shopping list
US20120101881A1 (en) * 2008-11-25 2012-04-26 Mary Theresa Taylor Loyalty promotion apparatuses, methods and systems
US20100191570A1 (en) * 2009-01-23 2010-07-29 Joe Phillip Michaud Loyalty reward program simulators
US8286863B1 (en) 2009-02-04 2012-10-16 Metabank System and computer program product to issue a retail prepaid card including a user-designed external face using a chit and related computer implemented methods
US20110078081A1 (en) * 2009-09-30 2011-03-31 Kiushan Pirzadeh Mobile payment application architecture
US20110137804A1 (en) * 2009-12-03 2011-06-09 Recursion Software, Inc. System and method for approving transactions
US20110201306A1 (en) * 2010-02-15 2011-08-18 Samama Technologies Systems and methods for unified billing
US20130080239A1 (en) 2010-07-06 2013-03-28 Michael D. Okerlund System and Method for Incentives
US8799087B2 (en) 2010-10-27 2014-08-05 Mastercard International Incorporated Systems, methods, and computer readable media for utilizing one or more preferred application lists in a wireless device reader
US20120143703A1 (en) 2010-12-03 2012-06-07 Google Inc. Multiple contactless device interactions and communication protocols per tap
US20130030934A1 (en) * 2011-01-28 2013-01-31 Zumigo, Inc. System and method for credit card transaction approval based on mobile subscriber terminal location
US20120271712A1 (en) * 2011-03-25 2012-10-25 Edward Katzin In-person one-tap purchasing apparatuses, methods and systems
US9008616B2 (en) * 2011-08-19 2015-04-14 Google Inc. Point of sale processing initiated by a single tap
US20130080236A1 (en) 2011-09-26 2013-03-28 First Data Corporation Systems and Methods for Enrolling Consumers in Loyalty Programs
US8583549B1 (en) * 2012-04-10 2013-11-12 Hossein Mohsenzadeh Systems, devices, and methods for managing a payment transaction
US20140164082A1 (en) * 2012-12-06 2014-06-12 Capital One Financial Corporation Systems and methods for social media referrals based rewards
US20140244365A1 (en) * 2012-12-29 2014-08-28 DGRT Software LLC Toll app system
US20150220924A1 (en) * 2014-02-04 2015-08-06 Outsite Networks, Inc. Method and system for linking a customer identity to a retail transaction

Patent Citations (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5717989A (en) * 1994-10-13 1998-02-10 Full Service Trade System Ltd. Full service trade system
US20020062249A1 (en) * 2000-11-17 2002-05-23 Iannacci Gregory Fx System and method for an automated benefit recognition, acquisition, value exchange, and transaction settlement system using multivariable linear and nonlinear modeling
US20030069737A1 (en) * 2001-10-04 2003-04-10 Netscape Communications Corporation Hierarchical rule determination system
US20030069736A1 (en) * 2001-10-04 2003-04-10 Netscape Communications Corporation Inheritance and relationship to directory information in an e-commerce application
US20040049452A1 (en) * 2002-09-09 2004-03-11 First Data Corporation Multiple credit line presentation instrument
US8768838B1 (en) * 2005-02-02 2014-07-01 Nexus Payments, LLC Financial transactions using a rule-module nexus and a user account registry
US20060235795A1 (en) * 2005-04-19 2006-10-19 Microsoft Corporation Secure network commercial transactions
US20080021787A1 (en) * 2006-07-14 2008-01-24 Mackouse Jack Customer controlled account, system, and process
US20080149707A1 (en) * 2006-10-19 2008-06-26 Alfred Urcuyo Bank card management system
US20100063903A1 (en) * 2008-03-10 2010-03-11 Thayne Whipple Hierarchically applied rules engine ("hare")
US20100312700A1 (en) * 2008-11-08 2010-12-09 Coulter Todd R System and method for managing status of a payment instrument
US20100312636A1 (en) * 2008-11-08 2010-12-09 Coulter Todd R System and method for applying stored value to a financial transaction
US20100274678A1 (en) * 2009-04-22 2010-10-28 Gofigure Payments, Llc Systems, methods and devices for facilitating mobile payments
US20110035278A1 (en) * 2009-08-04 2011-02-10 Visa U.S.A. Inc. Systems and Methods for Closing the Loop between Online Activities and Offline Purchases
US20110137740A1 (en) * 2009-12-04 2011-06-09 Ashmit Bhattacharya Processing value-ascertainable items
US20110251892A1 (en) * 2010-04-09 2011-10-13 Kevin Laracey Mobile Phone Payment Processing Methods and Systems
US20110276475A1 (en) * 2010-05-04 2011-11-10 Cheryl Godejohn Payment transaction dispute resolution system
US20140250004A1 (en) * 2011-06-20 2014-09-04 Amazon Technologies, Inc. Coupling Prepaid Debit Cards to Online Stored-Value Accounts
US20130282563A1 (en) * 2011-08-31 2013-10-24 First Data Corporation Systems and Methods for Routing Debit Transactions

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016196449A1 (en) * 2015-06-01 2016-12-08 Jpmorgan Chase Bank, N.A. System and method for loyalty integration for merchant specific digital wallets

Also Published As

Publication number Publication date Type
US8924300B2 (en) 2014-12-30 grant
US20130080236A1 (en) 2013-03-28 application
US20130080219A1 (en) 2013-03-28 application
US20130080273A1 (en) 2013-03-28 application
US20130080328A1 (en) 2013-03-28 application
US8688604B2 (en) 2014-04-01 grant
US20130080329A1 (en) 2013-03-28 application
US10089617B2 (en) 2018-10-02 grant

Similar Documents

Publication Publication Date Title
US7628319B2 (en) Method and system for enabling item-level approval of payment card
US8401904B1 (en) Real-time payment authorization
US20130254102A1 (en) Systems and Methods for Distributing Tokenization and De-Tokenization Services
US20140122331A1 (en) System and Method for Providing a Security Code
US20090171778A1 (en) Methods and systems for applying a rewards program promotion to payment transactions
US20090192904A1 (en) System and Method for Conducting Transactions with a Financial Presentation Device Linked to Multiple Accounts
US20100057553A1 (en) System and Method for Performing a Real Time Redemption Transaction by Leveraging a Payment Network
US20010054006A1 (en) Points trading service method and system therefor
US20080255947A1 (en) Mobile commerce infrastructure systems and methods
US20140129435A1 (en) Electronic wallet apparatus, method, and computer program product
US8620790B2 (en) Systems and methods for dynamic transaction-payment routing
US20070150352A1 (en) Techniques for transaction data coordination
US20130275300A1 (en) Virtual wallet account with automatic-loading
US20110208656A1 (en) Method, apparatus, and computer program product for facilitating promotions with an e-wallet
US20100076836A1 (en) Consumer information and promotion system
US20060026073A1 (en) Methods and Systems for Managing Card Programs and Processing Card Transactions
US20100057554A1 (en) Method and System for Enabling Promotion of Product(s) and/or Service(s)
US20120271697A1 (en) Methods and systems for offer and dynamic gift verification and redemption
US20090036103A1 (en) Mobile communication systems and methods for redeeming and reporting coupons
US20130254052A1 (en) Systems and Methods for Facilitating Payments Via a Peer-to-Peer Protocol
US20130073361A1 (en) Methods and systems for offering targeted deals to customers and real-time automatic redemption thereof
US20140081854A1 (en) Systems and methods for facilitating remote authorization and payment of goods via mobile commerce
US20140081750A1 (en) Social media transaction visualization structure
US20130103472A1 (en) Affiliate offer redemption method and system
US20080301037A1 (en) Systems and methods for automatic migration of a consumer between financial accounts

Legal Events

Date Code Title Description
AS Assignment

Owner name: CREDIT SUISSE AG, CAYMAN ISLANDS BRANCH, NEW YORK

Free format text: SECURITY INTEREST;ASSIGNOR:FIRST DATA CORPORATION;REEL/FRAME:035136/0692

Effective date: 20150101

AS Assignment

Owner name: WELLS FARGO BANK, NATIONAL ASSOCIATION, AS COLLATE

Free format text: SECURITY INTEREST;ASSIGNOR:FIRST DATA CORPORATION;REEL/FRAME:035245/0721

Effective date: 20140701

Owner name: WELLS FARGO BANK, NATIONAL ASSOCIATION, AS COLLATE

Free format text: SECURITY INTEREST;ASSIGNOR:FIRST DATA CORPORATION;REEL/FRAME:035245/0553

Effective date: 20140701