WO2009046157A1 - Traitement multi-autorisation - Google Patents

Traitement multi-autorisation Download PDF

Info

Publication number
WO2009046157A1
WO2009046157A1 PCT/US2008/078525 US2008078525W WO2009046157A1 WO 2009046157 A1 WO2009046157 A1 WO 2009046157A1 US 2008078525 W US2008078525 W US 2008078525W WO 2009046157 A1 WO2009046157 A1 WO 2009046157A1
Authority
WO
WIPO (PCT)
Prior art keywords
authorization
processor
request
response
expense
Prior art date
Application number
PCT/US2008/078525
Other languages
English (en)
Inventor
Gregory R. Morris
Eugene J. Walters
Bruce Mcanally
Original Assignee
Trihealix, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Trihealix, Inc. filed Critical Trihealix, Inc.
Publication of WO2009046157A1 publication Critical patent/WO2009046157A1/fr

Links

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
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions

Definitions

  • the present invention relates generally to payment authorization for goods and services on behalf of a purchaser, and more specifically to payment authorization on behalf of a purchaser utilizing one or more funding sources to satisfy all or part of the purchaser's liability.
  • BACKGROUND OF THE INVENTION Purchasers of goods and services often pay for such goods and services by using a variety of funding sources and/or payment arrangements. For example, a purchaser may split payment across two separate credit cards, which may be facilitated by two separate authorization transactions covering the total amount due for the goods and services. Payment arrangements may also be more complex. For example, a purchaser of goods and services may be an eligible beneficiary, a member of a discount or incentive plan, or part of an insured or prearranged benefit plan that reduces the purchaser's payment liability outright or transfers payment liability (in whole or in part) to a third party on behalf of the purchaser.
  • a third party may have pre-arranged terms with a merchant/seller of goods and services that modifies the invoice or expense claim amount, thereby altering the amount due from the purchaser.
  • Such payment arrangements often involve the merchant/seller submitting the invoice or expense claim to a third party who re-prices the goods and service, applies benefits, and determines the remaining amount due to the merchant/seller from the purchaser.
  • the third party may also play a role in authorizing and/or settling a benefit claim. Further adding to this complexity, the purchaser may have additional, stacked funding sources that further reduce the remaining expense claim liability.
  • the purchaser may then be presented with a "net invoice" and choose to fund the remaining amount from one or more additional funding sources (e.g. cash, one or more debit cards, and/or one or more credit cards, etc.).
  • additional funding sources e.g. cash, one or more debit cards, and/or one or more credit cards, etc.
  • Expense claim processing is not standardized to a single authorization format or process.
  • electronic message formats, protocols, standards, and process flows e.g. international organization of standards (ISO), Credit Card Association, automated clearing house (ACH), national council for prescription drug programs (NCPDP), electronic data interchange (EDI), health insurance portability and accountability act (HIPAA), and others
  • ISO international organization of standards
  • ACH automated clearing house
  • NCPDP national council for prescription drug programs
  • EDI electronic data interchange
  • HIPAA health insurance portability and accountability act
  • a merchant/seller may opt out of this complexity by demanding out of pocket payment, thereby transferring the responsibility for managing the reimbursement from the funding sources to the purchaser.
  • An example of current art processing technology in the healthcare industry may be viewed in terms of a prescription drug purchase by a customer.
  • the pharmacist would typically send a NCPDP prescription billing transaction to the purchaser's primary prescription drug plan (PDP) authorization processor for adjudication/authorization, and would receive a response indicating any prearranged discounted price for the prescription drug, a commitment of the amount payable by the PDP, and any remaining amount payable by the consumer.
  • the pharmacist would then execute a second billing transaction to the purchaser's secondary insurance plan, indicating the amount paid by the PDP and the remaining amount due, to request additional funding authorization against the remaining amount owed by the consumer.
  • the secondary plan would send an additional response indicating any amount to be paid by the secondary plan, and the remaining amount still owed by the purchaser.
  • the pharmacist would then request the form of payment (e.g. cash, debit, or credit) from the purchaser for the remaining amount and would process the relevant transaction for the remaining amount due.
  • the pharmacy would receive three separate payments, and presumably apply them individually against the prescription sale.
  • a disadvantage of current processing technology is that a single invoice or expense claim for goods and services may require that multiple, independent, and unrelated transactions of potentially different transaction types be processed and authorized in order for payment in full to be authorized and settled.
  • a further disadvantage of this multi-step process is that it increases a variety of costs for the merchant/seller including, but not limited to, administrative resource costs and fees required to process and track invoices and payments, transaction resource costs and fees to gain relevant authorizations, cash flow costs related to multiple, sequential authorizations, and other costs and inefficiencies associated with the increased time required to deal with such a multi-step process.
  • a disadvantage for the purchaser is that these complexities often result in paperwork and other investments in time associated with managing and understanding payments from available funding sources.
  • the present invention provides a method for addressing the problems that are presented to a merchant/seller and to a purchaser/consumer of goods and services when more than one funding source and/or more than one transaction type is to be used to gain payment authorization against an invoice or claim.
  • a multi-authorization processing system and method works with a myriad transaction modes (standard and proprietary) to gain individual authorizations against an invoice or claim, by recognizing an initial authorization request transaction and processing it within the rules and standards for its transaction type.
  • claims may include, but are not limited to, healthcare claims (HIPAA), prescription claims(NCPDP), automated clearinghouse claims (NACHA), and/or credit/debit card claims (e.g. MasterCard, Visa, Discover, etc.).
  • Transactions are processed based on knowledge of the purchaser's funding sources and proprietary rules management.
  • the multi-authorization processing system systematically processes type-specific authorization requests against the purchaser's funding sources to optimize funding authorizations and consolidate those authorizations into a single authorization response while minimizing the purchaser's remaining liability.
  • An illustrative embodiment of the invention provides a method of processing an expense claim.
  • the method includes the steps of receiving an authorization request for an expense claim, routing the authorization request to a multi-authorization processor, identifying authorization processors that may authorize at least a portion of the expense claim based on a type of the authorization request, ordering the authorization processors for multi-authorization processing; and routing by the multi-authorization processor an appropriately formatted authorization request to a first authorization processor in response to the ordering.
  • the illustrative method also includes processing the request and responses transactions with one or more next authorization processors in sequence until all next authorization processors have responded or remaining liability is zero.
  • Another illustrative embodiment of the invention provides a system for processing an expense claim including a multi-authorization request processor in communication with one or more authorization request processors.
  • the multi-authorization request processor is adapted to identify authorization processors that may authorize at least a portion of the expense claim based on a type of the authorization request, order the authorization processors for multi-authorization processing and route an appropriately formatted authorization request to a first authorization processor in response to the ordering.
  • the multi-request processor may be further adapted to validate the authorization request against a purchaser's available sources of funds.
  • the multi-authorization processor is also adapted to format at least a portion of the authorization request in accordance with formats used by the respective processors.
  • the multi-authorization processor may receive an authorization response to the request from the first authorization processor, determine based on the response received from the first authorization processor, whether a remaining expense claim liability exists, determine a next authorization processor that may authorize against the remaining purchaser, and generate a revised authorization request to be sent to a next authorization processor in response to determining that additional authorization processor(s) may authorize at least a portion of the remaining expense claim liability.
  • Another illustrative embodiment of the invention provides a computer readable medium including software executable on a computer for performing the steps of receiving an authorization request for an expense claim, routing the authorization request to a multi -authorization processor, identifying authorization processors that may authorize at least a portion of the expense claim based on a type of the authorization request, ordering the authorization processors for multi-authorization processing; and routing by the multi -authorization processor an appropriately formatted authorization request to a first authorization processor in response to the ordering.
  • the software may also be executable to perform the steps of receiving an authorization response to said request from the first authorization processor by the multi-authorization processor, determining by the multi -authorization processor based on the response received from the first authorization processor, whether a remaining expense claim liability exists, determining a next authorization processor that may authorize against the remaining purchaser, and generating a revised authorization request to be sent to a next authorization processor in response to determining that additional authorization processor(s) may authorize at least a portion of the remaining expense claim liability.
  • FIG. 1 is a block diagram depicting an expense claim involving one or more authorization processors and a single authorization request according to an illustrative embodiment of the invention
  • FIG. 2 is a block diagram depicting prescription drug claim billing in a multi-source funding model according to an illustrative embodiment of the invention
  • FIG. 3 is a flow diagram of a multi-authorization processor method according to an illustrative embodiment of the invention.
  • a general embodiment of the invention provides a multi-authorization processing method to payment authorizations in which one or more funding sources may be used to fund the payment of a financial liability of a consumer, business, or other entity.
  • FIG. 1 provides a block diagram depicting a general multi-authorization process 104.
  • a single authorization request 100 can be satisfied from one or more funding sources that may be administered by "N" levels of authorization processors 108, 1 10, and 1 12.
  • the funding sources may include, but are not limited to, cash, debit/credit cards, checking/savings accounts, retirement accounts, and/or lines of credit.
  • a single authorization request 100 may be sent to the multi-authorization processor 120 in a standard format 1 14.
  • the authorization request 101 may be sent directly to the multi -authorization processor 120, or routed to the multi-authorization processor 120 via a request transaction router 102.
  • the multi-authorization processor 120 receives the authorization request 100, and validates the purchaser on the request against the source of funds manager 118, which stores information about the purchaser's preferred funding sources and the preferred order for accessing these sources. It is contemplated that the source of funds manager 1 18 may store similar information for a variety of other purchaser claim types.
  • the source of funds manager 1 18 determines the available sources of funds, and their respective processing orders if there are more than one.
  • the multi-authorization processor 120 then sends a primary billing request 124 to the first authorization processor 108 identified in the primary billing request 124. This request may be sent directly, or it may be routed to the first authorization processor 108 via a billing transaction router 106.
  • a primary billing request 124 may be sent to the first authorization processor 108 in a variety of standard formats.
  • the first authorization processor 108 processes the primary billing request 124 and returns a primary billing response 126 in a standard format to the multi-authorization processor 120.
  • the multi-authorization processor 120 identifies the secondary authorization processor 110 designated as the next available source of funds by the source of funds manager 1 18.
  • the multi-authorization processor 120 then sends a secondary billing request 128 to the second authorization processor 1 10, either directly or indirectly via a billing transaction router 106, which indicates the remaining expense claim liability.
  • the second authorization processor 1 10 processes the secondary billing request 128 and returns a secondary billing response 130 in a standard format to the multi-authorization processor 120.
  • the multi-authorization processor 120 Based on the response from the second authorization processor 110, if there is remaining expense claim liability, the multi-authorization processor 120 identifies the next preferred funding source from the source of funds manager 1 18 and sends a level N billing request 132 to the level N authorization processor 112, which then processes the request in a manner analogous to that described above for the first and second authorization processors 108, 1 10.
  • the level N authorization processor 1 12 then returns a level N billing response 134 in standard format to the multi-authorization processor 120.
  • the multi-authorization processor 120 Upon receiving the level N billing response 134, the multi-authorization processor 120 confirms that no additional funding sources are available (or applicable) to satisfy any remaining expense claim liability. The multi-authorization processor 120 consolidates all of the authorized amounts and creates a consolidated billing response 1 16 that indicates the total amount payable (sum of the N number of authorization processor cycles and their respective authorized amounts), as well as the net/final remaining liability. The consolidated billing response 1 16 is then returned to the initial entity that submitted the single authorization request 100. The multi -authorization process 104 stores and relates all of the authorization request/response transactions performed while completing the single authorization request 100 and manages that information through the Multi -Authorization Transaction Manager 122.
  • FIG. 2 depicts an illustrative embodiment of the invention as used in the healthcare industry for a prescription drug purchase at a pharmacy.
  • a purchaser of prescription medication may have a primary and a secondary prescription drug plan (PDP) that entitles the purchaser (in this case an individual covered under a health care plan) to a discounted purchase price and/or insured benefits.
  • PDP prescription drug plan
  • the purchaser may also have a preferred credit card account that he or she wishes to use to pay any remaining purchase liability after the primary and secondary insurance plans have been applied.
  • a multi-authorization processing system 204 consolidates and keeps track of the purchaser ' s preferred funding sources via a source of funds manager 218, which allows the purchaser to identify and maintain any and/or all sources of funds that may be used to fulfill the purchase liability associated with various types of expense claims.
  • the pharmacy initiates a prescription billing request 200 that may be sent to a multi- authorization processor 220 via a standard format 201 that may include, but is not limited to, a variety of healthcare claim types.
  • a standard format 201 may include, but is not limited to, a variety of healthcare claim types.
  • such purchaser claim types may include, but are not limited to, vision claims, general medical claims, and any other expense claims that might involve authorizations against multiple funding sources.
  • the prescription billing request 200 may be sent directly to the multi-authorization processor 220, or routed to the multi-authorization processor 220 via a pharmacy request transaction router 214.
  • the multi-authorization processor 220 processes the prescription billing request 200 against the purchaser's sources of funds that are applicable for prescription billing, as documented in the source of funds manager 218.
  • the source of funds manager 218 may contain the purchaser's primary and secondary PDP information, which may include, but is not limited to, cardholder identification #, cardholder plan type, transaction routing information, co-payment amount, etc. Additionally, the source of funds manager 218 may contain information about the purchaser's preferred funding sources, which may include, but are not limited to, cash, debit/credit cards, checking/savings accounts, retirement accounts, and/or lines of credit.
  • the source of funds manager 218 may order this information, effectively creating a funding source sequence for the processing of each prescription billing request related to that purchaser.
  • similar information may be stored and managed within the source of funds manager 218 for various other expense claim types (for example vision claims, general medical claims, and any other expense claims that might involve authorizations against multiple funding sources).
  • the multi-authorization processor 220 receives the pharmacy billing request 200, it compares the purchaser on the billing request 200 with the source of funds manager 218 and determines the purchaser's available sources of funds and the respective processing order of each source. The multi -authorization processor 220 then transfers a primary prescription billing request 224 to the PDP Authorization Processor 208 identified by the source of funds manager 1 18. This transfer may occur either directly, or via the pharmacy billing transaction router 206. The PDP authorization processor 208 processes the request and returns a primary prescription billing response 226 in the NCPDP Rx Billing Response standard format to the multi-authorization processor 220.
  • the multi-authorization processor 220 Upon receipt of the primary prescription billing response 226, if there is remaining expense claim liability, the multi-authorization processor 220 identifies the secondary PDP from the source of funds manager 218 that represents the next available source of funds, and forms a secondary prescription billing request 228 indicating the remaining purchase liability and the result of the primary PDP's authorization (as indicated in the NCPDP Rx Billing Request transaction standard) to be sent to the secondary PDP authorization processor 210 for processing, either directly or via the pharmacy billing transaction router 206. Based on the secondary prescription billing response 230 received from the secondary PDP authorization processor 210, if there is remaining expense claim liability, then multi-authorization processor 220 identifies the preferred credit card from the source of funds manager 218 as the next source of funds.
  • the multi-authorization processor 220 forms a credit card authorization request 232 in the credit card association standard indicating the remaining expense claim liability amount as the authorization request amount to be sent to the credit card issuer processor 212 for processing, either directly or via a credit card association network (not shown).
  • the multi-authorization process 220 Upon receiving the credit card billing response 234 from the credit card issuer processor 212, the multi-authorization process 220 confirms no additional funding accounts are available (or applicable) to satisfy any remaining amount.
  • the multi-authorization processor 220 consolidates all of the authorized amounts and creates a consolidated prescription billing response 202, indicating the total amount payable (sum of the N number of authorization processor cycles and their respective authorized amounts), as well as the net/final remaining liability.
  • the multi-authorization processor 220 then transmits the consolidated prescription billing response 202 in the NCPDP Rx Billing Response standard format.
  • Multi-authorization processing 204 stores and relates all of the authorization request/response transactions performed while completing the pharmacy prescription billing request 200 and manages that information through the multi-authorization transaction manager 222.
  • FIG. 3 is a process flow diagram describing a multi-authorization processing method according to an illustrative embodiment of the invention.
  • the system receives an authorization request from a submitter 300 and determines from the source of funds manager (SOFM) whether or not there there is a level 1 authorization processor record 302 If there is not a level 1 record, the system triggers an error 304 and informs the submitter of the response failure. If there is a level 1 record, the system routes the authorization response to the identified level 1 authorization processor 306 and waits for a response.
  • SOFM source of funds manager
  • the system When the system receives the level 1 authorization processor response 308, it queries whether or not the response was approved 310. If the response was not approved, the system queries whether or not there was a critical error 312. If there was a critical error, the authorization response is returned to the submitter 314.
  • the system queries whether or not there was an unmet responsibility 316. If there was no unmet responsibility, the authorization response is returned to the submitter 314. If there was an unmet responsibility, the system then queries whether or not there is a level 2 authorization processor record 318. If there is not, then the authorization response is returned to the submitter 314.
  • the system builds a level 2 authorization request 320 and routes the authorization response to the identified level 2 authorization processor 322 and waits for a response.
  • the system When the system receives the level 2 authorization response 324, it recalculates the authorization totals and unmet responsibility 326. The system then queries whether or not there is any remaining unmet responsibility 328. If there is no remaining unmet responsibility, the system builds an authorization response for return to the submitter 352, and returns the response to the submitter 354. If there is remaining unmet responsibility, the system queries whether or not there is a level 3 authorization processor record. If there is not, the system builds an authorization response for return to the submitter 352, and returns the response to the submitter 354.
  • the system builds a level 3 authorization request 332 and sends it to the identified level 3 authorization processor 334 and waits for a response.
  • the system receives the level 3 authorization response 336, it recalculates the authorization totals and unmet responsibility 338. The system then queries whether or not there is any remaining unmet responsibility 340. If there is no remaining unmet responsibility, the system builds an authorization response for return to the submitter 352, and returns the response to the submitter 354. If there is remaining unmet responsibility, the system queries whether or not there is a level 4 authorization processor record. If it is not, the system builds an authorization response for return to the submitter 352, and returns the response to the submitter 354.
  • the system builds a level 4 authorization request 344 and sends it to the identified level 4 authorization processor 346 and waits for a response.
  • the system receives the level 4 authorization response 348, it recalculates the authorization totals and unmet responsibility 350.
  • the system then builds an authorization response for return to the submitter 352, and returns the response to the submitter 354.
  • Levels 1 - 4 depicts Levels 1 - 4, although fewer or additional levels may be associated with a purchaser via a source of funds manager.
  • level 1 may be a Medicare Part D plan administrator/processor
  • level 2 may be a supplemental pharmacy assistance plan administrator/processor
  • level 3 may be a flexible spending account administrator/processor
  • level 4 may be a credit card administrator/processor.
  • multi-authorization processing as described in the pharmacy billing example above, automates, consolidates, relates, and simultaneously processes all of the authorizations within the transaction by process standards recognized by pharmacies, PDPs, purchasers and other constituents in the pharmacy billing environment, while streamlining and reducing the resource investment required to complete those activities.
  • a consumer/purchaser may be a person or entity that agrees to pay for goods and/or services received from a merchant/seller.
  • a merchant/seller may be a person or entity that provides goods or services to a consumer/purchaser in exchange for an agreement to pay for those goods and services.
  • an authorization submitter may be the source of an authorization request. This may be, but is not limited to, the merchant/seller or a representative.
  • the transaction router may be an entity or network that moves transactions between submitter, multi-authorization processor, and authorization processor.
  • a transaction router may include, but is not limited to, clearinghouses, switches, card associations, trading partners, and/or intermediaries.
  • an authorization request may include a request transaction from a merchant/seller claiming purchaser liability for goods and/or service seeking processing by at least one authorization processor for an amount due.
  • an authorization request may include, but is not limited to, a major medical or preventive care insurance claim submission (e.g. HIPAA ANSI X12 837), a pharmacy prescription claim (e.g. NCPDP v5.1 Bl), retail debit /credit card authorization request (e.g. ISO 8583), and/or an automated clearing house (ACH) request (NACHA format)
  • a source of funds may include any financial account or benefit account/set associated with a consumer/purchaser, directly or indirectly, that may be utilized to fulfill all or part of an authorization request.
  • a level "N' authorization processor may be any entity that processes an authorization request against consumer's/purchaser's source(s) of funds to meet all or part of the consumer's/purchaser's responsibility based on the terms of the source of funds as established by the source of fund's issuer/sponsor and as managed by that processor.
  • Examples of might include (without limitation): a medical insurance plan sponsor or its third party administrator, health plan, pharmacy benefit manager, credit or debit card issuer or processor, a bank or any other entity that authorizes requests against a consumer's/purchaser's "source(s) of funds.”

