US20140351142A1 - Systems and methods for processing payment transactions - Google Patents
Systems and methods for processing payment transactions Download PDFInfo
- Publication number
- US20140351142A1 US20140351142A1 US14/456,804 US201414456804A US2014351142A1 US 20140351142 A1 US20140351142 A1 US 20140351142A1 US 201414456804 A US201414456804 A US 201414456804A US 2014351142 A1 US2014351142 A1 US 2014351142A1
- Authority
- US
- United States
- Prior art keywords
- transaction
- payment account
- rules
- consumer
- computer
- 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.)
- Abandoned
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
- G06Q20/327—Short range or proximity payments by means of M-devices
- G06Q20/3278—RFID or NFC payments by means of M-devices
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, 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/405—Establishing or using transaction specific rules
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/02—Banking, e.g. interest calculation or account maintenance
Definitions
- 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.
- 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.
- 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.
- a Visa or Mastercard payment account may be utilized at any accepting merchant.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- restrictions and/or preferences associated with a payment account may be stored by a service provider.
- 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.
- 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.
- preferences for utilizing the payment account in association with various merchants, merchant types, transaction amounts, and/or other criteria.
- restrictions and/or parameters may be stored in association with any number of 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.
- 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.
- a department store may allow a payment account to be utilized at various grocery stores.
- 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.
- 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.
- an increased reward incentive e.g., cash back, coupons, etc.
- 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.
- 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.
- 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.
- 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.
- 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.
- a special purpose computer or particular machine may be formed that facilitates the decoupling of transaction processing rules and/or parameters.
- 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.
- RAM random access memory
- ROM read-only memory
- 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 .
- OS operating system
- DBMS database management system
- transaction processing module 147 a transaction processing module
- 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 .
- 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.
- the OS may be, but is not limited to, Microsoft Windows®, Apple OSXTM, 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.
- 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 .
- 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.
- 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.
- an issued payment account may be an open loop payment account that may be utilized in association with a wide variety of merchants.
- 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.
- an issuer may define one or more rules and/or parameters that will be utilized by the service provider to process a proposed transaction.
- 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.
- MCC merchant category code
- 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.
- 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.
- 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.
- 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.
- the consumer may specify a particular payment account to utilize (if supported) at grocery stores.
- the consumer may specify a particular payment account to utilize for transactions that exceed a threshold amount.
- 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.
- a payment device e.g., payment card, etc.
- 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.
- 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.
- proposed transaction information may be received from a merchant computer or device 110 (e.g., a merchant point of sale device, etc.).
- proposed transaction information may be received from a merchant acquiring platform 155 or merchant gateway associated with a merchant computer 110 .
- 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.
- 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.
- 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 .
- the service provider computer 105 may receive and/or communicate information to other components of the system 100 .
- a merchant computer 110 may be a suitable point-of-sale (“POS”) device (e.g., a POS terminal) located at a physical merchant location.
- POS point-of-sale
- a merchant computer 110 may be a suitable server that facilitates the processing of online purchase transactions.
- 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 .
- a processing entity e.g., an acquiring platform, a service provider computer 105 , etc.
- a special purpose computer or particular machine may be formed that facilitates the generation and/or output of proposed transactions.
- 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
- 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.
- RAM random access memory
- ROM read-only memory
- 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 .
- OS operating system
- a transaction module 167 a transaction module
- 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 .
- 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.
- the OS 166 may be, but is not limited to, Microsoft Windows®, Apple OSXTM, Unix, a mainframe computer operating system (e.g., IBM z/OS, MVS, OS/ 390 , etc.), or a specially designed operating system.
- the merchant computer 110 may additionally include one or more host modules that facilitate interaction with remote consumer devices 115 .
- 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.
- 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.
- 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.
- 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.
- a wide variety of responses such as an approval of the
- a consumer device reader 162 may facilitate communication with a consumer device at a point of sale.
- 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.
- a reader 162 may be incorporated into the merchant computer 110 .
- 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 .
- the merchant computer 110 may receive and/or communicate information to other components of the system 100 .
- any number of consumer devices 115 may be provided.
- 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 .
- 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.
- various consumer devices 115 may facilitate the provision of payment account information to a merchant computer 110 in association with a proposed transaction.
- a payment card, contactless device, or a transaction-enabled mobile device e.g., a mobile device including NFC or other contactess technology
- 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.
- suitable networks 125 e.g., the Internet, a cellular network, etc.
- 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 .
- certain consumer devices 115 may include one or more processors, memory devices, I/O interfaces, and/or network interfaces.
- An issuer system 120 may facilitate the backend processing of a proposed transaction.
- an issuer system 120 may facilitate the approval and/or settlement of a proposed transaction.
- 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.
- 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 .
- rules may be provided to an associated Web server 150 via one or more suitable networks 130 .
- rules may be provided via an interprocess communication and/or via any number of suitable communication techniques.
- 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 .
- 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 .
- networks 125 , 130 , 135 may be utilized in association with embodiments of the disclosure.
- Certain networks 125 , 130 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.
- PSTN publicly switched telephone network
- 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.
- 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.
- a consumer may utilize a consumer device 115 to provide payment account information to a merchant system 110 .
- 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.
- 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.
- 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.
- FIG. 1 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.
- 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.
- 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 .
- one or more payment accounts associated with an issuer may be identified or determined.
- 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.
- one or more issuer restrictions and/or rules associated with user of the identified payment accounts may be received and/or otherwise obtained.
- 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.
- 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 .
- 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.
- issuer rules may be received, obtained, and/or identified.
- 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.
- MCCs merchant types
- 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.
- 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.
- an issuer of a closed loop payment account may allow the payment account to be utilized at merchants outside of the closed loop.
- the issuer may specify one or more conditions associated with use of the payment account at the merchants.
- an issuer e.g., a retailer
- 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.
- 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.
- an issuer may offer loyalty points for transactions completed at particular merchants and/or merchant types, such as merchants outside of a closed loop.
- 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.
- 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.
- payment account information and/or at least a portion of the issuer rules and/or restrictions may be presented to a consumer associated with a payment account.
- a consumer may utilize a suitable consumer device to access one or more Web pages hosted by the Web server.
- 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.
- 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.
- the consumer may utilize various options presented by the Web pages in order to specify one or more consumer rules.
- consumer rules may be utilized as desired in various embodiments of the disclosure.
- 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.
- a combination of any of these rules may be associated with a payment account.
- 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.
- certain consumer rules may be associated with the use of various consumer payment devices.
- 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.).
- 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.
- 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.
- 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.
- 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 .
- 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.
- merchant type e.g., MCC
- a designated payment account may be identified.
- the received transaction information may be evaluated in order to identify a payment account number for a designated payment account.
- identification information for a payment device e.g., a mobile identifier, a secure element identifier for a mobile device, etc.
- a merchant and/or a merchant type associated with the proposed transaction may be identified.
- a merchant identifier and/or an MCC associated with the proposed transaction may be identified.
- 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.
- 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.).
- rules and/or parameters may be accessed as desired in various embodiments of the disclosure, including issuer rules and/or consumer rules.
- 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.
- 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.
- operations may continue 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.
- operations may continue 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.
- 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 .
- 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.
- the proposed transaction may be identified as a decoupled transaction.
- 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.
- 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.
- a consumer payment device e.g., a mobile device identifier, a secure element identifier, etc.
- received information associated with one or more payment account numbers may be utilized to identify a consumer.
- information associated with the proposed transaction may be utilized to identify a merchant and/or a merchant type (e.g., MCC, etc.)
- 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.
- 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.
- consumer payment device information e.g., a mobile device identifier, a payment application identifier, a payment account number read from a payment device, etc.
- merchant information e.g., a mobile device identifier, a payment application identifier, a payment account number read from a payment device, etc.
- 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.
- issuer rules may be utilized to determine whether the proposed transaction qualifies for any incentives.
- the proposed transaction may be approved for routing and/or routed to a processing system associated with the selected payment account.
- the proposed transaction may be routed to an issuer system and/or a financial institution system associated with the selected payment account.
- 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.
- 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.
- 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.
- 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.
Abstract
Description
- 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.
- 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.
- 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.
- 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.
-
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. - 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 anexample system 100 for providing transaction processing services, according to one embodiment of the disclosure. Thesystem 100 may facilitate the decoupling of payment account processing parameters from a payment account issuer and/or from a payment device. As shown inFIG. 1 , the system may include one or moreservice 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 ormore consumer devices 115, and/or one or more issuer and/orfinancial institution system 120. Any number of suitable networks, such as the illustratednetworks 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. Aservice provider computer 105 may utilize one ormore 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, theservice provider computer 105 may utilize the one ormore 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, theservice provider computer 105 may further include one ormore memory devices 141, input/output (“I/O”) interface(s) 142, and/or network interface(s) 143. Thememory 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. Thememory 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 atransaction processing module 147. The data files 144 may include any suitable data that facilitates the operation of theservice provider computer 105 and/or interaction of theservice provider computer 105 with one or more other components of thesystem 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. TheOS 145 may be suitable module that facilitates the general operation of theservice 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. TheDBMS 146 may be a suitable program module that facilitate management of the data files 144, data stored in thememory 141, and/or data stored in one or more separate databases, such as one or more transactionprocessing 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 theservice provider computer 105, and the host modules may facilitate interaction with other components of thesystem 100. For example, one ormore Web servers 150 may be provided, and theWeb 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/orconsumer 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, thetransaction 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. Thetransaction 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. Thetransaction processing module 147 may then direct storage of the rules in one or moresuitable 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 amerchant acquiring platform 155 or merchant gateway associated with amerchant computer 110. Following receipt of a proposed transaction, thetransaction processing module 147 may identify one or more applicable rules, and thetransaction processing module 147 may evaluate the proposed transaction utilizing the applicable rules. In this regard, thetransaction processing module 147 may determine whether the proposed transaction may be routed to an issuer for approval and/or settlement processing. Alternatively, thetransaction processing module 147 may determine a payment account to utilize in association with the proposed transaction. Indeed, thetransaction 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 theservice 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 theservice provider computer 105. The one ormore network interfaces 143 may facilitate connection of theservice provider computer 105 to one or more suitable networks, for example, the network(s) 125, 130, 135 illustrated inFIG. 1 . In this regard, theservice provider computer 105 may receive and/or communicate information to other components of thesystem 100. - With continued reference to
FIG. 1 , any number ofmerchant computers 110 may be provided. In certain embodiments, amerchant 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, amerchant computer 110 may be a suitable server that facilitates the processing of online purchase transactions. As desired, eachmerchant 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. Amerchant computer 110 may utilize one ormore 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, aservice 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 ormore processors 160 to execute computer-readable instructions that facilitate the provision of issuer and/or merchant rules to theservice provider computer 105. - In addition to having one or
more processors 160, themerchant computer 110 may further include and/or be associated with one ormore memory devices 161,consumer device readers 162, input/output (“I/O”) interface(s) 163, and/or network interface(s) 164. Thememory 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. Thememory 161 may store a wide variety of data files 165 and/or various program modules, such as an operating system (“OS”) 166, and/or atransaction module 167. The data files 165 may include any suitable data that facilitates the operation of themerchant computer 110 and/or interaction of themerchant computer 110 with one or more other components of thesystem 100. For example, the data files 165 may include acquiring platform information, service provider information, and/or routing information for proposed transactions. TheOS 166 may be suitable module that facilitates the general operation of themerchant computer 110, as well as the execution of other program modules. For example, theOS 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, themerchant computer 110 may additionally include one or more host modules that facilitate interaction withremote 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, thetransaction 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, thetransaction module 167 may receive payment account information collected from a consumer device. For example, thetransaction module 167 may interact with aconsumer device reader 162 to receive payment account information at a point of sale. As another example, thetransaction module 167 may receive payment account information via one or moresuitable networks 125, such as the Internet. Following the identification of transaction information and payment account information, thetransaction module 167 may generate a proposed transaction or proposed transaction request, and thetransaction 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 acquiringplatform 155, and the acquiringplatform 155 may forward the proposed transaction to theservice provider computer 105. As another example, the proposed transaction may be output for communication to theservice provider computer 105. In certain embodiments, theservice provider computer 105 may be associated with a particular acquiringplatform 155. Alternatively, theservice provider computer 105 may communicate with a plurality of different acquiring platforms. Following, the output of a proposed transaction, thetransaction 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 moreconsumer device readers 162 may be provided in certain embodiments. Aconsumer device reader 162 may facilitate communication with a consumer device at a point of sale. For example, aconsumer 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, areader 162 may be incorporated into themerchant computer 110. In other embodiments, areader 162 may be in communication with themerchant 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, aconsumer device reader 162, etc., that facilitate user interaction with theservice provider computer 105. The one ormore network interfaces 164 may facilitate connection of themerchant computer 110 to one or more suitable networks, for example, the network(s) 125, 135 illustrated inFIG. 1 . In this regard, themerchant computer 110 may receive and/or communicate information to other components of thesystem 100. - Additionally, with continued reference to
FIG. 1 , any number ofconsumer devices 115 may be provided. Examples ofsuitable 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 theservice provider computer 105. For example, a consumer may utilize aconsumer device 115 to access aWeb 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 amerchant 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 amerchant 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 amerchant computer 110 by theconsumer device 115. As desired,certain consumer devices 115 may be processor-driven devices that include components similar to those described above for theservice provider computer 105 and/or themerchant 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/orfinancial institution systems 120 may be provided. Anissuer system 120 may facilitate the backend processing of a proposed transaction. For example, anissuer system 120 may facilitate the approval and/or settlement of a proposed transaction. In certain embodiments, a proposed transaction may be routed to anissuer system 120 via asuitable transaction network 135, and theissuer system 120 may evaluate the proposed transaction. An approval or rejection of the proposed transaction may then be output for communication to amerchant computer 110. Theissuer 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 associatedWeb server 150 via one or moresuitable networks 130. As another example, rules may be provided via an interprocess communication and/or via any number of suitable communication techniques. As desired, anissuer system 120 may be or may include any number processor-driven devices that include components similar to those described above for theservice provider computer 105 and/or themerchant computer 110. For example, anissuer device 120 may include one or more processors, memory devices, I/O interfaces, and/or network interfaces that facilitate the operations of theissuer device 120. - A wide variety of
suitable networks Certain networks 125, 130 (which may be the same network or different networks) may facilitate the communication of rules to theservice provider computer 105 and/or the communication of transaction requests (e.g., eCommerce requests) from theconsumer devices 115 tomerchant computers 110. Thesenetworks Other networks 135 may be suitable transaction networks that facilitate the routing of proposed transactions. Thesetransaction 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 aconsumer device 115 to provide payment account information to amerchant 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 amerchant system 110 in association with an eCommerce or Web-based transaction. Themerchant computer 110 may generate a proposed transaction, and themerchant computer 110 may output the proposed transaction for communication to theservice provider computers 105 either directly or via one or more other entities, such as an acquiringplatform 155. Theservice provider computers 105 may utilize at least a portion of the stored rules to process the proposed transaction, and theservice 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 toFIG. 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 inFIG. 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 anexample 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 themethod 200 may be performed by a suitable service provider computer and/or associated Web servers, such as theservice provider computer 105 andWeb servers 150 illustrated inFIG. 1 . Themethod 200 may begin atblock 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. Atblock 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 ormore Web servers 150, and the issuer restrictions may be entered, established, and/or modified via one or more Web pages provided by theWeb 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. Atblock 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 theservice 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 followingblock 230. -
FIG. 3 illustrates a flow diagram of oneexample method 300 for processing a proposed payment transaction, according to an example embodiment of the disclosure. In certain embodiments, the operations of themethod 300 may be performed by a suitable service provider computer, such as theservice provider computer 105 illustrated inFIG. 1 . Themethod 300 may begin atblock 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. Atblock 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. Atblock 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 atblock 335. Atblock 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 atblock 330 that the various rules and/or parameters have been satisfied, then operations may continue atblock 340. Atblock 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 anotherexample 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 themethod 400 may be performed by a suitable service provider computer, such as theservice provider computer 105 illustrated inFIG. 1 . Themethod 400 may begin atblock 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, atblock 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. Atblock 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 atblock 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 followingblock 440. - The operations described and shown in the
methods 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 inFIGS. 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)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US14/456,804 US20140351142A1 (en) | 2011-09-26 | 2014-08-11 | Systems and methods for processing payment transactions |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201161539206P | 2011-09-26 | 2011-09-26 | |
US13/627,654 US8924300B2 (en) | 2011-09-26 | 2012-09-26 | Systems and methods for processing payment transactions |
US14/456,804 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 |
---|---|---|---|
US13/627,654 Division US8924300B2 (en) | 2011-09-26 | 2012-09-26 | Systems and methods for processing payment transactions |
Publications (1)
Publication Number | Publication Date |
---|---|
US20140351142A1 true US20140351142A1 (en) | 2014-11-27 |
Family
ID=47912273
Family Applications (6)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/627,670 Expired - Fee Related US10089617B2 (en) | 2011-09-26 | 2012-09-26 | Systems and methods for facilitating card present transactions |
US13/627,683 Abandoned US20130080219A1 (en) | 2011-09-26 | 2012-09-26 | Systems and Methods for Providing Value Added Services in Association with Payment Transactions |
US13/627,665 Expired - Fee Related US8688604B2 (en) | 2011-09-26 | 2012-09-26 | Systems and methods for facilitating communication between a point of sale device and a consumer device |
US13/627,678 Abandoned US20130080236A1 (en) | 2011-09-26 | 2012-09-26 | Systems and Methods for Enrolling Consumers in Loyalty Programs |
US13/627,654 Expired - Fee Related US8924300B2 (en) | 2011-09-26 | 2012-09-26 | Systems and methods for processing payment transactions |
US14/456,804 Abandoned 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 |
---|---|---|---|
US13/627,670 Expired - Fee Related US10089617B2 (en) | 2011-09-26 | 2012-09-26 | Systems and methods for facilitating card present transactions |
US13/627,683 Abandoned US20130080219A1 (en) | 2011-09-26 | 2012-09-26 | Systems and Methods for Providing Value Added Services in Association with Payment Transactions |
US13/627,665 Expired - Fee Related US8688604B2 (en) | 2011-09-26 | 2012-09-26 | Systems and methods for facilitating communication between a point of sale device and a consumer device |
US13/627,678 Abandoned US20130080236A1 (en) | 2011-09-26 | 2012-09-26 | Systems and Methods for Enrolling Consumers in Loyalty Programs |
US13/627,654 Expired - Fee Related US8924300B2 (en) | 2011-09-26 | 2012-09-26 | Systems and methods for processing payment transactions |
Country Status (1)
Country | Link |
---|---|
US (6) | US10089617B2 (en) |
Cited By (4)
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 |
NO20151207A1 (en) * | 2015-09-16 | 2017-03-17 | Evry As | Consumer companion application framework |
CN113342838A (en) * | 2021-08-06 | 2021-09-03 | 腾讯科技(深圳)有限公司 | Data processing method, device and equipment based on block chain and readable storage medium |
WO2022146530A1 (en) * | 2020-12-30 | 2022-07-07 | MasterCard International Incorported | Multi-network tokenization systems and methods |
Families Citing this family (65)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10867298B1 (en) | 2008-10-31 | 2020-12-15 | Wells Fargo Bank, N.A. | Payment vehicle with on and off function |
US20100114768A1 (en) | 2008-10-31 | 2010-05-06 | Wachovia Corporation | Payment vehicle with on and off function |
US8811892B2 (en) | 2010-04-05 | 2014-08-19 | Mastercard International Incorporated | 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 |
US10089617B2 (en) | 2011-09-26 | 2018-10-02 | First Data Corporation | Systems and methods for facilitating card present transactions |
US10438196B2 (en) | 2011-11-21 | 2019-10-08 | Mozido, Inc. | Using a mobile wallet infrastructure to support multiple mobile wallet providers |
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 |
JP2014194731A (en) * | 2012-12-11 | 2014-10-09 | Toshiba Tec Corp | Electronic receipt system, commodity sales data processor, electronic receipt management server, information processor and program |
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 |
US10282709B2 (en) * | 2013-04-05 | 2019-05-07 | Visa International Service Association | 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 |
US9582792B2 (en) | 2013-07-29 | 2017-02-28 | Exxonmobil Research And Engineering Company | System and method to purchase and dispense fuel and other products using a mobile device with improved user experience |
US10346822B2 (en) * | 2013-08-23 | 2019-07-09 | Visa International Service Association | Dynamic account selection |
TWI625684B (en) * | 2015-04-17 | 2018-06-01 | Yang Jian Gang | Mobile payment method and mobile payment device |
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 |
US10181129B2 (en) | 2013-12-11 | 2019-01-15 | Mastercard International Incorporated | Method and system for identifying optimal rewards programs |
US9785940B2 (en) | 2014-03-27 | 2017-10-10 | Bank of the Ozarks | System and method for distributed real time authorization of payment transactions |
FR3023640B1 (en) * | 2014-07-10 | 2016-08-12 | Roam Data Inc | METHOD FOR MANAGING TRANSACTION, SERVER, COMPUTER PROGRAM PRODUCT AND CORRESPONDING STORAGE MEDIUM |
US9830606B2 (en) | 2014-10-31 | 2017-11-28 | Visa International Services Association | Systems and methods for enrolling a user in a membership account |
US10997654B1 (en) | 2015-01-15 | 2021-05-04 | Wells Fargo Bank, N.A. | Identity verification services through external entities via application programming interface |
US10621658B1 (en) | 2015-01-15 | 2020-04-14 | Wells Fargo Bank, N.A. | Identity verification services with identity score through external entities via application programming interface |
US10937025B1 (en) | 2015-01-15 | 2021-03-02 | Wells Fargo Bank, N.A. | Payment services via application programming interface |
US10990974B1 (en) | 2015-01-15 | 2021-04-27 | Wells Fargo Bank, N.A. | Identity verification services and user information provision via application programming interface |
US11429975B1 (en) | 2015-03-27 | 2022-08-30 | Wells Fargo Bank, N.A. | Token management system |
US20160294967A1 (en) * | 2015-03-31 | 2016-10-06 | Toshiba Global Commerce Solutions Holdings Corporation | Discoverable and shareable device brokers in pos system |
US11127009B2 (en) * | 2015-04-07 | 2021-09-21 | Omnyway, Inc. | Methods and systems for using a mobile device to effect a secure electronic transaction |
US11373168B2 (en) * | 2015-06-05 | 2022-06-28 | Apple Inc. | Value added services polling |
US11170364B1 (en) | 2015-07-31 | 2021-11-09 | Wells Fargo Bank, N.A. | Connected payment card systems and methods |
TWI707286B (en) * | 2015-08-21 | 2020-10-11 | 新加坡商萬事達卡亞洲/太平洋私人有限公司 | Method and system for modifying transaction credentials, server and non-transitory computer readable medium |
JP2019503546A (en) | 2015-10-23 | 2019-02-07 | シビックス ホールディングス リミテッド ライアビリティ カンパニー | Authentication system and method using mobile device |
US20170161727A1 (en) * | 2015-12-07 | 2017-06-08 | American Express Travel Related Services Company, Inc. | System and method for creating and issuing virtual transaction instruments |
US20170278124A1 (en) * | 2016-03-28 | 2017-09-28 | Visa International Service Association | Merchant loyalty account enrollment through payment checkout platform services |
ITUA20164661A1 (en) * | 2016-06-07 | 2017-12-07 | Empirya Srl | DEVICE FOR DETECTION OF PROXIMITY AND TWO-WAY COMMUNICATION OF SHORT RADIO COMPATIBLE WITH SMARTPHONES BASED ON HETEROGENEOUS OPERATING SYSTEMS |
US11615402B1 (en) | 2016-07-01 | 2023-03-28 | Wells Fargo Bank, N.A. | Access control tower |
US11935020B1 (en) | 2016-07-01 | 2024-03-19 | Wells Fargo Bank, N.A. | Control tower for prospective transactions |
US11886611B1 (en) | 2016-07-01 | 2024-01-30 | Wells Fargo Bank, N.A. | Control tower for virtual rewards currency |
US11386223B1 (en) | 2016-07-01 | 2022-07-12 | Wells Fargo Bank, N.A. | Access control tower |
US10992679B1 (en) | 2016-07-01 | 2021-04-27 | Wells Fargo Bank, N.A. | Access control tower |
EP3285220A1 (en) * | 2016-08-18 | 2018-02-21 | Mastercard International Incorporated | Transaction control management |
US11556936B1 (en) | 2017-04-25 | 2023-01-17 | Wells Fargo Bank, N.A. | System and method for card control |
US11062388B1 (en) | 2017-07-06 | 2021-07-13 | Wells Fargo Bank, N.A | Data control tower |
US11188887B1 (en) | 2017-11-20 | 2021-11-30 | Wells Fargo Bank, N.A. | Systems and methods for payment information access management |
US11676126B1 (en) | 2017-12-28 | 2023-06-13 | Wells Fargo Bank, N.A. | Account open interfaces |
US11106515B1 (en) | 2017-12-28 | 2021-08-31 | Wells Fargo Bank, N.A. | Systems and methods for multi-platform product integration |
US11651369B2 (en) * | 2018-07-12 | 2023-05-16 | American Express Travel Related Services Company, Inc. | Remote EMV payment applications |
US20200118097A1 (en) * | 2018-10-10 | 2020-04-16 | The Toronto-Dominion Bank | Value-added services enabled by a cloud-based payment system |
US11093912B1 (en) | 2018-12-10 | 2021-08-17 | Wells Fargo Bank, N.A. | Third-party payment interfaces |
US11228578B2 (en) | 2019-05-17 | 2022-01-18 | International Business Machines Corporation | Multi-factor authentication utilizing event data |
US11496503B2 (en) | 2019-05-17 | 2022-11-08 | International Business Machines Corporation | Event data fencing based on vulnerability detection |
US11044246B1 (en) | 2019-06-21 | 2021-06-22 | Wells Fargo Bank, N.A. | Secure communications via third-party systems through frames |
US11250414B2 (en) | 2019-08-02 | 2022-02-15 | Omnyway, Inc. | Cloud based system for engaging shoppers at or near physical stores |
US11468432B2 (en) | 2019-08-09 | 2022-10-11 | Omnyway, Inc. | Virtual-to-physical secure remote payment to a physical location |
US11237869B2 (en) * | 2019-09-16 | 2022-02-01 | Bank Of America Corporation | System for intelligent routing of resources associated with resource entities |
US11270330B1 (en) | 2020-02-26 | 2022-03-08 | Patreon, Inc. | Systems and methods to determine tax classification of benefits offered to subscribers of a membership platform |
US11386377B1 (en) | 2020-03-17 | 2022-07-12 | Patreon, Inc. | Systems and methods to recommend price of benefit items offered through a membership platform |
US10992606B1 (en) | 2020-09-04 | 2021-04-27 | Wells Fargo Bank, N.A. | Synchronous interfacing with unaffiliated networked systems to alter functionality of sets of electronic assets |
KR102440733B1 (en) * | 2020-10-26 | 2022-09-05 | 피네보 주식회사 | System and method for processing card payment |
US11546338B1 (en) | 2021-01-05 | 2023-01-03 | Wells Fargo Bank, N.A. | Digital account controls portal and protocols for federated and non-federated systems and devices |
US11368735B1 (en) | 2021-05-18 | 2022-06-21 | Patreon, Inc. | Systems and methods to facilitate quality control of benefit items created for subscribers of a membership platform |
Citations (25)
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 |
US20030069736A1 (en) * | 2001-10-04 | 2003-04-10 | Netscape Communications Corporation | Inheritance and relationship to directory information in an e-commerce application |
US20030069737A1 (en) * | 2001-10-04 | 2003-04-10 | Netscape Communications Corporation | Hierarchical rule determination system |
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 |
US8117100B1 (en) * | 2008-03-19 | 2012-02-14 | Unites Services Automobile Association (USAA) | Systems and methods for managing consolidated purchasing, billing and payment information |
US20120059736A1 (en) * | 2009-12-04 | 2012-03-08 | Ashmit Bhattacharya | Processing value-ascertainable items |
US20120143669A1 (en) * | 2010-12-02 | 2012-06-07 | Microsoft Corporation | Loyalty offer modeling |
US8249961B1 (en) * | 2008-03-19 | 2012-08-21 | United States Automobile Association | Systems and methods for managing consolidated purchasing, billing and payment information |
US20130073459A1 (en) * | 2011-09-20 | 2013-03-21 | Plastic Jungle, Inc. | Digital exchange and mobile wallet for digital currency |
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 |
US8924300B2 (en) * | 2011-09-26 | 2014-12-30 | First Data Corporation | Systems and methods for processing payment transactions |
Family Cites Families (69)
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 |
US8783561B2 (en) * | 2006-07-14 | 2014-07-22 | Modiv Media, Inc. | System and method for administering a loyalty program and processing payments |
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 |
US7403785B2 (en) * | 2003-06-17 | 2008-07-22 | International Business Machines Corporation | Consolidating online privacy preferences |
US20050038876A1 (en) * | 2003-08-15 | 2005-02-17 | Aloke Chaudhuri | System and method for instant match based on location, presence, personalization and communication |
WO2005048145A1 (en) | 2003-10-13 | 2005-05-26 | Starbucks Corporation D/B/A Starbucks Coffee Company | Dual card |
US20070210162A1 (en) * | 2003-12-08 | 2007-09-13 | Keen Ian J | Data storage devices |
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 |
US20060064391A1 (en) * | 2004-09-20 | 2006-03-23 | Andrew Petrov | System and method for a secure transaction module |
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 |
US20060208060A1 (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 |
US8352323B2 (en) | 2007-11-30 | 2013-01-08 | Blaze Mobile, Inc. | Conducting an online payment transaction using an NFC enabled mobile communication device |
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 |
US20080121687A1 (en) * | 2006-11-28 | 2008-05-29 | Motorola, Inc. | Method and system for detecting an end of transaction for contactless transactions on a mobile device |
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 |
US20090055278A1 (en) * | 2007-08-20 | 2009-02-26 | Symbian Software Ltd. | Complete Secure Retail Transaction Via A Mobile Device |
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 |
US8306912B2 (en) * | 2007-12-19 | 2012-11-06 | Metabank | Private label promotion card system, program product, and associated computer-implemented methods |
US20090191897A1 (en) * | 2008-01-24 | 2009-07-30 | Cortxt, Inc. | Environment Characterization for Mobile Devices |
US20090276305A1 (en) * | 2008-04-11 | 2009-11-05 | Brian Clopp | Affiliate and cross promotion systems and methods |
AU2009249272B2 (en) * | 2008-05-18 | 2014-11-20 | Google Llc | Secured electronic transaction system |
US8606640B2 (en) * | 2008-08-14 | 2013-12-10 | Payfone, Inc. | System and method for paying a merchant by a registered user 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 |
US10380573B2 (en) * | 2008-09-30 | 2019-08-13 | Apple Inc. | Peer-to-peer financial transaction devices and methods |
US10666749B2 (en) * | 2008-11-17 | 2020-05-26 | International Business Machines Corporation | System and method of leveraging SIP to integrate RFID tag information into presence documents |
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 |
CA2751554C (en) * | 2009-02-05 | 2015-07-21 | Wwpass Corporation | Centralized authentication system with safe private data storage and method |
SG164294A1 (en) * | 2009-02-17 | 2010-09-29 | Taggo Pte Ltd | An automated membership system |
US20100273452A1 (en) * | 2009-04-26 | 2010-10-28 | Qualcomm Incorporated | Apparatus and Methods For Locating Tracking and/or Recovering a Wireless Communication Device |
US10454693B2 (en) | 2009-09-30 | 2019-10-22 | Visa International Service Association | 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 |
US20110238476A1 (en) * | 2010-03-23 | 2011-09-29 | Michael Carr | Location-based Coupons and Mobile Devices |
US10521813B2 (en) * | 2010-07-06 | 2019-12-31 | Groupon, Inc. | System and method for incentives |
WO2012021170A2 (en) * | 2010-08-10 | 2012-02-16 | Zoosk, Inc. | System and method for locating desired traits in resources using a network |
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 |
US20120166270A1 (en) * | 2010-12-23 | 2012-06-28 | Apriva, Llc | System and device for facilitating mobile enrollment and participation in a loyalty campaign |
US20130030934A1 (en) * | 2011-01-28 | 2013-01-31 | Zumigo, Inc. | System and method for credit card transaction approval based on mobile subscriber terminal location |
WO2012135115A2 (en) * | 2011-03-25 | 2012-10-04 | Visa International Service Association | 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 |
US8583549B1 (en) * | 2012-04-10 | 2013-11-12 | Hossein Mohsenzadeh | Systems, devices, and methods for managing a payment transaction |
WO2014032049A2 (en) * | 2012-08-24 | 2014-02-27 | Environmental Systems Research Institute, Inc. | Systems and methods for managing location data and providing a privacy framework |
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 |
US9454723B1 (en) * | 2013-04-04 | 2016-09-27 | Sprint Communications Company L.P. | Radio frequency identity (RFID) chip electrically and communicatively coupled to motherboard of mobile communication device |
US20150220924A1 (en) * | 2014-02-04 | 2015-08-06 | Outsite Networks, Inc. | Method and system for linking a customer identity to a retail transaction |
-
2012
- 2012-09-26 US US13/627,670 patent/US10089617B2/en not_active Expired - Fee Related
- 2012-09-26 US US13/627,683 patent/US20130080219A1/en not_active Abandoned
- 2012-09-26 US US13/627,665 patent/US8688604B2/en not_active Expired - Fee Related
- 2012-09-26 US US13/627,678 patent/US20130080236A1/en not_active Abandoned
- 2012-09-26 US US13/627,654 patent/US8924300B2/en not_active Expired - Fee Related
-
2014
- 2014-08-11 US US14/456,804 patent/US20140351142A1/en not_active Abandoned
Patent Citations (25)
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 |
US20030069736A1 (en) * | 2001-10-04 | 2003-04-10 | Netscape Communications Corporation | Inheritance and relationship to directory information in an e-commerce application |
US20030069737A1 (en) * | 2001-10-04 | 2003-04-10 | Netscape Communications Corporation | Hierarchical rule determination system |
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") |
US8117100B1 (en) * | 2008-03-19 | 2012-02-14 | Unites Services Automobile Association (USAA) | Systems and methods for managing consolidated purchasing, billing and payment information |
US8249961B1 (en) * | 2008-03-19 | 2012-08-21 | United States Automobile Association | Systems and methods for managing consolidated purchasing, billing and payment information |
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 |
US20120059736A1 (en) * | 2009-12-04 | 2012-03-08 | Ashmit Bhattacharya | Processing value-ascertainable items |
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 |
US20120143669A1 (en) * | 2010-12-02 | 2012-06-07 | Microsoft Corporation | Loyalty offer modeling |
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 |
US20130073459A1 (en) * | 2011-09-20 | 2013-03-21 | Plastic Jungle, Inc. | Digital exchange and mobile wallet for digital currency |
US8924300B2 (en) * | 2011-09-26 | 2014-12-30 | First Data Corporation | Systems and methods for processing payment transactions |
Cited By (6)
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 |
US10762521B2 (en) | 2015-06-01 | 2020-09-01 | Jpmorgan Chase Bank, N.A. | System and method for loyalty integration for merchant specific digital wallets |
NO20151207A1 (en) * | 2015-09-16 | 2017-03-17 | Evry As | Consumer companion application framework |
WO2022146530A1 (en) * | 2020-12-30 | 2022-07-07 | MasterCard International Incorported | Multi-network tokenization systems and methods |
US11710133B2 (en) | 2020-12-30 | 2023-07-25 | Mastercard International Incorporated | Multi-network tokenization systems and methods |
CN113342838A (en) * | 2021-08-06 | 2021-09-03 | 腾讯科技(深圳)有限公司 | Data processing method, device and equipment based on block chain and readable storage medium |
Also Published As
Publication number | Publication date |
---|---|
US20130080219A1 (en) | 2013-03-28 |
US20130080328A1 (en) | 2013-03-28 |
US8924300B2 (en) | 2014-12-30 |
US20130080236A1 (en) | 2013-03-28 |
US20130080329A1 (en) | 2013-03-28 |
US8688604B2 (en) | 2014-04-01 |
US20130080273A1 (en) | 2013-03-28 |
US10089617B2 (en) | 2018-10-02 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8924300B2 (en) | Systems and methods for processing payment transactions | |
US10552883B2 (en) | Third party merchant-funded rewards accrual and redemption network | |
US8768831B2 (en) | Systems, devices, and methods for managing a payment transaction | |
US20180315102A1 (en) | Value processing network and methods | |
US8583549B1 (en) | Systems, devices, and methods for managing a payment transaction | |
US9342828B2 (en) | Systems and methods for facilitating the approval and use of a credit account via mobile commerce | |
US10007900B2 (en) | Systems and methods for facilitating point of sale transactions | |
US10026089B2 (en) | System, method, and computer program for dynamically identifying a merchant associated with an authorization request for a payment card | |
US10922671B2 (en) | Systems, devices, and methods for managing a payment transaction | |
US9852407B2 (en) | Systems and methods for routing debit transactions | |
US20160042340A1 (en) | Closed prepayment program via merchant pos terminals | |
US20150006270A1 (en) | Payment and reward optimization in electronic commerce system | |
US11741446B2 (en) | Electronic system and method for transaction processing | |
CN109214815B (en) | System and method for accepting dual function payment credentials | |
US20170161768A1 (en) | Systems, methods, and devices for implementing a scavenger hunt reward program | |
US20180075467A1 (en) | Methods and apparatus for identifying and classifying customer segments | |
US11893586B2 (en) | Method, system, and computer program product for processing a potentially fraudulent transaction | |
US20200019941A1 (en) | Systems and methods for facilitating payment by installments |
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 |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NON FINAL ACTION MAILED |
|
AS | Assignment |
Owner name: FIRST DATA CORPORATION, COLORADO Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:CREDIT SUISSE AG, CAYMAN ISLANDS BRANCH;REEL/FRAME:049898/0402 Effective date: 20190729 |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER |
|
AS | Assignment |
Owner name: FIRST DATA CORPORATION, NEW YORK Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENT RIGHTS;ASSIGNOR:WELLS FARGO BANK, NATIONAL ASSOCIATION;REEL/FRAME:050093/0135 Effective date: 20190729 Owner name: FIRST DATA CORPORATION, NEW YORK Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENT RIGHTS;ASSIGNOR:WELLS FARGO BANK, NATIONAL ASSOCIATION;REEL/FRAME:050092/0963 Effective date: 20190729 Owner name: FIRST DATA CORPORATION, NEW YORK Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENT RIGHTS;ASSIGNOR:WELLS FARGO BANK, NATIONAL ASSOCIATION;REEL/FRAME:050094/0455 Effective date: 20190729 |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: FINAL REJECTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |