Patent Application
20110087592
The present invention relates to consumer payment accounts and products. In particular, the present invention relates to systems and methods for facilitating transactions involving multiple product categories using a single payment account with one or more subaccounts.
The field of card payment systems includes well-established practices and standards for authorizing, clearing and settling purchases conducted by consumers at merchant locations. These transactions typically involve a single card account used for payment of a single purchase amount in a single purchase event. For example, consumers are commonly issued credit cards which include an account number identifying a credit account associated with the consumer. When the consumer uses the credit card to make a purchase (even if multiple products are purchased) a single transaction (for the total purchase amount) is posted to the consumer's credit account.
In some cases, payments for purchases are divided among different payment tenders, with each payment tender corresponding to a payment instrument issued under a separate account by a single issuer or by separate instruments issued by different issuers. For example, it is not uncommon for a cardholder to pay for a purchase using funds from both a debit and a credit card, or for a cardholder to designate which part of the purchase amount is to be paid for with the credit card and which part of the payment is to be paid for with the debit card. Cardholders may, for example, desire to pay for some categories of items with a debit card which possesses tax advantages for buying approved health care related products and the remaining categories of items with a credit card or cash. In these cases, the choice of how to allocate purchase amounts to various payment instruments and the choice of instruments to be used for payment requires a close interaction between the cardholder and the merchant. For example, the cardholder may need to complete separate payment transactions (using separate payment instruments) for different categories of products.
Current payment systems lack the flexibility and functionality to enable cardholders to acquire and use a single payment account containing multiple subaccounts designated for payment of a specific category of products. More particularly, current systems do not support the processing of a single transaction which includes the redemption of multiple types of products or product categories using multiple subaccount funds with each subaccount restricted for redemption of a particular subset of products in the transaction. An example is a case in which third party payors of health care benefits desire to fund a stored value account but wish to restrict eligible purchases to specific health care products, such as over the counter drugs or medical devices. In instances in which multiple payors each provide value to a beneficiary in the form of funds or access to credit with conditions that restrict the redemption of the funds to specific categories of products, current payment systems are unable to redeem funds from each subaccount in an automated fashion that satisfies the conditions of the value providers.
While payment systems support the limitation of purchase transactions to categories of merchants or industries using Merchant Category Codes and other industry standards, there does not exist the ability to redeem value from payment accounts based upon an identification of the individual product or services being purchased.
To alleviate problems inherent in the prior art, the present invention introduces systems and methods in which a single payment account may be accessed which has multiple subaccounts, each having one or more permitted product categories that may be purchased using funds from the subaccount.
Pursuant to some embodiments, a payment account including multiple subaccounts is provided where each subaccount can be used only for payment for a designated category of products. Pursuant to some embodiments, purchases using the subaccounts can be automatically combined in a single transaction to redeem multiple categories of products, with each subaccount providing funds for the redemption of a single product category. In some embodiments, the payment account may include a subaccount that contains value that is unrestricted and available for general spending or to automatically provide supplementary funds for the redemption of products from subaccounts with product category restrictions. The value contained within each subaccount may be immediately available funds, access to credit provided by an entity who has agreed to extend credit to the account holder for purchasing products in a designated category or a combination of these types of value. Alternatively, in some embodiments, the value may include benefits provided by a health care plan whose redemption is limited to specific categories of products and services as provided by the plan.
Pursuant to some embodiments, transaction processing involving multiple product categories and multiple subaccounts with each subaccount is provided where the processing is restricted to the redemption of products from a particular category. In some embodiments, restricted subaccount values can be automatically combined with unrestricted value in cases where restricted funds are insufficient to redeem a purchase. In some embodiments, the designation of how funds should be combined in a purchase can be made either by the account holder or by the account provider. The processing of transactions pursuant to some embodiments includes an initial categorization of products at a merchant point of sale and an automated adjudication of product category subtotals against account holder subaccounts designated for redemption of individual product categories. Once adjudicated, the purchase transaction is submitted for authorization, clearing and settlement in a manner that is consistent with the processing of standard payment transactions.
Pursuant to some embodiments, the authorization request and redemption request messages are transmitted in a single message from the merchant to the account provider, and the account provider initiates clearing and settlement of an approved portion of the transaction based on the single message received from the merchant.
Pursuant to some embodiments, methods of categorizing products at the point of purchase are provided. Merchants, including product and service providers, access a database which links accounts to product categories eligible for purchase with the account and links product categories to individual products using product codes such as Universal Product Code (UPC) indicators. Using the database, merchants are able to match each product to a product category and also determine if a particular account being presented for payment is linked to a restricted category of products.
With these and other advantages and features of the invention that will become hereinafter apparent, the invention may be more clearly understood by reference to the following detailed description of the invention, the appended claims, and the drawings attached herein.
For the purposes of describing features of embodiments of the present invention, a number of terms are used herein. For example, the term “account access device” is used to refer to a token, card or other device that is associated with a payment account pursuant to the present invention and which is issued to an account holder (such as an insured consumer or business). An account access device may be provided in any of a number of different forms, including as a standard ISO 7816 magnetic stripe card (such as a debit card, credit card, stored value card, prescription card, medical card, or the like) as an RFID chip encapsulated in a card or other device, as a chip or application embodied in a smart phone or PDA, or as a virtual account number so long as the account access device identifies (or allows identification of) an associated account.
As used herein, the term “product” is used to refer to physical products or goods (such as pharmaceuticals, over the counter drugs, medical devices or aids, or the like) as well as services (such as services rendered or to be rendered by a medical professional or the like).
As used herein, the term “category” or “product category” is used to refer to a grouping of products. A grouping may be made based on characteristics of a product (e.g., eyeglasses may be grouped together), and/or based on the tax or reimbursement qualifications of a product (e.g., generic prescription medications may be grouped together). The categorization of products may be modified from time to time, and the term “category” is not meant to imply a fixed or permanent grouping of products. In some embodiments, a category may consist of a single product. As used herein, a wide variety of different product identifiers may be used to identify individual products (and to associate those products with categories). For example, products may be identified by one or more of the following codes or identifiers: a stock keeping unit (SKU) code, a universal product code (UPC), a global trade item number (GTIN), a European Article Number (EAN) code, an International Standard Book Number (ISBN), a Current Procedural Terminology (CPT), an International Classification of Diseases (ICD), an Healthcare Common Procedure Code (HPCP) code, a product serial number, or other coding or identification schemes now known or later developed.
Prior to describing features of the present invention in detail, an illustrative example will first be introduced. This example is purely for illustration of certain features of some embodiments. In the example, a cardholder (John) is issued an account access device (in this example, the device is a magnetic stripe card with a card body embossed with John's name, and a primary account number or “PAN” and with a magnetic stripe storing card data). The access device is issued by a financial institution (“Big Bank”) and is associated with an account held by Big Bank for John. The account has several subaccounts associated with it, including an “unrestricted” subaccount which is a prepaid account, such as a prepaid debit card account (having an available balance of $1,000). The account also has two “restricted” subaccounts, one is restricted to purchases of products categorized as “over the counter drugs”, and another restricted to purchases of products categorized as “prescription drugs”. The first restricted subaccount is linked to a stored value account as a source of value, and John has previously deposited $500 into the stored value account. The second restricted subaccount is linked to an account provided by John's health care plan as a source of value.
In the illustrative example, John will purchase three products at a merchant: a box of stationary, a bottle of prescription sleeping pills, and a bottle of over the counter pain medication.
Pursuant to some embodiments, John is able to use his account access device at participating merchant locations and may purchase products from different categories (and even products not included in any permitted categories) with a single swipe or presentment of his account access device. By presenting an account access device pursuant to the present invention, John is able to purchase different items in a single transaction and have the purchase of those items funded by different sources of value according to their categorization. John's purchases in this illustrative example will be followed throughout the remainder of this disclosure as a means to provide a specific example of some features of the present invention.
Turning now in detail to the drawings,
The account provider device 110 is in communication with a number of devices, including one or more merchant systems 130 and one or more value sources 160. Those skilled in the art will appreciate that a large number of merchant systems 130 and value sources 160 may be in communication with account provider device 110 (and that there may be multiple account provider devices 110). Merchant systems 130 include a number of modules or devices, including one or more point of sale devices 134, a product data store 132, and an account list 136. Value sources 160 may be external (or, in some embodiments, internal) sources of funds or value which are used to transfer or load value into one or more accounts or subaccounts held at the account provider device 110. The value sources 160 may be any of a number of different types or kinds of value sources, including, for example, third party systems, point systems, reward systems, reimbursement accounts, rebates, discounts, loyalty programs, health care benefits, other payment accounts such as stored value, direct deposit, credit, or the like.
As used herein, devices (including the account provider devices 110, the merchant systems 130 and the value sources 160) may communicate, for example, via communication networks 140 and 150 such as a Local Area Network (LAN), a Metropolitan Area Network (MAN), a Wide Area Network (WAN), a proprietary network, a Public Switched Telephone Network (PSTN), a Wireless Application Protocol (WAP) network, a Bluetooth network, a cable television network, or an Internet Protocol (IP) network such as the Internet, an intranet or an extranet. Moreover, as used herein, communications include those enabled by wired or wireless technology. In some embodiments, one of the networks 140, 150 is an open loop payment card network such as the BankNet® network operated by MasterCard International Incorporated, or the VisaNet® network operated by Visa International Service Association, or the networks branded as NYCE, STAR, or the like. In some embodiments, one of the networks 140, 150 is a closed loop payment card network such as those operated by American Express or Discover. In some embodiments, one of the networks 140, 150 is a closed loop, private label network.
The account provider device 110 includes a number of components or modules, several of which are shown in
Reference is now made to
The account identifier 902 may be, for example, an alphanumeric identifier uniquely identifying a particular payment account. In some embodiments, the account identifier is a primary account number (“PAN”) formatted such that a portion of the PAN identifies the account provider (e.g., is formatted as a Bank Identification Number or “BIN”) allowing authorization and redemption request messages to be routed to the account provider for authorization and other processing.
The subaccount identifier 904 may be, for example, an alphanumeric identifier identifying a particular subaccount associated with the account identifier 902. The subaccount type 906 may represent a type of the subaccount identified by subaccount identifier 904 (e.g., in some embodiments, a subaccount may be either a restricted or an unrestricted type of subaccount). The subaccount identifier 904 may be used to conditionally process redemption requests as will be described further below.
The value source 908 includes information identifying a source of value to be used when funding transactions posted against the account and the subaccount identified by account identifier 902 and subaccount identifier 904. The value source 908 may be a pointer or reference to a value source or it may be a representation of actual value. The value source 908 may have an available balance amount 910. In some embodiments, the identification of a value source for a subaccount may be specified by the account holder or the account provider upon creation of an account. In some embodiments, the value source may be updated or specified after creation of an account. In some embodiments, a load interface (e.g., such as that shown in
The value loaded into the subaccounts may be in the form of cash, the availability of credit from a third party, points, rewards, reimbursements, rebates, discounts or other forms of value associated with a loyalty program, or benefits as provided under a health care plan. In an exemplary embodiment, the value provided to the subaccounts would be in the form of cash comprising a stored value account which can be used for purchasing a specified set of over the counter drugs. An alternative embodiment may be in the form of a line of credit. Value may be a fixed amount or be variable based upon specified behavior of the account holder or the types of products purchased. For example, in one embodiment the value may include higher discounts for purchases of two or more products in a category.
The value sources identified in the value source field 908 may include the account holder, the account provider or third parties who desire to contribute value to the account, such as business entities, health care plan providers, hospitals, clinics, government entities, individuals, groups, or non-profit organizations. Value sources may provide value to more than one subaccount and contribute different forms of value to each subaccount.
The account datastore 900 also specifies one or more categories 912 which represent categories of products which may be purchased using funds in a given subaccount 904. For example, certain value sources may require that only certain specified categories of products may be purchased using funds from that subaccount and value provider. It is often desirable, for example, for value providers such as health plans to provide benefits to members of the plan but limit those benefits to spending on products and services related to health care or a certain medical condition. In this case, the health plan may designate a category of products which are eligible to be redeemed by the benefits contributed by the plan.
In general, each of the unrestricted subaccounts can hold value that is not limited to spending on any particular product or product category. Unrestricted subaccounts may hold value which is restricted for spending on products which are included in product categories 912 established for that subaccount 904. For example, a subaccount may include value which can only be redeemed for purchases of products included in a category of over-the-counter drugs. This category may specify which Universal Product Codes (“UPC”s) are eligible for redemption of the value contained within the subaccount of that particular account. Products which do not meet the conditions of this category would not be eligible for redemption by this subaccount, but could be redeemed from value included in an unrestricted account. In alternative embodiments of the invention, an account 902 may include only restricted subaccounts without an unrestricted subaccount. In these cases, the account 902 would be limited to spending only on products which correspond to product categories established for each subaccount 904. In one embodiment, the subaccounts 904 may be variable such that the categories 912 may be changed. For example, for a period of time a particular subaccount 904 may be assigned a product category 912 corresponding to over the counter drugs, and subsequently be assigned a product category 912 for prescription drugs.
In some embodiments, the account datastore 900 exist on a computer server managed by account provider 110. The computer server maintains the rules, applications, logic, and interfaces for loading value into the subaccounts, assigning parameters for restricting spending on subaccounts, obtaining current and historical information on account and subaccount activity and balances for purposes of managing the system and providing customer service, adding, managing and deleting account holder information, processing transactions for redeeming value from the subaccounts, creating and issuing tokens or other devices for accessing the account or subaccounts, and calculating, billing and collecting fees and expenses from account holders, merchants and value providers for operating the system. While
In some embodiments, some or a portion of the networks allow communication between the value sources 160 and the account provider device 110 to load (or reload) value into payment accounts at the account provider device 110. For example, load or reload transactions may use the Internet, private networks, automated teller networks such as Plus, Cirrus, Star, or NYCE, stored value networks such as GreenDot or ValueLink, or electronic wallet systems such as PayPal. Load or reload transactions may also use open loop payment card networks such as those operated by Visa or, MasterCard, closed loop payment card networks such as those operated by American Express or Discover, or non-branded private label closed loop networks, and may also use electronic funds transfer networks such as the Automated Clearing House or bank wire transfer systems. Further, the networks used to load or reload value may also utilize physical processing systems, such as the use of paper checks and deposits, money orders, or other non-electronic means of transferring value.
Reference is now made to
The value sources may specify categories 1004 of products 1002 which condition the spending of value from the subaccount to which they provide value (e.g., as specified in the account database 900). It is often desirable, for example, for value providers such as health plans to provide benefits to members of the plan but limit those benefits to spending on products and services related to health care or a certain medical condition. In this case, the health plan may designate a category of products which are eligible to be redeemed by the benefits contributed by the plan.
Products 1002 may be identified by codes assigned to each product for purposes of providing unique identification, such as UPCs, EANs, GTINs, ISBNs, CPT codes or product serial numbers. For example, a category 1004 may be designated as over the counter drugs and include a set of UPCs which correspond to individual products such as Ephedrin or Tylenol that are eligible for redemption by subaccounts having the category “Over the Counter Drugs” listed as permitted purchases. Each category 1004 may be linked to more than one subaccount. Further, each category 1004 may be comprised of more than one product 1002.
In some embodiments, the table 1000 is maintained by account provider 110 and is distributed to merchants 130 (along with certain account data from table 900). In some embodiments, this distribution may be via a load interface or other connection. For example the data may be distributed to merchants using electronic file distribution techniques based upon standards such as FTP or web services or proprietary communications protocols. In some embodiments, the product data 1000 and selected account data 900 may be distributed using physical media such as CDROMs, DVDs, paper file catalogs, magnetic tapes or magnetic discs. Distribution of the data may occur at least once over a period of time and may occur at regular intervals or as the accounts, product categories or products comprising the account list change or are updated.
Reference is now made to
Process 200 begins at 202 where a transaction involving a payment account issued pursuant to the present invention is initiated at a merchant location (e.g., such as at a physical point of sale location, an Internet point of purchase or other point of interaction with a merchant). For example, processing may begin when an account holder presents an account access device at a merchant point of sale terminal along with one or more products to purchase. Processing at 202 includes identifying a payment account number (e.g., by reading a magnetic stripe, or otherwise detecting an account number associated with an account access device), and identifying products (and categories of those products) presented for purchase at a merchant location.
Processing continues at 204 where a redemption request message is created and transmitted (over a first network, such as network 140 of
For example, continuing the illustrative example introduced above, John wishes to purchase three products at the merchant: a box of stationary, a bottle of prescription sleeping pills, and a bottle of over the counter pain medication. As such, processing at 202 (in John's example) may include the merchant swiping John's magnetic stripe payment card to read his PAN (and other account data) and scanning the bar codes of the three products to be purchased. The merchant systems perform other processing which will be described further below (e.g., such as checking John's payment account number and categorizing the products), but for the purposes of
Processing continues at 206 where a redemption response message is received from the account provider. The redemption response message can include a number of items of data for each of the product categories. For example, the redemption response may indicate whether the subaccounts had sufficient value for each of the product categories (e.g., whether each product can be purchased using funds from a specific subaccount) and whether a general spend or unrestricted category must be used. A transaction identifier is also returned in the redemption response for matching of subsequent authorization messages (as will be described further below).
Continuing the illustrative example, the redemption response returned for John's transaction may include the following information: (i) an approval for the prescription drugs (i.e., John's restricted subaccount for that category had sufficient funds), (ii) an approval for the over the counter drugs (i.e., John's restricted subaccount for that category had sufficient funds), and (iii) an approval for the office supplies (i.e., John's account has an unrestricted subaccount allowing him to purchase non-medical related items using the unrestricted subaccount, and that subaccount had sufficient value to purchase the stationary). A total redemption approval amount of $80 is indicated.
Pursuant to some embodiments, the transaction processing is not yet complete—instead, a subsequent authorization request must be transmitted to cause funds to be processed. This occurs at 208 where a standard payment authorization request message is transmitted to the account provider over a second network (such as network 150 of
In this manner, a payment account holder using a payment account pursuant to the present invention is able to purchase multiple products, from multiple categories, and use funds from multiple value sources in a single transaction. Further, when the account holder receives his or her statement, details of each of the items purchased, along with their relevant categories and source of value may be shown, providing easy record keeping and accounting.
Further details of each of the steps described above will now be detailed by reference to
Process 300 begins at 302 where a transaction involving a payment account issued pursuant to the present invention is initiated at a merchant location (e.g., such as at a physical point of sale location, an Internet point of purchase or other point of interaction with a merchant). For example, processing may begin when an account holder presents an account access device at a merchant point of sale terminal along with one or more products to purchase.
At 304 the merchant processes scanned, read or key entered information to determine if the payment account received at 302, is included in product category and account lists (132, 136). If the account is not a participating account (or if the products and categories are not ones eligible for processing using the account), processing continues at 308 where the purchase transaction is processed as a normal transaction (e.g., where a single authorization request for the total purchase is submitted using the payment network 150).
In some embodiments, the merchant 130 and the account provider 110 may have an agreement that unless the payment account is included in the account list 136, value from the payment account is not eligible for redemption. If the merchant 130 determines that the payment account is included in the account list 136, processing continues at 310. In some embodiments, processing at 306 is performed by the merchant 130 transmitting the account number to the account provider (e.g., over a network 140) to identify if the account number is in the account list stored at the account provider 110.
Processing continues at 310 where the merchant point of sale system 134 operates to sort the products presented for purchase into one or more categories (e.g., using data read from the product data 132) and then computes a total purchase amount for all products and subtotal amounts for each category. In an alternative embodiment, for accounts included in account list 136, the merchant point of sale system 134 submits each of the product codes such as UPCs from a purchase transaction to account provider 110 (e.g., over network 140) so that the account provider 110 may perform the sorting of products by category and the computation of category specific subtotals and a total purchase amount.
Processing continues at 312 where the merchant point of sale system 134 creates a redemption request message which includes information sufficient to identify the merchant, the merchant's POS location and environment, the access device and the purchase transaction, including category subtotals and the total purchase amount.
Processing continues at 314 where the merchant 130 transmits the redemption request to the account provider 110 over a first network 140. Product information provided to account provider 110 may be in the form of an industry standard such as ISO 8583 or in a proprietary standard.
Processing continues at the account provider 110 as shown in
Processing continues at 404 where the account provider 110 iteratively compares each category contained in the redemption request message with categories designated in the restricted category subaccounts associated with the account number. This may be performed, for example, by consulting the account datastore 112 (e.g., such as the datastore illustrated in
In general, the iterative processing proceeds as follows. For a given category of product in the purchase, a first determination is made at 404 if the category is a permitted category of one of the restricted subaccounts. If it is, processing continues at 406 where a determination is made whether there is sufficient value in the restricted subaccount to cover the cost of the products in that category. If so, processing continues at 408 where a redemption response message is updated to indicate that there was sufficient value for the products in that category for redemption.
If there is insufficient value in the restricted subaccount, processing continues at 416 where the value that is available in the restricted subaccount is subtracted from the category total and then a determination is made at 422 if there is sufficient value in any unrestricted subaccount to cover the remaining balance for that category. If so, processing continues at 424 where the response message is updated to indicate that there was sufficient value to cover the cost of products in that category (e.g., redemption of that category was successful).
If processing at 404 indicated that the category was not one that was a permitted category for any of the restricted subaccounts, processing continues at 412 where a determination is made whether there is sufficient value available in any unrestricted subaccount to cover the category subtotal amount. If so, processing continues at 414 where the redemption response message is updated to indicate that redemption of that category is successful. If not, processing continues at 420 where the redemption response message is updated to indicate that redemption of that category was not successful.
This processing repeats until all categories in the redemption request message have been processed and a determination has been made whether redemption in each category is successful or unsuccessful. Upon completion of the iteration, the redemption response message is completed (with redemption responses for each of the categories) and transmitted to the merchant (via the first network, such as network 140). In some embodiments, the account provider 110 stores a record of the redemption response message and assigns it a transaction identifier so that the transaction can easily referred to upon subsequent authorization processing.
In some embodiments, the redemption response data, including the transaction identifier and an indication of sufficient or insufficient funds for each category, are included in a single redemption response message transmitted to the merchant 130. The redemption response message may be in the form of an industry standard such as ISO 8583 or in a proprietary standard.
Processing reverts to the merchant location, as shown in
At 504, the merchant 130 determines whether the total of the redemption approvals (e.g., the sum of all the category approvals) is equal to the total purchase amount. If so, processing continues at 506 where the merchant constructs a standard payment authorization request message including the total redemption approval amount, the payment account number and other transaction details, and submits the authorization request message to a payment network (e.g., such as network 150 of
Processing again reverts to the account provider 110 in the process 600 shown in
As will be discussed further below in conjunction with
In addition, the account provider device 700 includes an account interface 720 and a load interface 750 that may be constituted by one or more conventional processors. The interfaces 720, 750 operate to execute processor-executable process steps so as to control the account provider device 700 to provide desired functionality. The account provider device 700 further includes one or more storage devices 730, 740 to store account data and product data. Note that the engines 720, 750 and storage devices 730, 740 may be co-located with, or remote from, the account provider device 700.
The account provider device 700 may operate in accordance with any of the embodiments described herein. By way of example only,
In addition, the merchant device 800 includes a load interface 820 and a transaction staging data area 850 that may be constituted by one or more conventional processors. The interfaces 820, 850 operate to execute processor-executable process steps so as to control the merchant device 800 to provide desired functionality. The merchant device 800 further includes one or more storage devices 830, 840 to store account data and product data. Note that the engines 820, 850 and storage devices 830, 840 may be co-located with, or remote from, the merchant device 800.
The merchant device 800 may operate in accordance with any of the embodiments described herein. By way of example only,
Although the present invention has been described in connection with specific exemplary embodiments, it should be understood that various changes, substitutions, and alterations apparent to those skilled in the art can be made to the disclosed embodiments without departing from the spirit and scope of the invention as set forth in the appended claims.
For example, in some embodiments, the redemption request and response and the authorization request and response may be combined in a single message and transmitted over a single one of networks 140, 150. Features of such an embodiment will now be described by reference to
Processing of
For example, for any category for which sufficient funds in a restricted or unrestricted subaccount is available, the account provider 110 may create (or update) an authorization response message indicating that sufficient value exists for the category and, further, initiate clearing and settlement against that subaccount (as shown in blocks 1114, 1108, 1124 and 1118). For any category for which sufficient funds are not available (in either a restricted or an unrestricted sub account), the account provider 110 may create (or update) an authorization response message indicating that the portion of the transaction involving that category or item is not authorized. For any such unauthorized portion of a transaction the merchant 130 may be required to obtain an alternative form of payment from the consumer.
In some embodiments, an account may be associated with a general purpose (or unrestricted) subaccount that may be used to authorize any uncategorized products. For example, in the illustrative example introduced above, if John attempts to purchase a box of stationary, a bottle of prescription sleeping pills and a bottle of over the counter paid medication, process 1100 may cause the prescription drugs to be authorized (and later cleared and settled) against the restricted subaccount restricted for prescription drugs, while the over the counter sleeping pills are authorized (and later cleared and settled) against the restricted subaccount restricted for over the counter medication, and the stationary is authorized (and later cleared and settled) against the unrestricted subaccount. By allowing such purchases to be redeemed (or compared to category and subaccount restrictions) and also authorized, transaction efficiencies can be realized using a single processing network. In some embodiments, the authorization response transmitted to the merchant as a result of process 1100 may include one or more authorization indicators so that the merchant can complete the purchase transaction according to the authorization processing at account provider 110.
Although the present invention has been described in connection with specific exemplary embodiments, it should be understood that various changes, substitutions, and alterations apparent to those skilled in the art can be made to the disclosed embodiments without departing from the spirit and scope of the invention as set forth in the appended claims.