Abstract

L'invention concerne un système de traitement multi-autorisation qui traite systématiquement des demandes d'autorisation de type spécifique par rapport à des sources de financement d'un acheteur afin d'optimiser les autorisations de financement et de consolider ces autorisations dans une réponse d'autorisation unique tout en minimisant la dette restante de l'acheteur. Une demande d'autorisation pour une note de frais est reçue et transmise à un processeur multi-autorisation. Les processeurs d'autorisation qui peuvent autoriser au moins une partie de la note de frais en se basant sur un type de demande d'autorisation sont identifiés et commandés. Une demande d'autorisation correctement formatée est transmise par le processeur multi-autorisation à un premier processeur d'autorisation en réponse à la commande. La demande et les transactions de réponse sont traitées avec un ou plusieurs processeurs d'autorisation suivants en séquence jusqu'à ce tous les processeurs d'autorisation suivants aient répondu ou que la dette restante soit nulle.
PCT/US2008/078525 2007-10-02 2008-10-02 Traitement multi-autorisation WO2009046157A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US97683807P 2007-10-02 2007-10-02
US60/976,838 2007-10-02

Publications (1)

Publication Number Publication Date
WO2009046157A1 true WO2009046157A1 (fr) 2009-04-09

Family

ID=40526657

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2008/078525 WO2009046157A1 (fr) 2007-10-02 2008-10-02 Traitement multi-autorisation

Country Status (1)

Country Link
WO (1) WO2009046157A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160260072A1 (en) * 2015-03-06 2016-09-08 Vantiv, Llc Technologies for enhanced credit transactions

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5500890A (en) * 1993-08-19 1996-03-19 Exxon Research And Engineering Company Point-of-sale system using multi-threaded transactions and interleaved file transfer
US20030212904A1 (en) * 2000-05-25 2003-11-13 Randle William M. Standardized transmission and exchange of data with security and non-repudiation functions
US20040210531A1 (en) * 2002-02-11 2004-10-21 Total System Services, Inc. System and method for single event authorization control of transactions

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5500890A (en) * 1993-08-19 1996-03-19 Exxon Research And Engineering Company Point-of-sale system using multi-threaded transactions and interleaved file transfer
US20030212904A1 (en) * 2000-05-25 2003-11-13 Randle William M. Standardized transmission and exchange of data with security and non-repudiation functions
US20040210531A1 (en) * 2002-02-11 2004-10-21 Total System Services, Inc. System and method for single event authorization control of transactions

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160260072A1 (en) * 2015-03-06 2016-09-08 Vantiv, Llc Technologies for enhanced credit transactions
US10304071B2 (en) * 2015-03-06 2019-05-28 Worldpay, Llc Technologies for enhanced credit transactions
US10891645B2 (en) 2015-03-06 2021-01-12 Worldpay, Llc Technologies for enhanced credit transactions
US11928701B2 (en) 2015-03-06 2024-03-12 Worldpay, Llc Technologies for enhanced credit transactions

Similar Documents

Publication Publication Date Title
US7905399B2 (en) Linking transaction cards with spending accounts
US20180315102A1 (en) Value processing network and methods
US8660862B2 (en) Determination of healthcare coverage using a payment account
US7922083B2 (en) Payment programs for healthcare plans
US7590557B2 (en) Healthcare card incentive program for multiple users
US7434729B2 (en) Healthcare card closed loop network
US7174302B2 (en) System and method for processing flexible spending account transactions
US7676409B1 (en) Method and system for emulating a private label over an open network
US20110087592A1 (en) Systems and methods for facilitating transactions
US8788281B1 (en) System and method for processing qualified healthcare account related financial transactions
US20100211493A9 (en) Incentive Programs For Healthcare Cards
US20060026041A1 (en) System and method for managing a prescription drug savings plan
US20070185799A1 (en) Spending Account Systems and Methods
US20070194108A1 (en) Assured Payments For Health Care Plans
US20050015280A1 (en) Health care eligibility verification and settlement systems and methods
US20070011088A1 (en) Assured Payments for Health Care Plans
US20070185800A1 (en) Spending Account Systems and Methods
US8515784B2 (en) Systems and methods of processing health care claims over a network
MX2008011027A (es) Tarjeta de bedito de salud vinculada a cuentas de financiamiento relacionadas y no relacionadas con salud.
US20100185461A1 (en) Method for controlling the purchase of health care products and services
US10963875B2 (en) Processing financial products
US20070185802A1 (en) Incentive Programs For Healthcare Cards
US20080183627A1 (en) Filtered healthcare payment card linked to tax-advantaged accounts
US20100070409A1 (en) Healthcare Card Incentive Program for Multiple Users
US20090006135A1 (en) Accelerated Payments for Health Care Plans

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 08836322

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 08836322

Country of ref document: EP

Kind code of ref document: A1